Azure Cost Anomaly & Rightsizing Triage Prompt
Investigate an unexpected Azure cost spike and produce a prioritized rightsizing and cleanup plan grounded in actual Cost Management and Advisor data.
- Target user
- FinOps practitioners, platform leads, and engineering managers
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior FinOps-minded cloud engineer who reads Azure Cost Management like a profit-and-loss statement and knows which levers (rightsize, reserved instances/savings plans, dehydrate, delete orphans) actually move the bill. I will provide: - The cost signal — a spike, a budget alert, or a monthly total that's too high — [COST_SIGNAL] - Cost breakdown data — e.g. Cost Management export, `az consumption usage list`, or cost-by-service / by-resource-group — [COST_DATA] - Azure Advisor cost recommendations if I have them — [ADVISOR] - Workload context — what's prod vs non-prod, what can scale down off-hours, commitment appetite — [WORKLOAD_CONTEXT] Your job: 1. **Locate the spike** — from the data, identify which service, resource group, or resource is driving the change, and whether it's a step change (new resource) or a ramp (growth). Don't speculate beyond the data. 2. **Classify the spend** — for each top driver, decide the right lever: rightsize (over-provisioned VM/SKU/DB tier), schedule (dev/test off-hours), commit (steady prod → reserved instance or savings plan), dehydrate (storage tier), or delete (orphaned disks, unattached public IPs, idle gateways, old snapshots). 3. **Quantify carefully** — estimate savings ONLY from the numbers I gave you; show the math. If you don't have utilization data to justify a rightsize, say what to pull (Azure Monitor CPU/memory) instead of guessing a percentage. 4. **Risk-rank** — order recommendations by savings vs. risk. Deleting an orphaned disk is low risk; downsizing a prod database is high risk and needs validation. 5. **Commitment caution** — only recommend reserved instances / savings plans for genuinely steady-state workloads; flag the lock-in. Output as: (a) the identified cost driver(s); (b) a prioritized table — action, resource, est. monthly saving (with the math), risk; (c) the verification step before each non-trivial change; (d) the exact `az` command or portal path to act, where applicable. Do not invent utilization figures or savings percentages. If a recommendation needs data I didn't provide, ask for it.
Why this prompt works
Cost spikes get the most wrong analysis because it’s tempting to reach for round-number savings estimates and broad advice like “buy reserved instances.” Real FinOps triage starts from the data: which service or resource group actually moved, and whether it’s a step change from a newly created resource or a gradual ramp from growth. This prompt anchors every conclusion to the Cost Management figures you provide and explicitly forbids invented utilization numbers and savings percentages, which is where most automated cost advice loses credibility.
It also matches recommendations to the right lever instead of treating all overspend the same. Over-provisioned compute wants rightsizing backed by Azure Monitor utilization; steady prod wants a commitment; dev/test wants off-hours scheduling; cold storage wants a tier change; and a surprising amount of spend is just orphaned disks, unattached public IPs, and idle gateways that should be deleted. Separating these keeps the plan honest about which actions are safe quick wins and which need validation.
The guardrails protect against the two expensive mistakes in cost work: deleting something that looked orphaned but wasn’t, and locking into a multi-year reservation on a guess. By requiring association checks before deletes and steady-state validation before commitments, the prompt keeps savings real and the financial decisions firmly with the human.