AWS Cost Control 101: Cost Explorer, Budgets, Alerts & Free-Tier Guardrails

Quick take: AWS charges you per-second for things you forgot you turned on. The four controls that stop a surprise bill are all free or nearly free: a free-tier usage alert, a Budget with an 80%/100% threshold wired to SNS, a CloudWatch billing alarm (only in us-east-1), and Cost Anomaly Detection. Cost Explorer tells you where the money went; the Cost and Usage Report (CUR) in S3 tells you down to the resource. Set all four on day one, before you launch anything.

A developer spins up a quick demo: a t3.micro behind an Application Load Balancer, an RDS database, and — because a tutorial said so — a NAT gateway in each of three Availability Zones so the private subnets can reach the internet. The EC2 instance is inside the Free Tier, so they assume the whole thing is free. Three weeks later a $180 bill arrives. The instance was indeed free. The three NAT gateways were not: roughly $0.045 per hour each plus $0.045 per GB processed, running 24×7, is about $97/month before a single byte of app traffic — and the ALB, the RDS storage, and a handful of unattached Elastic IPs did the rest. Nobody set an alert, so nobody knew until the invoice landed.

This article is the guardrail that would have caught it on day two instead of day thirty. It is written for someone new to AWS billing but it does not hand-wave: you will learn exactly what the Free Tier covers (and its three very different flavours), how to turn on free-tier usage alerts, how to enable and drive Cost Explorer (filters, group-by, granularity, forecast, RI/Savings Plans reports), how to build every kind of AWS Budget and wire its thresholds to SNS/email, the crucial difference between actual and forecasted alerts, how to add the CloudWatch billing alarm that only lives in us-east-1, how Cost Anomaly Detection learns your baseline, how consolidated billing works across an organization, and how the CUR lands hourly line items in S3 for deep analysis. Every step comes with the Console path, the aws CLI, and Terraform.

By the end you will never be surprised by an AWS bill again — not because AWS got cheaper, but because you built the trip-wires. You will also know the usual suspects behind a shock invoice (NAT gateway hours and data, inter-AZ and internet egress, idle Elastic IPs and EBS volumes, forgotten load balancers and RDS instances, verbose CloudWatch Logs) and exactly which Cost Explorer filter surfaces each one. Cost control on AWS is not an accounting chore you do at month-end; it is four small, mostly free objects you create before you build.

What problem this solves

AWS is pay-as-you-go with no spending cap by default. There is no “stop at $50” switch on a personal account — the platform will happily let a misconfigured resource, a runaway Lambda loop, a leaked access key running crypto-mining, or three forgotten NAT gateways bill you for the entire month. The bill is only tallied and shown to you after the usage happens, and full invoice detail can lag by up to a day. If you have not set up any alerting, the first time you learn about a problem is the invoice — by which point the money is already spent.

What breaks without cost control is not the workload; it is your wallet and your trust in the platform. The three shapes this pain takes are:

• The slow leak — a resource that quietly bills 24×7 (a NAT gateway, an idle RDS Multi-AZ, an unattached gp3 volume, a public IPv4 address). Individually small, collectively a few hundred dollars a month, invisible until you look. The fix is a Budget and a monthly Cost Explorer review.
• The spike — a sudden jump: a data-transfer explosion, a fan-out Lambda bug, a new service someone launched, a compromised key. The fix is Cost Anomaly Detection (learns the baseline, alerts on the deviation) plus a forecasted Budget alert.
• The Free-Tier cliff — you were “on the Free Tier” and blew past a limit (750 EC2 hours, 5 GB of S3, 1 TB of CloudFront egress) without noticing. The fix is free-tier usage alerts plus a small dollar Budget as a backstop.

Everyone hits at least one of these. Beginners hit all three in their first month. The controls in this article are the standard, AWS-native answer — and, importantly for a learner, they are free or cost cents, so there is no excuse to skip them.

Learning objectives

By the end of this article you can:

• Explain the three kinds of Free Tier (12-month, always-free, short-term trials) and the newer credit-based sign-up plan, and enable free-tier usage alerts.
• Navigate the Billing and Cost Management console and turn on Cost Explorer and the Receive Billing Alerts preference.
• Drive Cost Explorer end-to-end: filter, group-by service/tag/account, change granularity, read the forecast, and open RI/Savings Plans coverage and utilization reports.
• Create every type of AWS Budget (cost, usage, RI, Savings Plans) with actual and forecasted threshold alerts to SNS/email, and understand budget actions.
• Add a CloudWatch billing alarm on AWS/Billing EstimatedCharges in us-east-1, and know why it must be there.
• Turn on Cost Anomaly Detection with a monitor and an alert subscription.
• Understand consolidated billing, blended rates, and how the Free Tier and RI/SP sharing behave across an organization.
• Enable a Cost and Usage Report (CUR) to S3 and know when to reach for it over Cost Explorer.
• Recognise the top surprise-bill culprits and the exact Cost Explorer filter that surfaces each.

Prerequisites & where this fits

