AWS Billing Alerts That Actually Fire: The 3-Layer Setup

AWS billing alerts only protect you if they actually fire, and the setup most tutorials show, one budget with one email, fails in three separate ways: budget data can be a day behind, the CloudWatch billing alarm silently does nothing unless you build it in one specific region with one preference switched on first, and a forecast alert stays quiet for about five weeks after you create it. This guide sets up the three layers that cover each other: AWS Budgets for the monthly ceiling, a CloudWatch billing alarm for the fast trip-wire, and Cost Anomaly Detection for the surprise you didn't budget for. Every threshold, price and delay below is current as of September 2026, and the whole setup costs nothing for a normal account.

The email that arrived a day after the damage

Jake runs a phone-repair shop, and in August he did what every AWS beginner is told to do: he created a budget of $20 a month with an email alert at 100%. Then he wrote a small script to back up his shop's photos to S3, made a typo in the loop, and left it running over a weekend.

The email arrived on Monday afternoon. It said he had spent $20. By the time he read it, the actual figure in the console was $61, because the script had kept uploading, and the budget's data was hours behind the meter.

"I did exactly what the tutorial said," he told Ethan. "It even worked. It just worked late."

"It worked the way budgets work," Ethan said. "AWS updates the numbers a budget looks at about once a day, sometimes a bit more. A budget is a monthly ceiling, not a smoke detector. For the smoke detector you want a different tool, and for the fire you never planned for, a third one. None of them costs anything. People just stop after the first."

That is the whole shape of this guide: three layers, each fixing a gap in the one before, and an honest account of what each one can't do. If your own alert ever arrived after the money was spent, you did nothing wrong. You were handed one tool and told it was three.

Why one alert isn't enough: the three ways alerts fail

Here is what each layer sees, and what it misses. This table is the reason the rest of the post exists.

"So the budget is the slow one, the alarm is the fast one, and the anomaly thing is the clever one," Jake said.

"And the Free Tier alerts are the free one you already have, if nobody turned them off," Ethan said. "Together they overlap. Alone, each has a hole exactly the size of your weekend script."

Layer 0: the Free Tier usage alerts you already have

Before you build anything, check the one alert AWS switches on for you. AWS Free Tier usage alerts email the root account address when your usage passes 85% of the Free Tier limit for a service, for every service with an active Free Tier offering that month. They are on automatically for individual accounts. They are off by default for the management account of an AWS Organization, which catches people who set up Organizations early.

To check them, or to send them somewhere better than the root mailbox: Billing and Cost Management console → Billing preferences → Alert preferences → Edit. Confirm Receive AWS Free Tier alerts is checked, and enter the email address you actually read.

Two limits, stated plainly. These alerts talk about usage (hours, gigabytes, requests), not money, so they can't tell you what a spike costs. And they stop at 85%; the right tool for the last 15% is a zero-spend budget, which is exactly where layer 1 begins.

Layer 1: AWS Budgets, set up so the alert means something

What it is. AWS Budgets lets you set a number, a cost or a usage amount, and get alerts as your month approaches it. It also has budget actions, which can do things when a threshold is crossed, such as attaching a restrictive IAM policy or stopping EC2 and RDS instances.

What it costs. Plain budgets, with notifications only, are free. Budgets with actions are free for the first two, and each further action-enabled budget costs $0.10 a day. For a personal or small-business account, everything in this section is $0.

The two templates worth knowing. When you choose Create budget, AWS offers templates. Zero spend budget alerts you the moment your spend goes above $0.01, which is the right first budget on the Free Plan, where any real charge means you have left free territory. Monthly cost budget is the classic ceiling. Use both if you are on the Free Plan; the second alone if you are on a Paid Plan.

Setting up a monthly cost budget with alerts that fire in order

