# Find an AWS cost spike

Answer first: identify the service, resource family, owning tag or missing tag, and 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/query

```text
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

```bash
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

```text
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

AWS, Cost Explorer, EC2, RDS, NAT Gateway, Tags.

## 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.