Cloud budget alerts and spend notifications for engineering and finance teams on AWS and Google Cloud

Cloud budget alerts are the cheapest cost control you have. On AWS and Google Cloud they cost nothing to create, and they take minutes to set up. This post is for engineering and finance teams on AWS and Google Cloud who want AWS budget alerts and Google Cloud budget notifications that someone actually acts on: which budgets to create, which thresholds to use, where to send them, and what a budget will never tell you.

What a budget alert can and can’t do

A budget compares spend in a period, usually the month, with an amount you choose. When spend, or the forecast for the period, crosses a threshold, it notifies someone. That’s all it does. It doesn’t stop anything on its own, it doesn’t say why spend rose, and it fires hours after the spend happened, because both clouds bill from usage data that arrives with a delay.

That makes budgets good at one job: making sure a person hears about an overrun before the invoice does. Treat them as a smoke detector. Finding the service and the resource behind the number is separate work, covered step by step in why did my AWS bill go up.

Set up AWS budget alerts with AWS Budgets

AWS Budgets tracks cost, usage, and Savings Plans and Reserved Instance utilization and coverage (AWS docs). For cost control you want a cost budget. Each one has a period (daily, monthly, quarterly, annually or custom dates), an amount, optional filters, and alerts.

Each alert has a threshold, either a percentage of the budget or an absolute amount, measured against actual or forecasted spend:

• An actual alert fires once per budget period, the first time spend crosses the threshold.
• A forecasted alert fires when AWS projects the period will end above the threshold. It can fire more than once if the forecast dips and rises again. AWS needs about five weeks of usage data before it can forecast, so a new account gets no forecasted alerts at first (AWS docs).

Each alert goes to up to 10 email addresses and one Amazon SNS topic, and email recipients have to verify their address before anything arrives. Through SNS, Amazon Q Developer in chat applications (formerly AWS Chatbot) posts alerts to Slack, Microsoft Teams or Amazon Chime (AWS docs). Budget data updates up to three times a day, so an alert can arrive well after the spend that triggered it.

Filters scope a budget to a service, linked account, Region, tag, cost category, usage type and more (AWS docs). A tag filter works only once the tag is activated as a cost allocation tag.

As of October 2026, budgets and their notifications are free. Budget actions can apply an IAM policy or a service control policy that blocks new resources, or stop specific EC2 and RDS instances (AWS docs). The first two action-enabled budgets are free, and each one after that costs $0.10 a day. Budget reports cost $0.01 per report delivered (pricing).

Here’s a monthly company budget with two alerts, from the CLI. This creates a budget in your account; use your management or payer account ID:

cat > budget.json <<'EOF'
{
  "BudgetName": "company-monthly",
  "BudgetType": "COST",
  "TimeUnit": "MONTHLY",
  "BudgetLimit": { "Amount": "20000", "Unit": "USD" }
}
EOF

cat > notifications.json <<'EOF'
[
  {
    "Notification": { "NotificationType": "ACTUAL", "ComparisonOperator": "GREATER_THAN",
                      "Threshold": 80, "ThresholdType": "PERCENTAGE" },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "[email protected]" }]
  },
  {
    "Notification": { "NotificationType": "FORECASTED", "ComparisonOperator": "GREATER_THAN",
                      "Threshold": 100, "ThresholdType": "PERCENTAGE" },
    "Subscribers": [{ "SubscriptionType": "EMAIL", "Address": "[email protected]" }]
  }
]
EOF

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

To see every budget and where it stands this period, this one only reads:

aws budgets describe-budgets \
  --account-id 111122223333 \
  --query 'Budgets[].[BudgetName, BudgetLimit.Amount,
      CalculatedSpend.ActualSpend.Amount, CalculatedSpend.ForecastedSpend.Amount]' \
  --output table

Google Cloud budget alerts and notifications

Google Cloud budgets live on the billing account. A budget can cover the whole account or be scoped to projects, folders, services, subaccounts or a label (Google Cloud docs). A label-scoped budget takes one label only.

A new budget gets thresholds at 50%, 90% and 100% of actual spend by default. You can add forecasted thresholds, which compare the projected spend at the end of the period with the amount. By default, emails go to everyone with the Billing Account Administrator or Billing Account User role. To reach anyone else, link Cloud Monitoring notification channels, up to five per budget (gcloud reference). Or connect a Pub/Sub topic, which receives the budget’s status several times a day for your own automation. Budgets and their alerts are free; Pub/Sub notifications bill at standard Pub/Sub prices (pricing).

