How to set up AWS billing alerts that actually warn you early

Choosing between AWS Budgets, CloudWatch, and Free Tier alerts

AWS provides three native mechanisms to monitor spending. They overlap in confusing ways, but they rely on different underlying data sources and trigger under different conditions.

AWS Budgets is the right starting point for most developers. You can set custom cost and usage budgets that trigger when spending exceeds your threshold or when AWS forecasts that your month-end spend will exceed it. Monitoring and receiving notifications on your budgets is free of charge. You can track overall costs, individual usage types, and aggregate Reserved Instance and Savings Plans coverage. Single accounts, management accounts, and member accounts in an AWS Organization can all create budgets by default.

CloudWatch billing alarms look strictly at current month-to-date charges. When monitoring of estimated charges is enabled, estimated charges are calculated and sent several times daily to CloudWatch as metric data. The metric is stored in the US East (N. Virginia) Region and represents worldwide AWS charges. It triggers only when current billing exceeds your threshold, so it does not use projections based on month-to-date usage. If you configure a threshold that your account has already passed, the alarm switches to the ALARM state immediately.

Free Tier usage alerts are separate. They send an automated email when you pass 85 percent of your Free Tier limit for any eligible service. Individual accounts get these turned on automatically, but management accounts in an AWS Organization must opt in manually.

How to set up a CloudWatch billing alarm

Before you can create a CloudWatch billing alarm, you have to turn on billing metric collection in the billing console. Once you enable billing alerts in AWS, you cannot disable billing metric data collection, though you can delete any created billing alarms.

You must be signed in using root credentials or as an IAM user with permission to view billing information. If your account sits inside an AWS Organization with consolidated billing, member linked account metrics are captured only if the payer account enables the Receive Billing Alerts preference. Accounts that belong to the Amazon Partner Network (APN) do not receive these metrics because billing metrics are not published to CloudWatch for APN accounts.

Step 1: Enable billing metrics in the Billing console

1. Open the AWS Billing and Cost Management console.
2. In the navigation pane, choose Billing Preferences.
3. Next to Alert preferences, choose Edit.
4. Select Receive CloudWatch Billing Alerts.
5. Choose Save preferences.

After enabling billing alerts for the first time, it takes approximately 15 minutes before you can view billing data and set CloudWatch billing alarms.

Step 2: Create the alarm in CloudWatch

Before creating your alarm, switch your console Region to US East (N. Virginia). The billing metric does not exist in any other region.

Open CloudWatch, navigate to Alarms, choose All alarms, and click Create alarm. Click Select metric. Under AWS Namespaces, select Billing, choose Total Estimated Charge, and pick the EstimatedCharges metric. The values appear exclusively in US dollars (USD), with currency conversion provided by Amazon Services LLC.

Now set the alarm parameters:

• Statistic: choose Maximum.
• Period: choose 6 hours.
• Threshold type: choose Static.
• Condition: choose Greater than, and enter your dollar threshold (such as 50).
• Under Additional Configuration, set Datapoints to alarm to 1 out of 1.
• For Missing data treatment, choose Treat missing data as missing.

For notifications, choose an existing Amazon SNS topic or create a new one that contains your email address. Name the alarm using only UTF-8 characters; it cannot contain ASCII control characters. Confirm the setup and save.

How to configure an AWS Budget for actual and forecasted spend

AWS Budgets gives you something CloudWatch alarms cannot: forecast alerts. If you spin up an expensive resource on day three of the month, a forecasted alert tells you that your current burn will blow your budget by day thirty, even if your actual spend is only five dollars right now.

If you have never opened Cost Explorer before, AWS Budgets automatically enables Cost Explorer when you create your first budget. Keep in mind that it can take up to 24 hours for the Cost Explorer graph to appear.

Step 1: Create the budget

Navigate to AWS Budgets in the console and choose Create budget. You can build a custom cost budget or start from a template. If you want to watch Free Tier usage up to 100 percent of the limit, you can configure a zero spend budget template, which flags any charge above zero dollars.

For a custom budget, choose to create a cost budget and enter your target amount.

Step 2: Add alerts for actual and forecasted spend

Do not rely on a single 100 percent alert. By the time an actual spend alert hits 100 percent, the money is gone.

Set up multiple alert thresholds:

1. Actual spend at 50 percent: gives you early notice mid-month that your baseline burn is higher than planned.
2. Actual spend at 80 percent: your warning that standard headroom is almost exhausted.
3. Forecasted spend at 100 percent: fires immediately when AWS predicts your month-end spend will exceed the target amount.

Enter your email address for each alert. Monitoring and receiving notifications on your budgets is completely free of charge. You can also configure actions on AWS Budgets to control IAM permissions, Service Control Policy (SCP) permissions, or target AWS resources when thresholds are breached. The first two action-enabled budgets are free each month, but every subsequent action-enabled budget incurs a $0.10 daily cost.

If your setup relies on cross-account billing views across an organization, your source account administrator must grant budgets:ModifyBudget and billing:GetBillingViewData permissions, and target users need iam:CreateServiceLinkedRole for budgets.amazonaws.com. If a view status switches to UNHEALTHY with reason BILLING_VIEW_NO_ACCESS or INVALID_FILTER, spend updates pause completely.

Why native AWS billing alerts fire late

