AWS Budgets and Billing Alerts

What a missing budget looks like

A startup launched their MVP on AWS in January. Their expected monthly spend was around $300 — two small EC2 instances and an RDS database. By March they had grown a bit, so they spun up some additional resources for testing and forgot to take them down. They also configured a NAT Gateway in a VPC without realising it was running 24 hours a day at $0.045/hour.

Month 3 arrives and the bill is $4,200.

The NAT Gateway had been running for 60 days ($65 in hourly charges), and it was processing more data than expected ($185 in data processing). The test EC2 instances were never terminated. Several EBS volumes were created and never deleted. None of it was noticed because nobody was watching the billing console.

AWS Budgets would have sent an email alert at $500 spend. The founder would have investigated immediately. The damage would have been contained.

AWS Budgets vs CloudWatch billing alarms

AWS offers two ways to alert on spend, and they serve different purposes.

CloudWatch billing alarms monitor your total estimated charges. You set a threshold in dollars, and CloudWatch triggers an SNS notification when charges exceed it. Simple, but limited — it only looks at total spend, and it reacts to actual charges already incurred.

AWS Budgets is the more capable tool. It supports:

• Cost budgets — alert when spending exceeds a dollar threshold
• Usage budgets — alert when a service’s usage (e.g., EC2 instance-hours) exceeds a threshold
• Reservation budgets — alert when Reserved Instance or Savings Plan utilisation drops below a threshold (helps you notice unused commitments)
• Savings Plans budgets — track Savings Plans coverage

Budgets also support forecasting: AWS will alert you if it predicts you will exceed your budget by end of month, even before you’ve actually spent the money. This is the most valuable feature — you get warning before the damage is done, not after.

For new accounts, the recommendation is to set up both: a CloudWatch billing alarm as a safety net and an AWS Budget for more granular control.

Creating a $100/month budget with email alerts

Here’s how to create a cost budget using the AWS CLI. This creates a $100/month budget that alerts at 80% ($80) and 100% ($100) and sends email to the specified address.

First, create a budget definition file:

{
  "BudgetName": "Monthly-Cost-Budget",
  "BudgetLimit": {
    "Amount": "100",
    "Unit": "USD"
  },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

Then create the notifications file:

[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {
        "SubscriptionType": "EMAIL",
        "Address": "you@yourcompany.com"
      }
    ]
  },
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 100,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {
        "SubscriptionType": "EMAIL",
        "Address": "you@yourcompany.com"
      }
    ]
  },
  {
    "Notification": {
      "NotificationType": "FORECASTED",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 100,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      {
        "SubscriptionType": "EMAIL",
        "Address": "you@yourcompany.com"
      }
    ]
  }
]

Deploy with:

aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

The three notifications cover: 80% of actual spend, 100% of actual spend, and a forecast to reach 100%. You get early warning, a warning when you hit the limit, and a forecast warning — three separate signals.

Budget types and when to use each

Budget Actions: automatic enforcement

Budget Actions let AWS take automatic action when a budget threshold is crossed. This goes beyond alerting — it can actually stop resources or restrict what accounts can do.

Three types of actions are available:

Apply a Service Control Policy (SCP) — attaches an SCP to an AWS Organizations account, restricting what services or actions are allowed. For example, deny all new resource creation when the budget is exceeded. This is effective in multi-account environments where you want to enforce hard limits on dev accounts. See AWS Organizations for context on how SCPs work.

Apply an IAM policy — attaches an IAM policy to users, groups, or roles, restricting their permissions.

Target EC2 or RDS instances — stop specific EC2 instances or RDS instances when the budget is hit.

Budget Actions can run automatically or require manual approval. For production accounts, the approval workflow is usually safer — you want a human to confirm before stopping instances. For dev and test accounts, automatic actions are often the right call.

Use caution: if you configure an action to stop all EC2 instances and your budget threshold is misconfigured or too low, you can trigger the action unexpectedly. Always test Budget Actions in non-production accounts first.

Scoping budgets to teams, projects, and services

A single account-level budget is a good start, but more targeted budgets are more useful for organisations with multiple teams or projects.

You can scope a budget by:

• AWS service — a budget that only tracks EC2 spend, for example
• Linked account — in an AWS Organizations setup, a budget for a specific team’s account
• Resource tags — a budget that tracks spend tagged with Project: payments-service
• Region — useful if you want to catch unintended spend in unexpected regions

Tag-based budgets require your resources to be tagged consistently. See resource tags for how to set up a tagging strategy that makes cost allocation possible.

For a team running a SaaS product, a practical setup is:

• One account-level budget with a $X/month limit
• One per-service budget for EC2 (the highest cost item)
• One per-tag budget for each major project or environment (production vs staging)

Alert delivery: email and SNS

Budget alerts can be delivered to:

• Email addresses — up to 10 per notification. Simple and no setup required.
• SNS topics — lets you route alerts to Slack (via a Lambda function), PagerDuty, or any other destination that can receive SNS messages.

For teams using Slack, the typical pattern is: Budget → SNS → Lambda → Slack webhook. This puts cost alerts directly into the channel where the engineering team already works, which increases the chance that someone acts on them.