Business Solutions

How I Built a FinOps Cost Optimization Agent on Amazon Bedrock AgentCore to Cut a Company’s AWS Bill

Ido Vapner

Jul 12, 2026

6 min read

Table of contents

This is some text inside of a div block.

Share this post

The Business Challenge

A CIO at a large enterprise reached out with a problem I hear often. Their cloud costs were climbing, but they had no budget to hire a dedicated FinOps team or to pay for one of the expensive SaaS cost-management platforms on the market.

Their engineering, cloud operations, and SRE teams needed a simple way to understand where the money was going, spot optimization opportunities, and get clear recommendations, without anyone having to become a FinOps specialist first. The request was direct:

“Can we build an AI assistant that understands our cloud environment, answers questions about our costs in plain language, and tells us how to reduce spending whenever the teams need it?”

That question is what led me to build a Cost Optimization Agent on AWS: a conversational interface that lets any engineer ask about cloud spend, see where it is going, and get specific actions to bring it down.

What I Built

The agent answers questions like “Are my costs higher than usual this month?” or “How can I reduce my Lambda spend?” and replies with an analysis and concrete recommendations. It is a single-agent design built from a few clear parts:

Claude Sonnet, served through Amazon Bedrock: the model that interprets the question and reasons over the cost data it gets back.
Amazon Bedrock AgentCore Runtime: hosts the agent in production and runs its reasoning-and-tool-selection loop, with auto-scaling, session isolation, and monitoring handled for me.
Amazon Bedrock Guardrails: content filtering on both the user input and the model output that keeps conversations inside the FinOps scope, blocks prompt injection, and prevents sensitive data from leaking.
A set of cost-intelligence tools: each function calls an AWS cost or monitoring API: Cost Explorer, AWS Budgets, Amazon CloudWatch, and AWS Compute Optimizer.
A production front door and supporting services: Amazon API Gateway and Amazon Cognito for access, Amazon DynamoDB for conversation context, and Amazon SNS for proactive alerts.

I started from the AWS reference implementation in the awslabs agentcore-samples repository, which gave me the core agent and its cost tools. On top of that, InfrOS — a platform that turns requirements in any form (a simple brief, PRD, design doc, TF, HLD diagram etc.) into a priced, validated cloud design — worked out the production architecture around it, adding the pieces a real deployment needs:

The API Gateway and Cognito front door
DynamoDB session persistence
SNS alerting
Compute Optimizer as a rightsizing source

so the result is a production setup for the customer rather than the sample running as is. The architecture behind it was designed, priced, and validated with InfrOS: it scored the component options across the priority dimensions, priced each one across on-demand, reserved, and spot, then generated the IaC and emulated it in a sandbox, benchmarking the design against the requirements before any of it reached a real AWS account. What would otherwise take an architect weeks came back as a validated, deployable blueprint in a single session.

Architecture

The system runs in us-east-1 and is organized into three layers. The first is the user interaction layer: engineers type their questions into a lightweight web chat UI whose requests arrive through Amazon API Gateway, where Amazon Cognito authenticates the user, Amazon DynamoDB stores and retrieves the conversation context so sessions persist, and Amazon SNS delivers proactive alerts. The second is the agent core: AgentCore Runtime hosts the agent and runs its reasoning loop with the Claude Sonnet model. The third is the cost-intelligence tools, which read from AWS Cost Explorer, AWS Budgets, Amazon CloudWatch, and AWS Compute Optimizer. Rather than running in the organization's management (payer) account, which AWS recommends reserving for org-wide administration rather than for hosting workloads, the agent runs in a dedicated FinOps tooling account. That account is registered as the delegated administrator for AWS Compute Optimizer and is granted scoped, read-only access to organization-wide Cost Explorer data, so it still reads consolidated cost and rightsizing data across every linked account at the organization level without placing an internet-facing workload in the most sensitive account in the organization. AWS Budgets sits in the global scope rather than the Region, since budgets are account wide.

‍

