What Actually Stops Cloud Spend: The Hard-Cap Inventory for AWS, GCP and Azure

Usually it does one of three things. It sends an email. It sends an email and applies a policy that blocks some subset of new actions. Or it is a credit balance on a non-production account and it genuinely stops everything, which is why the person who set it thinks caps work.

The useful question is not whether cloud spending limits exist. They do. The useful question is much narrower, and once you ask it in the narrow form the answer across all three providers comes out the same way: none of the three documents an account-wide, customer-chosen, dollar-denominated hard stop on pay-as-you-go usage. What they document instead is service-scoped, inconsistently denominated, and in several cases described by the vendor itself as leaky.

That is not a conspiracy. It is an architectural consequence of billing telemetry arriving after the resource has already run, and both AWS and Google Cloud say so on the page where they describe the control.

To be the thing finance thinks it bought, a control has to clear every one of these:

Read the rest of this with those four in hand. Most controls score two or three. Nothing in this post scores four, and the reason is always the same one: the controls that genuinely stop something are scoped to a single service, which fails the first condition before you get to the other three.

Start with the thing everybody has already turned on. AWS Budgets tracks cost and usage against a threshold you set and notifies you. That is the default posture, and the default posture does not stop anything.

Take that seriously as an operational number rather than a footnote. A runaway launched at 02:00 against a budget refreshed at 04:00 and again at 14:00 is a runaway you learn about on the second refresh at the earliest. Nothing in the alerting path shortens that, because the lag is in the billing pipeline and not in the alarm.

To be precise about what Budgets is and is not: AWS describes Budgets as a way to track and take action, and its own examples include automatically applying a custom IAM deny policy at a threshold. So the correct statement is not that Budgets does not stop spend. Budgets notifications do not stop spend. Enforcement is a separate thing called Budget Actions, and it does not exist until you configure it.

What Budget Actions can actually do

Three action types, and the list is short enough to memorise:

Cite that list from Configuring a budget action rather than from the Budget Actions overview. The overview frames the same three as actions that are available to you, which reads like a sample. The configuration page presents them as the set you choose from, which is what you need if you are going to tell finance the list is closed.

From a management account you can apply an SCP to another account, but you cannot target EC2 or RDS instances in another account.

That is the documented action list. AWS documents no account-wide halt among them, and the shape of the list tells you why the ones that exist do not add up to one. An IAM or SCP deny is a permissions control, so it blocks the creation of new things while leaving everything already running exactly as expensive as it was a minute ago. Stopping instances is a compute control, so it touches EC2 and RDS and nothing else. Neither one touches the categories that generate spend without anybody creating a resource: data transfer, request charges, storage that keeps existing, managed-service consumption already in flight.

Assume a mature estate with ten action-enabled budgets in a 30-day month: eight chargeable budgets at $0.10 per day is $24 for the month. That is a rounding error against most cloud bills, and it is also the reason a lot of estates have forty alert-only budgets and two enforcing ones. The free path and the safe path are not the same path.

Google Cloud does not ship a spend cap you switch on. It ships a tutorial for building one, and the tutorial states the consequences clearly enough that most of this section is just its own warnings.

The architecture: a Cloud Billing budget scoped to a single project publishes programmatic notifications to a Pub/Sub topic. A function subscribed to that topic compares the reported cost against the budget amount, and if cost has exceeded budget it calls updateProjectBillingInfo with the billing account name set to an empty string. That unlinks the project from its billing account, which shuts down the project.

Note the two words that do the work: project and shuts down. This is not a subscription-wide dollar cap. It is a project-scoped kill switch, and its granularity is binary. There is no setting between running and detached.

One detail worth having in front of you before your first deploy: the Python sample ships with a simulation flag set to true, with a developer note to flip it off only after validating against a test budget. The Node.js sample has no such guard and disables billing on the spot. If someone on your team copied the Node sample into a production project and wired it to a real budget, the first genuine threshold crossing is also the first live test.

That flag is the tell. The vendor shipping the sample built a safety catch into it because the sample is dangerous, and the safety catch means the thing you deployed may not do anything at all. Check which sample you are running and which state that flag is in. Both failure modes are real and they point in opposite directions.

This citation is also the one on the fastest drift in this post. The documentation host moved to docs.cloud.google.com and the function runtime already moved onto Cloud Run. Pin your access date and re-read the limitations section before you rely on any of it.

