"Why did the bill spike?" lands on ops, not finance. An LLM is genuinely good at turning cost-and-usage data into an attributed narrative — which service, which team, which change, since when — and genuinely bad at arithmetic and at resisting a plausible-sounding story.
Tier: Foundation · Hands-on time: ~35 minutes
This playbook produces a cost-anomaly explanation (and reusable monthly FinOps narratives) where every number and every attribution is re-verified against the billing console before anyone forwards it to leadership.
Skip AI when the anomaly is already obvious from one Cost Explorer group-by (a single new NAT gateway, an obvious data-transfer spike) — clicking two filters is faster than prompting.
Export a narrow, grouped dataset. From Cost Explorer (or CUR query), export daily costs for the anomaly window plus 2 weeks of baseline, grouped by service and by your team/app tag. Two small CSVs beat one giant one — LLMs mis-sum big tables.
Establish ground truth first. Before prompting, write down three numbers yourself: total spend for the window, the delta vs baseline, and the top line item. These are your canaries — if the AI's narrative contradicts them, the narrative is wrong.
Ask for an attributed narrative, not a guess. Paste the CSVs plus your change list:
You are helping explain a cloud cost anomaly. Attached: (a) daily cost by
service, (b) daily cost by team tag, (c) list of infra changes in the window.
Produce:
1. One-paragraph summary: what spiked, by how much, starting when.
2. Attribution table: each contributing line item, its delta vs baseline,
and the most likely cause FROM THE CHANGE LIST ONLY.
3. Anything you cannot attribute — list it as "unattributed", do not invent
a cause.
4. Every number must be computed from the attached data; show which rows
you used for each figure.
Do not use external knowledge of typical cloud pricing. If the data does
not support a claim, say so.
Verify every number against the console. Open Cost Explorer and re-check each figure in the attribution table with the corresponding filter. LLM addition errors of 5–20% are common on wide tables. Fix or annotate; anything you cannot reproduce gets deleted.
Verify every attribution against the change. For each "caused by" claim, open the actual PR/deploy/scaling event and confirm timing lines up (cost delta starts after the change, in the right account/region). Correlation offered by the model is a hypothesis, not a finding.
Produce the stakeholder version. Ask for a rewrite: one paragraph for leadership, one table for engineers, explicit "unattributed remainder: ₹X / $X, investigation owner: Y". Reuse the same prompt monthly for FinOps narratives by swapping the dataset — the structure is the recyclable asset.
The LLM writes the narrative; Cost Explorer stays the calculator. Any number you did not re-derive in the billing console does not go in the report.
For client cloud accounts under MSA restrictions (typical services-company setup):
ACCT_A, APP_1); keep the mapping local. Cost figures alone are usually still sensitive — when in doubt, normalize to percentages of baseline.A forwarded cost narrative with one wrong attribution can trigger a real budget decision — verification here protects money, not just accuracy.