You need an AWS account you can log into as the root user or an IAM/IAM Identity Center principal with billing access, and the AWS CLI v2 configured (aws configure or aws sso login). Terraform is optional but every step includes an aws provider snippet. A few tasks — enabling Cost Explorer, toggling billing preferences, viewing the Bills page — are management-account / root actions in an organization or require an explicit billing IAM policy (aws-portal:*, or the newer fine-grained billing, ce, budgets, cur actions). Nothing here needs you to launch a paid resource.

Where it fits: this is the foundation of the FinOps and governance track, and the first thing you should do in any new account. It sits directly beneath tagging (you tag resources so Cost Explorer and the CUR can slice by team/project — see the companion piece on tagging strategy and cost-allocation enforcement), quotas (service limits stop runaway counts; budgets stop runaway spend — see the companion on service quotas and limit-increase requests), and anomaly troubleshooting (when a spike fires, you triage it — see the companion on cost-spike anomaly-detection troubleshooting). It builds on account structure from AWS Organizations and IAM Foundations and pairs with the network cost knowledge in Amazon VPC, Subnets and Security Groups Explained.

Core concepts

Cost management on AWS is a small vocabulary. Learn these words precisely — the tools, the exam, and the invoices all use them exactly.

The single most important mental model is latency. Cost data is not real-time; each tool sees it on a different delay, which is the source of half the “why is it showing nothing?” confusion.

Because everything lags, you cannot use these tools to stop spend in real time — you use them to catch a problem within hours, not seconds. The only thing close to a hard stop is a budget action that applies a restrictive policy, and even that fires on the (delayed) budget evaluation, not instantly.

The AWS Free Tier: 12-month, always-free, and trials

“Free Tier” is three completely different things wearing one name. Confusing them is the number-one cause of a beginner’s first surprise bill.

The 12-month allowances (the ones that expire)

These are free for 12 months from the day you create the account, then bill at standard rates with no warning other than the alert you set. The headline members:

The always-free allowances (forever, monthly)

These never expire; you only pay for usage above the monthly cap. The important ones for a beginner:

Short-term trials (start on first use)

These are per-service free trials that begin the moment you first enable the service, run for a fixed window, and then bill fully. They do not align with your 12-month clock.

The newer credit-based sign-up plan

For accounts created from mid-2025 onward, AWS layered a credit-based free plan on top: on sign-up you receive credits (a sign-up grant plus more for completing onboarding activities, on the order of up to $200 total), valid for a limited window (about 6 months), and you can operate in a “free account plan” that will not incur charges until you deliberately upgrade to a paid plan — at which point normal Free Tier + pay-as-you-go rules apply. Legacy accounts keep the classic 12-month tier. Because both models are in the wild, always check Billing → Free tier and Billing → Credits to see which you have and how much runway remains.

Free-tier usage alerts

Independent of Budgets, AWS emails you when you are forecast to exceed 85% of a 12-month/always-free limit. Turn it on once:

# View current free-tier usage (needs the newer Free Tier API / console)
aws freetier get-free-tier-usage --region us-east-1 \
  --query 'freeTierUsages[].[service,usageType,actualUsageAmount,limit,forecastedUsageAmount]' \
  --output table

This is your first, zero-cost guardrail. It will not stop you crossing a limit — nothing does — but it means you find out at 85%, not on the invoice.

The Billing console and enabling Cost Explorer

Everything lives under Billing and Cost Management (the console link is usually your account-name menu → Billing and Cost Management). The pages you will use:

Two preferences unlock the alerting in this article. Set both once, in us-east-1 context:

Enabling Cost Explorer

Cost Explorer is off until you enable it once. Go to Billing → Cost Explorer → Launch/Enable. The first enable back-fills roughly the last 24 hours of history and up to ~12–14 months of past data over the following day — so if you enable it and it looks empty, that is expected; come back tomorrow. There is no CLI to “enable” it (it is an account-level, one-time console action), but once enabled the Cost Explorer API (ce) works:

# After enabling in the console, confirm the ce API responds (each call = $0.01)
aws ce get-cost-and-usage \
  --time-period Start=2026-06-01,End=2026-07-01 \
  --granularity MONTHLY \
  --metrics "UnblendedCost" \
  --query 'ResultsByTime[].Total.UnblendedCost' --output table

Once enabled, you can also grant IAM principals ce:* (read) so a team can self-serve without root.

Cost Explorer in depth

Cost Explorer answers “where did the money go, and where is it heading?” It is a UI over the same data the CUR holds, minus per-resource detail unless you pay for it. Four levers control every view: filter, group by, granularity, and date range (with forecast and cost type on top).

Filters — narrow the population

You can filter a report by any of these dimensions (include or exclude), and stack multiple filters (AND across dimensions, OR within one):

Group by — pivot the axis

The single most useful skill: group by Service for the what, group by Usage type for the culprit, group by Tag for the who, group by Linked account for the where.

Only one primary group-by applies at a time in the UI; combine with filters to drill (e.g. filter Service = EC2, group by Usage type → see BoxUsage vs NatGateway vs DataTransfer).

Granularity and date range

Cost types — the number is not one number

The same usage has several legitimate “costs” depending on how you treat commitments and org sharing. Pick deliberately:

Forecast