1. Open the Billing and Cost Management console, choose Budgets in the left menu, then Create budget.
2. Choose Customize (advanced), budget type Cost budget, and give it a name you'll recognize in an email at 2 a.m., such as monthly-ceiling-40.
3. Period Monthly, renewal Recurring. Make budgets recurring so the alerts don't quietly stop when a fixed period ends.
4. Budgeting method Fixed, and enter your ceiling. Pick the number that would make you act, not the number you hope for. Jake's is $40: twice his normal bill.
5. Leave the cost aggregation at Unblended, and leave credits and refunds included unless you have a reason not to. On the Free Plan, ticking "include credits" means the budget tracks what the credits are absorbing, which is what you want to see.
6. Alerts: add three, on Actual spend, at 50%, 80% and 100%. Add a fourth at 100% Forecasted (it will stay silent for about five weeks, and then it becomes the most useful one).
7. Recipients: up to 10 email addresses per alert, and optionally one SNS topic per alert (for SMS or a chat room). Put at least one address that is not the root account's.
8. Review, create, and then confirm the SNS subscription email if you used a topic; a budget cannot deliver to a topic you haven't confirmed.

The five ways budget alerts fail to fire

These are the reasons people search "aws budget alert not working", each with its cause:

- The data is a day behind. Billing data that budgets use is updated at least once per day. The alert fires on the refresh after you cross the line, not the minute you cross it. This is a design limit, not a fault; layer 2 exists because of it. - The forecast alert is new. AWS needs approximately 5 weeks of usage data to produce a forecast. A forecast alert on a young account or a new budget does nothing until then. - It already fired this month. Actual alerts send once per period. If you crossed 100% on the 3rd and are looking for a second email on the 20th, there won't be one. Add a higher threshold, or wait for the period to renew. - The SNS subscription was never confirmed. A topic you didn't confirm receives nothing, and the budget shows no error. - The budget expired. Custom-period budgets end on their end date and don't renew. Use monthly recurring budgets for the ceiling.

Budget actions: the alert that does something

If you want a budget to act, not just email, add a budget action: when a threshold is reached, AWS can apply an IAM policy (for example, a deny on launching new EC2 instances) or stop specific EC2 or RDS instances. Two honest warnings. First, actions need two IAM roles set up with AWS's managed policies, or nothing happens. Second, stopping an instance that belongs to an Auto Scaling group does not work on its own: Auto Scaling replaces it, so you'd pair the stop with a policy that removes the launch permissions. For most small accounts, the email alerts are enough and the action is a later refinement.

Layer 2: the CloudWatch billing alarm, built where it actually works

What it is. AWS publishes your estimated charges as a CloudWatch metric called EstimatedCharges, updated several times a day. A CloudWatch alarm on that metric is the fastest built-in warning you can have: hours behind real usage instead of a day. It is also the alert most people build wrong, because two prerequisites are easy to miss and the console gives no error when you miss them.

The two prerequisites. First, billing metrics are not collected at all until you turn on Receive CloudWatch Billing Alerts in the Billing console; after you enable it, the metric appears in about 15 minutes, and it cannot be switched off again (only the alarms can be deleted). Second, billing metric data is stored only in the US East (N. Virginia) region, even though it represents your worldwide charges. Build the alarm anywhere else and the Billing metric simply isn't in the list.

The alarm, step by step

1. Sign in as the root user or an IAM user with billing permissions. Open the Billing and Cost Management console → Billing preferences → Alert preferences → Edit → tick Receive CloudWatch Billing Alerts → Save preferences. If you use consolidated billing, do this in the management (payer) account; member-account metrics are only collected when the payer has this on.
2. In the top-right region selector, switch to US East (N. Virginia), us-east-1. Do not skip this.
3. Open CloudWatch → Alarms → All alarms → Create alarm → Select metric.
4. Under AWS Namespaces, choose Billing → Total Estimated Charge → tick EstimatedCharges (currency USD) → Select metric. If Billing isn't listed, go back to step 1 and wait 15 minutes.
5. Statistic Maximum, period 6 hours, threshold type Static, condition Greater than your number. Jake uses $30, below his budget ceiling, because this is the early tripwire.
6. Additional configuration: datapoints to alarm 1 out of 1, missing data Treat missing data as missing.
7. Notification: with In alarm selected, choose or create an SNS topic and add your email. Then confirm the subscription from the email SNS sends you; an unconfirmed topic delivers nothing.
8. Name it something you'll understand later, such as billing-estimated-charges-over-30, and create it.

"Insufficient data" and the other alarm states

