AWS FinOps Agent Readiness: 12 Things to Fix Before You Turn It On

Quick answer

AWS FinOps Agent is a preview service, launched 9 June 2026, that answers cost questions in plain language, investigates Cost Anomaly Detection alerts using CloudTrail, and turns Cost Optimization Hub and Compute Optimizer recommendations into Jira tickets. It reads your existing AWS cost data, so it inherits every gap in it. Before you turn it on, fix twelve things: account scope, three service opt-ins, tags, cost categories, owner mapping, anomaly monitors, CloudTrail coverage, IAM, integrations and a validation set.

Everything below was checked against the AWS announcement, the FinOps Agent FAQ and the user guide on 9 October 2026. It is a preview, so details may change.

What is AWS FinOps Agent, and where does it stand today?

AWS describes it as a frontier agent, built on Amazon Bedrock, that continuously monitors costs, investigates anomalies and surfaces optimization opportunities. In practice it does five jobs:

• Event-triggered anomaly investigation. It listens for Cost Anomaly Detection events and writes a consolidated investigation to Jira or Slack.
• Natural-language cost questions over your cost and usage data.
• Recurring reports, daily, weekly or monthly, as HTML, PDF or PPT.
• Recommendations in one place, pulled from Cost Optimization Hub and Compute Optimizer and summarised into Jira tickets.
• Context files and memory, so it uses your owners, categories and rules.

Sources: AWS What’s New, FAQ, quotas.

One thing it does not do: AWS lists no CUR or Data Exports source. The agent works through Cost Explorer APIs, so if your FinOps reporting is built on CUR and FOCUS exports, expect the agent’s numbers to line up with Cost Explorer, not necessarily with your warehouse.

Which data sources must be switched on first?

AWS’s IAM setup guide is blunt: “IAM permissions alone are not enough for the cost optimization and cost anomaly investigation features.”

1. Choose the account scope. Per the FAQ, an agent in the management account can cover the whole organization; one in a member account covers only that account. Organization-wide chargeback needs the management account. That also means deciding who gets web app access to organization-wide cost data, because anyone with access sees the same context files.

2. Opt in to Compute Optimizer. Without opt-in, the agent cannot retrieve rightsizing or idle resource recommendations. Opt in at the organization level if you want member accounts covered.

3. Enable Cost Optimization Hub. It is opt-in, and the agent’s savings recommendations depend on it. If you buy Savings Plans or Reserved Instances centrally, set Cost Optimization Hub’s preferences (savings estimation mode, plus the commitment term and payment option you actually buy) or its savings estimates will assume three-year, all-upfront commitments by default where applicable. Our RI vs Savings Plans guide covers that decision.

4. Check Cost Explorer depth. The agent’s policy includes GetCostAndUsageWithResources, which only returns data if resource-level data is enabled in Cost Explorer settings, and only for the last 14 days. Turn it on if you want resource-level answers about recent spikes.

Is your allocation data good enough for an agent?

This is where most readiness gaps sit, and it is the same problem we describe in our cloud tagging strategy guide: an agent cannot attribute spend that your data does not attribute.

5. Activate cost allocation tags and backfill. Tags only appear in Cost Explorer once activated in Billing. AWS lets the management account backfill activation for up to 12 months, but only for resources that actually carried the tag at the time. Measure spend-weighted coverage, not resource count.

6. Define cost categories. The agent can read cost category definitions, and AWS suggests uploading a cost category definition as context so reports use your categories. If you do not have categories for teams, products or environments, define them first.

7. Write the account-to-team mapping. AWS calls this “the most useful context file to upload first.” It is a simple CSV of account ID, team, lead and email, and it lets the agent attribute spend and route Jira tickets to an owner. Files can be TXT, CSV, JSON, Markdown, HTML or YAML, up to 10 MB each and 100 MB per agent. AWS warns not to upload sensitive or personal information, since context files are visible to anyone with agent access, so use team aliases rather than personal emails where you can.

Will anomaly investigations find the real cause?

8. Create and tune Cost Anomaly Detection monitors. The agent only investigates anomalies your monitors produce, and AWS requires at least one. Too few monitors and real spikes are missed; thresholds too low and every investigation becomes noise in Slack. Tune monitors per linked account, cost category or tag before connecting automation. This is exactly what our budget and alert validation work tests.

9. Understand the CloudTrail window. The agent uses CloudTrail event history through LookupEvents. Event history is on by default and free, but it covers only the past 90 days of management events, in a single account and Region, with no organization-level aggregation and no data events. Run a test anomaly in a member account and check whether the investigation actually names the change, rather than assuming organization-wide root-cause coverage.

What should security sign off on?

10. Review IAM before you click auto-create. The wizard can create two roles (agent and operator) using AWS managed policies. The agent policy is read-heavy across Cost Explorer, Budgets, Compute Optimizer, EC2, RDS, Lambda, CloudWatch Logs queries and Organizations, and its write actions are limited to EventBridge rules the agent itself manages. AWS notes you can remove actions you do not need. Users also need a separate web app policy, and the trust policy uses sts:SetSourceIdentity so CloudTrail shows which user drove each agent action.

11. Plan Jira and Slack routing. Quotas are tight in preview: one Jira and one Slack integration per account, and two Jira and two Slack connections per agent. Decide which Jira space receives recommendations and which channel gets anomaly reports, and who triages them. Slack is delivery-only in preview, so people cannot ask the agent questions there.

How do you know the agent is right?

12. Build a validation set. Before anyone forwards an agent report to finance, ask it ten questions you already know the answers to: last month’s spend by team, top three services, Savings Plans coverage, one known anomaly. Cross-check each in Cost Explorer. AWS’s own web app policy includes optional Cost Explorer read access for exactly this kind of cross-validation. Repeat the set whenever AWS changes the preview, and keep a record, because GA may bring changes.

Where to start

If you only have a week, do items 2, 3, 7 and 8: the opt-ins, the owner mapping and anomaly monitors. That gets useful investigations and recommendations flowing. Then work on tags and cost categories, which take longer and pay off in every tool you use, not just this one. Our FinOps audit checklist scores the same foundations.

AWS spend is only part of the picture if your teams also call models directly. For LLM spend outside AWS, see our AI gateway cost control comparison and the Claude Code and Cursor budgeting guide.

If you want it done properly the first time, our fixed-scope FinOps Agent readiness sprint covers all twelve items: service opt-ins, tag and cost category fixes, the owner mapping, anomaly monitor tuning, an IAM review and a validation set your finance team can sign off on. It is delivered through our tagging and cost allocation QA service. Talk to us before you switch the agent on.