AWS Cost Optimization and Anomaly Triage Prompt
Triage a cost spike or rightsize a bill using Cost Explorer, CUR, and utilization data, then sequence Savings Plans, rightsizing, and cleanup with confidence.
- Target user
- FinOps, platform, and engineering leads controlling AWS spend
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior FinOps engineer. You attribute cost before cutting it: you find which service, account, usage type, and dimension drives the spend, then sequence commitment, rightsizing, and cleanup so savings don't break workloads. I will provide: - Cost Explorer / CUR breakdown by service, usage type, and account: [COST_BREAKDOWN] - A spike or anomaly if any (when it started, which dimension moved): [ANOMALY] - Utilization data (CPU/memory, Compute Optimizer recommendations, RI/SP coverage and utilization): [UTILIZATION] - Constraints (workloads that must not change, commitment appetite): [CONSTRAINTS] Do the following, numbered: 1. Attribute the cost: rank the top drivers by service and usage type, and for any anomaly, isolate the dimension that moved (a usage type, an account, a region) and the likely cause (new deployment, NAT/data-transfer egress, untagged sprawl, idle resources). 2. For a spike specifically, check the usual suspects: cross-AZ or internet data-transfer charges, NAT Gateway processing, unattached EBS/EIP, idle load balancers, and storage class drift — these hide outside the obvious EC2 line. 3. Rightsize from evidence, not vibes: use Compute Optimizer and real CPU/memory to propose instance-family and size changes, and only for workloads not excluded by [CONSTRAINTS]. State the expected saving and the risk. 4. Sequence commitments correctly: rightsize FIRST so you don't buy a Savings Plan or RI for capacity you're about to shrink, then recommend a commitment level based on the stable baseline and current coverage/utilization gaps. Output as: (a) the ranked cost-driver table, (b) the anomaly root cause if any, (c) rightsizing recommendations with expected savings and risk, (d) a sequenced action plan (cleanup -> rightsize -> commit) with what to verify at each step. Recommend confirming utilization over a representative window before committing. Never recommend terminating or downsizing a resource without checking it's truly idle and tagged owner-confirmed; never buy a Savings Plan based on a pre-rightsizing baseline.
Why this prompt works
Cost work fails when people cut before they attribute. A bill is a sum of many dimensions — service, usage type, account, region — and the line that looks expensive is often not the line that grew. This prompt insists on ranking the real drivers and, for a spike, isolating the single dimension that moved before proposing any change. That attribution step is what separates a targeted fix from a panicked across-the-board cut that breaks a workload to save a few dollars.
The hidden-cost checklist matters because the biggest surprises rarely live in the obvious EC2 compute line. Cross-AZ and internet data-transfer charges, NAT Gateway processing fees, unattached EBS volumes and Elastic IPs, and idle load balancers all accumulate quietly and are frequently the true cause of an anomaly. By naming these explicitly, the prompt steers the model to look where the money actually leaks rather than where it is easiest to see.
The sequencing guardrail is the highest-stakes piece of FinOps advice here: rightsize before you commit. A Savings Plan or Reserved Instance is a one-to-three-year financial commitment, and buying one against a baseline you are about to shrink locks you into paying for capacity you will no longer use. By ordering the plan as cleanup, then rightsizing, then commitment — and by requiring owner-confirmed idleness and a representative utilization window before any termination — the prompt keeps a human firmly in control of decisions that are expensive to reverse.