The state everyone searches for is INSUFFICIENT_DATA. On a billing alarm it means one of three things: you built the alarm before enabling billing alerts (no metric yet); you built it in the wrong region (the alarm exists but watches nothing); or the alarm is brand new and the first data point hasn't arrived, which resolves within a few hours. OK means charges are under your line. ALARM means they are over it. The alarm does not use projections; it compares the current estimated total against your number, nothing more.

"So the alarm is the smoke detector," Jake said. "Why isn't it the whole answer?"

"Because it only knows one number: the total," Ethan said. "It can't tell you that a service you've never used just started costing money, and it can't forecast. That's the third layer."

Layer 3: Cost Anomaly Detection, the alert for the bill you didn't plan

What it is. AWS Cost Anomaly Detection watches your spending patterns with machine-learning models and alerts you when something is unusual: a service that normally costs $2 a day costing $40, a new region appearing on the bill, a tag's spend doubling. It learns weekly and monthly seasonality so that a busy Monday doesn't count as an anomaly. AWS's pricing pages list no separate charge for it.

What it isn't. It doesn't know your budget. A perfectly steady $500 a month is not an anomaly, even if you meant to spend $50. That is why it sits alongside the first two layers rather than replacing them.

Setting it up

1. Open the Billing and Cost Management console → Cost Anomaly Detection (under Cost Management).
2. Look for the AWS-managed monitor for AWS services. Newer accounts often have one already; if not, choose Create monitor → monitor type AWS services → recommended. This one monitor evaluates every service independently, which is what a small account wants. Organizations can add monitors by linked account, cost allocation tag or cost category later.
3. Create an alert subscription: a name, the alerting frequency, and recipients. Choose Individual alerts to be emailed as anomalies are found, or a daily or weekly summary if you'd rather batch them. Add up to the allowed email addresses, or an SNS topic if you want the alert in Slack or a chat room.
4. Set a threshold so small blips don't page you: an absolute amount (alert when the anomaly's impact exceeds, say, $10) or a percentage above expected spend. For a small account, an absolute $10 to $20 is a sensible start.
5. Save. Then wait: a new monitor takes up to 24 hours to begin detecting, and any service needs 10 days of history before its spend can be judged unusual.

How fast it reacts, honestly

Cost Anomaly Detection runs about three times a day, but it reads Cost Explorer data, which itself lags by up to 24 hours. So an anomaly can take up to a day to surface after the usage happened. That is slower than the CloudWatch alarm and about the same as a budget. Its value is not speed; it is that it notices the shape of the spend, root-causes it for you (ranked by dollar impact across service, account, region and usage type), and catches things no threshold you set would have caught.

Two gaps: it doesn't cover AWS Marketplace charges (except third-party foundation models on Bedrock), so a Marketplace subscription needs a budget with the Billing entity filter; and it isn't available on accounts using billing transfer.

"How do I stop AWS billing?" The honest answer

This is one of the most-searched phrases around AWS bills, so it belongs here. There is no switch that stops billing while keeping your resources; AWS bills for what exists, whether or not you are using it. Stopping the bill means one of three things:

1. Shut down what is running. Terminate EC2 instances (stopped instances still bill for their disks), delete unattached EBS volumes and snapshots you don't need, release unattached Elastic IPs, delete NAT gateways and idle load balancers, empty and delete S3 buckets you're done with, and delete RDS instances (take a final snapshot only if you want it, since snapshots bill too). Our post on the 10 most common surprise charges is the checklist.
2. Set a budget action that removes permissions when spend crosses a line, so nobody can launch more while you investigate.
3. Close the account, from the account settings page. Closing stops new charges; you still owe for usage up to that point, and you have 90 days to reopen. On the Free Plan, AWS also closes the account itself when the six months end or the credits run out, without charging you.

"And the fastest one, if I'm panicking at midnight?" Jake asked.

"Terminate the thing that's costing money; the console's Cost Explorer shows you which service, and Cost Anomaly Detection's root cause tells you where," Ethan said. "Closing the account is the last resort, not the first click."

How to check your AWS bill before an alert ever arrives

Alerts are for the moments you aren't looking. For the moments you are, four pages in the Billing and Cost Management console answer "what am I paying, and for what" in under five minutes:

1. Billing home shows month-to-date spend, the forecast for the month, and the Recommended actions widget, which flags any Free Tier service you've used past 85% of its limit.
2. Bills lists the current month by service and by region. This is where a $12 line for a NAT gateway you forgot about shows up with its name attached.
3. Free Tier (on the Free Plan and Paid Plan alike) shows each free offering, how much of it you've used, and when a service will start billing at standard rates. On the Free Plan it also shows your credit balance and the days remaining.
4. Cost Explorer is the 15-minute literacy course: spend over time, grouped by service, with filters. The first time you open it, AWS takes up to 24 hours to prepare the data. Our guide to reading Cost Explorer walks through the views worth knowing.

A habit that costs nothing: open Bills once a week, on the same day, for one minute. Jake does it on Monday mornings with his coffee. Two of his surprises this year were caught by that minute, not by an alert.

The other budget types: usage, reservation and Savings Plans budgets

Cost budgets are the ones everyone makes, but AWS Budgets has four types, and two of them answer questions a cost budget can't.

For a usage budget aimed at the Free Tier, the trick AWS itself suggests is a budget on the specific usage type, alerting when you are forecasted to exceed 100% of the free amount, for example the free EBS storage. That turns the 85% email into a full-coverage warning. The free-tier types and their names show on the Free Tier tracking page, and the console's Free Tier page shows the same names next to your usage.

Setting the alerts up as code: CLI, CloudFormation and Terraform

If you rebuild accounts, or manage several, click-through setup doesn't scale. Every layer here can be created from a file. These are the shapes to start from; adjust the numbers and addresses.

A monthly cost budget with two alerts, in CloudFormation:

Resources:
  MonthlyCeiling:
    Type: AWS::Budgets::Budget
    Properties:
      Budget:
        BudgetName: monthly-ceiling-40
        BudgetType: COST
        TimeUnit: MONTHLY
        BudgetLimit:
          Amount: 40
          Unit: USD
      NotificationsWithSubscribers:
        - Notification:
            NotificationType: ACTUAL
            ComparisonOperator: GREATER_THAN
            Threshold: 80
            ThresholdType: PERCENTAGE
          Subscribers:
            - SubscriptionType: EMAIL
              Address: you@example.com
        - Notification:
            NotificationType: FORECASTED
            ComparisonOperator: GREATER_THAN
            Threshold: 100
            ThresholdType: PERCENTAGE
          Subscribers:
            - SubscriptionType: EMAIL
              Address: you@example.com

The CloudWatch billing alarm, in CloudFormation. Deploy this stack in us-east-1, after enabling billing alerts, or the alarm will sit on a metric that doesn't exist:

Resources:
  BillingAlarm:
    Type: AWS::CloudWatch::Alarm
    Properties:
      AlarmName: billing-estimated-charges-over-30
      Namespace: AWS/Billing
      MetricName: EstimatedCharges
      Dimensions:
        - Name: Currency
          Value: USD
      Statistic: Maximum
      Period: 21600
      EvaluationPeriods: 1
      Threshold: 30
      ComparisonOperator: GreaterThanThreshold
      TreatMissingData: missing
      AlarmActions:
        - !Ref BillingTopic
  BillingTopic:
    Type: AWS::SNS::Topic
    Properties:
      Subscription:
        - Protocol: email
          Endpoint: you@example.com

The same two in Terraform, using the aws_budgets_budget and aws_cloudwatch_metric_alarm resources, with the alarm's provider pinned to us-east-1:

resource "aws_budgets_budget" "monthly" {
  name         = "monthly-ceiling-40"
  budget_type  = "COST"
  limit_amount = "40"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_email_addresses = ["you@example.com"]
  }
}

resource "aws_cloudwatch_metric_alarm" "billing" {
  provider            = aws.us_east_1
  alarm_name          = "billing-estimated-charges-over-30"
  namespace           = "AWS/Billing"
  metric_name         = "EstimatedCharges"
  dimensions          = { Currency = "USD" }
  statistic           = "Maximum"
  period              = 21600
  evaluation_periods  = 1
  threshold           = 30
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "missing"
  alarm_actions       = [aws_sns_topic.billing.arn]
}

Whichever tool you use, the two rules from the console apply unchanged: an SNS email subscription still has to be confirmed by clicking the email, and the billing alarm still only works in US East (N. Virginia) with billing alerts switched on. Code doesn't get you around either; it just makes the third account as easy as the first.