Amazon Bedrock plays two distinct roles in the design, worth separating because the service name is the same in both. One role is Guardrails, filtering the conversation on the way in and on the way out; the other is the model endpoint that serves Claude Sonnet for the agent’s reasoning. Same service, two different jobs.

‍

The agent itself is inexpensive to run about $479 a month against the customer’s $1,500 budget. For a FinOps tool, the interesting detail is that roughly 86% of that ($412) is the Claude Sonnet inference, not the surrounding infrastructure. The model is the cost to watch, which is a point I come back to under future work.

Architecture Decisions

Each part of the design was a deliberate choice that InfrOS evaluated and scored against the priority profiles, and the trade-offs are worth spelling out. Here is the reasoning behind the main ones.

‍

Why AgentCore Runtime?

‍

The customer wanted a production agent, not a prototype, but had no appetite for managing the infrastructure under it. AgentCore Runtime handles auto-scaling, monitoring, and session isolation, and it deploys through the AgentCore starter toolkit, which provisions the runtime, the IAM execution role, and the container image for you. Session isolation matters when several engineers query cost data at once meaning each conversation stays separate. Using AgentCore Runtime, rather than the managed Agents for Amazon Bedrock feature, kept the agent code under our control while still getting managed hosting.

‍

Why Claude Sonnet?

‍

This agent leans on two things: understanding loosely worded cost questions in plain English, and reasoning over structured billing data to produce a clear recommendation with the trade-offs spelled out.

‍

Claude Sonnet is strong at both, and its reliability at choosing the right tool from the catalog kept the loop accurate. Serving it through Amazon Bedrock also kept the model inside the customer’s AWS account and security boundary, which was a requirement.

‍

‍So why Guardrails?

‍

A cost assistant should only ever talk about costs. Amazon Bedrock Guardrails enforce that topic boundary on both the user input and the model output, block prompt-injection attempts, and stop sensitive data such as access keys or PII from appearing in a response. Putting safety in a managed, declarative layer kept it separate from the agent logic and applied it consistently to every query.

How It Works

A request follows the same numbered path every time, shown end to end below.

AWS Cost Optimization Agent - Request Flow

An engineer submits a cost question through Amazon API Gateway.
Amazon Cognito authenticates the request.
DynamoDB stores or retrieves the conversation context, so a follow-up keeps its thread.
Bedrock Guardrails validate the query, dropping anything off-topic or unsafe.
The safe prompt is forwarded to AgentCore Runtime, where the agent reasons with the Claude Sonnet foundation model and decides which tools to call:
1. Rightsizing recommendations from AWS Compute Optimizer.
2. Cost forecasting from AWS Cost Explorer.
3. Anomaly detection from Amazon CloudWatch.
4. Budget monitoring from AWS Budgets.
When something needs attention, CloudWatch and Budgets dispatch alerts through Amazon SNS.
The synthesized answer is returned to the engineer.

The agent does not run a fixed script; the model chooses which tools to call based on the question and may call several before answering.

‍

The four cost tools map directly to AWS APIs:

Cost Anomaly Detection: unusual spending patterns and spikes, detected with Amazon CloudWatch anomaly detection over cost metrics published from Cost Explorer, with alerts dispatched over SNS.
Cost Forecasting and Trend Analysis: projected spend and historical trends from AWS Cost Explorer.
Service Cost Breakdown: spend by service, account, and resource, combining AWS Compute Optimizer rightsizing data with Cost Explorer to flag unused, underutilized, and oversized resources.
Budget Monitoring and Status: utilization and overrun forecasts from AWS Budgets, with alerts dispatched over SNS.

Infrastructure and Deployment

The agent deploys through the AgentCore starter toolkit, wrapped by the repository’s scripts. After cloning the reference repository and installing dependencies, there are three steps, test locally, deploy, then test the deployed agent against live cost data:


# Clone the AWS reference implementation
git clone https://github.com/awslabs/amazon-bedrock-agentcore-samples.git
cd amazon-bedrock-agentcore-samples/02-use-cases/cost-optimization-agent
pip install -r requirements.txt
 
# 1. Run the agent locally against six sample questions
python test_local.py
 
# 2. Provision AWS resources and deploy to AgentCore Runtime
python deploy.py
 