Cost Explorer’s forecast uses your history to project month-end (and up to 12 months out) with an 80% confidence interval. It needs a baseline — on a brand-new account or right after a big architecture change the forecast is wildly off, because there is little or contradictory history. Forecast improves after a few weeks of steady usage.

RI and Savings Plans reports

If you buy commitments, Cost Explorer ships purpose-built reports:

Saved reports and defaults

Cost Explorer ships default reports (Monthly costs by service, Daily costs, Monthly costs by linked account, RI/SP utilization & coverage, etc.) and lets you save any customised view. Saved reports are how a team standardises “the three views we check every Monday.”

# Cost Explorer itself is enabled in the console (one-time), but you can
# codify an "anomaly monitor" and cost categories that shape CE. Example: a
# cost category that maps usage into business buckets Cost Explorer can group by.
resource "aws_ce_cost_category" "product" {
  name         = "Product"
  rule_version = "CostCategoryExpression.v1"

  rule {
    value = "Checkout"
    rule {
      tags {
        key           = "Product"
        values        = ["checkout"]
        match_options = ["EQUALS"]
      }
    }
  }
  rule {
    value = "Platform"
    rule {
      dimension {
        key           = "LINKED_ACCOUNT"
        values        = ["111122223333"]
        match_options = ["EQUALS"]
      }
    }
  }
}

AWS Budgets: cost, usage, RI, Savings Plans, and budget actions

A Budget is a target plus one or more alert thresholds that notify (and optionally act) when crossed. This is your primary trip-wire.

Budget types

Budget parameters

Actual vs forecasted — the distinction that trips everyone

The standard pattern for a small account: actual at 80% and 100%, plus forecasted at 100% once you have a few weeks of history. On a brand-new account, skip forecasted until the forecast stabilises, or it will scream on day two.

Budget actions — make it actually stop

A budget action runs automatically (or after manual approval) when a threshold is crossed. This is the closest AWS gets to a spending cap.

Actions can require approval (someone clicks “execute”) or run automatically. Use them carefully — an auto-applied Deny SCP that fires on a forecast blip can lock a team out of the account. Prefer approval-required for anything destructive.

Notification targets

For SNS, the topic access policy must allow budgets.amazonaws.com to SNS:Publish — the number-one reason a budget alert never arrives is a missing topic policy or an unconfirmed subscription.

Budgets pricing

CLI and Terraform

# Create a $10/month cost budget (JSON files shown in the lab section)
aws budgets create-budget \
  --account-id 111122223333 \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

resource "aws_budgets_budget" "monthly_cost" {
  name         = "monthly-cost-10usd"
  budget_type  = "COST"
  limit_amount = "10"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_types {
    include_credit = false
    include_refund = false
    include_tax    = true
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_sns_topic_arns  = [aws_sns_topic.budget_alerts.arn]
    subscriber_email_addresses = ["ops@example.com"]
  }

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 100
    threshold_type             = "PERCENTAGE"
    notification_type          = "FORECASTED"
    subscriber_sns_topic_arns  = [aws_sns_topic.budget_alerts.arn]
  }
}

The CloudWatch billing alarm

Before Budgets existed, this was the cost alert, and it is still the cheapest near-real-time signal. AWS publishes a single running metric, EstimatedCharges in the AWS/Billing namespace — but only to CloudWatch in us-east-1, and only after you opt in to “Receive CloudWatch billing alerts.”

# 1) Confirm the metric exists (only works in us-east-1, after opt-in)
aws cloudwatch list-metrics --namespace "AWS/Billing" \
  --metric-name EstimatedCharges --region us-east-1

# 2) Create an alarm that fires when month-to-date > $10
aws cloudwatch put-metric-alarm --region us-east-1 \
  --alarm-name "billing-over-10-usd" \
  --namespace "AWS/Billing" --metric-name EstimatedCharges \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum --period 21600 --evaluation-periods 1 \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:billing-alerts

resource "aws_cloudwatch_metric_alarm" "billing" {
  provider            = aws.use1              # MUST be us-east-1
  alarm_name          = "billing-over-10-usd"
  namespace           = "AWS/Billing"
  metric_name         = "EstimatedCharges"
  dimensions          = { Currency = "USD" }
  statistic           = "Maximum"
  period              = 21600
  evaluation_periods  = 1
  threshold           = 10
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.budget_alerts.arn]
}

Budgets vs the billing alarm: Budgets is richer (usage/RI/SP, forecast, filters, actions, per-service) and is what you build going forward; the CloudWatch alarm is a dead-simple total-dollar trip-wire that many teams keep as a belt-and-braces backstop.

Cost Anomaly Detection

Budgets and alarms fire on thresholds you guessed. Cost Anomaly Detection (CAD) is different: it uses machine learning to learn your normal spend pattern per service and alerts when reality deviates — catching the spike you did not think to threshold. It is free.

Monitors — what CAD watches

Alert subscriptions

# A monitor over all AWS services
aws ce create-anomaly-monitor --anomaly-monitor \
  '{"MonitorName":"all-services","MonitorType":"DIMENSIONAL","MonitorDimension":"SERVICE"}'

