AWS costs: Cost allocation tags - seeing which project spends

A single AWS billing alert always eventually fails you, and the reason is almost never the one people blame. Most guides tell you to turn on one CloudWatch billing alarm and call the job done — but that alarm only checks a handful of times a day, only fires after you've already crossed the number, and has no idea whether today's spend is normal for you or a runaway Lambda loop. The fix that actually holds is three separate, free AWS tools stacked on top of each other, each catching what the other two are structurally blind to.

Why one billing alert was never going to be enough

Jake found out the expensive way. He'd set up a single CloudWatch billing alarm months earlier — $50, email him if it goes over. It never fired. Then a Saturday customer walked in wanting his phone data pulled off a cracked screen, Jake fired up a little S3-backed recovery tool he'd built on a t3.small instance to speed through it, forgot to shut the instance down that night, and by the time he checked his email Tuesday the bill was already past $90. The alarm had fired — sometime Sunday, buried under three newsletters and a shipping notification he'd already deleted the thread for.

Every one of AWS's billing alert tools has this shape: it's genuinely useful, and it has a gap that's completely invisible until it costs you money. An AWS Budget can warn you before you spend the money, using a forecast built from your account's own historical usage — but a brand-new account with almost no history won't have much of a forecast to work from yet, and a single budget notification only reaches up to ten email addresses or one SNS topic. A CloudWatch billing alarm reacts fast on an absolute dollar figure and doesn't care about forecasts at all — but its Total Estimated Charge metric updates only a handful of times per day, and it can only ever tell you that you're already over the number, never that you're about to be. AWS Cost Anomaly Detection uses machine learning to notice spend that's weird for you specifically, which catches the case where your bill is still technically under every dollar threshold you set but three times higher than any normal Tuesday — but it needs your own account's spending history to learn from, so it's least useful in the first days of a brand-new account, which is exactly when a mistake is most likely.

None of these three systems talk to each other. They live in different parts of the Billing and Cost Management console, they're configured on different pages, and stacking them is a job you can genuinely finish in one sitting once you know where each piece lives — which is what the rest of this post walks through, in order, along with the two supporting steps almost nobody bothers with that make Layer 3 actually earn its keep.

Layer 1: AWS Budgets — the tool that can warn you before the money's spent

AWS Budgets is a free tool inside the Billing and Cost Management console that tracks your cost or usage against a limit you set and notifies you when you cross it, or when AWS forecasts that you will. You can create a budget without turning anything else on first, which is the opposite of Layer 2. When you create your first budget, AWS Budgets also enables Cost Explorer for you if it isn't already on, so you get a graph of your incurred spend right on the same page — it can take up to 24 hours for that graph to actually appear.

ACTUAL vs. FORECASTED — the difference that actually matters

Every notification you attach to a budget is one of two types. An ACTUAL notification fires when your real, already-incurred spend crosses the threshold — it's reacting to money you've already spent. A FORECASTED notification fires when AWS predicts, based on your usage pattern so far in the period, that you're on track to cross the threshold before the period ends — that one can warn you while the number is still lower than the limit. Almost every guide sets up ACTUAL-only budgets and stops there, which throws away the one feature that makes a budget better than a plain bank statement.

Thresholds are expressed as a percentage of the budget amount, and AWS's own guidance for the CLI notes that many customers set thresholds anywhere between 50% and 200% of the budgeted amount, with a hard ceiling of 1,000,000% above it if you genuinely need one. A sane starting stack for a $100 monthly budget is a FORECASTED alert at 80%, an ACTUAL alert at 100%, and a second ACTUAL alert at 150% as a "this has clearly gone wrong" tripwire. A budget can hold up to five notifications total, and each notification can have one SNS subscriber plus up to ten email subscribers — eleven recipients on a single threshold if a whole team needs to see it.

Templates: don't build from scratch if you don't need to

AWS Budgets ships with one-page templates that fill in sane defaults for common cases, instead of the full five-step advanced workflow. The two you'll use most:

• Zero spend budget — notifies you after your spending exceeds AWS Free Tier limits. This is the one to set up the same day you open a new account, before you've deployed anything.
• Monthly cost budget — a recurring monthly budget that notifies you if you exceed, or are forecasted to exceed, the amount you set. This is your main ongoing spend guardrail.

Two more templates exist for people managing Reserved Instances or Savings Plans commitments: a daily Savings Plans coverage budget and a daily reservation utilization budget, both of which warn you when your paid-for commitment is going unused rather than when you're overspending. Jake's shop doesn't buy Reserved Instances, so those two won't come up for him — but if you're running always-on infrastructure, an under-utilized commitment is its own kind of wasted money. Every template can also be edited afterward: create it under Custom template settings and every field opens up, including linked-account filters and cost category filters that the simplified single-page workflow hides by default.