# 3. Exercise the deployed agent with live cost data
python test_agentcore_runtime.py

‍

The deploy step calls the starter toolkit, which builds the container image, creates the IAM execution role and ECR repository, and registers the runtime so the agent itself does not need a hand-written infrastructure module. The supporting resources around it (API Gateway, Cognito, DynamoDB, SNS, the Guardrail, and the budget) are defined in Terraform so they are version-controlled and repeatable. The Guardrail, for example, is a short block that also blocks prompt-injection attempts and stops AWS keys from ever appearing in a response:


resource "aws_bedrock_guardrail" "finops" {
  name                      = "finops-cost-agent"
  blocked_input_messaging   = "I can only help with AWS cost and FinOps questions."
  blocked_outputs_messaging = "That response was blocked by policy."
 
  topic_policy_config {
    topics_config {
      name       = "NonFinOps"
      type       = "DENY"
      definition = "Any request not related to AWS cost analysis or optimization."
    }
  }


  content_policy_config {
    filters_config { type = "PROMPT_ATTACK" input_strength = "HIGH" output_strength = "NONE" }
  }
 
  sensitive_information_policy_config {
    pii_entities_config { type = "AWS_ACCESS_KEY" action = "BLOCK" }
    pii_entities_config { type = "AWS_SECRET_KEY" action = "BLOCK" }
  }
}

‍

The Outcome

Before any production rollout, we ran the agent against the customer’s dev and test AWS environment three linked accounts with about $1,012 of spend over the previous 30 days (a window that straddled April and May) to see what it would find. This is the summary it returned:

In a single run it flagged a $115.38 anomaly (EKS extended support, billed April 19–26) and forecast May at $1,023.76, up 13.3% on the full April calendar month of about $904. The $1,012.38 headline is the trailing-30-day total, which runs higher than the April calendar month because that window also caught the EKS spike. Against that roughly $1,012 monthly run rate it identified $369 a month in savings: a 36.5% reduction worth about $4,428 a year.

‍

To be precise, that is spend the agent recommended cutting rather than money already removed, and on a roughly $1,000-a-month sandbox the $4,428-a-year figure is a proof of capability more than an ROI case: at $479 a month the agent would cost more to run than that. What mattered in the pilot was that it surfaced this much on a tiny environment in a single run, as a summary panel alongside its conversational answers. The ROI argument sits with the production rollout below, where the same engine runs against a far larger bill.

‍

On the strength of that pilot the customer moved the agent into production. Within the first few months, the changes the engineers acted on added up to roughly a 12% reduction in the monthly bill. A good part of that came from one early find: an oversized Amazon RDS instance that Compute Optimizer flagged for rightsizing, alongside a handful of EC2 instances the team had spun up for a project and left running for months after they stopped using them.

‍

The agent surfaced both in response to a plain question about where the months spend was going, the kind of thing that usually hides in a billing console until someone goes looking.

‍

Just as important was the change in who could ask cost questions and how fast. Engineers no longer waited on a central team or a paid dashboard; they asked in plain language and got an answer with a recommended action, so cost awareness happened during day to day work instead of in a monthly review. Against the production bill, the roughly $479-a-month agent cost a small fraction of the 12% it helped remove, and it met the original constraint of meaningful FinOps coverage without a dedicated team or a third-party platform, which was the whole reason the CIO called in the first place.

Further Improvements and Architecture Vision

The clearest piece of the architecture vision is memory. Today Amazon DynamoDB stores and retrieves the conversation context, which means I am managing session state, retrieval, and expiry myself. I plan to replace it with Amazon Bedrock AgentCore Memory, which provides short-term memory for the active session and long-term memory that persists across sessions as a native capability of the runtime already hosting the agent. That removes a hand-managed store and lets the platform handle what it is built for the same reasoning behind choosing AgentCore Runtime in the first place. DynamoDB would only stay if there were structured, non-conversational records worth keeping.

Conclusion

