Cloud Spend Limits Compared: Google Caps One Listed Service per Project, AWS Pauses a Whole Project in a Gradual Rollout, Azure Ties Limit to Credit

Overview

Google Cloud, AWS and Azure each document a spending limit that stops usage once a threshold is reached, and the pages and reports cited here describe three different things being stopped. Google Cloud’s blog, in a post dated October 31, 2026, announced that spend caps on Cloud Billing Budgets are generally available, and InfoQ reported on November 10 that they let customers “pause new usage of a service in a project once a monthly budget is reached, without deleting resources.” AWS announced a project-level spend limit on September 16 as part of a new sign-up experience that it says it is gradually rolling out to new customers; its documentation says that when a project reaches its limit, “AWS pauses your project and stops all resources.” Microsoft’s page on the Azure spending limit says the limit “prevents spending over your credit amount.”

The comparison below is the Herald’s own reading of those documents. Of the three independent outlets cited, InfoQ and The Register largely relay vendor documentation and announcements, adding comparison and commentary, and TechCrunch reports on the wider demand for AI cost controls rather than on these three limits.

Background: from budget alerts to enforcement

Companies were pressing for cost controls before these features appeared. TechCrunch reported on June 5, 2026 that “Across the industry, companies are starting to balk at the price of AI.” It quoted J.R. Storment, executive director of the FinOps Foundation, as saying the conversation among companies had shifted from “go fast” to “we need guardrails, how do we control this?”, and Alexander Embiricos, OpenAI’s head of enterprise, as saying customers now ask “What token controls do you have?” TechCrunch also reported, citing Chris Reed, senior director of IT finance at Priceline, that the company had begun placing token limits on certain groups.

Google’s own framing is similar. Its July 29, 2026 post announcing the public preview said “Generative AI can make cloud costs difficult to predict” and that “While Google Cloud offers budget alerts, you need proactive guardrails that work out of the box.” Google’s documentation separates spend cap budgets from alerts-only budgets.

The dated sequence in the cited sources is: Google’s public-preview post on July 29; AWS’s announcement on September 16 (the post’s metadata gives 2026-09-16T10:50:14-07:00), which The Register reported on September 18 (published 05:52 UTC); Google’s general-availability post on October 31; and InfoQ’s report on November 10. Google, InfoQ and Microsoft print dates without a time zone, so those dates are used as printed; Microsoft’s page shows a last-updated date of 2026-04-29.

Current situation

Google Cloud: one service in one project

According to Google’s documentation, a spend cap is scoped to “a single Google Cloud project and a single eligible service within the specified project.” The page lists four eligible services: the Gemini API, Gemini Enterprise Agent Platform, Cloud Run and Cloud Run functions, and its FAQ says additional services will be included in subsequent releases. When a cap triggers, new usage of that service in that project is paused and in-flight requests are processed to completion, accruing charges. The page adds that caps “don’t pause any on-going, fixed usage associated with persistent resources (such as compute and storage services), which remain active and continue to accrue charges.” It also says enforcement “isn’t instant and any cost overages are billed as normal.”

The same documentation page says that for certain services the amount used for enforcement is based on estimated costs that exclude savings, while for the remaining services it is calculated from actual costs; the estimates use list prices and “don’t include savings and credits.” Alerts go to billing administrators and project owners at 50%, 80% and 100% of the budget, and the page says the alerts and recipients cannot be customised.

Google’s general-availability post says caps for AI services trigger “within minutes of usage using estimated, live costs,” and that a new caps API lets teams “instantly apply a spend cap whenever a developer spins up a new sandbox project.” Enforced caps now reset automatically at the start of the next month; the post says that previously the block stayed until someone lifted it in the console. It advises starting with “non-production environments.” InfoQ reports that three things changed between the July public preview and general availability (the API, live estimated costs for AI services and the monthly reset).

AWS: a pause on the whole project

AWS’s announcement says users can set a monthly spend limit on a project “starting at $20 per month,” that each project has its own limit, and that if spend reaches the limit “AWS pauses your project rather than accumulating charges.” The documentation says a Paid Plan is required, that the minimum is “the greater of $20 or a conservative estimate of your likely spend,” and that spend limits can be applied to up to 10 projects. The same page lists notifications when actual costs reach 50%, 75% and 90% of the limit, or when a project is on track to reach it within 10 days.