Setting up Layer 1, step by step

1. Open the Billing and Cost Management console and choose Budgets in the navigation pane.
2. Choose Create budget, then under Budget setup choose Use a template (simplified).
3. Pick Zero spend budget if this is a new account, or Monthly cost budget for an ongoing guardrail, and enter your budget amount.
4. Enter the email address (or addresses, up to ten per notification) that should receive alerts, or attach an SNS topic instead.
5. If you used the template, edit the notification thresholds afterward: add a FORECASTED alert around 80% and a second ACTUAL alert well past 100% as a hard tripwire, since the template alone won't give you both notification types by default.
6. Choose Create budget.

Layer 2: the CloudWatch billing alarm — a second system, on a second clock

This is the alarm most tutorials treat as the entire solution, and on its own it isn't one — but it's not redundant with Layer 1 either, because it runs on entirely separate infrastructure. AWS Budgets is billing data evaluated by the Budgets service. A CloudWatch billing alarm watches a CloudWatch metric called Total Estimated Charge, calculated and sent to CloudWatch several times a day, representing your worldwide account charges. If AWS Budgets ever has an outage, gets misconfigured, or an SNS subscription silently lapses, a CloudWatch alarm built independently is still watching.

The step almost everyone forgets: enabling billing alerts

Before this metric even exists for you to alarm on, you have to turn on billing alerts once, per account. This is a permanent, one-way switch: once you enable it you cannot disable the data collection again, though you can still delete any alarms you build on top of it later. Go to Billing Preferences, find Alert preferences, choose Edit, check the box for Receive CloudWatch Billing Alerts, and save. After you enable this for the first time, it takes about 15 minutes before the billing data and the option to build alarms actually appear. If you're on a consolidated (Organizations) billing setup, this switch has to be flipped in the management/payer account specifically — enabling it in a member account does nothing, and if you ever change which account is your payer account, you have to re-enable it there too.

The Region trap

Billing metric data is stored in the US East (N. Virginia) Region and represents worldwide charges, no matter which Region your resources actually run in. If you build the alarm from any other Region selected in the console, the Billing metric won't even show up as an option to alarm on. This single detail is responsible for most "I set this up and it's just not there" reports.

Setting up Layer 2, step by step

1. In the Billing and Cost Management console, go to Billing Preferences, edit Alert preferences, check Receive CloudWatch Billing Alerts, and save. Wait roughly 15 minutes.
2. Open the CloudWatch console, and confirm your Region is set to US East (N. Virginia) in the top-right Region selector — the billing alarm cannot be created from anywhere else.
3. In the navigation pane choose Alarms, then All alarms, then choose Create alarm.
4. Choose Select metric, then in the Browse tab choose Billing, then Total Estimated Charge, and select the metric.
5. Set the statistic and period, set your dollar threshold under Static conditions with a "Greater" comparison, and under Additional configuration set Datapoints to alarm to 1 out of 1 and treat missing data as missing.
6. Under Notification, choose In alarm and attach or create an Amazon SNS topic; the topic's subscribers get notified when the alarm state changes.
7. Name the alarm (UTF-8 characters only, no ASCII control characters), review, and create it.

Layer 3: Cost Anomaly Detection — catching the spend that's weird, not just big

Here's the case Layers 1 and 2 both miss on purpose: a charge that's completely under every dollar threshold you've set, but wildly out of character for your account. Say your normal EC2 spend runs about $8 a day and one day it jumps to $35 — still nowhere near a $100 budget, so no alert fires, but something is clearly different. AWS Cost Anomaly Detection exists specifically for this gap. It uses machine learning to understand your spend patterns and trigger alerts when they look abnormal for you, rather than checking a static number.

Monitor types — segment your spend so the model actually works

A single monitor watching your entire account will treat a completely normal seasonal jump in one service as suspicious just because your total spend moved. Cost Anomaly Detection lets you segment by AWS service, by linked account, by cost allocation tag, or by cost category, because your Amazon EC2 spend pattern and your AWS Lambda spend pattern are naturally different curves, and mixing them into one number makes both harder to judge. You can create up to one AWS Services monitor and up to 500 custom monitors covering linked accounts, tags, or cost categories, with up to 501 total attachable to an alert subscription. For most solo accounts and small shops, the default AWS Services monitor alone catches the majority of real problems; add a linked-account or tag-based monitor only once you actually have more than one team or project sharing the bill.