Azure is the only one of the three with a built-in, default-on subscription spending limit, and the honest version of that sentence has a second half.

From Microsoft's Azure spending limit doc: the limit is on by default for the Azure free account and for subscription types that include credits across multiple months. When usage exhausts it, the services you deployed are disabled for the rest of the billing period. Where the subscription includes credits across multiple months, it re-enables automatically at the start of the next billing period.

Now the constraints, all from the same page.

On what breaking looks like: the page's illustration is the free account, where exhausting the included credit removes deployed resources from production, stops and deallocates virtual machines, and leaves storage account data readable but not writable. It repeats the deallocation warning in its guidance on why you might want to remove the limit, along with a note that settings such as virtual IP addresses are lost when resources are deallocated. Treat that as the shape of the outage, and treat the specific behaviour on your own subscription type as something to confirm rather than assume.

The subscription-type question is delegated. The spending-limit page points to Azure's offer details page for the authoritative per-offer availability list, and that is where you check your own offer number rather than reasoning from the free-account example.

The built-in limit is not the whole Azure story, and stopping there would leave a false asymmetry in place: AWS gets Budget Actions, Google Cloud gets a disable-billing pipeline, and Azure appears to offer nothing you can configure on the subscriptions that matter. It does. Microsoft documents the analogue in a tutorial called Azure billing and cost management budget scenario, and it is the closest thing Azure has to enforcement on a subscription with no built-in limit available.

The pipeline: a Cost Management budget scoped to the subscription notifies an Azure Monitor action group, the action group triggers a Logic App, and the Logic App parses the threshold amount out of the notification payload and calls one of two webhooks on an Azure Automation runbook imported from the gallery. At the 80 percent threshold the webhook carries a resource group name, so it stops the virtual machines in that one group. At 100 percent the second webhook carries no parameters and stops all remaining virtual machines in the subscription. The tutorial creates the budget itself through the Consumption REST API.

Score that against the four conditions and it lands almost exactly where AWS Budget Actions land. Customer-chosen and dollar-denominated, yes. Account-wide, no: what it stops is virtual machines, so storage, databases, egress and every managed service go on billing at the same rate they did a minute earlier. Enforcing, only in the sense that stopping compute reduces future spend rather than capping the period. And it inherits the latency of whatever fires it, because the trigger is a budget notification with the same reporting lag as everything else in this post.

Two practical notes before anybody builds from that page. The whole thing is four Azure resources deep, an Automation account, a runbook, a Logic App and an action group, all of which you then own, patch and pay for. And its setup step still walks you through creating an Automation Run As account, so check that against your current Automation account guidance rather than following it literally.

Here is where the sweeping version of this argument falls apart, and it is worth being precise because the sweeping version is what most write-ups on this topic publish. Customer-set enforcing limits do exist. They all fail the same condition, the first one, because every one of them is scoped to a single service. Where they differ is which of the other three they also miss.

Treat what follows as the set worth knowing rather than a closed list. One of these shipped in November 2025 and another lives on a page almost nobody opens, which is the practical reason not to publish a count and then have to defend it.

Credit walls are hard stops. Pay-as-you-go gets alerts.

The clean way to see the boundary is to compare the two account postures side by side, because both AWS and Azure enforce hard on credits and alert soft on pay-as-you-go.

Since the July 2025 Free Tier change, AWS accounts choose between a free account plan and a paid account plan at sign-up. As of August 2026, new customers receive USD 100 in credits on sign-up regardless of plan, and can earn up to another USD 100 by completing activities, for up to USD 200 total. The free account plan runs for up to six months and AWS documents that you will not incur charges during that period until you upgrade to a paid plan. The plan ends after six months or when credits are fully used, whichever comes first. Free account plans also exclude access to services that could rapidly deplete the credits, and they convert automatically to paid if you do things like join AWS Organizations or set up a Control Tower landing zone.

Those credit figures and that duration are promotional, so treat them as the most perishable numbers in this post.

That is a genuine hard stop. It is also unavailable to you, because the mechanism is a credit balance running out rather than a limit you configured, and the enforcement AWS can offer on it is closing the account. Azure's built-in limit works the same way: the limit is the credit, and the credit is the limit. Where money is prepaid, the vendor can stop at zero because there is nothing to bill against. Where the payment method is a card with no ceiling of its own, the meter runs and the controls describe it.