> Source: https://meetrix.io/blogs/aws-billing-alarm/ > Markdown copy of that page. Cite the URL above, not this file. Development # How to Set a Billing Alarm in AWS with CloudWatch and Budgets [By Hiruna Kumara](https://meetrix.io/blogs/authors/hiruna-kumara/) • September 18, 2026 • 5 min read Every AWS horror story ends the same way: someone finds out about the bill when it arrives. A forgotten GPU instance, a test cluster left running over a long weekend, a video server that pushed far more traffic than expected. A billing alarm doesn't prevent any of that, but it turns a month-end surprise into a same-day email. It takes about five minutes. Do it on every account, including the test ones, which are usually where the forgotten resources live. ## Step 1: turn on CloudWatch billing alerts AWS doesn't publish billing data to CloudWatch until you ask it to. 1. Open the Billing and Cost Management console, signed in as the root user or an IAM user with billing access. 2. Go to **Billing preferences** and edit **Alert preferences**. 3. Tick **Receive CloudWatch billing alerts** and save. The billing metrics show up in CloudWatch after that, usually within a few hours. In an AWS Organization, do this in the management account; it can see charges for every member account. ## Step 2: create the billing alarm in AWS Switch to US East (N. Virginia) first Billing metrics exist only in the us-east-1 region, whatever region your servers run in. If CloudWatch is set to Frankfurt or Mumbai, the Billing namespace simply isn't there. This is the most common reason people think the setup failed. 1. In CloudWatch (us-east-1), open **Alarms** and click **Create alarm**. 2. Click **Select metric**, then **Billing**, then **Total Estimated Charge**. Tick the row for USD and click **Select metric**. 3. Set the statistic to **Maximum** and the period to **6 hours**. Billing data only updates a few times a day, so shorter periods just produce gaps. 4. Under conditions, choose **Static**, **Greater/Equal**, and enter your threshold in dollars. 5. Under notification, create a new SNS topic and add the email addresses that should get the alert. 6. Name the alarm clearly, for example `billing-over-200-usd`, then review and create it. 7. Open the email from AWS Notifications and click **Confirm subscription**. Until every address confirms, those addresses receive nothing. AWS's own walkthrough is in the [CloudWatch billing alarm guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html). ### Choosing the threshold The metric is the **month-to-date** estimate, and it resets on the first of each month. So a single alarm at your monthly budget only fires once you have already spent it. We set three: | Alarm | Threshold | Why | | --- | --- | --- | | Early warning | 50% of the monthly budget | Fired before mid-month means something is wrong | | Budget | 100% | The normal limit | | Runaway | 2x the budget | Wakes someone up | For per-service alarms, the same Billing namespace has a metric for each service, so you can alarm on EC2 or data transfer charges separately. ## When the alarm doesn't send anything - **The SNS subscription is still "Pending confirmation".** Check the topic in SNS. Corporate spam filters often eat the confirmation email. - **Wrong region.** An alarm created in another region has no billing data to watch. - **The state is "Insufficient data".** Normal for the first few hours after enabling billing alerts, and after each new month begins. - **The threshold is above anything you reach.** See the month-to-date point above. ## AWS Budgets: the better default [AWS Budgets](https://aws.amazon.com/aws-cost-management/aws-budgets/) does the same job with two big advantages. It can alert on **forecasted** spend, so you hear on the 10th that you are heading for twice your budget, not on the 25th when you are already there. And monitoring budgets are free; only budgets with automated actions cost anything past the first two. Create one under Billing and Cost Management, then Budgets: pick a cost budget, set the monthly amount, and add alerts at 80% of actual and 100% of forecasted spend. Budget actions can also apply an IAM policy or stop specific EC2 and RDS instances when a limit is hit. Test that on something unimportant first. We keep both: Budgets for forecasts, and one CloudWatch alarm as a blunt backstop. ## What drives the bill on a Jitsi server If you self-host Jitsi Meet on AWS, the surprise is rarely the instances. It is **data transfer out**. Every participant's video goes through the videobridge to every other participant, and AWS charges for all of it. A busy week of large meetings can cost more in bandwidth than the servers did all month. Recording servers left running are the second culprit. A per-service alarm on data transfer catches the first. Scheduled shutdowns fix the second: [cutting Jitsi server costs with scheduled shutdown](https://meetrix.io/blogs/jitsi-meet-scheduled-server-shutdown/) shows how. For real numbers on what a Jitsi deployment costs, see [how much it costs to self-host Jitsi Meet on AWS](https://meetrix.io/blogs/jitsi-meet-self-hosting-cost/), and to keep an eye on bridge traffic as it happens, [monitor the Jitsi videobridge with CloudWatch](https://meetrix.io/blogs/monitor-jitsi-videobridge-cloudwatch/). ## Frequently Asked Questions How do I set a billing alarm in AWS? Turn on 'Receive CloudWatch billing alerts' in Billing preferences, switch CloudWatch to US East (N. Virginia), create an alarm on the Billing EstimatedCharges metric with a threshold in USD, and send it to an SNS topic with your email. Confirm the subscription email. Why can't I find the billing metric in CloudWatch? Two usual reasons: billing alerts are not enabled in Billing preferences yet, or CloudWatch is set to a region other than US East (N. Virginia). Billing metrics only exist in us-east-1, whatever region your resources run in. What issues commonly affect AWS billing notifications? An unconfirmed SNS email subscription, looking in the wrong region, a threshold set too high to fire before month end, and the delay in billing data, which is updated several times a day rather than in real time. Should I use a CloudWatch billing alarm or AWS Budgets? Use AWS Budgets for most accounts: it can alert on forecast spend before you actually reach the limit, and monitoring budgets are free. A CloudWatch billing alarm is still useful as a simple hard threshold, or when you want billing in the same alarm system as everything else. Does a billing alarm stop AWS from charging me? No. It only notifies you. Resources keep running and costs keep growing until you act. Budget actions can apply restrictive IAM policies or stop some instances automatically, but test them before relying on them. Meetrix Store Grafana Dashboards and alerts for Prometheus and more [Deploy it](https://meetrix.io/store/grafana/) Meetrix Store New Deploy what this guide covers, pre-configured. - [Grafana Dashboards and alerts for Prometheus and more](https://meetrix.io/store/grafana/) - [Metabase Dashboards your team can build without SQL](https://meetrix.io/store/metabase/) - [PostgreSQL A Postgres server with backups to Amazon S3](https://meetrix.io/store/postgresql/) - [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/) - [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/) - [Coturn TURN/STUN for WebRTC, no per-minute relay fees](https://meetrix.io/store/coturn/) [Browse all products](https://meetrix.io/store/)