The Cost Optimization Agent took a request that usually ends in a hire or a software purchase and answered it with a small, focused build instead. Claude Sonnet through Amazon Bedrock supplies the reasoning, Bedrock Guardrails keep it safe and on topic, AgentCore Runtime hosts it and runs the tool loop, and a set of cost tools connect it to Cost Explorer, Budgets, CloudWatch, and Compute Optimizer with API Gateway, Cognito, DynamoDB, and SNS making it a real deployment. The pattern is reusable: give a model a clear set of narrow tools and a safe runtime, and you can put a useful assistant in front of a problem that used to need a whole team. And the build itself was just as lean: InfrOS turned what would have been weeks of architecture work into a single session, exploring and scoring the options and handing back a priced, validated, IaC-ready design.

Share this post

Keep on reading

Events

Most cloud teams are already using cloud automation. There's Terraform in one repo, Ansible playbooks in another and a CI pipeline ties them all together. The problem is that "infrastructure automation tools" cover such a diverse range of use cases that it’s hard comparing them directly. In this blog post we’ll review 9 such tools, that actual task each one solves, and the niche it occupies. InfrOS is our product hence we will list it first, but we made sure to be fair in reviewing the rest. And also, we'll be upfront about our view - most cloud teams have too many tools stitched together, and we believe fewer is better.

‍Key Takeaways

Infrastructure automation covers provisioning, configuration, orchestration and, more recently, architecture decisions.
Terraform, OpenTofu, Pulumi and CloudFormation build infrastructure. Spacelift and env0 are infrastructure orchestration tools that run and govern those builds.
Almost every tool starts after someone has already picked the architecture. InfrOS works on that earlier step.
Most teams juggle too many tools. The fewer tools you work with, the fewer handoffs where things break.

What Counts as Infrastructure Automation

Infrastructure automation, for the purposes of the list, refers to software that performs a step within the process of creating, configuring, or maintaining an infrastructure component in an automated way instead of a manual one. This includes IaC, configuration management, the process of running and approving changes, and policy enforcement. General CI/CD systems like GitHub Actions or Jenkins were excluded because they belong to a separate category - they could run Terraform, but wouldn't know what infrastructure is. The same is true about monitoring solutions that merely point at broken parts of an infrastructure but don't fix it.

Automating a Decision Is Not the Same as Automating Deployment

The vast majority of tools perform an action according to the plan - you decide which cloud, regions, database, networking design and redundancy level you need, and the tool implements it. This is good, but the tool doesn't care whether your design was right or wrong. If your architecture costs you twice as much as it needs to, or collapses after region failure, Terraform will build it anyway.

A subset of these tools actually creates the design. They consider your requirements, contrast various architectural options and highlight the trade-offs in terms of costs, performance, resilience, and compliance before any implementation takes place. This is important because an architecture design mistake can easily be corrected on the whiteboard but would be very costly once implemented. For more details check out this blog post about shift-left cloud infrastructure design.

The 9 Best Infrastructure Automation Tools

With that split in mind, here's each tool, what it automates, how it deploys and who it fits.

‍

1. InfrOS

InfrOS covers the entire cycle in one single package. It first helps to identify your infrastructure as well as requirements. This is followed by creation of different architectural options for you and analysis of them based on cost, performance, resiliency, and compliance. Before making any choice, it simulates the behavior of all options. Thus, you will be choosing based on facts rather than guesswork. Finally, after selecting one option, InfrOS helps to generate infrastructure as code and deploy the same. It will keep monitoring the live environment to inform you about better options whenever available. We call this Evolving Architecture™.

Recommended for: Cloud teams working in one or multiple clouds who seek a single solution for their design, validation, IaC and ongoing assessments.

‍

2. Terraform

Terraform remains the default choice for most teams, and deservedly so. Describe infrastructure in HCL files, execute the plan to see the changes to be done, and then apply those changes. With hundreds of providers, it can connect to pretty much any cloud or SaaS APIs. Nearly all Terraform automation done at scale happens either via HCP Terraform or a third party orchestrator which provides capabilities of remote executions and state management.

Best for: Pretty much any team that starts with IaC, especially in the context of multiple clouds.