Alert subscriptions — pick a cadence that matches how you actually check email

When you attach an alert subscription to a monitor, you choose between individual alerts (one notification per anomaly, as it's found), a daily summary, or a weekly summary, delivered by email or an SNS topic. A daily summary is the sane default for most people — enough to catch a problem within 24 hours without turning your inbox into a stream of pings every time a normal end-of-month usage spike looks slightly unusual.

Setting up Layer 3, step by step

1. Open the Billing and Cost Management console and choose Cost Anomaly Detection in the navigation pane.
2. Check the Cost monitors tab first — if your account has been auto-configured with an AWS Services monitor already, you don't need to build that one from scratch.
3. To add another, choose Create monitor, pick a monitor type (AWS Services, linked account, cost allocation tag, or cost category), and name it something you'll recognize later.
4. Go to the alert subscription step, name your subscription, choose email or SNS as the delivery channel, and add recipients.
5. Choose your alert cadence — individual, daily summary, or weekly summary — and, for email subscribers, set an absolute or percentage threshold and frequency for when they get notified.
6. Save the subscription. New monitors typically need up to 24 hours before they start surfacing alerts, since the model needs at least some spend data to evaluate against.

The step right after Layer 3: activating cost allocation tags

A tag-based cost monitor is only as good as the tags underneath it, and this is the part people skip because nothing in the setup wizard forces the issue. Applying a tag like CostCenter: recovery-tool to an EC2 instance does not automatically make it show up anywhere in Cost Explorer, a budget filter, or an anomaly monitor. Tags have to be activated first.

AWS splits cost allocation tags into two kinds. AWS-generated tags are ones AWS defines, creates, and applies for you. User-defined tags are the ones you create and apply yourself — think project, environment, or owner. Both types have to be activated separately in the Billing and Cost Management console before they'll appear anywhere in cost reporting, and once you activate or deactivate a tag key, that decision applies to every value under that key at once.

Activating tags, step by step

1. Create and apply your tags to resources first — a tag key created after a resource already exists won't retroactively apply to that resource.
2. In the Billing and Cost Management console, choose Cost allocation tags in the navigation pane.
3. Select the tag keys you want to activate under either the AWS-Generated or User-Defined tab, and choose Activate. You can also do this in bulk using the UpdateCostAllocationTagsStatus API operation if you're scripting the setup.
4. Wait — it can take up to 24 hours for a newly created tag key to even appear on the activation page, and then up to another 24 hours for the activation itself to take effect.

Two details worth knowing before you rely on this for anomaly monitoring: only a management account in an organization, or a standalone account that isn't part of one, has access to the cost allocation tags manager — a member account can't activate its own tags independently. And if an account ever moves between organizations, its previously activated tags lose their active status and the new management account has to reactivate them, which is an easy thing to forget if you reorganize accounts and then wonder why a tag-based anomaly monitor suddenly goes quiet.

Who else can see these alerts: the IAM side of billing access

By default, IAM users and roles cannot access the Billing and Cost Management console at all — only the account root user can see it out of the box. If you want anyone other than the root user to see a budget, edit an alarm, or check on a cost monitor, two separate things have to happen: the root user has to activate IAM access to Billing once (a one-time, account-wide switch), and each user or role still needs an actual IAM policy attached that grants the specific billing permissions they need.

To build a budget from the console yourself, you also need permission to view billing information, create CloudWatch alarms, and create Amazon SNS notifications — all three, since a budget notification is really just AWS wiring those three services together on your behalf. AWS provides a managed Billing job-function policy that covers viewing account usage and viewing and modifying budgets and payment methods, which is the fastest way to hand a trusted teammate full billing visibility without writing a custom policy from scratch. If you're building budgets or alarms programmatically instead of through the console, AWS recommends creating a distinct IAM role just for that programmatic access, separate from whatever role controls console access — it keeps who can see the console cleanly separated from what can call the API.

Where each layer fails on its own — and why the other two catch it

Ethan's take is blunt about this: "People treat these three like they're competing for the same job. They're not. Each one is structurally incapable of doing what the other two are for." Here's the honest breakdown of what each one cannot do, by design, not by accident:

• AWS Budgets alone: if you only attach ACTUAL notifications and skip FORECASTED ones, you've built a system that can only tell you after the fact — the exact weakness people assume a budget solves. A budget also has no idea what "normal" looks like for you; it just compares against a flat number you chose, so a genuinely unusual charge sitting comfortably under your threshold sails through silently. And there's an inherent reporting delay: there can be a lag between when you incur a charge and when the resource usage is actually billed, so you might exceed a threshold before AWS Budgets can notify you, and your spend can keep moving in either direction after the notification lands.
• CloudWatch billing alarm alone: it's blind to gradual creep if your threshold is set too generously, since it only compares against one static dollar figure with no forecasting behavior at all. It also updates only a handful of times a day, so a sudden overnight spike sits unreported for hours. And it depends entirely on you remembering the one-time, permanent step of enabling billing alerts and being in the correct Region when you build it — both easy to get wrong on the first try.
• Cost Anomaly Detection alone: it needs your account's own history to learn what's normal, so a brand-new account or one that just went through a genuine, planned scale-up will produce either weak signal or false positives for a while. It also has no concept of an absolute dollar ceiling — it will happily stay quiet through a slow, steady creep that never looks statistically "anomalous" even as it quietly triples your bill over six months. And it can only tag and segment spend that's actually been tagged and activated — an untagged resource just falls into the general AWS Services monitor bucket instead of a monitor built for it.

Stack all three and the gaps close. Budgets warns you before the money's gone. The CloudWatch alarm is a second, independent tripwire that doesn't care about forecasts or machine learning, just a number. Anomaly Detection watches for the case that's technically under every threshold but wrong for you specifically. None of them cost anything to run beyond what CloudWatch alarm evaluation itself costs under CloudWatch's standard alarm pricing — Budgets monitoring and notifications are free, and Cost Anomaly Detection is a free tool, though action-enabled budgets that automatically restrict permissions or resources are a separate, paid feature you'd opt into deliberately.

The Free Tier special case: set this up before you deploy anything

If you're new to AWS, the single highest-value five minutes you can spend is creating a Zero spend budget before you launch a single instance. This template notifies you after your spending exceeds AWS Free Tier limits — which means the moment you accidentally leave something running past the free allowance, or pick a resource size that was never covered by the Free Tier to begin with, you get a warning instead of a surprise. This is the one layer that genuinely works from minute one, with zero spending history required, because it isn't forecasting or learning anything — it's just watching for the first dollar.

When you set all three up and nothing ever arrives

Every one of these three tools has a specific, boring reason it goes quiet, and every one of them is checkable in under a minute:

• Budget alerts never arrive: if you used an SNS topic, confirm you actually accepted the subscription confirmation email — an unconfirmed SNS subscription silently drops every notification with no error shown anywhere in the Budgets console. If you used plain email, check spam, and check that you didn't exceed the ten-email cap per notification.
• CloudWatch billing alarm never triggers, even though you know you're over: confirm the console Region is US East (N. Virginia) — the Billing/Total Estimated Charge metric doesn't exist to select in any other Region. Then confirm you enabled Receive CloudWatch Billing Alerts in Billing Preferences and waited the roughly 15 minutes it takes to propagate. If you're on consolidated billing, confirm the switch was flipped in the management/payer account, not a member account.
• Anomaly alerts never show up: a brand-new monitor can take up to 24 hours to start evaluating, so give it a full day before assuming it's broken. Also check whether you're looking under the wrong account — cost monitors and alert subscriptions are only visible to the account that created them, so a monitor built under a member account is invisible to the management account and vice versa. If it's a tag-based monitor, confirm the tag key was actually activated — a tag key can sit unactivated for 24 hours after AWS first notices it exists, which reads as "the monitor isn't working" but is really "the tag isn't visible to it yet."
• You genuinely crossed a threshold and nothing fired anywhere: remember the built-in reporting delay — there's a gap between when a resource is used and when that usage is actually billed, so your Budgets and CloudWatch alarm are both working from slightly stale numbers by design, not because they're broken.

If you can only set up one today, set up Layer 1

Ethan doesn't hedge on this one: "If you're only doing one thing today, it's the Budget with a forecasted alert. Everything else is a better version of 'after,' but that's the only one that has a shot at telling you 'before.'" A CloudWatch billing alarm is the fastest to build once billing alerts are already enabled, and Cost Anomaly Detection needs the least ongoing attention once it's running — but neither of them can warn you while the number is still climbing instead of after it's already landed. Set up the budget first, add the alarm the same sitting if you can, and treat anomaly detection as the layer you check on and tune over the following weeks as your account builds a real spending history — that's also the point to go back and activate the tags in the section above, once you have a rough sense of which projects or resources actually need their own monitor.

Frequently asked questions

Do I need to enable anything before I can use AWS Budgets?

No. Unlike the CloudWatch billing alarm, AWS Budgets works the moment you open the Budgets page — there's no separate "enable billing alerts" switch required first.

Why didn't my CloudWatch billing alarm show the Billing metric at all?

Almost always a Region issue. Billing metric data is stored specifically in US East (N. Virginia) and represents your worldwide charges — if your console Region is set to anything else, the Billing/Total Estimated Charge metric simply won't appear to select.

Can I turn off billing alerts once I've enabled them?

You can't disable the underlying data collection once you've enabled it for your account, but you can delete any individual billing alarms you've built on top of that data at any time.

What's the actual difference between ACTUAL and FORECASTED budget alerts?

ACTUAL fires based on money you've already spent. FORECASTED fires when AWS predicts, from your usage pattern so far in the period, that you're on track to cross your threshold before the period ends — it's the only alert type in this whole setup that can warn you ahead of the charge.

How many people can get notified by one budget alert?

Each notification on a budget supports one SNS subscriber plus up to ten email subscribers — eleven recipients total per notification, and a single budget can hold up to five separate notifications.

I set up SNS for my budget and never got an email. What happened?

Almost certainly an unconfirmed subscription. For a budget notification to actually reach you through SNS, the budget needs permission to publish to the topic, and you have to accept the subscription confirmation for that topic — an easy step to miss since the confirmation email doesn't look urgent.

Does a billing alarm stop my resources from running once it fires?

No. A basic CloudWatch billing alarm only sends a notification through the SNS topic you attach. Stopping resources or restricting permissions automatically requires configuring separate, paid budget actions — an alarm or alert by itself never shuts anything down.

Is Cost Anomaly Detection already running on my account without me setting it up?

Possibly. Since March 27, 2023, new Cost Explorer customers with a Payer or Regular account get an automatic AWS Services monitor and a daily email alert subscription with no manual configuration. Check the Cost monitors tab before assuming you need to build one from scratch.

Why would I segment anomaly monitors by service instead of using one monitor for everything?

Different services have naturally different spend patterns — your EC2 usage curve and your Lambda usage curve don't look alike. Segmenting lets the model judge each pattern on its own terms, which reduces false positives compared to judging your entire account total as one blended number.

How many cost monitors can I actually create?

Up to one AWS Services monitor plus up to 500 custom monitors covering linked accounts, cost allocation tags, or cost categories, for a maximum of 501 monitors attachable to a single alert subscription.

Why do I need to activate a tag before I can use it in a cost monitor?

For tags to appear on your billing reports or be usable as a filter anywhere in Cost Explorer, Budgets, or Cost Anomaly Detection, you have to activate the tag key in the Cost allocation tags page first. Applying the tag to a resource alone doesn't make it visible to any billing or cost tool.

Why can't my IAM user see the Cost Anomaly Detection page even though they can see my budgets?

Activating IAM Access to the Billing console doesn't extend to everything under the billing umbrella. It specifically doesn't control access to the Cost Anomaly Detection console pages, the Savings Plans console pages, or the underlying Billing and Cost Management SDK APIs — those need their own IAM permissions granted separately.

What's a Zero spend budget for, exactly?

It's a budget template that notifies you after your spending exceeds AWS Free Tier limits — useful specifically because it works from day one with no spend history and no dollar figure you have to guess at yourself.

If I already crossed my threshold, why did my alarm or budget notify me late?

There's a built-in delay between when a resource is used and when that usage is actually billed. You can incur additional costs beyond your notification threshold before Budgets or a CloudWatch alarm can catch up, and your spending can keep changing in either direction after the alert lands — this is a structural reporting lag, not a misconfiguration.

Does any of this cost extra to run, and does anyone besides the root user need special access to set it up?

Monitoring and notifications through AWS Budgets are free, and Cost Anomaly Detection is a free tool. A CloudWatch billing alarm falls under CloudWatch's standard alarm pricing, so check AWS's current CloudWatch pricing page for the specific rate in your account. The one feature in this stack that carries a distinct, separate cost is action-enabled budgets that automatically restrict permissions or resources. On access: IAM users can't reach the Billing console by default, so the root user has to activate IAM Access once and then attach the right billing permissions — such as the AWS managed Billing job-function policy — to whoever needs to build or view these alerts.

Revision note. Written September 2026, covering AWS Budgets, CloudWatch billing alarms, Cost Anomaly Detection, cost allocation tags, and the IAM permissions behind all three, as currently documented in the Billing and Cost Management, CloudWatch, and IAM consoles. This will need a revisit if AWS changes the default Cost Anomaly Detection configuration again or reworks the Budgets notification limits. If you're reading this because a bill already surprised you, you're not the first person this has happened to, and getting these layers running today is enough to make sure it's the last time.Happy learning, See you on next post.!