Set a cloud spending limit and find out it is not a limit

Before you start

This covers AWS, properly, rather than three providers badly. The idea holds elsewhere and the menus do not.

You need an account you can change billing settings on. If somebody else administers the account, this is a conversation rather than a task, and step 6 is the part they will care about.

Read what your existing budget is set to do

If you already have a budget, start here rather than making another one.

Open the Billing and Cost Management console and go to Budgets. Open the budget you have and look for whether anything is listed under actions, as distinct from alerts.

For almost everybody the answer is that there are notifications and no actions. That is the default and it is not a mistake you made. It is worth seeing on your own screen before you fix it, because “I have a budget” and “I have a limit” feel identical right up until the invoice.

Set the budget on the number that matters

Create a cost budget, or edit the one you have.

Set the amount to what you would be unhappy to pass, not to what you expect to spend. Those are different numbers and people usually enter the second one, which produces an alert every month that they learn to ignore.

Set the threshold to trigger on actual cost rather than only forecasted. Forecasted is useful early warning, and it is a projection. For the thing that stops spending you want the trigger tied to money that has genuinely been incurred.

Give it an action

This is the step that separates a budget from a limit, and it is a separate configuration, not a checkbox on the one you already made.

Under budget actions, AWS can do three kinds of thing on your behalf when the threshold is crossed:

Apply an IAM policy

, typically a custom Deny that removes the ability to provision more resources

Apply a service control policy

, an organization-level version of the same idea

Target specific EC2 or RDS instances

, stopping the named ones

For a solo operator the IAM Deny is usually the right first choice. It leaves what is already running alone and stops anything new from being created, which is the failure mode you actually have. Stopping named instances is the sharper tool and it takes your service down with it, so reach for it only where that is the correct trade.

The Deny is a policy you write. A minimal one, blocking new compute and new databases, looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "rds:CreateDBInstance",
        "rds:CreateDBCluster"
      ],
      "Resource": "*"
    }
  ]
}

Create that as a customer managed policy in IAM first, then choose it when you configure the action. Add the services you actually use, because a Deny only covers the actions it names, and this one says nothing about, for example, Lambda or S3.

You will be asked to set up a role that lets AWS Budgets carry the action out. That is expected, and without it the action cannot run.

Decide whether it runs on its own

An action can run automatically, or wait for you to approve it.

Automatic is the honest choice for a spend ceiling. An action that waits for approval is a notification with extra steps, and if you are asleep when the threshold trips, you have rebuilt the thing you were trying to replace.

Manual approval earns its place in one situation: the action would interrupt something customers are using, and a person needs to weigh a bill against an outage. If that describes your setup, choose manual and know you chose it.

Confirm the action exists, do not assume it

Go back to the budget and read it as though somebody else configured it.

It has to list an action, with a threshold, with a state that says it will run. A budget page showing only alert recipients is a budget with no action attached, whatever you intended in step 3.

Check the role too. A configured action with a role that cannot act fails at the moment it is needed, quietly, which is the worst time to find out.

Set the threshold lower than you think, because of the lag

Here is the part that decides how much this is worth, and AWS documents it plainly.

Budget data updates up to three times a day, and updates typically arrive 8 to 12 hours after the previous one. AWS also notes that you can incur costs past your threshold before Budgets can notify you at all, and that costs may keep moving after the notification.

So the action does not fire when you cross the line. It fires when the next refresh notices you crossed it, which can be many hours later, and whatever was spending in the meantime kept spending.

The practical response is to put the threshold well under the number that would actually hurt. If a four hundred dollar month is the point of pain, do not set the action at four hundred. Set it at two hundred and accept the overshoot as the cost of the mechanism. You are configuring a brake with a delay, not a wall, and the size of the gap is yours to choose.

A boundary worth knowing about

Everything on offer here works by attaching a policy or stopping named resources. Nothing on the budget screen switches the account off, and it is worth reading that as a design decision rather than an oversight. A blunt stop would take a production service down during a legitimate traffic spike, which for most businesses is the worse outcome. That is also why the tools you get are policy-shaped: they let you decide precisely what stops.

Two smaller edges. A service control policy can be applied from a management account to another account, but EC2 and RDS instances in another account cannot be targeted that way, so a multi-account setup needs the action configured where the resources actually live. And an IAM Deny stops new provisioning while leaving current usage running, which is the correct behavior and also means a single expensive thing already running is untouched by it.

If you have staff

The alert should not go to one person. A threshold that trips while somebody is on leave is a threshold nobody saw. Send it to an address more than one person reads.

Decide in advance who can lift the Deny. The policy will eventually fire on a legitimate spike, and at that point somebody needs to remove it quickly and put it back afterward. If that person is the only one with the permission and they are unreachable, the cost control has become the outage.

The short version

1. Open Budgets and read whether your existing budget has any action, or only alerts
2. Set the amount to what you would be unhappy to pass, triggering on actual cost
3. Add a budget action, usually a custom IAM Deny on provisioning, and set up the role it needs
4. Make it run automatically unless an outage is the worse outcome
5. Re-read the budget and confirm an action is listed, not just recipients
6. Set the threshold well below your real ceiling, because data refreshes up to three times a day

Sources

• Managing your costs with AWS Budgets — “AWS Budgets information is updated up to three times a day. Updates typically occur 8–12 hours after the previous update”, and the documented delay between incurring a charge and being notified
• Configuring budget actions — the IAM policy, SCP and EC2/RDS targeting actions, automatic versus manual approval, and the cross-account limitation
• Creating a budget — cost budgets, thresholds and notification setup

Written August 2026. Console paths and refresh behavior checked against the AWS Cost Management user guide on 23 August 2026.