The cloud bill has tripled in six months while traffic grew 40%. How do you find out why, and what do you expect to find?

What the interviewer is testing

Whether you approach cost with the same rigour as latency, and whether you know where cloud money actually goes.

How to find out

1. Get unit economics, not totals. Cost per request, per tenant, per transaction. Traffic grew 40% and cost grew 200%, so unit cost roughly doubled — that is the number to explain, and it reframes the problem from "spend too much" to "efficiency regressed".

2. Break the bill down by service and by tag, over time. The shape of the increase tells you a lot: a step change points at a deployment or a configuration change on a specific date; a smooth curve points at data growth; a sawtooth points at something scheduled.

3. Correlate the step changes with the deployment log. Most cost regressions are a change somebody made, and they are far easier to find by date than by inspection.

4. Check allocation coverage. If 40% of spend is untagged, the analysis is guesswork until that is fixed.

What you usually find

In rough order of frequency:

• Data transfer. Cross-AZ and cross-region traffic generated by an architectural change nobody costed — a service moved, a replica added, a chatty call path that now crosses a zone. Invisible on a diagram, substantial on a bill.
• Observability. Log and metric volume grows super-linearly with services and cardinality, and a debug-level log left on in production is a classic. Telemetry bills that rival compute bills are common and rarely anticipated.
• Storage that is never deleted. Snapshots, old backups, orphaned volumes from terminated instances, object storage with no lifecycle policy, log retention set to "forever" by default.
• Idle and oversized resources. Non-production environments running at nights and weekends, instances sized for a load test that ended, an autoscaler with a floor set too high.
• Managed service tier creep. Someone scaled a database up during an incident and it was never scaled back. This is extremely common.
• Expired commitments. Reserved instances or savings plans that lapsed, so the same compute moved silently to on-demand pricing at a large multiple.
• A retry loop or a runaway job — the one that produces a genuinely alarming single-week number.

The fix, and the fix after the fix

Immediate: rightsize, delete the orphans, set lifecycle policies, reduce log verbosity, renew commitments, schedule non-production shutdown.

Structural, and more important: cost allocation by tag enforced at provisioning, unit cost as a tracked metric with alerting on regression, and cost visible to the teams that generate it. The tripling happened because nobody saw it for six months; that is the defect to fix.

What a strong answer adds

Framing it as unit cost rather than total, and saying that spending more to serve more is fine — the objective is knowing the per-unit number and choosing deliberately, not minimising the bill.