Skip to content

AWS Updated 2026-07-04

AWS Budgets and billing alerts: the setup that catches overruns mid-month

How to set up AWS Budgets and billing alerts so overspend surfaces mid-month instead of on the invoice: actual and forecast thresholds, SNS delivery, per-team budgets, and the data-latency caveat.

The AWS Budgets setup that actually catches overruns is small: one monthly cost budget for the account with alerts at 80% actual and 100% forecast, delivered to SNS as well as email, plus one scoped budget per team or environment once tagging supports it. Alert-only budgets are free. The one caveat to internalize: budget data refreshes a few times a day with hours of lag, so this is mid-month protection against multi-day overruns — not a real-time tripwire against a runaway loop.

What’s happening

AWS Budgets compares metered spend against a limit you set and fires notifications when actual or forecasted spend crosses a threshold. The forecast is the part people underuse: a forecast alert at 100% tells you in week two that the month is trending over, while an actual alert at 100% tells you after the money is spent. Forecast alerts need several weeks of usage history before AWS will compute them on a new account — they activate once the model has data.

Mechanics that shape the setup: budget data updates up to three times a day, so expect eight-to-twelve-hour blind spots. Each budget supports multiple alert thresholds, and each alert can notify email subscribers and an SNS topic — SNS is what connects budgets to chat and paging. Budgets can be scoped by service, linked account, tag, or Cost Category, which is what turns one blunt account-level number into per-team accountability. Alert-only budgets are free; budgets with actions attached (see below) bill per day after a small free allowance — the structure is documented in the AWS Cost Management docs.

The older mechanism — CloudWatch billing alarms on the EstimatedCharges metric — still works and requires enabling Receive Billing Alerts under Billing and Cost Management > Billing preferences; the metric lives only in us-east-1. Budgets supersedes it for almost every purpose; keep a billing alarm only if you want billing wired into an existing CloudWatch-based alerting stack.

What to check first

  • Do any budgets exist, and does anyone receive them? Budgets pointed at departed employees’ inboxes are the most common finding.
  • Is there an SNS path to a watched channel? Email-only alerting adds a day of human latency.
  • What is the realistic monthly number? A budget set to last year’s spend on a growing product fires monthly and trains everyone to ignore it.
  • Are cost allocation tags active? Tag-scoped team budgets require activated tags; without them, account and service scoping are your options.

How to verify

# What budgets exist and where do they stand?
aws budgets describe-budgets --account-id 111111111111

# Full alert configuration for one budget
aws budgets describe-notifications-for-budget \
  --account-id 111111111111 \
  --budget-name monthly-total

Console: Billing and Cost Management > Budgets shows each budget with current actual, forecast, and threshold status in one table. Red forecast bars with no one paged means the notification wiring is broken — check the SNS topic policy allows budgets.amazonaws.com to publish.

The runbook

  1. Create the account-level monthly cost budget. Set the limit to expected spend plus a realistic margin, with two notifications — 80% actual, 100% forecast:

    aws budgets create-budget \
  --account-id 111111111111 \
  --budget '{"BudgetName":"monthly-total","BudgetLimit":{"Amount":"10000","Unit":"USD"},"TimeUnit":"MONTHLY","BudgetType":"COST"}' \
  --notifications-with-subscribers '[{"Notification":{"NotificationType":"ACTUAL","ComparisonOperator":"GREATER_THAN","Threshold":80,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"SNS","Address":"arn:aws:sns:us-east-1:111111111111:budget-alerts"},{"SubscriptionType":"EMAIL","Address":"ops@example.com"}]},{"Notification":{"NotificationType":"FORECASTED","ComparisonOperator":"GREATER_THAN","Threshold":100,"ThresholdType":"PERCENTAGE"},"Subscribers":[{"SubscriptionType":"SNS","Address":"arn:aws:sns:us-east-1:111111111111:budget-alerts"}]}]'

  2. Route SNS to where the team lives. Slack, Teams, or the paging tool — the same delivery pattern as the CloudWatch alarm baseline. A budget alert that arrives where work happens gets acted on the same day.

  3. Add scoped budgets as attribution matures. One per team tag or member account, owned by that team, sized to their footprint. The account budget catches the total; scoped budgets make the conversation specific.

  4. Add a forecast-only “early smoke” threshold if the account is volatile. A second forecast notification at 90% gives a week more warning on fast-growing workloads.

  5. Consider budget actions only for hard-cap environments. Actions can apply a restrictive IAM or SCP policy or stop tagged EC2/RDS instances when a threshold breaches. This is appropriate for sandboxes and training accounts; it is a blunt instrument for production, where stopping instances to save money causes the outage you were paying to avoid.

  6. Pair budgets with anomaly detection. Budgets catch “over the number you predicted”; anomaly detection catches “unusual shape you did not predict.” The second tool’s setup is covered in the Cost Anomaly Detection guide — run both.

When this is the wrong move

A budget is the wrong tool for stopping a runaway process in the hour it starts — data latency guarantees the first several hours are unmetered. Protection at that timescale comes from service quotas, concurrency limits, and capacity caps in the workload itself. Budgets are also the wrong place to encode “spend as little as possible”: a limit nobody believes in produces alert fatigue, not savings.

Common mistakes

  • Set-and-forget limits. Spend grows, the budget fires every month, everyone mutes it. Re-size the limit quarterly.
  • Email-only subscribers. The alert lands in one inbox, on a vacation week.
  • One giant budget for an Organization. Overruns hide inside the aggregate; member-account or tag scoping is what makes the alert actionable.
  • Confusing the forecast with the meter. A forecast alert is a projection with model error, not a statement that money is spent — read it as “trending over,” not “over.”

Prevention

  • Review budget limits and recipients quarterly, at the same review where you read the bill.
  • Test the SNS path when created — publish a test message, confirm it lands.
  • Template the standard budget pair into new-account provisioning so coverage is automatic.
  • Keep one person named as owner of budget hygiene; shared alerts rot fastest.
  • Document what each alert means and the expected response, so 80%-actual is a look and 100%-forecast is an action.

Budgets are twenty minutes of setup that convert billing surprises from month-end archaeology into a mid-month Slack message with time to act. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.