Skip to main content
Example workflow

Find an AWS cost spike

Use this workflow when the AWS bill jumps and a dashboard says what increased, but not why it increased or what changed around it.

Clanker Cloud ties cost signals to live resources, tags, provider state, and change context before suggesting a reviewed optimization plan.

Answer first: identify the service, the resource family, the owning tag or missing tag, and the operational event that made spend move.

Problem

AWS spend is up sharply this week and the team needs to know which resources, services, and changes explain it.

App workflow or query

Copy the app query below, then adjust context names, profiles, namespaces, and provider scopes for your environment.

Safety boundary

The app reads Cost Explorer and resource metadata through the local runtime. It does not resize, delete, or purchase commitments. Any optimization that changes infrastructure should be generated as a plan and explicitly approved.

Next step

Run a reviewed savings plan: add missing tags, route high-volume traffic through cheaper paths, right-size idle resources, or schedule shutdowns for non-production workloads.

Proof artifact

Problem, app query, context, output, and safety

Problem

AWS spend is up sharply this week and the team needs to know which resources, services, and changes explain it.

App workflow/query
Clanker Cloud app:
1. Open Cost Explorer.
2. Choose AWS profile prod and the week since Monday.
3. Ask:
Explain the AWS spend spike since Monday. Tie it to services, resource identifiers, tags, regions, and recent deploy or scaling signals.
Open-source CLI equivalent
clanker cost detail --provider aws --profile prod --top 20
clanker cost anomalies --provider aws --profile prod

# Same investigation prompt in the Clanker Cloud app:
Explain the AWS spend spike since Monday. Tie it to services, resource identifiers, tags, regions, and recent deploy or scaling signals.
Input context

Clanker Cloud app connected to AWS profile prod, date window for the spike, expected baseline spend, known deploy window, required tags such as Environment, Owner, and Project.

Output example
Finding: spend increased by about $247/month equivalent. The largest movement is NAT Gateway data processing in us-east-1 after checkout-api moved image pulls through private subnets. Second contributor is an idle db.r6g.large read replica tagged Environment=staging but attached to no active app. Suggested next step: inspect egress path and generate a reviewed plan for VPC endpoint coverage or image pull routing before deleting anything.
Safety boundary

The app reads Cost Explorer and resource metadata through the local runtime. It does not resize, delete, or purchase commitments. Any optimization that changes infrastructure should be generated as a plan and explicitly approved.

Supported providers
AWSCost ExplorerEC2RDSNAT GatewayTags
Next step

Run a reviewed savings plan: add missing tags, route high-volume traffic through cheaper paths, right-size idle resources, or schedule shutdowns for non-production workloads.

FAQ

Common questions

Does this workflow change infrastructure?

The app reads Cost Explorer and resource metadata through the local runtime. It does not resize, delete, or purchase commitments. Any optimization that changes infrastructure should be generated as a plan and explicitly approved.

Can the same pattern run from the open-source CLI?

Yes. The examples lead with the Clanker Cloud app because that is the product workflow. The public Clanker CLI powers the local runtime and remains the equivalent path for terminals, automation, and MCP clients.

Next step

Want the full example library?

Browse the proof-oriented examples for Kubernetes, cost, Cloudflare, MCP, and review-before-apply workflows.