Two details catch people out. A new budget can take several hours to send its first notification. And a monthly budget keeps tracking for the first two days of the next month, to pick up late-reported usage and taxes.

The most important one: a regular budget never caps spend. Hitting 100% sends an email and nothing else. Google has added spend cap budgets that pause new usage at the cap, but only for a short list of services, such as the Gemini API, Cloud Run and Cloud Run functions, and only when the budget covers one project and one service (Google Cloud docs). For everything else, Google points to Pub/Sub automation, such as disabling billing on a project, which stops everything in it.

The same company budget from the CLI, with a forecasted threshold added. This creates a budget:

gcloud billing budgets create \
  --billing-account=0X0X0X-0X0X0X-0X0X0X \
  --display-name="company-monthly" \
  --budget-amount=20000USD \
  --threshold-rule=percent=0.5 \
  --threshold-rule=percent=0.9 \
  --threshold-rule=percent=1.0 \
  --threshold-rule=percent=1.0,basis=forecasted-spend

Listing them only reads:

gcloud billing budgets list --billing-account=0X0X0X-0X0X0X-0X0X0X

Which cloud budgets to create

More budgets aren’t better. A budget nobody owns is noise. Create one for each level that has an owner who can act on it:

The daily budget works because an actual alert fires once per period: with a daily period, it can fire every day. Set it above your busiest normal weekday, or it will fire every Monday.

Set amounts from history, not hope: the last three months of spend for that scope, plus the growth you planned. A budget set well above normal never fires. One set below normal fires every month and gets ignored.

Per-team budgets depend on tags. If yours are patchy, fix them first: cloud cost allocation by team covers tags and labels on both clouds.

Thresholds people act on

Each threshold should map to an action, or it shouldn’t exist. A set that works on both clouds:

• 50% actual: informational. Around mid-month it’s on plan; before the 10th, something is off.
• 80% actual: the owner checks what’s driving spend this week.
• 100% forecasted: the early warning. It fires while there’s still time to change the month.
• 100% actual: the overrun. Finance hears about it from you, not from the invoice.

Send the 50% alert to email only. Send the forecast and the overrun to the owning team’s chat channel as well, where they get read. And name budgets so the alert explains itself: payments-monthly says more in an inbox than budget-3.

Cloud spend notifications beyond budgets

Budgets watch a total against a number. Two other kinds of cloud spend notifications catch what budgets miss.

Anomaly alerts watch the shape of spend. A service that doubles overnight can stay under its monthly budget for weeks, but an anomaly monitor flags the first day. AWS Cost Anomaly Detection is free (AWS), and so is Google Cloud’s anomaly detection, which shows cost anomalies for your projects in the Billing console, with alerts you can manage (Google Cloud docs). Cloud cost anomaly detection covers how they work and how to tune them.

Savings digests cover the other side: a weekly list of new waste worth cutting, such as idle instances, unattached volumes and oversized databases. A budget tells you spend is high. A digest tells you what to do about it.

Why alerts alone fall short

A budget alert says “payments is at 82% of $20,000”. It doesn’t say which service moved, on which day, on which resource, or whether it’s growth you planned. Someone still has to open Cost Explorer or the billing reports and narrow it down, which is exactly the work that gets postponed when the alert lands on a busy afternoon.

Alerts also lag. AWS Budgets updates up to three times a day, and Google Cloud’s cost data arrives with reporting delays. A resource that started at 9 a.m. may not reach an alert until the next day. And alerts without owners decay: once a channel fills with alerts nobody acted on, people stop reading it.

So keep your budgets, but pair each alert with an owner, an explanation of what changed, and a short list of what to cut.

How Omni FinOps handles budgets and alerts

Omni FinOps reads your AWS and Google Cloud costs through read-only access, so its budgets sit on the same data as its anomalies and savings leads. Budgets & Alerts holds caps by month, quarter or year, scoped to the whole company, a service type, an account, a Region or an allocation such as a team tag, each with its own alert percentage. Alerts go out by email on three channels: a monthly cap reaching its alert percentage, a spend anomaly with the sentence that explains it, and a weekly digest of new savings leads. Each channel takes up to 10 recipients, and during the trial, alerts go only to you. See how it connects on AWS and Google Cloud.