Watch out for: HashiCorp put Terraform under Business Source License in 2023. HashiCorp got acquired by IBM recently. For most of us, nothing much changed, but for some companies, a fully open source option became preferable.

‍

3. OpenTofu

OpenTofu is the open-source fork of Terraform, created after that license change and now run under the Linux Foundation. Same HCL, same providers, very similar CLI, so moving over is usually a small job. It has also added features of its own, like built-in state encryption.

Best for: Teams that want the Terraform workflow with an open-source license and community governance.

Watch out for: The two projects are slowly drifting apart, so features don't always match.

‍

4. Pulumi

Pulumi allows for writing infrastructure using real programming languages such as TypeScript, Python, Go, C# and Java. This implies usage of loops, functions and unit testing instead of configuration language. It still operates through the desired state at its core meaning that you get to see the preview of each change before it is deployed.

Good for: Teams with a lot of developers willing to write code instead of learning HCL.

Keep in mind: With power comes increased ability to write messier infrastructures. Having a good system of code reviews in place is crucial.

‍

5. AWS CloudFormation

AWS CloudFormation is AWS’ own IaC solution. Using YAML or JSON templates AWS deploys and updates your infrastructure as a stack with rollback upon failure. Service itself is free but you have to pay for the resources it builds.

Good for: Teams which only use AWS and are interested in staying within their tooling ecosystem.

Keep in mind: It's AWS-only. The moment you start deploying your infrastructure to other clouds, you'll need another tool.

‍

6. Ansible

Ansible manages configurations of running servers. You craft playbooks using YAML format, and then Ansible connects via SSH to deploy packages, manage settings, and provision applications. There’s no agent involved, which makes the whole process straightforward.

Best for: Operations teams managing dozens of VMs, on-premise servers or networking devices. Usually used together with Terraform, where Terraform provisions and Ansible configures.

Be aware of: Ansible is not good with monitoring state of cloud resources, and therefore it’s not the best choice as a primary infrastructure provisioning solution.

‍

7. Spacelift

Spacelift is one of those infrastructure orchestrators that are sitting on top of your IaC. It allows running Terraform, OpenTofu, Pulumi, CloudFormation, Ansible, and Kubernetes workloads directly from your Git repositories. On top of it, it provides policies in code through Open Policy Agent, approvals, drift management and stack dependencies.

Best for: Platform teams with multiple stacks and multiple contributors that need some guardrails.

Be aware of: It’s one more platform to learn and use. Teams with only a few stacks probably don’t need it yet.

‍

8. env0

Similar in concept to Spacelift but focusing more on developer self-service and cost optimization, env0 allows platform teams to release approved templates for use by developers who build environments from those templates, with cost information added by env0 prior to deployment. If your concern is cloud governance, we've covered cloud governance tools for engineering teams before.

Best For: Organizations where developers should be able to spin up their own environments without giving them access to everything.

Beware: Like Spacelift, this is worth its weight in gold at scale.

‍

9. Crossplane

Crossplane is Kubernetes-as-a-control-plane for cloud infrastructure. Resources are defined as Kubernetes objects and managed through reconciliation (even when manual changes have been made), allowing platform teams to define APIs for themselves as a sort of wrapper, like a "database" object that handles all the cloud configuration under the hood.

Best For: Platform engineering teams who know their way around Kubernetes well.

Beware: This one's quite steep for those just starting with Kubernetes.

Tools Compared at a Glance

Here's how all nine line up on the same criteria.

Tool	What it automates	How you define it	Cloud scope	Model	Best for
InfrOS	Architecture design, validation, IaC generation, deployment, ongoing checks	Requirements and existing infrastructure	Single cloud, multi-cloud or hybrid	Commercial	Replacing a multi-tool stack with one loop
Terraform	Provisioning	HCL	Multi-cloud	Source-available (BSL)	General IaC
OpenTofu	Provisioning	HCL	Multi-cloud	Open source (MPL)	Open-source IaC
Pulumi	Provisioning	TypeScript, Python, Go, C#, Java	Multi-cloud	Open-source core	Developer-led teams
CloudFormation	Provisioning	YAML or JSON templates	AWS only	Free AWS service	AWS-only teams
Ansible	Configuration	YAML playbooks	Any server, any cloud	Open source	Server and app config
Spacelift	IaC orchestration and policy	Wraps your IaC	Multi-cloud	Commercial	Platform teams with many stacks
env0	IaC orchestration and self-service	Wraps your IaC	Multi-cloud	Commercial	Dev self-service and cost control
Crossplane	Provisioning through Kubernetes	Kubernetes resources	Multi-cloud	Open source (CNCF)	Kubernetes platform teams