Indie developers and small teams often wonder why an alert did not save them from a surprise bill. The short answer is data latency. Native AWS alerts are designed for accounting oversight, not for real-time infrastructure defense.

CloudWatch billing metrics are calculated and sent several times daily. Because the metric only updates a few times a day and uses a 6-hour evaluation period, there is a multi-hour delay before an alarm can react. If a runaway Lambda function invokes itself in a recursive loop at 2:00 AM, CloudWatch will not see the charge jump until the next batch calculation runs.

AWS Budgets relies on Cost Explorer data. Cost Explorer does not update continuously; billed costs can be up to a day behind reality. If you want to know why AWS Cost Explorer doesn't show today's spend yet, the pipeline requires downstream billing records to settle before aggregating them.

Similarly, Free Tier alerts trigger only after your usage crosses 85 percent of the eligible limit. If a burst workload consumes 500 percent of your allowance in twenty minutes, the alert will fire, but your account is already accumulating billable usage by the time you open the email. There are also coverage gaps: you might not see Free Tier data if you use a service that offers no Free Tier, if your Free Tier has expired, if you access AWS through an Organizations member account, or if you run resources in GovCloud regions.

What happens when an alert triggers?

A standard AWS billing alert sends an email. That is it.

AWS does not stop your EC2 instances, throttle your serverless endpoints, or revoke credentials just because an alarm enters the ALARM state. The bill continues to climb until an engineer reads the notification, logs into the AWS console, finds the offending resource, and shuts it down. If you are asleep, in a meeting, or away from your desk, several hours of runaway spend will accumulate.

While AWS Budgets supports budget actions that can run automation, configuring them requires setting up specific IAM roles, systems manager automations, or SCPs. If an automated script cuts off access improperly, it can break production workloads without a clean rollback path. Read our analysis on whether you can set a hard spending limit on an AWS account for the mechanical details of what actually halts AWS spend.

Faster alerts and one-click cutoffs with Costbrake

If you run production workloads or experiment with generative AI models where an error can rack up hundreds of dollars in minutes, native daily batch alerts are simply too slow.

Costbrake monitors what you spend across cloud, AI and SaaS providers, alerting you to sudden spikes, budget thresholds, month-end forecasts and new charges. Instead of waiting for daily billing aggregates, Costbrake estimates Lambda, Bedrock, NAT gateway and GPU instance spend from CloudWatch hourly on the Free plan, every 5 minutes on Pro and Team, and up to every minute during an active spike. Everything else comes from Cost Explorer, which Costbrake re-reads every 4 hours.

A spike alert triggers whenever an hour costs more than 3x your usual 7-day baseline and at least $5 more than usual. Forecast alerts trigger when month-to-date spend plus your last 72 hours of burn would exceed your budget by month-end. You can push alerts to email, Slack, Discord, webhooks, or PagerDuty. If you need team chat integrations, see our guide on how to send cloud billing alerts to Slack or Discord.

To bridge the gap while Cost Explorer settles, Costbrake combines billed costs with live CloudWatch estimates. It queries CloudWatch metrics for Lambda requests and duration, Bedrock tokens per model, NAT gateway data processed, and running G, P, and Inf instance vCPUs across up to 8 active regions.

To set up read-only monitoring, run this AWS CLI snippet using a profile that can manage IAM in your management account:

PROFILE=default
aws iam create-policy --profile "$PROFILE" --policy-name CostbrakeReadOnly --policy-document '{"Version":"2012-10-17","Statement":[{"Sid":"CostbrakeReadCosts","Effect":"Allow","Action":["ce:GetCostAndUsage"],"Resource":"*"},{"Sid":"CostbrakeLiveEstimates","Effect":"Allow","Action":["cloudwatch:GetMetricData","cloudwatch:ListMetrics"],"Resource":"*"}]}'
aws iam create-user --profile "$PROFILE" --user-name costbrake-reader
ACCOUNT_ID=$(aws sts get-caller-identity --profile "$PROFILE" --query Account --output text)
aws iam attach-user-policy --profile "$PROFILE" --user-name costbrake-reader --policy-arn "arn:aws:iam::${ACCOUNT_ID}:policy/CostbrakeReadOnly"
D=$(mktemp -d /tmp/costbrake.XXXXXX)
aws iam create-access-key --profile "$PROFILE" --user-name costbrake-reader --query "AccessKey.[AccessKeyId,SecretAccessKey]" --output text > "$D/key.txt"
cut -f1 "$D/key.txt"

The key uses only three permissions: ce:GetCostAndUsage, cloudwatch:GetMetricData, and cloudwatch:ListMetrics. It cannot modify resources. AWS charges $0.01 per Cost Explorer API request, and Costbrake reads it at most every 4 hours, which adds roughly 210 requests or about $2 a month to your AWS bill.

When an emergency happens, Pro and Team plans include brakes: opt-in, reversible killswitches across 18 providers. A brake never runs automatically; an admin must click and confirm it. On AWS, you can throttle a runaway Lambda function to zero reserved concurrency, stop an EC2 instance, turn off an active IAM access key within seconds, or block Amazon Bedrock model calls across an entire role or user.

Check out Costbrake pricing to review plan tiers, or run an agent setup to have your AI coding agent configure the read keys for you.