[HN Gopher] Show HN: An MCP server for understanding AWS costs
___________________________________________________________________
Show HN: An MCP server for understanding AWS costs
Hey all - I work at Vantage, a FinOps platform. I know AI is peak
hype right now. But it has definitely changed some of our dev
workflows already. So we wanted to find a way to let our customers
experiment with how they can use AI to make their cloud cost
management work more productive. The MCP Server acts as a
connector between LLMs (right now only Claude, Cursor support it
but ChatGPT and Google Gemini coming soon) and your cost and usage
data on Vantage which supports 20+ cloud infra providers including
AWS, Datadog, Mongo, etc. (You have to have a Vantage account to
use it since it's using the Vantage API) Video demo:
https://www.youtube.com/watch?v=n0VP2NlUvRU Repo:
https://github.com/vantage-sh/vantage-mcp-server It's really
impressive how capable the latest-gen models are with an MCP server
and an API. So far we have found it useful for: Ad-Hoc questions:
"What's our non-prod cloud spend per engineer if we have 25
engineers" Action plans: "Find unallocated spend and look for
clues how it should be tagged" Multi-tool workflows: "Find recent
cost spikes that look like they could have come from eng changes
and look for GitHub PR's merged around the same time" (using it in
combination with the GitHub MCP) Thought I'd share, let me know if
you have questions.
Author : StratusBen
Score : 106 points
Date : 2025-04-25 14:43 UTC (5 days ago)
| cat-whisperer wrote:
| This is going to different, as resources end up getting
| intertwined? or is there a way to standardize it?
| andrenotgiant wrote:
| What's the difference between connecting an LLM to the data
| through Vantage vs directly to the AWS cost and usage API's?
| StratusBen wrote:
| A few things.
|
| The biggest is giving the LLM context. On Vantage we have a
| primitive called a "Cost Report" that you can think of as being
| a set of filters. So you can create a cost report for a
| particular environment (production vs staging) or by service
| (front-end service vs back-end service). When you ask questions
| to the LLM, it will take the context into account versus just
| looking at all of the raw usage in your account.
|
| Most of our customers will create these filters, define
| reports, and organize them into folders and the LLM takes that
| context into account which can be helpful for asking questions.
|
| Lastly, we support more providers beyond AWS so if you wanted
| to merge in other associated costs like Datadog, Temporal,
| Clickhouse, etc.
| mdaniel wrote:
| How does this work? https://github.com/vantage-sh/vantage-mcp-
| server?tab=License...
|
| That is extra weird when thinking about the audience who might be
| Vantage.sh users (and thus have the ability to create the read-
| only token mentioned elsewhere) but would almost certainly be
| using it from their workstation, in a _commercial_ context.
| Sounds like you 're trying to keep someone from selling your MCP
| toy and decided to be cute with the licensing text
| bluck wrote:
| I'm just trying to understand licenses, but doesn't the choice
| of MIT contradict the inital "non-commercial purposes" as MIT
| says 'including without limitation the rights to use, copy,
| modify, merge, publish, distribute, sublicense, and/or sell
| copies of the Software' - Therefore, the non-commercial
| purposes is actually void and I can use the software to the
| limits of MIT defines? And because it is already MIT, they can
| relicense only future software but not this piece anymore?
| skwashd wrote:
| IANAL but that is my understanding. I created an issue to get
| some clarification - https://github.com/vantage-sh/vantage-
| mcp-server/issues/31
| skwashd wrote:
| The issue was initially closed with the following comment:
|
| > Hey Dave, it is as it is stated. The MCP is published
| with dual licenses depending on your intent. >
| https://fossa.com/blog/dual-licensing-models-explained/
|
| After further discussion on the ticket the license is now
| just MIT.
| ddingus wrote:
| You have a couple problems that I can see:
|
| One is the MIT license does not prohibit selling. And
| wrapping it in a "for non-commercial uses" clause creates a
| contradiction difficult, if not impossible to enforce.
| globalise83 wrote:
| So if I want to use the software I just have to create a fork
| on my home machine for non-commercial purposes, update the
| license to MIT only, and then the fork is mine to do with as I
| want commercially? What's even the point of this license?
| ponywombat wrote:
| AWS have also made their own cost analysis MCP server
| https://github.com/awslabs/mcp/tree/main/src/cost-analysis-m...
| neuroelectron wrote:
| What a great solution. They can leverage this to avoid
| liability for their own price quotes and solutions while
| simultaneously adding another layer of vender lock-in.
| _synergy_
| cowsandmilk wrote:
| How does this avoid liability for anything?
| mcintyre1994 wrote:
| I don't think anyone's really stated this outright, but
| large companies must believe they're not liable for
| anything their models/AI products are producing. That must
| be the case for their business model to work.
| neuroelectron wrote:
| A better question is how can they be held liable at all.
| _pdp_ wrote:
| On a related note, I'm not sure when it became "ok" to leave
| production credentials scattered across your system in
| configuration files. So many MCP server examples encourage this
| pattern, and inevitably, it's going to cause trouble at some
| point.
| Game_Ender wrote:
| What is your preferred way to manage them?
| ivanvanderbyl wrote:
| 1Password's CLI op does a reasonably good job of this
| devenjarvis wrote:
| The 1pass CLI is great! However if you aren't using 1password
| as your secrets vault, I'm building an open source, vault-
| agnostic alternative called RunSecret
| (https://github.com/runsecret/rsec)
| mdaniel wrote:
| You may want to do your own Show HN about it, so folks
| don't have to be "MCP curious" to find out that it exists
|
| That said, given https://github.com/runsecret/rsec#aws-
| secrets-manager presumably in order to keep _AWS_
| credentials off disk one would then have to have this?
| "vantage-mcp-server": { "command":
| "/opt/homebrew/bin/aws-vault", "args": [
| "exec", "--region=us-east-1", "my-awesome-profile",
| "--", "/opt/homebrew/bin/rsec", "run", "--",
| "/opt/homebrew/bin/vantage-mcp-server" ],
| "env": {"VANTAGE_BEARER_TOKEN":
| "rsec://012345678912/sm.aws/VantageBearerToken?region=us-
| east-1"} }
|
| in contrast to the op binary that is just one level of
| indirection, since they already handshake with the desktop
| app for $(op login) purposes
| devenjarvis wrote:
| This is great feedback, thank you!
|
| I agree RunSecret adds a level of indirection at this
| stage that op doesn't (if you are using 1pass). This is
| something I plan to polish up once more vaults are
| supported. You've given me some ideas on how to do that
| here.
|
| And thanks for the advice on doing a Show HN, planning to
| do so once a few more rough edges are smoothed out.
| nel-vantage wrote:
| Vantage engineer who worked on this feature here. The
| security posture of MCP servers is still in its early stages
| (see "The 'S' in MCP Stands for Security" from three weeks
| ago [https://elenacross7.medium.com/%EF%B8%8F-the-s-in-mcp-
| stands...]). The recommendations above to use something like
| the 1Password CLI wrapper when invoking an MCP server seem
| sound.
|
| That being said, an easier-to-distribute user experience
| would be to leverage short-lived OAuth tokens that LLM
| clients such as Claude or Goose ultimately manage for the
| user. We're exploring these avenues as we develop the server.
| klooney wrote:
| If your service is running in AWS, use the native IAM
| identity loading from ECS, EKS, EC2, etc. If it's your
| laptop, set AWS_PROFILE and let the SDK load the temporary
| creds from ~/.aws.
|
| If you really really really need to use static creds on your
| laptop, use aws-vault to export them, or ephemeral creds
| generated from them, into your environment.
| salynchnew wrote:
| This is dangrous, as I've long held that inscrutible cloud
| billing was one of the greatest protections we had against a
| runaway superintelligent AI.
|
| Now we only have poor IAM UX to fall back on.
|
| /s
___________________________________________________________________
(page generated 2025-04-30 23:02 UTC)