The alert fired. The next thirty minutes, in order

An alert is only as useful as what you do in the half hour after it lands. This is the sequence that turns "the email came" into "the bill stopped growing", and it is the same whether the message came from a budget, the alarm or anomaly detection.

1. Find the service, not the total. Open Cost Explorer, set the range to the last 7 days, group by Service, then by Usage type. If the alert came from Cost Anomaly Detection, its detail page already ranks the root cause by dollar impact across service, account, region and usage type; start there. You want one line that is bigger than it was last week.
2. Check the region selector. A surprising share of "I'm not running anything" bills are resources in a region you don't normally look at. Cost Explorer's group-by Region shows it in one click.
3. Stop the meter. Terminate or delete the thing that's growing: an instance, a NAT gateway, a load balancer, a runaway Lambda schedule, a bucket that a script keeps filling. Stopping an EC2 instance keeps its disk billing; terminating ends it. If you're unsure, stop first and decide in the morning.
4. Ask whether it was you. If the spend is in a region or a service you have never touched, treat it as a possible compromised access key until proven otherwise: rotate keys, check IAM for users you don't recognize, and follow the steps in our leaked access key guide. Unusual spend in strange regions is the most common first sign of a leaked key.
5. Tighten the alert that caught it. If the budget fired at 100% and the alarm didn't fire at all, the alarm threshold is too high or it was built in the wrong region. Fix it now, while you remember.
6. Write the number down. Whatever the incident cost, note it next to the budget. Three months of these notes tell you what your real ceiling should be far better than any rule of thumb.

One honest note on refunds. AWS's support pages say that charges for accidental usage can sometimes be reviewed on request through a billing support case, at AWS's discretion. It is worth asking politely, once, with the facts; it is not something to plan around. The alerts are the plan.

"So the alert is the start of the job, not the end," Jake said.

"The alert is the doorbell," Ethan said. "You still have to answer the door."

The full three-layer setup on one page

The numbers scale with you. A bigger account moves the alarm and budget lines up; the structure stays the same. And the whole thing, on a normal account, costs $0.

For IT admins: Organizations, consolidated billing and the management account

- Enable billing alerts in the management (payer) account. Member-account metrics only reach CloudWatch when the payer has Receive CloudWatch Billing Alerts on. Change the payer account, and you must re-enable it there. - Free Tier usage alerts are off by default for a management account. Opt in under Billing preferences if you want them. - Budgets per account or per team. Budgets can be filtered by linked account, tag or cost category, so one budget per project is possible without one account per project. Note what happens when a member account leaves the organization: its budgets track only costs after departure, with no notification of the change. - Cost Anomaly Detection monitors by linked account are the right shape for a multi-account setup; the AWS-services monitor watches the whole organization from the payer. - Permissions. To create budgets, a user needs to view billing information and to create CloudWatch alarms and SNS notifications. For budget actions, use AWS's two managed policies (one for the user to pass a role, one for Budgets to execute) or the action will silently not run. - Chat delivery. Both budget alerts and anomaly alerts can post to Slack or Chime through an SNS topic and the Amazon Q Developer chat integration, which is the setup most teams actually read.

Billing alerts that aren't firing: the fix table

"That table is mostly 'you built it in the wrong place' and 'wait'," Jake said.

"Most billing-alert problems are," Ethan said. "The tools work. They just have manuals nobody hands you."

AWS billing alerts: the questions people search

How do I set up billing alerts in AWS?

Three layers: create an AWS Budget with alerts at 50%, 80% and 100% of actual spend; enable Receive CloudWatch Billing Alerts and build a CloudWatch alarm on the EstimatedCharges metric in US East (N. Virginia); and add an alert subscription in Cost Anomaly Detection. The steps for each are above.

How do I set a budget limit in AWS?

Billing and Cost Management → Budgets → Create budget → Cost budget, monthly and recurring, then enter your amount and add alert thresholds. A budget does not stop spending by itself; add a budget action if you want it to apply a restrictive policy or stop instances.

Is AWS Budgets free?

Yes for budgets that only send notifications, no matter how many you create. Budgets with actions attached are free for the first two, then $0.10 per day for each additional action-enabled budget.

