A team asks you to "cap" their AWS spend at a fixed amount each month. Explain what AWS Budgets can and cannot do for them, including actual versus forecasted alert thresholds and what budget actions add.

## The honest answer to "cap our spend" AWS does not offer a hard spending limit on a normal account. Nothing in the platform will refuse an API call because the month's budget is exhausted. This surprises people arriving from consumer cloud services or from prepaid billing models, and it is the first thing to say out loud — because designing around a cap that does not exist is how teams end up with an unpleasant invoice and no alarm history. What exists is **AWS Budgets**: a small evaluation engine over your billing data that compares spend, usage or commitment metrics against a target you define, and notifies when a threshold is crossed. ## What a budget is made of A budget has a **type**, a **period**, an **amount**, an optional **scope**, and one or more **alert thresholds**. Types go beyond plain cost. A **cost budget** targets money. A **usage budget** targets a usage quantity — hours, gigabytes — which is useful where the unit is the thing you actually want to control. There are also budgets that track **Savings Plans and reservation utilization or coverage**, so you can be told when a commitment stops being used properly rather than discovering it at the end of the quarter. The period is typically monthly, but daily, quarterly and annual budgets exist, and a budget can be scoped with the same kind of filters Cost Explorer uses — a service, a region, a linked account, a cost category — so one team's budget genuinely tracks one team's spend. ## Actual versus forecasted thresholds This is the distinction interviewers probe, because it maps directly to whether the alert is useful. An **actual** threshold fires when spend that has already accrued crosses the line. It is truthful and late. On the twenty-eighth of the month, an alert saying you have reached 100% of budget leaves almost nothing to do. A **forecasted** threshold fires when AWS's projection of the period's final total crosses the line. AWS builds that projection from the spend pattern so far, which means it needs some history to be meaningful and it is noisy early in a period or for a brand-new workload — a single expensive day on the second of the month can project into an alarming month-end figure. The usual configuration is layered: a forecasted alert at 100% as an early warning, plus actual alerts at, say, 50%, 80% and 100% so you have a factual record of the progression. Notifications are delivered to email addresses or published to an **SNS topic**. SNS is the important one operationally, because from a topic you can route into chat, a ticketing system or a pager, and you can subscribe a Lambda function that does something programmatic. ## Budget actions — the only enforcement there is A **budget action** attaches to a threshold and, when it trips, applies a change to your account rather than merely telling someone. The available action types are: applying a restrictive **IAM policy** to specified users, groups or roles; applying a **service control policy** to an organizational unit or account; and **stopping EC2 or RDS instances** matched by the action's configuration. Each action can be set to execute automatically or to wait for an approval, which matters more than it sounds. An automatic deny policy in a production account is an outage you built on purpose; the same action in a sandbox or a training account is exactly right. The common design is automatic enforcement in non-production, approval-gated actions in production, and pure notification for anything customer-facing. Actions are also blunt by nature. Stopping an instance is not a graceful shutdown of a workload, and an SCP that blocks provisioning also blocks the emergency fix your team needs. Treat enforcement as protection against runaway *experiments*, not as capacity management. ## Timing, and what it costs Budgets evaluate against billing data that refreshes only a few times a day, so there is a lag of hours between spend happening and a threshold firing. Nothing here reacts in seconds. A budget will not catch a script that spins up expensive instances and burns thousands of dollars in twenty minutes — for that class of problem you need guardrails at provisioning time, such as policy limits on instance types, rather than a spend alert after the fact. Budgets themselves are cheap but not free beyond a small free allowance, billed per budget per day, which is worth knowing before generating hundreds of them programmatically. ## The design that actually works A budget answers "is this account on track?" It does not answer "is anything unusual happening right now?" — that question belongs to anomaly detection, which watches for deviation from a learned pattern rather than against a fixed number. Mature setups run both: budgets for the fixed, financial commitment, and anomaly monitors for the unexpected. Neither is a substitute for the other, and neither is a cap.