Swipe sideways to see all columns.

A few things jump out. Four of these tools (Terraform, OpenTofu, Pulumi and CloudFormation) do basically the same job with different languages and licenses, so you only need one of them. Spacelift and env0 only make sense once you have one of those four. And InfrOS is the only one that covers the steps before, during and after provisioning. So the real question isn't which tool is best. It's how many tools you actually need.

How These Tools Fit Together in One Pipeline

Consider the traditional pipeline to have four tiers. The first one is the decision tier where you select the architecture. The second is the definition tier where the architecture gets converted into code using Terraform, OpenTofu, Pulumi, or CloudFormation. Then, there is the orchestration tier where Spacelift or env0 executes the code with policy enforcement and approvals, or Crossplane does the same within Kubernetes. Finally, there is the configuration tier where Ansible configures the servers and applications.

‍

And that means four tools, four vendors, and four handoffs – and every single handoff becomes another point of failure. Instead, InfrOS uses a different approach, encompassing the decision-making, the IaC itself, the validation process and the monitoring within one loop, making it possible for you to remove quite a few elements from the stack rather than keeping it all running. This is end-to-end cloud automation, spanning design and live operations. Looping is important here because the process does not stop at deployment. Workloads evolve, pricing changes, new requirements come up – and an architecture that was perfect last year may no longer work.

Keeping it in shape is an ongoing job, which our guide to cloud infrastructure optimization best practices covers.

FAQ

What is infrastructure automation?

It's the use of software for performing the tedious tasks of creating and managing the infrastructure. The tasks include coding of the infrastructure, provisioning of cloud resources, server configurations, approvals and policy enforcement. This aims at improving the speed, repeatability, and accuracy of change. More recent automation technologies extend the process of automation right from the stage of architectural designs to determine the best architecture options.

‍

What is the difference between automation and orchestration?

Automation is getting one task done without a person, like creating a database with a single Terraform apply. Orchestration is coordinating many automated tasks into one flow, in the right order and with the right checks. Think provisioning, then a policy check, then an approval, then configuration. Spacelift and env0 are infrastructure orchestration tools, while Terraform and Ansible are mostly automation. Once things grow, you usually need both.

‍

Do these tools replace Terraform?

Automation involves getting a single task completed without human intervention, such as building a database through a single apply in Terraform. On the other hand, orchestration involves managing all the automated tasks together as part of one workflow, in order and with the proper checks. For example, provision, policy check, approval, and configuration. Env0 and Spacelift are examples of infrastructure orchestration tools, whereas Terraform and Ansible are more automation tools.

‍

Which infrastructure automation tools suit small teams?

Keep it simple. You typically need one infrastructure-as-code tool for a small group, such as Terraform, OpenTofu or Pulumi, that operates within the CI pipeline you’re already using. CloudFormation will do the job just fine if you're only working in the AWS environment. Orchestration platforms and Kubernetes tools like Crossplane are more likely to give you return value later down the line when you have many stacks.

‍

How do you measure the return on infrastructure automation?

Let's start from things that are quantifiable. Measure the time that is required to deploy a change, the number of deployments that failed, the amount of time spent handling manual tickets, and how frequently drift occurred. In case of architecture level automation solutions, let's not forget about comparing cloud costs to some kind of baseline and counting the number of designs that were avoided after the go live.

‍

Our post on a FinOps cost optimization agent shows one way to tie automation to real cost numbers.

About InfrOS

InfrOS assists cloud teams in choosing what to build, validating that decision prior to production, and adapting as needed going forward.

‍