# A subscription that emails when an anomaly's impact exceeds $50
aws ce create-anomaly-subscription --anomaly-subscription '{
  "SubscriptionName":"anomalies-over-50",
  "MonitorArnList":["arn:aws:ce::111122223333:anomalymonitor/…"],
  "Frequency":"IMMEDIATE",
  "Subscribers":[{"Type":"EMAIL","Address":"ops@example.com"}],
  "ThresholdExpression":{"Dimensions":{"Key":"ANOMALY_TOTAL_IMPACT_ABSOLUTE","Values":["50"],"MatchOptions":["GREATER_THAN_OR_EQUAL"]}}
}'

resource "aws_ce_anomaly_monitor" "services" {
  name              = "all-services"
  monitor_type      = "DIMENSIONAL"
  monitor_dimension = "SERVICE"
}

resource "aws_ce_anomaly_subscription" "over_50" {
  name      = "anomalies-over-50"
  frequency = "IMMEDIATE"
  monitor_arn_list = [aws_ce_anomaly_monitor.services.arn]

  subscriber {
    type    = "EMAIL"
    address = "ops@example.com"
  }

  threshold_expression {
    dimension {
      key           = "ANOMALY_TOTAL_IMPACT_ABSOLUTE"
      values        = ["50"]
      match_options = ["GREATER_THAN_OR_EQUAL"]
    }
  }
}

CAD needs about 10 days of history to build a baseline. Deep-dive triage of a fired anomaly (root-causing the exact usage type and resource) is its own discipline — see the companion piece on cost-spike anomaly-detection troubleshooting.

Consolidated billing across an organization

If you use AWS Organizations, the management (payer) account receives one consolidated bill for all member (linked) accounts. This is not just convenience — it changes the numbers.

The Free-Tier rule surprises people: spin up ten member accounts thinking each gets 750 free EC2 hours, and you get 750 total, not 7,500. Turn off RI/SP sharing for an account when a team wants to see its own un-subsidised cost. Governance of member accounts (SCPs, guardrails, account vending) is covered in AWS Control Tower, Guardrails and the Multi-Account Foundation.

The Cost and Usage Report (CUR)

Cost Explorer is a UI with limits (14 months, coarse resource detail). When you need every line item, hourly, at resource granularity, queryable in SQL, you enable the Cost and Usage Report — the most detailed billing data AWS produces — delivered to your S3 bucket (now via Data Exports / CUR 2.0).

CUR vs Cost Explorer, at a glance:

# List existing CUR definitions (must run in us-east-1)
aws cur describe-report-definitions --region us-east-1

# Create a Parquet, hourly, resource-level CUR (report def JSON abbreviated)
aws cur put-report-definition --region us-east-1 --report-definition '{
  "ReportName":"kloudvin-cur",
  "TimeUnit":"HOURLY",
  "Format":"Parquet",
  "Compression":"Parquet",
  "AdditionalSchemaElements":["RESOURCES"],
  "S3Bucket":"kloudvin-cur-111122223333",
  "S3Prefix":"cur",
  "S3Region":"us-east-1",
  "ReportVersioning":"OVERWRITE_REPORT"
}'

resource "aws_cur_report_definition" "cur" {
  provider                   = aws.use1
  report_name                = "kloudvin-cur"
  time_unit                  = "HOURLY"
  format                     = "Parquet"
  compression                = "Parquet"
  additional_schema_elements = ["RESOURCES"]
  s3_bucket                  = aws_s3_bucket.cur.id
  s3_region                  = "us-east-1"
  s3_prefix                  = "cur"
  additional_artifacts       = ["ATHENA"]
  report_versioning          = "OVERWRITE_REPORT"
}

The biggest surprise-bill culprits

Most shock bills come from a short list of resources that bill 24×7 regardless of app traffic, or that meter data you did not realise moved. Learn this table and the Cost Explorer filter that finds each — it is the single most valuable page here.

Data transfer pricing (the invisible meter)

The lesson: egress and cross-AZ transfer are the meters you cannot see in the console’s resource list. Cost Explorer grouped by Usage type is the only place they become obvious.

Architecture at a glance

The diagram traces one dollar of cost from the resource that spends it to the human who gets alerted, left to right, and marks the six points where a beginner’s setup breaks. Start at USAGE: your running resources (EC2, RDS, EBS, ALB) meter continuously, and the classic culprit — a NAT gateway at ~$0.045/hr plus ~$0.045/GB, per AZ (badge 1) — bills 24×7 whether or not your app is busy. That usage flows into COST DATA: Cost Explorer renders it in the UI after a ~24-hour lag and a one-time enable (badge 2), while the CUR lands hourly Parquet line items in an S3 bucket for deep, per-resource SQL analysis (badge 3).

Three MONITORS watch that data: AWS Budgets evaluates both actual and forecasted spend against your thresholds (badge 4), Cost Anomaly Detection compares reality to an ML baseline, and a CloudWatch billing alarm on EstimatedCharges — which exists only in us-east-1 after you opt in (badge 5). When any of them crosses its line, the BREACH → FAN-OUT stage publishes to a single SNS topic — but only if the subscription is confirmed and the topic policy lets budgets.amazonaws.com publish (badge 6). Finally, NOTIFY + ACT delivers the alert to an email/Slack inbox and can trigger an automated budget action (apply a restrictive SCP/IAM policy or stop tagged EC2/RDS) — the closest AWS gets to a hard cap. Read the legend as symptom · how to confirm · fix for each numbered failure point.