Three optional early controls described in AWS’s documentation act before the limit: about 7 days ahead new resources stop launching, about 5 days ahead idle resources are paused, and about 4 days ahead the highest-cost active resources are paused. At the limit, that page says, AWS “pauses your project and stops all resources. Your data is preserved,” but “If you take no action within 90 days of your project being paused, AWS permanently deletes your project data.”

The Register frames the spend limit as one part of a new getting-started experience, reports that users can apply a limit starting from $20 a month and that AWS will pause a project rather than let it exceed the budget, and says it understands AWS had been working on the experience for almost a year. Its account largely follows the AWS post.

Azure: a limit equal to the credit

Microsoft’s page says “All new customers who sign up for an Azure free account or subscription types that include credits over multiple months have the spending limit turned on by default.” On that page, the limit’s amount equals the credit and cannot be changed, though the limit can be removed, and custom spending limits are not available. It is not available for subscriptions with commitment plans or pay-as-you-go pricing. When the limit is exhausted, deployed services are disabled for the rest of the billing period; in the page’s example of a free account, virtual machines are stopped and de-allocated and storage account data is available as read-only. The page also says a spending limit does not prevent all charges, because some Azure Marketplace services are billed separately. InfoQ summarises the Azure limit as confined to free accounts and credit-based subscriptions.

Where the three differ (the Herald’s own comparison)

• Unit of enforcement. Google caps one service in one project. AWS pauses a project. Microsoft attaches its limit to subscriptions of the types that carry credit.
• What stops. On Google, new requests to the capped service stop while persistent resources keep running and accruing charges. On AWS, all of the project’s resources stop and the data is preserved until 90 days without action. On Azure, deployed services are disabled and, in the page’s free-account example, virtual machines are de-allocated.
• Who sets the amount. On Google, a user with the spend-cap permissions enters a target amount. On AWS, project owners manage the limit, AWS suggests a figure and the documentation sets a floor. Microsoft’s amount is fixed to the credit.
• Default status. Of the pages cited here, only Microsoft’s describes a limit as turned on by default. The Google pages describe configuring a cap, and the AWS pages describe setting a limit.
• Programmability. Google’s post describes a caps API for lifting, updating or deleting caps. The AWS and Microsoft pages cited here describe steps in AWS Settings and the Azure portal and do not mention an API for managing the limit.
• Alert thresholds. Google lists 50%, 80% and 100%; AWS lists 50%, 75% and 90% plus an on-track warning; Microsoft’s page mentions email notifications when the limit is reached.

Implications

Each of the three providers’ pages cited here addresses the risk of stopping workloads, in different words. Google advises applying caps first to “non-production environments.” AWS says its limits are “designed for experimentation, learning, and sandbox workloads” and “can be used for production environments when it is acceptable to have a brief pause of your resources.” Microsoft’s page lists “You have services that you don’t want disrupted” among the reasons to remove the limit.

A second issue is what a cap leaves uncovered. InfoQ writes that because Compute Engine, Cloud Storage and networking are not eligible, the Google cap “addresses a runaway model or agent loop and not a forgotten GPU instance.” AWS’s documentation differs in this respect: its optional idle-resource control currently covers EC2, RDS and SageMaker endpoints, and the limit itself stops the project’s resources. InfoQ also reports a Hacker News commenter who called the result of Google’s design “very crude, not granular like the rich IAM system.”

InfoQ reports that developer Simon Willison argued in October that pay-by-usage services should default to hard caps, and that “most businesses and individuals would prefer errors to a surprise $10,000+ bill.” Against that position, the three providers’ pages differ: of the pages cited here, only Microsoft’s describes a default-on limit, and it covers credit-based subscriptions rather than pay-as-you-go ones. AWS describes its limit as part of an experience still rolling out to new customers.

Reading across the three, a limit set in one provider does not translate into the same behaviour in another. A figure entered on Google blocks one service in one project, a figure entered on AWS pauses everything in a project, and Azure’s amount is fixed to the credit. Teams that run agents or sandboxes on more than one provider therefore have different failure modes to plan for. That is the Herald’s inference from the documentation, not a finding reported by the cited outlets.

What the cited sources do not say

None of the cited sources reports a test of how closely enforcement tracks actual spend, or the size of any overage. None of them gives a count of customers who have the new AWS experience or have set a Google spend cap. The Microsoft page cited here does not mention AI services.