Mr. Latte News


AWS and Google Cloud add spending caps that stop usage at the limit instead of just sending alerts

This English page is a machine translation of the Korean original, so some phrasing may read awkwardly.

The spending caps AWS introduced on September 16 and Google Cloud on July 28 do more than send alerts when you reach the limit. They stop usage.

Read the original at AWS What's New ↗

A cloud spending limit usually brings warning emails to mind. But the spending caps AWS and Google Cloud have introduced work differently. When you hit the limit, usage actually stops.

On September 16, AWS announced a new builder experience with monthly spending limits per project on its paid plan. When spending reaches the limit, the project is paused for the rest of the month. For now, it is available only to a limited group of customers.

It doesn't just shut down without warning, either. You can enable each of these actions separately: block new resource creation about 7 days before spending is expected to reach the limit, stop unused resources about 5 days before, and stop the most expensive resources about 4 days before. Alerts arrive at 50%, 75%, and 90% of the limit.

Google Cloud added Spend Caps to its budgets feature earlier, on July 28, in public preview. You can set a monthly cap for a specific service within a project. When the cap is reached, it blocks further billable usage of that service. Data and resources are not deleted, and someone must manually lift the restriction in the console.

Why is this coming up now? In an October 3 post, developer Simon Willison pointed out that coding agents have made it easier to run services that cost money. He argued that limits that only send warning emails are not enough, and proposed making usage stop at the limit by default.

Stopping isn't always the right answer. AWS's documentation says these limits were designed for experimentation and learning, though they can also be used in production environments where brief interruptions are acceptable. Whether downtime is worse than an unexpected bill depends on the service.

Still, if an agent can keep calling paid APIs while people sleep, I think it's safer to make that decision in advance.

There are other things to decide when setting a cap. Keeping experimental projects separate from production services can limit what gets shut down. If someone has to lift the restriction manually, as with Google Cloud, you also need to decide who will investigate the cause and decide whether to turn things back on.

Both features are still optional and must be enabled by the user. That is still some way from Willison's proposal to make them the default.

Sources

  1. AWS: New AWS experience helps builders get started and ship faster, September 16, 2026.
  2. AWS documentation: Create a spend limit in AWS Settings, accessed October 4, 2026.
  3. Google Cloud Blog: New early anomalies and spend caps on Google Cloud Budgets, July 28, 2026.
  4. Simon Willison: We're going to need default hard budget caps on pretty much everything, October 3, 2026.

A question to think about

If an agent calls paid APIs all night, what would you rather wake up to: a warning email or a service that has stopped running?

Get new posts by RSS

Add the feed address to your RSS reader to follow new posts.

Open feed ↗