Real-world scenario

FrameHive, a five-person video-tooling startup in Bengaluru, ran everything in one AWS account on a personal credit card. Their architect had spread the app across three AZs “for resilience,” following a reference architecture that placed a NAT gateway in each private subnet. Month one, the founder — who had signed up believing the t3.micro tier meant “basically free” — got a ₹14,800 (~$178) bill and panicked, assuming they had been hacked.

They had not. The triage, using exactly the tools in this article, took twenty minutes. First, Cost Explorer → group by Service showed the money split roughly: EC2-Other $71, EC2 $9, RDS $58, ELB $16, CloudWatch $12, everything else <$12. “EC2-Other” is where AWS files NAT gateways, EBS, and data transfer — so the founder re-ran with group by Usage type, which is the move that cracks every one of these. The top rows were unmistakable: NatGateway-Hours $97 across three gateways, NatGateway-Bytes $14, EBS:VolumeUsage.gp3 $11 on two volumes attached to instances they had terminated (the volumes were not deleted on termination), and PublicIPv4:InUseAddress $8 for addresses on resources they forgot they had.

The fixes were structural and free-to-cheap. They deleted two NAT gateways and kept one (dev traffic did not need per-AZ NAT), saving ~$65/month, and replaced S3 and DynamoDB access with gateway VPC endpoints (free) so that traffic never touched NAT at all. They deleted the two orphaned gp3 volumes and set DeleteOnTermination=true on future instances. They released the idle Elastic IPs. RDS was legitimately needed but was Multi-AZ on a db.t3.medium for a dev database — they dropped it to Single-AZ db.t3.micro (inside the 12-month tier), cutting it to near-zero.

Then they built the guardrails so this could never recur silently. A $50/month cost Budget with actual alerts at 80% and 100% and a forecasted alert at 100%, all to an SNS topic that fanned to the whole team’s Slack via AWS Chatbot. A CloudWatch billing alarm at $30 in us-east-1 as a backstop. Cost Anomaly Detection with an all-services monitor and a $25 impact threshold. And free-tier usage alerts on, so the next time they approached 750 EC2 hours they would know at 85%. The next month’s bill was ₹1,900 (~$23) — and when a teammate later left a load-test ALB running over a weekend, the anomaly alert fired on Saturday morning, not on the invoice. Total cost of all four guardrails: under $1/month.

Advantages and disadvantages

Cost Explorer + Budgets + free-tier alerts cover the 90% case for a beginner at essentially no cost. Reach for the CUR and Cost Categories only when a single account’s spend gets big enough to need chargeback and per-resource audits. Reserve budget actions (especially auto-apply SCP/IAM) for accounts where a runaway is genuinely dangerous, and prefer approval-required to avoid self-inflicted lockouts.

Hands-on lab

You will set a free-tier alert, create a $10 monthly cost Budget with 80% and 100% SNS alerts, and add a CloudWatch billing alarm — via Console, aws CLI, and Terraform — then tear it all down. Nothing here launches a paid resource; SNS and the first two budgets and ten alarms are within free limits.

⚠️ Cost note: 3rd+ budgets cost $0.02/day; the first two are free. SNS email and 10 CloudWatch alarms are free-tier. This lab stays free.

Part A — Turn on the two billing preferences (Console)

1. Sign in and open Billing and Cost Management. Ensure the console Region shows us-east-1 for billing actions (top-right selector) — billing data is global but published in us-east-1.
2. Go to Billing preferences → Alert preferences → Edit.
3. Tick Receive AWS Free Tier alerts and enter an ops email in Additional email address.
4. Tick Receive CloudWatch billing alerts (this enables the EstimatedCharges metric).
5. Save. Expected: both toggles show enabled; the CloudWatch metric appears in us-east-1 within a few hours.

Part B — Create the SNS topic and confirm a subscription (CLI)

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

# Create the topic in us-east-1 (so Budgets + the billing alarm can share it)
TOPIC_ARN=$(aws sns create-topic --name billing-alerts --region us-east-1 \
  --query TopicArn --output text)
echo "$TOPIC_ARN"   # arn:aws:sns:us-east-1:<acct>:billing-alerts

# Subscribe your email; AWS emails a confirmation link you MUST click
aws sns subscribe --topic-arn "$TOPIC_ARN" --protocol email \
  --notification-endpoint ops@example.com --region us-east-1

# Verify: after clicking the link, this should show a real SubscriptionArn
aws sns list-subscriptions-by-topic --topic-arn "$TOPIC_ARN" --region us-east-1 \
  --query 'Subscriptions[].[Endpoint,SubscriptionArn]' --output table

Expected: before you click the email link, SubscriptionArn is PendingConfirmation; after, it is a real ARN. An unconfirmed subscription receives nothing — this is the most common “my alert never came” bug.

Now allow Budgets to publish to the topic (attach an access policy):

