Problem
AWS spend is up sharply this week and the team needs to know which resources, services, and changes explain it.
Use case
AWS cost spike investigation
A team sees an AWS bill spike and wants a resource-level explanation before resizing, deleting, or committing to savings actions.
This page is short on purpose: problem, app query, required context, sample output, and safety boundary before the CTA.
Use Clanker Cloud when the question is not only what got expensive, but which resource, tag, route, deploy, or scaling event explains it.
Concrete workflow
Problem, query, context, output, and safety boundary
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
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.
Buyer query
A team sees an AWS bill spike and wants a resource-level explanation before resizing, deleting, or committing to savings actions.
Read-only first
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.
Proof artifact
The workflow below includes the app query, local context required, example output, supported providers, and next step.
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.
Related proof
Read the supporting pages
Full example workflow
Open the longer proof page with the same app-first workflow pattern.
Local credentials
Read what stays local, what can go to model providers, and how read-only/maker/apply differ.
Example library
Browse all proof workflows for cost, security, Kubernetes, MCP, and review-before-apply.
FAQ
Common questions
Does this use case require write access first?
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.
Why is this separate from the example page?
The use-case page answers the high-intent buyer query directly. The example page is the deeper proof artifact with the same concrete workflow format.
Next step
Run the read-first workflow
Download the desktop app, connect the existing local context, and start with inspection before reviewed plans.