Setting a Bedrock Spend Alert With AWS Budgets

A Bedrock budget alert is straightforward to create and easy to misunderstand. It is not a spending cap, and it is not real time. Knowing how far behind it runs is what decides whether you rely on it alone.

What a budget can and cannot see

AWS Budgets evaluates the same cost data Cost Explorer shows, so it filters on the same dimensions. For Bedrock the useful ones are Service (the value is Amazon Bedrock), Usage type, Region, Linked account, Tag and Cost category. Charge type is worth knowing about too, because it is how you exclude tax and credits from a target that is meant to track engineering behaviour.

What it cannot see is anything below a cost line item. It has no notion of a model, a prompt, a user or a request. “Alert me if one customer spends more than $50” is not a budget; it is application-level accounting, and per-customer LLM cost is where that belongs. A budget answers one question well: is this account’s Bedrock bill heading somewhere I did not agree to.

Tag before you budget

A budget filtered only on Service tells you the whole account’s Bedrock spend, which for a single-team account is often enough. To split it by team or workload you need tags on the spend, and Bedrock inference is not a resource you can tag directly — there is no instance to label.

Amazon’s answer is application inference profiles: you create a profile that points at a model, attach cost allocation tags to the profile, and pass the profile ARN as modelId instead of the model id. The profile’s tags are then attached to the billing record for each request. Two properties of this matter for a budget:

• Tags must be activated as cost allocation tags in the Billing console before they appear anywhere, and Amazon documents up to 24 hours before they start populating.
• Cost allocation tags are not retroactive. Only costs incurred after activation carry the tag. A budget created today against a tag activated today reports zero for reasons that have nothing to do with your spend.

Do the tag activation first, wait a day, confirm the tag appears in Cost Explorer, and only then write the budget against it.

Creating the budget

1. Pick the target from evidence, not intuition. Take the last full month of Bedrock spend from Cost Explorer and set the budget where a deviation would actually be a surprise.
2. Define the budget as JSON. The CLI takes two documents: the budget itself, and the notifications with their subscribers.
3. Set two notifications, not one — a forecast alert that gives you warning and an actual alert that cannot be wrong.

# budget.json
{
  "BudgetName": "bedrock-monthly",
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "BudgetLimit": { "Amount": "2000", "Unit": "USD" },
  "CostFilters": { "Service": ["Amazon Bedrock"] },
  "CostTypes": {
    "IncludeTax": false,
    "IncludeCredit": false,
    "IncludeRefund": false,
    "UseAmortized": false
  }
}

# notifications.json
[
  {
    "Notification": {
      "NotificationType": "FORECASTED",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      { "SubscriptionType": "SNS", "Address": "arn:aws:sns:us-east-1:111122223333:cost-alerts" }
    ]
  },
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 100,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [
      { "SubscriptionType": "SNS", "Address": "arn:aws:sns:us-east-1:111122223333:cost-alerts" }
    ]
  }
]

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

If you tagged with application inference profiles, replace the cost filter with the tag — user-defined tag keys take the user: prefix in this context, so the filter reads "TagKeyValue": ["user:Team$search"]. An SNS topic rather than a bare email address is worth the extra resource: it is the only subscriber type that can reach a chat channel, a ticket queue and a Lambda at once, and it gives you somewhere to attach an automated response later.

The lag, and what it means

This is the section that changes how you use the feature. AWS states that budget information is updated up to three times a day, with updates typically occurring 8 to 12 hours after the previous one, and separately warns that there is a delay between incurring a charge and that charge being billed at all.

Compose those two delays and a runaway job started at 9pm can plausibly run all night before anything fires. For a service billed per token with no instance to notice, that is a materially different risk from the same alert on EC2, where a wrong instance type costs a bounded amount per hour. The consequences:

• A budget is a smoke alarm, not a circuit breaker. It tells you a month is going wrong. It cannot stop a runaway loop.
• The forecast alert is the one that earns its keep, because it fires on a trend rather than on an arrival, which buys back some of the lag.
• Something faster has to exist upstream. A CloudWatch alarm on Bedrock’s InvocationCount or OutputTokenCount metric reacts in minutes rather than hours, because it watches invocations rather than dollars. Pair the two: metric alarms for the incident, application-level budget controls for the actual limit, and the budget for the month.

When an alert should become an action

AWS Budgets supports budget actions: at a threshold it can apply an IAM policy, attach an SCP, or stop EC2 and RDS instances. For Bedrock the useful one is applying a Deny policy on bedrock:InvokeModel to a named role or group, which is a real kill switch.

It is also a blunt one, and the lag makes it bluntest exactly when it matters. An action that fires 10 hours after the spend that triggered it will stop inference for whoever is working at that moment, not for whoever caused it. Configure actions in approval-required mode first, so the alert arrives with a one-click remedy attached rather than an outage. If a hard cap is genuinely the requirement, it belongs in the request path — a per-tenant counter checked before the call, which is the pattern budget controls describes — not in the billing system.