aws sns set-topic-attributes --region us-east-1 --topic-arn "$TOPIC_ARN" \
  --attribute-name Policy --attribute-value "{
    \"Version\":\"2012-10-17\",
    \"Statement\":[{
      \"Sid\":\"AllowBudgets\",
      \"Effect\":\"Allow\",
      \"Principal\":{\"Service\":\"budgets.amazonaws.com\"},
      \"Action\":\"SNS:Publish\",
      \"Resource\":\"$TOPIC_ARN\"
    }]
  }"

Part C — Create the $10 monthly Budget with 80%/100% alerts (CLI)

Create budget.json:

{
  "BudgetName": "monthly-cost-10usd",
  "BudgetLimit": { "Amount": "10", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}

Create notifications.json (80% actual + 100% forecasted, both to SNS + email):

[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      { "SubscriptionType": "SNS", "Address": "arn:aws:sns:us-east-1:111122223333:billing-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:111122223333:billing-alerts" }
    ]
  }
]

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

# Verify
aws budgets describe-budget --account-id "$ACCOUNT_ID" \
  --budget-name monthly-cost-10usd \
  --query 'Budget.{Name:BudgetName,Limit:BudgetLimit.Amount,Type:BudgetType}' \
  --output table

Expected: the budget lists with a $10 limit; Budgets → your budget in the console shows both alerts. (Replace 111122223333 with your real account ID in the JSON.)

Part D — Add the CloudWatch billing alarm (CLI)

aws cloudwatch put-metric-alarm --region us-east-1 \
  --alarm-name "billing-over-10-usd" \
  --namespace "AWS/Billing" --metric-name EstimatedCharges \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum --period 21600 --evaluation-periods 1 \
  --threshold 10 --comparison-operator GreaterThanThreshold \
  --treat-missing-data notBreaching \
  --alarm-actions "$TOPIC_ARN"

# Verify (state may be INSUFFICIENT_DATA until the metric populates ~6h)
aws cloudwatch describe-alarms --region us-east-1 \
  --alarm-names billing-over-10-usd \
  --query 'MetricAlarms[].[AlarmName,StateValue]' --output table

Expected: the alarm exists; state is INSUFFICIENT_DATA until EstimatedCharges publishes (up to ~6h after opt-in), then OK.

Part E — Everything as Terraform (IaC)

terraform {
  required_providers { aws = { source = "hashicorp/aws" } }
}

# Billing metric + CUR live in us-east-1 — use an aliased provider
provider "aws" { region = "ap-south-1" }
provider "aws" { alias = "use1"  region = "us-east-1" }

data "aws_caller_identity" "me" {}

resource "aws_sns_topic" "budget_alerts" {
  provider = aws.use1
  name     = "billing-alerts"
}

resource "aws_sns_topic_policy" "allow_budgets" {
  provider = aws.use1
  arn      = aws_sns_topic.budget_alerts.arn
  policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect    = "Allow",
      Principal = { Service = "budgets.amazonaws.com" },
      Action    = "SNS:Publish",
      Resource  = aws_sns_topic.budget_alerts.arn
    }]
  })
}

resource "aws_sns_topic_subscription" "email" {
  provider  = aws.use1
  topic_arn = aws_sns_topic.budget_alerts.arn
  protocol  = "email"
  endpoint  = "ops@example.com"   # confirm the link in your inbox
}

resource "aws_budgets_budget" "monthly_cost" {
  name         = "monthly-cost-10usd"
  budget_type  = "COST"
  limit_amount = "10"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  notification {
    comparison_operator        = "GREATER_THAN"
    threshold                  = 80
    threshold_type             = "PERCENTAGE"
    notification_type          = "ACTUAL"
    subscriber_sns_topic_arns  = [aws_sns_topic.budget_alerts.arn]
    subscriber_email_addresses = ["ops@example.com"]
  }
  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_sns_topic_arns = [aws_sns_topic.budget_alerts.arn]
  }
}

resource "aws_cloudwatch_metric_alarm" "billing" {
  provider            = aws.use1
  alarm_name          = "billing-over-10-usd"
  namespace           = "AWS/Billing"
  metric_name         = "EstimatedCharges"
  dimensions          = { Currency = "USD" }
  statistic           = "Maximum"
  period              = 21600
  evaluation_periods  = 1
  threshold           = 10
  comparison_operator = "GreaterThanThreshold"
  treat_missing_data  = "notBreaching"
  alarm_actions       = [aws_sns_topic.budget_alerts.arn]
}

terraform init && terraform apply   # confirm the SNS email link afterwards

Part F — Teardown

# CLI-created resources
aws cloudwatch delete-alarms --alarm-names billing-over-10-usd --region us-east-1
aws budgets delete-budget --account-id "$ACCOUNT_ID" --budget-name monthly-cost-10usd
aws sns delete-topic --topic-arn "$TOPIC_ARN" --region us-east-1

# Terraform-created resources
terraform destroy

Expected: describe-alarms and describe-budget return empty/NotFound. Leave Receive Billing Alerts / Free Tier alerts on — they cost nothing and you want them permanently.

Common mistakes & troubleshooting

This is the playbook — bookmark it. First the scannable table, then the nastiest failures in full.

The three that bite hardest, in full:

1 & 2 — the alert that never comes. The overwhelmingly common failure is a silent SNS chain. An email subscription stays PendingConfirmation until someone clicks the AWS confirmation email, and an unconfirmed subscription receives nothing — no error, just silence. Separately, Budgets publishes as the service principal budgets.amazonaws.com, so the topic’s access policy must explicitly allow it to SNS:Publish; without that, the budget evaluates and “fires” but the publish is denied. Confirm both: aws sns list-subscriptions-by-topic --topic-arn <arn> (look for a real ARN, not PendingConfirmation) and aws sns get-topic-attributes --topic-arn <arn> (look for the budgets.amazonaws.com Allow). Fix by clicking the link and attaching the policy from Part B. Test end-to-end with aws sns publish --topic-arn <arn> --message test — if that email arrives, the chain works and the problem is upstream in the budget config.

4 & 5 — the billing alarm in the wrong Region. AWS/Billing EstimatedCharges is published only to us-east-1, because AWS treats billing as a global service homed there. Create the alarm in ap-south-1 and it will sit in INSUFFICIENT_DATA forever, because the metric does not exist in that Region. And even in us-east-1, the metric only appears after you enable Billing preferences → Receive Billing Alerts, and then only after the next ~6-hour publish. Confirm with aws cloudwatch list-metrics --namespace "AWS/Billing" --region us-east-1 — an empty result means either wrong Region or opt-in off. This is the single most common CloudWatch-billing-alarm mistake, and every Terraform config must pin an aliased us-east-1 provider on the alarm resource.

6 — the forecast that screams on a new account. Cost Explorer and Budgets forecast month-end from history. On a brand-new account, or the month after a big architecture change, there is little or contradictory history, so the forecast can project an absurd number and a FORECASTED alert fires immediately. This is expected, not a bug. Use ACTUAL thresholds (50/80/100%) for the first few weeks, then add a FORECASTED 100% alert once the daily trend has stabilised. The same caveat applies to auto-adjusting budgets: give them a couple of periods of history before trusting the baseline.

CLI error / status reference

Decision table — “which control do I reach for?”

Best practices

• Set the four guardrails on day one, before launching anything: free-tier alert, a small cost Budget, a CloudWatch billing alarm, and Cost Anomaly Detection. All free or near-free.
• Enable Cost Explorer immediately — the ~24h back-fill means the sooner you enable, the sooner you have history and a usable forecast.
• Wire alerts to SNS, not just email, so you can fan out to Slack/Teams (via Chatbot) and to automation (Lambda) later without rebuilding.
• Always confirm the SNS subscription and topic policy — test end-to-end with sns publish so you know the chain works before you rely on it.
• Use ACTUAL thresholds early, add FORECASTED once you have history. New-account forecasts are unreliable.
• Group Cost Explorer by Usage type when hunting a mystery charge — it surfaces NAT, egress, and cross-AZ that the resource list hides.
• Tag everything and activate the tag keys so Cost Explorer and the CUR can slice by team/project/environment — see the tagging-strategy companion.
• Put the billing alarm in us-east-1 and pin an aliased provider in IaC; it is the number-one region mistake.
• Prefer approval-required budget actions for anything that applies a Deny policy — auto-apply on a forecast blip can lock you out.
• Delete-on-terminate for EBS, release idle EIPs, and use VPC endpoints to keep traffic off NAT — structural fixes beat alerting.
• Review Cost Explorer weekly (a saved report), not at month-end; a small leak caught early is cents, caught late is dollars.
• In an org, remember the Free Tier is shared and set a per-account budget rather than trusting per-account free allowances.

Security notes

Cost data is sensitive business information — it reveals architecture, scale, launch timing, and vendor relationships. Treat access to it with least privilege.

Cost & sizing

The controls themselves are the cheapest insurance in AWS. What each one costs:

In INR terms, a complete guardrail set — Cost Explorer, two budgets, a billing alarm, anomaly detection, free-tier alerts — costs effectively ₹0/month. Even a heavy setup (a dozen budgets, a scripted CE dashboard, a CUR feeding QuickSight) is a few hundred rupees a month — trivially less than the first surprise bill it prevents. The right-sizing rule: spend zero on the guardrails, spend your effort on the structural fixes (delete NAT/EIP/EBS waste, right-size RDS/EC2, buy Savings Plans once you have a steady baseline).

Interview & exam questions

1. Why must a CloudWatch billing alarm be created in us-east-1? (CLF-C02, SOA-C02) — Because AWS publishes the AWS/Billing EstimatedCharges metric only to CloudWatch in us-east-1; billing is a global service homed there. An alarm in any other Region sits in INSUFFICIENT_DATA because the metric does not exist locally. You also must enable “Receive Billing Alerts” first.

2. What is the difference between an actual and a forecasted budget alert? (CLF-C02) — An actual alert fires when real, already-incurred spend crosses the threshold; a forecasted alert fires when the projected month-end spend crosses it. Actual never false-alarms but only warns after the money is spent; forecasted warns early but needs history and is noisy on new accounts.

3. Name the three kinds of AWS Free Tier. (CLF-C02) — 12-month free (from sign-up, e.g. 750 EC2 hours/mo, expires at month 13), always-free (forever, monthly, e.g. 1M Lambda requests, 25 GB DynamoDB), and short-term trials (fixed days from first use, e.g. 30-day GuardDuty). Newer accounts may instead have a credit-based free plan.