What is the difference between an AWS billing alarm and a budget?

A budget compares month-to-date spend or usage with a number you set and refreshes about once a day, with optional forecasts. A CloudWatch billing alarm watches the EstimatedCharges metric, which updates several times a day, so it warns faster, but it only works in US East (N. Virginia) after billing alerts are enabled and it does not forecast.

Why is my AWS budget alert not working?

The common causes: budget data is up to a day behind; a forecast alert needs about five weeks of history; actual alerts fire once per period; an SNS subscription was never confirmed; or a custom-period budget expired. The troubleshooting table above covers each.

Why does my CloudWatch billing alarm say Insufficient data?

Usually because billing alerts were not enabled before the alarm was created, or the alarm was built outside US East (N. Virginia), where billing metrics are stored. Enable the preference, wait about 15 minutes, and build the alarm in us-east-1.

How do I create a CloudWatch alarm for billing?

Switch the console to US East (N. Virginia), open CloudWatch → Alarms → Create alarm → Select metric → Billing → Total Estimated Charge → EstimatedCharges, set Maximum over 6 hours, a static threshold, and an SNS topic with your email. Billing alerts must be enabled first.

What is AWS Cost Anomaly Detection and does it cost anything?

It is the machine-learning monitor that alerts you when spending patterns look unusual, with root causes by service, account, region and usage type. There is no separate charge for it. It needs 24 hours to start and 10 days of history per service.

How long does it take for AWS billing alerts to fire?

Free Tier usage alerts are immediate on crossing 85%. A CloudWatch billing alarm reacts within hours. A budget alert arrives on the next daily data refresh after you cross the threshold. Cost Anomaly Detection can take up to 24 hours because it reads Cost Explorer data.

Can AWS send billing alerts by SMS or to Slack?

Yes. Budgets and Cost Anomaly Detection can both deliver to an Amazon SNS topic, and SNS supports SMS subscriptions. For Slack or Chime, connect the topic through the Amazon Q Developer chat integration.

How do I stop AWS from charging me?

Shut down what is running (terminate instances, delete volumes, snapshots, NAT gateways, load balancers and unused buckets), add a budget action to block new launches if needed, or close the account. Closing stops new charges but you still owe for usage to date.

Do budget alerts work on the AWS Free Plan?

Yes. The Zero spend budget template is designed for it: it alerts as soon as spend passes $0.01, which on the Free Plan means you have used something the credits are covering. Free Tier usage alerts also warn at 85% of each free limit.

Why did my billing alarm trigger immediately?

Because your month's estimated charges were already above the threshold when you created it. CloudWatch evaluates the current value at once, so the alarm goes straight to ALARM. Raise the threshold or treat it as your first alert.

How many alerts can one AWS budget have?

Each alert can go to up to 10 email addresses and one SNS topic. Add separate alerts for each threshold you want (for example 50%, 80%, 100% actual and 100% forecast).

Does Cost Anomaly Detection cover AWS Marketplace charges?

No, except for third-party foundation models on Amazon Bedrock. For other Marketplace subscriptions, create a cost budget filtered by Billing entity to track them.

What should the billing alarm threshold be?

Below your budget ceiling, so it fires first. A common pattern is the alarm at about 75% of the budget amount. Jake's account uses a $30 alarm under a $40 budget.

Can I get billing alerts for a member account in AWS Organizations?

Yes, when the management (payer) account has enabled Receive CloudWatch Billing Alerts; member-account metrics are captured only then. Budgets can also be filtered by linked account from the payer.

If an AWS bill has ever ambushed you, please hear the part that matters: you set up the alert you were told to set up, and it did its job, just on its own clock. Nobody explained that there were three clocks. Now you have all three running, none of them costs you a cent, and the next surprise gets caught from three directions. If a step here doesn't match what you see in the console, tell me through the contact page; AWS moves buttons, and this page stays accurate because readers write in.

Revision note. Written September 26, 2026; data delays, thresholds and the two free action-enabled budgets are current as of that date. Next check: when AWS changes the Budgets refresh cadence, the billing-metric region rule, or Cost Anomaly Detection's pricing. Set the three layers up tonight; it is twenty minutes that pays for itself the first time something runs over a weekend.