The bill is not a brake
How production systems bound runaway cloud spend when the platform converts demand into capacity in milliseconds and the billing signal arrives hours to days later.
Reconstructs the spend-containment architecture from six published billing incidents (Milkie Way, Troy Hunt, the Netlify and empty-S3-bucket bills, Cara, the 2026 AWS estimates outage) and the platform mechanisms built in response at AWS, Google Cloud, Vercel, Netlify and Supabase. A reader leaves able to place every control on one of four planes by time-to-act, choose between caps, quotas and kill switches with the conditions that flip each choice, and test that a budget actually blocks.
The hard cap was not never-built: Google built it, removed it (2019-2023) because its coverage could not keep up with the platform, and reintroduced it in 2026 enforced on estimated rather than actual costs, conceding in the design that a cap wired to billing data cannot work because the bill is structurally hours to days late.
What you get out of it
- Billing data lags the meter by 8 hours to days on every major cloud (AWS Budgets: 3x/day; Cost Explorer: 24h+; GCP alerts: up to a few days), so no control built on the bill can stop fast spend; every working brake runs on estimated cost in the request path.
- The scaling defaults are the de facto budget: Milkie Way's $72k night was max-instances 1000 times per-read pricing, against a $7 budget that constrained nothing.
- Accidental runaway and denial-of-wallet attacks share one defence set (rate limits, concurrency caps, timeouts, loop breakers), so deploying it buys both; from the meter's side, virality and attack are the same signal.
- Platforms fix billing exposure only after public incidents, in a repeating arc: forgive the bill, then stop metering rejected traffic, then ship an estimate-based pause actuator (S3 2024, CloudFront 2024, Netlify 2024-25, Vercel 2023-24, GCP 2026).
- The alert plane is itself a failure domain: in July 2026 AWS's corrupted estimate pipeline fired customers' budget alarms and both budget and anomaly alerts were disabled platform-wide during mitigation, so automation consuming spend signals needs plausibility bounds.
Scope
Why this, now. Google shipped hard spend caps in July 2026, twenty years after they became the most-requested billing feature and three years after it removed the last ones, driven by AI-priced usage; the same month, AWS's estimated-billing pipeline showed customers trillion-dollar bills and its cost alarms were disabled platform-wide.
What it does not cover. Steady-state cost optimisation, rightsizing, commitment purchasing and cloud repatriation (covered by the 2026-08-30 owning-hardware guide), LLM token-cost optimisation, and FinOps organisational practice beyond enforcement.
Other field guides
When owning hardware wins, and when it owns you
Dropbox banked an SEC-audited $74.6M by leaving S3; 37signals cut its bill from $3.2M to $1.3M on the way to deleting its AWS account; and in the sam…
29 sources · 25 organisations · 3 postmortemsZone-local traffic and the cross-zone bill
Spreading across three availability zones is billed twice: in standing idle capacity, and at a cent per gigabyte for every crossing. This guide recon…
34 sources · 21 organisations · 4 postmortemsTen years of changing a runtime you are not allowed to break
A hosted runtime cannot ask its tenants to upgrade, so Cloudflare pins semantics to a date per deployment and releases the runtime every day. This gu…
24 sources · 5 organisations · 2 postmortems