AWS project spending limits pause runaway bills but delete data after 90 days

AWS has added project-level spending limits to its simplified builder experience, announced September 16, and one condition in the documentation deserves attention from anyone letting AI agents provision cloud resources: once a project is paused for exceeding its cap, AWS permanently deletes the project's data if no action is taken within 90 days. According to a dev.to writeup that walks through the AWS documentation, the limit is positioned as an automatic stopping point for unattended experiments — exactly the kind of workload a coding agent can spin up and leave running.

A cap with a floor

Per the documentation, the limit applies to a project's monthly pre-tax charges and excludes credits. The feature is being released to a limited number of customers, and creating a limit requires a paid plan; project owners set the value while anyone with project access can view it.

The minimum permitted limit is the greater of $20 or AWS's own conservative estimate of likely spend, computed from month-to-date activity, currently running resources and the prior month's usage. That means a cluttered environment pushes the floor up, and AWS advises stopping resources first if you want a lower number. Notifications arrive at 50%, 75% and 90% of the limit, or when the forecast says it will be reached within ten days. At the limit itself, AWS pauses the project and stops its resources.

The dev.to piece frames the feature against a wider argument about defaults. On October 3, Simon Willison argued that usage-priced services should ship with hard budget caps enabled by default, describing the familiar failure mode where a budget alert lands overnight and spending continues until a human intervenes. Coding agents sharpen the problem: a successful deployment says nothing about how much the resulting application is permitted to spend, and the account owner inherits that question. Willison's proposal would make unlimited spending an explicit choice rather than a default.

Controls that bite before the cap

Three optional controls act on forecast spending before the hard limit is reached. Blocking new resource creation takes effect roughly seven days ahead; existing resources keep running, but new launches — including autoscaling additions — fail. Pausing idle resources comes about five days ahead, with idle defined per service; a SageMaker endpoint with zero invocations over the previous 14 days qualifies. Pausing top cost drivers, about four days ahead, is explicitly disruptive and can target EC2, RDS, Lambda, Bedrock and SageMaker. The dev.to author recommends documenting which controls are enabled, which services they can affect and who receives the notifications, since a vague sense that a budget exists is not an operational plan.

The deletion clock

The reassuring half of the documentation says a paused project keeps its data. Recovery runs through raising the limit in AWS Settings, and some resources may need manual restarts afterwards. The catch follows: 90 days of inaction after the pause means permanent deletion of the project's data. The clock starts at the pause, not at the instant the cap is hit, and it is not a blanket policy for every inactive account — but it ties a spending control to a data-retention deadline. The suggested setup pairs a human who owns the notifications with a restart checklist and a backup stored outside the paused environment, reachable without it, since a copy inside the same environment can inherit the same problem.

Google's narrower version

Google announced comparable controls in July, in public preview, scoped to a single service within a single project: Gemini API, Agent Platform, Cloud Run and Cloud Run Functions. Google says its AI-service caps take effect within minutes of crossing the threshold, that the restriction preserves data and resources, and that services outside the cap's scope are unaffected.

Why it matters

Hard caps convert a billing risk into an availability risk, and AWS's variant adds a data-loss deadline on top. An agent-deployed sandbox that trips its limit now carries a 90-day timer that one missed email can turn into permanent deletion, while the pre-cap controls can quietly degrade autoscaling in anything resembling production. Anyone pointing autonomous agents at a cloud account should isolate them in a capped project, decide in advance whether an error response beats a surprise invoice, and treat a paused project as an incident with an owner — not a quiet resting state.