> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.
# AWS Cost Analyzer
> Scans a connected AWS account for waste across six use cases and reports findings ranked by estimated monthly impact, each with its evidence.
Deploy this agent to find cost waste in an AWS account and get it back ranked by what it is actually
worth fixing. You choose which analyses to run; it reports findings with the evidence and a concrete
remediation step for each. This page covers the six use cases, what the account needs enabled
first, and where it stops.
## What it does
You name the use cases you want run, with any scoping — regions, tag keys, thresholds. It scans the
connected account and returns findings ranked by estimated monthly cost impact, each carrying the
evidence behind the estimate and a specific step to act on.
| Use case | What it finds |
| --------------------------- | -------------------------------------------------------------- |
| Idle resources | Provisioned capacity that is not doing work |
| Service and tag cost trends | Where spend is moving, broken down by service or tag |
| Tagging gaps | Spend that cannot be attributed because tags are missing |
| Cross-AZ network cost | Traffic crossing availability zones, and what is causing it |
| Reserved-instance coverage | Committed-use gaps against actual steady-state usage |
| Savings toggles | Opt-in savings settings that are available but not switched on |
It runs only the use cases you name. A prompt that names none gets the list back rather than a full
scan — deliberately, because a blind scan of every use case across every region is the slowest
possible way to start.
## The preflight
Every run, regardless of which use cases you chose, first checks whether the account's opt-in cost
and data features are enabled — Cost Explorer, Cost and Usage Reports, VPC Flow Logs, Cost Anomaly
Detection, Budgets and Compute Optimizer.
This is not optional, and it is worth reading before the findings. Several use cases are blocked or
degraded without those features, and a thin result is much more often a disabled feature than a
clean account.
## What it reads
Read-only, across the services the analysis needs: Cost Explorer, CloudWatch, S3, EC2, EBS, RDS,
ELB, EKS and the tagging APIs.
## Before you deploy
| Requirement | Detail | Where to set it up |
| ------------ | ------------------------------------------------------ | ------------------------------------------------------------------------ |
| Model access | The managed model gateway, or your own Claude API key | [Credentials & secrets](/manage-your-agents/build/credentials-secrets) |
| AWS access | A connection, unless the pod supplies its own identity | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |
The AWS connection offers the same two authentication modes as the AWS investigator, and which you
see depends on where the agent runs:
| Mode | How it works | Offered for |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ------------- |
| Cross-account IAM role | Komodor assumes a read-only role in your account per run, from a CloudFormation stack you deploy. No long-lived keys are stored. | Komodor cloud |
| IRSA | The pod inherits AWS access from its Kubernetes ServiceAccount's IAM role. | Self-hosted |
## Ask it for
In chat, or as a run's prompt:
```text theme={null}
Run the idle-resources and cross-AZ network analyses against eu-west-1 and
us-east-1. Ignore anything under $50/month. Show me the evidence behind each
estimate.
```
## Defaults and limits
| | |
| ----------- | --------------------------------------- |
| Catalog ID | `aws-cost-analyzer` |
| Model | `claude-sonnet-5` |
| Time budget | 1800 seconds, which is also its ceiling |
| Deployment | Komodor cloud or self-hosted |
| Chat | Yes |
This agent's budget starts at its maximum rather than below it. A real multi-region account needs
the full window for even one use case, so there is nothing to gain by asking for more — scope the
run by naming fewer use cases or fewer regions instead.
## In a workflow
It is a scheduled analysis rather than an incident specialist: give it a trigger, point it at one
account, and let the findings accumulate where someone reviews them. Where you run it across several
accounts, deploy one per account so each run's findings carry an unambiguous owner.
See [Triggers & schedules](/manage-your-agents/build/triggers-schedules) and [Cloud
optimization](/modules-and-workflows/cost-optimization/cloud-optimization).
## What it will not do
It finds waste; it never acts on it. There is no mutating tool in its surface, so it cannot stop an
instance, delete a volume, change a tag or buy a reservation. Every finding is a recommendation for
someone else to carry out.
It is also bounded by the preflight: where an opt-in feature is disabled, the analyses that depend
on it are degraded or unavailable, and it reports that rather than estimating around the gap.
## Next steps
The module that turns these findings into tracked work.
Run the analysis on a schedule.
The same account, read for incidents rather than waste.
Every catalog agent, side by side.
## Related topics
- [AWS Infrastructure Investigator](/manage-your-agents/build/catalog/aws-investigator.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Cloud Cost](/modules-and-workflows/cost-optimization/cloud-optimization.md)
- [Kubernetes Cost](/modules-and-workflows/cost-optimization/k8s-cost.md)
- [Overview](/get-started/overview.md)