A spend limit that pauses the project — and can delete a fine-tuned model

As of 23 Sep 2026, the AWS Account Management reference still opens with a warning: spend limits are releasing to a limited number of customers, and your account might not have them. Where they exist, they are a project-level ceiling in AWS Settings (settings.aws.com → Billing → Cost by project). Hit the ceiling and AWS pauses the project. Ignore that pause for 90 days and AWS permanently deletes the project data.

AWS calls this a type of AWS Budgets. Treat that sentence as branding. The behavior is a kill switch with optional steps that run days earlier. It is not the SNS SMS monthly spend limit. It is not the alert you already configured in the Cost Explorer and Budgets guide.

Reproduce this — Copy control-choice-worksheet.csv and fill the last row before you click Set spend limit. The first three rows are decision rules from the AWS reference, not a customer bill.

What the limit actually does

The number you set is the most you will pay that month in pre-tax charges. Credits do not count toward it. The minimum AWS will accept is the greater of $20 or a conservative estimate of likely spend. That estimate uses month-to-date activity and what is running now. If last month was higher, last month becomes the floor. It is not “spend so far divided by days elapsed, times days in the month.” A project full of running instances will not accept a token cap until you stop those instances. Reactivating a paused project sets the floor to spend already incurred this month plus usage that was not charged.

You need a Paid Plan. Project owners manage the limit. Anyone with project access can see it. You can limit at most 10 projects. Other projects in the same account can stay uncapped. The limit takes effect immediately.

Notifications fire when actual cost hits 50%, 75%, and 90%, or when AWS forecasts you will reach the limit in the next 10 days.

Opinion: Turn the limit on for sandbox and learning projects. Leave it off for a storefront. AWS says production is acceptable when a brief pause is fine. A commerce checkout is not that workload. A 90-day deletion clock is not an acceptable failure mode for order data.

Route 53 sits in a special case: you can buy one domain every 24 hours, and the purchase fails if the domain price would break the limit. Raise the limit before you retry. Do not debug Route 53 when the spend limit rejected the cart.

The early controls are not gentle

These three switches are optional. AWS describes them as acting earlier so you stay under the cap. Read the resource actions before you enable them.

Idle EC2, over the last 14 days: peak CPU under 5% and network I/O under 5 MB per day. G and P instances add a GPU test: GPU idle more than 99% of the lookback, encoder unused for 99% or more of runtime, GPU memory under 5%, plus the same CPU and network tests.

Idle RDS for MySQL or PostgreSQL: not a read replica, and over 14 days no database connections, low CPU, and low read/write activity. Other engines are not in this pause list.

Idle SageMaker endpoint: zero invocations in 14 days.

Top cost drivers are a different list, and they are destructive:

• EC2. AWS terminates the instance. It snapshots each attached EBS volume first and releases associated Elastic IPs. Compute and volume charges stop. Snapshots keep billing. You launch a new instance from the snapshots if you still want the workload.
• RDS. AWS stops the instance. Compute stops. Storage, provisioned IOPS, and automated backups continue. RDS starts the instance again after 7 days. If the spend limit is still at risk, AWS stops it again.
• Lambda. Event source mappings and triggers are disabled. Provisioned concurrency is removed. Code and configuration stay. You re-enable triggers yourself, and you reconfigure provisioned concurrency if you had it.
• Bedrock. Provisioned throughput is deleted. There is no pause API for it. Custom model weights on that provisioned model are deleted. Training data in S3 is not. Restore means a new provisioned allocation, or a retrain from S3 for a custom model.

What broke (AWS-documented) — The top-cost-driver path has no soft landing for Bedrock. AWS states deletion is the only way to stop provisioned-throughput charges. A fine-tune you cannot retrain from the original S3 data is gone. Detection is the Bedrock console after the control runs, not a Budgets email. Recovery is retrain or recreate. Leave this switch off on any project that holds a custom model.

How it differs from the controls you already have

Budgets remain the right tool for a known monthly number on an account you cannot pause. The FinOps ownership guide is how you attribute that number to a team. A spend limit does not replace tags. It pauses a project. It does not explain which team burned it.

What to Do This Week

1. Open AWS Settings. If Spend limit is missing, you are outside the limited release or not on a Paid Plan. Do not file an IAM ticket first.
2. List sandbox and classroom projects. Cap those. Use the worksheet. Minimum is the greater of $20 and the estimate AWS shows. If the estimate is high, stop idle instances, then set the limit.
3. Enable Stop new resource launches on sandboxes. Enable Pause idle resources only if a stopped dev database is acceptable.
4. Leave Pause top cost drivers off on anything with a Bedrock custom model, a production RDS instance, or an Elastic IP you cannot afford to release.
5. Write down who raises the limit. The pause preserves data. The 90-day clock does not.
6. Keep production on Budgets, anomaly detection, and budget actions you authored. Review them with the Budgets guide.

What This Post Doesn’t Cover

Service-control-policy JSON for every service (AWS points at a separate “Service control policies for spend limits” page). Exact dollar math for your estimate. We did not enable a spend limit in a customer account for this post. The feature may be invisible in your account until AWS widens the release. Organization-wide SCPs, Savings Plans, and credits behavior beyond the one line AWS published: credits are excluded, charges are pre-tax.