"Even when looking at the AWS invoice left by the previous vendor we took over from, no one can explain why this amount goes out every month"—this is recently the most frequent consultation we receive from clients whose maintenance we took on through custom development. The monthly bill is substantial. Yet, which services and what usage patterns are driving it? What caused it to rise compared to last month? No one inside the company can answer these questions immediately. Opening Cost Explorer merely presents bar charts broken down by service, without telling you "so, what should be done to lower it?"
Ultimately, cost analysis becomes personalized around "a handful of people familiar with AWS pricing models." If those individuals cannot spare the time, monthly cost reviews are skipped, leaving high bills neglected. The more an engagement involves taking over from a predecessor, the more resources with unclear architectural intent remain, compounding the issue.
A tool has emerged that appears poised to tackle this "inability to explain cost drivers" head-on: AWS FinOps Agent, which began public preview on June 18, 2026. In this article, we analyze from a practical systems operations perspective how this agent can transform cost management in custom maintenance, as well as architectural considerations and pitfalls when integrating it into practical custom development workflows.
An agent answering "why costs increased last month" in natural language
FinOps Agent is an AI agent specialized in cost management built on Amazon Bedrock. Its defining feature is that engineers can ask questions about costs in natural language and receive answers grounded in actual cost and usage data.
For instance, asking "Why did AWS costs increase last month?" triggers a flow that detects cost shifts, identifies contributing services, and digs into the underlying usage drivers to provide an answer. It is designed to replace investigations that previously required pricing experts to manually switch services in Cost Explorer, compare timeframes, reconcile usage metrics, and so forth, with a single prompt.
Its capabilities extend beyond answering cost queries. According to AWS announcements, it can primarily perform the following:
| Features | Details |
|---|---|
| Answering cost queries | Identifies cost shifts, contributing services, and usage drivers to answer natural language questions |
| Presenting optimization opportunities | Retrieves and presents recommendations from Cost Optimization Hub and Compute Optimizer |
| Automated cost anomaly investigation | Detects unexpected cost increases and automatically investigates root causes |
| Periodic FinOps workflows | Schedules and executes daily, weekly, and monthly cost reports |
Reports can be generated and downloaded in HTML, PDF, or PPT formats, and optimization recommendations can be aggregated into Jira tickets so engineering teams can act using their everyday tooling. During the preview period, usage of the agent itself is free of charge, incurring only standard fees for underlying AWS APIs invoked behind the scenes.
However, clear limitations exist at this stage. Available regions during preview are limited to US East (N. Virginia). As it remains a public preview, scope and response accuracy are not guaranteed to be production-grade. When using it in custom development, this must be communicated transparently to clients as a baseline premise.
The true value is "eliminating dependency on specialized individuals for cost analysis"
Viewing FinOps Agent merely as a "tool where AI lowers costs for you" will likely misalign expectations. The value I see in the context of custom maintenance lies elsewhere: eliminating dependency on specialized individuals for cost analysis.
The true nature of the "inability to explain" problem mentioned at the beginning is not high AWS costs per se, but that the people capable of tracking cost drivers are limited, and their manual investigations are burdensome. Consequently, monthly cost reviews fall by the wayside. Introducing an agent that can drill into root causes in natural language allows maintenance engineers to trace why costs increased for a given project last month with a single question, without needing to be specialized AWS pricing experts.
In short, its value lies in enabling monthly cost reviews—previously skipped because they were persona-dependent and tedious—to operate as standard practice in custom maintenance. If establishing a workflow that periodically generates reports for clients is achieved, the very state of "bills staying high without explanation" naturally moves toward resolution. Moving away from relying on goodwill and sheer determination for cost investigations and embedding them into systems is directly connected to balancing AI costs against labor expenses when making investment decisions.
One distinction to clarify here is that this is about AWS infrastructure costs. This is a different layer from "AI budget governance" aimed at preventing LLM API usage from overrunning budgets; confusing the two will lead to the wrong countermeasures. Architectural approaches to capping LLM spending and preventing runaway costs are discussed in Custom Development Implementing AI Cost Budget Governance with Cloudflare AI Gateway (GH Media), which can be read in tandem to understand the layered distinction. FinOps Agent looks at infrastructure bills such as EC2, RDS, and data transfer, so designing around managing both separately is the safest approach.
How to integrate it into custom maintenance
In our custom maintenance practice, when adopting new AWS tooling, we never stop at "just getting it running"; we always design three aspects: permissions, operations, and decision-making. FinOps Agent is no exception.
Design permissions around least privilege and read-only access
The first item to solidify is the permissions granted to the agent. FinOps Agent reads cost and usage data and retrieves recommendations. Granting overly broad permissions here turns a tool intended for cost analysis into an expanded attack surface for the environment. Establish clear boundaries from the outset: restrict access strictly to what is required for referencing cost data and optimization recommendations, granting no write access to configuration changes or billing settings.
Particularly in inherited projects, IAM configurations left behind by predecessor vendors are often disorganized, frequently leaving it ambiguous who has access to what. Granting permissions to an agent presents an ideal opportunity to re-evaluate the entire setup under least privilege principles. The conceptual framework for IAM governance when granting AI agents access to AWS resources is specifically organized in Agent Access with IAM Governance via AWS MCP Server (GH Media), which serves as a solid foundation for accelerating permission design implementation.
Schedule reports and integrate them into client-facing operations
Next, incorporate daily, weekly, and monthly report generation into schedules so they serve as material for monthly reviews. The value of custom maintenance lies not in one-off investigations, but in continuously delivering monthly cost status in a format clients can digest. Because outputs can be generated as PDFs or PPTs, explaining "this service behaved this way this month" to non-technical IT teams or executive leadership becomes straightforward. Transforming persona-dependent investigations into reproducible monthly operational workflows is essential; without designing this, adopting the agent will simply revert back to "skipped monthly reviews."
Do not take optimization proposals at face value; cross-check them against business requirements
The aspect requiring the greatest care is handling optimization proposals. FinOps Agent surfaces recommendations from Cost Optimization Hub and Compute Optimizer, such as "this instance can be downsized" or "costs will decrease by purchasing Reserved Instances." Applying these blindly just "because the AI said so" is dangerous.
For example, in a custom maintenance engagement for an enterprise system in manufacturing (company name withheld), a proposal indicated that downsizing a specific instance per recommendations would indeed lower monthly costs. However, that environment ran batch processes where load spiked sharply during only the first few days of each month; downsizing based purely on regular usage rates risked creating bottlenecks at month-start. Because optimization proposals are generated from average usage patterns, business-specific peaks and SLAs may not be factored in. Treat recommendations as candidates, cross-checking and filtering them against business and availability requirements. Humans must retain this decision-making authority and document the rationale for why proposals were adopted or rejected.
The same applies to purchasing commitments like Reserved Instances or Savings Plans; without cross-checking them against project lifecycles and planned configuration changes, efforts to reduce costs become restrictive commitments that end up backfiring financially. A specific case study examining trade-offs between database cost and performance in AWS custom development is also covered in Modernizing Databases in Custom Development with Aurora Serverless v4 (GH Media), which serves as a helpful reference for balancing cost and availability.
Common pitfalls to avoid
First, degrading availability by applying optimization proposals as-is. As noted earlier, cost reduction recommendations stem from usage statistics, overlooking business-specific peaks and intentional redundancy designs. Applying them solely focusing on "costs going down" can lead to paying a far steeper price in the form of outages.
Second, granting overly broad permissions. Having a tool introduced for cost visualization violate least privilege undermines the entire premise. Keep it read-focused and strictly confined to what is necessary and sufficient.
Third, getting derailed by anomaly detection noise. Automated cost anomaly investigations are convenient, but if anticipated seasonal fluctuations or campaign-driven spikes are flagged as "anomalies," response efforts become hollow routines. Plan on investing effort during the initial months to tune what qualifies as an anomaly and isolate fluctuations that can be safely ignored.
Above all, remember that it is in the preview stage. Supported regions are limited, and response accuracy remains evolving. If introducing it in custom development, the honest approach with clients is not promising "this solves everything," but rather "we are using it, limitations included, as a first step toward eliminating dependency on specialized individuals for cost analysis."
Where to begin first
An inherited AWS environment with unexplainable costs quietly bleeds money month after month if left unattended. FinOps Agent is a tool that allows tracking the causes of those leaks without relying on specialized individuals. However, whether it delivers results depends entirely on human-engineered foundations: permission design, operationalized reporting, and selective evaluation of proposals.
To get started, we recommend first taking inventory of current monthly costs to identify where "unexplained, neglected expenditures" reside. Following that, designing read permissions and establishing scheduled reporting operations will bring you closer to clearly explaining "why the bill is this amount" starting from the next monthly review.
If you are struggling with unseen costs in an inherited AWS environment or wish to establish monthly cost reviews as standard custom operations, please reach out via our inquiry form. After reviewing your current AWS architecture and billing, we will work together to construct an operational design for cost visualization and optimization.
Sources
- AWS FinOps Agent is now generally available in public preview (AWS Official Blog)
- Custom Development Implementing AI Cost Budget Governance with Cloudflare AI Gateway (GH Media)
- Agent Access with IAM Governance via AWS MCP Server (GH Media)
- Modernizing Databases in Custom Development with Aurora Serverless v4 (GH Media)