4. Cost Explorer shows nothing right after you enable it. Why? (CLF-C02) — Cost Explorer is a one-time opt-in that back-fills roughly 24 hours (and up to ~14 months of history over the following day). Empty immediately after enable is expected; return in ~24 hours.

5. Where do NAT gateway and data-transfer costs appear in Cost Explorer? (SOA-C02) — Group by Usage type (not just Service). NAT lands under NatGateway-Hours/NatGateway-Bytes (filed under “EC2-Other”), and transfer under DataTransfer-Out-Bytes/DataTransfer-Regional-Bytes. The resource console does not show these meters.

6. How does the Free Tier behave in an AWS Organization? (CLF-C02) — There is one Free Tier for the whole organization, aggregated at the payer, not one per member account. Ten accounts share 750 free EC2 hours total, not 7,500.

7. What is the closest thing AWS has to a hard spending cap? (CLF-C02, SOA-C02) — A budget action: when a threshold is crossed, it can automatically (or with approval) apply a restrictive IAM policy or SCP, or stop tagged EC2/RDS instances. It still fires on the delayed budget evaluation, so it is not truly instantaneous.

8. When would you use the CUR over Cost Explorer? (SOA-C02) — When you need per-resource, hourly line items, unlimited history, or SQL/BI analysis (chargeback, deep audits). Cost Explorer is capped at ~14 months and coarser resource detail; the CUR delivers full detail to your S3 bucket for Athena/QuickSight.

9. What does Cost Anomaly Detection add over Budgets? (CLF-C02) — It uses ML to learn your normal spend and alerts on deviations without you setting a threshold, catching spikes you never anticipated. Budgets only fire on thresholds you defined in advance.

10. What are unblended vs amortized cost? (SAA-C03) — Unblended is the actual rate charged on each line at the time of use (matches the invoice). Amortized spreads upfront RI/Savings Plans fees across the commitment term, giving a truer per-hour run-rate when you have commitments.

11. Your budget crossed its threshold but no email arrived. First two things to check? (SOA-C02) — (a) Is the SNS email subscription confirmed (not PendingConfirmation)? (b) Does the SNS topic policy allow budgets.amazonaws.com to SNS:Publish? Both are silent failures.

12. What enables the EstimatedCharges metric in the first place? (CLF-C02) — The Receive Billing Alerts preference in Billing preferences → Alert preferences. Until it is on, no AWS/Billing metric is published, even in us-east-1.

Quick check

1. A teammate created a CloudWatch billing alarm in ap-south-1 and it never fires. What are the two things wrong, and where must the alarm live?
2. You enable a brand-new account’s budget with a FORECASTED 100% alert and it fires on day two. Is this a bug? What should you have used instead?
3. Cost Explorer’s “group by Service” shows a big EC2-Other bucket. What single change reveals whether it’s NAT, EBS, or data transfer?
4. Your $10 budget crossed 80% but no email came, even though the budget shows the alert as triggered. Name the two silent failure points.
5. In an org with eight member accounts, how many free EC2 hours per month do you actually get across the org, and why does that surprise people?

Answers

1. Two things: (a) the AWS/Billing EstimatedCharges metric is published only in us-east-1, so an alarm elsewhere has no metric and sits in INSUFFICIENT_DATA; (b) the Receive Billing Alerts preference may not be enabled. The alarm must live in us-east-1.
2. Not a bug. A new account has no history, so the forecast is unreliable and can project an absurd month-end. Use ACTUAL thresholds (50/80/100%) first and add FORECASTED once a few weeks of steady history exist.
3. Change group-by from Service to Usage type. “EC2-Other” splits into NatGateway-Hours/-Bytes, EBS:VolumeUsage, DataTransfer-*, etc., pinpointing the meter.
4. (a) The SNS email subscription is unconfirmed (PendingConfirmation — the recipient never clicked the link); (b) the SNS topic policy doesn’t allow budgets.amazonaws.com to SNS:Publish. Both fail silently.
5. 750 total, not 6,000. The Free Tier is one allowance for the whole organization, aggregated at the payer account — not one per member account. People assume it multiplies per account.

Glossary

Next steps

You can now build the four guardrails and read where the money goes. Extend outward:

• Next: Tag everything so Cost Explorer and the CUR can slice by team, project, and environment — the companion AWS tagging strategy and cost-allocation enforcement (wave sibling) makes chargeback possible.
• Related: Stop runaway counts (not just spend) with the companion on AWS service quotas, limits, and increase requests — quotas and budgets are the two halves of guardrails.
• Related: When an anomaly fires, triage it fast with the companion on AWS cost-spike anomaly-detection troubleshooting — root-causing the exact usage type and resource.
• Related: AWS Organizations and IAM Foundations — consolidated billing, the payer account, and delegating billing access safely.
• Related: AWS Control Tower, Guardrails and the Multi-Account Foundation — SCPs and guardrails, the same policies a budget action can apply.
• Related: Amazon VPC, Subnets and Security Groups Explained — where NAT gateways, endpoints, and egress cost actually come from.