On this page · 10 sections
Summary. On 19 August 2026 AWS announced that Cost Anomaly Detection "now monitors spend on third-party foundation models running on Amazon Bedrock, such as Anthropic Claude and other provider-hosted models", with no setup required and coverage in all commercial regions except AWS GovCloud and the China Regions. The AWS Billing and Cost Management User Guide page that the announcement links to says the opposite. That page states that Cost Anomaly Detection "does not monitor third-party products and services available through AWS Marketplace", and names the exclusion explicitly: "third-party LLMs like Anthropic Claude models on Amazon Bedrock (which appear in Cost Explorer and on your bill under the legal entity 'Anthropic, PBC') and any models you deploy through Amazon Bedrock Marketplace". It then tells you to use AWS Budgets instead. Both sources were live on 21 August 2026. Until one changes, do not switch off the Budgets alarm you are already relying on for generative AI spend.
The two statements, side by side
| Source | Date | What it says about third-party Bedrock models |
|---|---|---|
| AWS What's New announcement | 19 August 2026 | Cost Anomaly Detection "now monitors spend on third-party foundation models running on Amazon Bedrock, such as Anthropic Claude" |
AWS Billing and Cost Management User Guide, manage-ad |
live 21 August 2026 | "Cost Anomaly Detection does not monitor third-party products and services available through AWS Marketplace. This includes third-party LLMs like Anthropic Claude models on Amazon Bedrock" |
| Getting started with AWS Cost Anomaly Detection | live 21 August 2026 | Silent — no mention of Marketplace, third-party charges or Bedrock at all |
AnomalyMonitor API reference |
live 21 August 2026 | Silent — dimensions are SERVICE, LINKED_ACCOUNT, TAG, COST_CATEGORY only |
The announcement is not vague. It says the evaluation happens "through your AWS managed service monitor, with no setup required", and that when spend on a model changes unexpectedly you get "an alert and a root-cause breakdown ranked by dollar impact across AWS service, account, Region, and usage type". The user guide is not vague either. It gives the billing legal entity you would look for, Anthropic, PBC, and routes you to AWS Budgets with the Billing entity filter.
Only one of those can be true for your account today, and the announcement links to the page that contradicts it.
Why the billing-entity detail is the tell
The user guide's parenthetical is the most useful sentence in either document, because it explains the mechanism rather than the outcome. Third-party model charges appear on the bill under a separate legal entity, Anthropic, PBC, because they route through AWS Marketplace rather than through the AWS service line. Cost Anomaly Detection's AWS managed monitors analyse a cost dimension — the API reference lists SERVICE, LINKED_ACCOUNT, TAG and COST_CATEGORY — and the AWS services monitor "automatically evaluates all AWS services used by your account for anomalies".
A charge booked against a different billing entity is not obviously an AWS service line, which is exactly why the exclusion existed. For the announcement to be accurate, something in that plumbing changed. Neither the getting-started page nor the AnomalyMonitor API reference reflects any such change: MonitorDimension still has four valid values and none of them is a billing entity or a model identifier.
What the detector can tell you even when it works
Assume the announcement is right and your account is covered. The resolution you get is still coarser than most generative AI teams expect, and that is worth knowing before you retire another control.
Root causes are ranked by dollar impact and "split across four dimensions: AWS service, AWS account, Region, or usage type". Not model ID. Not agent. Not prompt template, tenant, or feature flag. The EventBridge payload confirms it: the rootCauses array carries linkedAccount, linkedAccountName, region, service and usageType, and nothing model-specific. If three teams share one account and one of them ships a retrieval loop that triples token spend, the alert tells you the account and the usage type. Finding the team is still your job, and the way to make that automatic is cost allocation tags, not the anomaly detector.
Timing is the second constraint. Cost Anomaly Detection "runs approximately three times a day" against net unblended cost, and it "uses data from Cost Explorer, which has a delay of up to 24 hours", so "it can take up to 24 hours to detect an anomaly after a usage occurs". A new monitor takes 24 hours to begin detecting. A new service subscription needs 10 days of historical usage before anomalies can be detected for it. For a runaway agent loop billed per token, a day is a long time.
| Property | Value | Source |
|---|---|---|
| Evaluation frequency | Approximately three times a day | User guide |
| Detection latency | Up to 24 hours after usage | User guide |
| New monitor warm-up | 24 hours | User guide |
| New service subscription warm-up | 10 days of historical usage | User guide |
| Values tracked by an AWS managed monitor | Top 5,000 by cost within a dimension | Getting started, AnomalyMonitor |
| Values selectable per customer managed monitor | 10 | Getting started |
| Default anomaly view window | 90 days | Getting started |
Thresholds and delivery, which the announcement skips entirely
If you are wiring this into an on-call rota rather than an inbox, three details matter.
Delivery channel is bound to frequency and cannot be swapped. The AnomalySubscription API states it plainly: "Notifications are sent either over email (for DAILY and WEEKLY frequencies) or SNS (for IMMEDIATE frequency)." So an alert you want to reach a pager must be an immediate alert on an SNS topic. Daily summaries carry the top 10 alerts from the previous day, generated at 00:00 UTC, and weekly summaries arrive once a week; both require at least one email recipient.
Thresholds come in two shapes. ThresholdExpression supports ANOMALY_TOTAL_IMPACT_ABSOLUTE and ANOMALY_TOTAL_IMPACT_PERCENTAGE, requires the GREATER_THAN_OR_EQUAL match option, and accepts values "between 0 and 10,000,000,000 in string format". The older flat Threshold field is deprecated, is an absolute dollar value, and cannot be combined with ThresholdExpression. Impact percentage is "(total cost impact / expected spend) * 100", and the getting-started page notes it "cannot be calculated when expected spend is zero", showing "N/A" instead — which is precisely the situation for a model you just started calling.
The third detail is the one that bites organisations at scale: "Alert subscriptions attached to AWS managed monitors use the same threshold across all tracked values." One threshold, up to 5,000 values. A $500 absolute threshold that is right for your largest account is noise-cancelling for a small one. AWS's own suggested workaround is to "create supplementary customer managed monitors with dedicated alert subscriptions with specific thresholds", and each of those tops out at 10 selected values.
Two more constraints worth noting before you plan around this. Cost monitors for linked accounts, cost allocation tags and cost categories "can only be created in the management account", and you "cannot convert existing customer managed monitors to AWS managed monitors". Anomalies below your threshold are still detected and still visible in the console and through GetAnomalies — the threshold governs notification, not detection.
What to do this week
Do not remove an AWS Budgets alarm on Bedrock spend on the strength of the announcement. The user guide's instruction stands until it changes: a cost budget tracks total AWS costs including AWS Marketplace, and the Billing entity filter isolates the Marketplace charges. Keep it.
Verify the claim in your own account rather than in documentation. Look at Cost Explorer for charges under Anthropic, PBC, then check whether any detected anomaly in the last 90 days attributes to them. If the detector genuinely covers them now, you will see it there before any doc page tells you.
If you rely on immediate alerting for generative AI spend, use an SNS-backed immediate subscription with an absolute threshold rather than a daily summary, and route it through EventBridge — the event arrives with "source": "aws.ce" and "detail-type": "Anomaly Detected", and carries totalActualSpend, totalExpectedSpend, totalImpact and totalImpactPercentage in the impact object, which is enough to branch on in a rule.
Tag before you need the tags. Because root causes resolve only to service, account, Region and usage type, an AWS managed monitor on a cost allocation tag key is the only configuration that will name a team when spend jumps. The getting-started page describes it directly: specifying a tag key such as application-team tracks every value independently and "new tag values are automatically included as they're created".
Finally, note the region asymmetry. This launch reaches "all AWS commercial regions, except the AWS GovCloud and the China Regions". The IAM quota change AWS shipped the same week reached commercial regions, GovCloud (US) and China Regions — see our analysis of the IAM managed-policy quota moving from 10 to 20. Regulated estates should not assume a given week's cost-management improvements land everywhere.
India-specific considerations
Indian teams building generative AI on Bedrock for domestic clients tend to run token-heavy retrieval workloads with sharp week-on-week growth, which is the shape most likely to be swallowed by a percentage threshold — a workload that doubles every fortnight makes doubling look expected. Absolute thresholds behave more predictably there. The multi-tenant delivery pattern common to Indian services firms also runs straight into the single-threshold constraint on AWS managed monitors, since one number has to serve a large client account and a pilot in the same organisation. Where a client's spend must be attributable for contractual or Digital Personal Data Protection Act, 2023 record-keeping reasons, cost allocation tags carry that attribution; the anomaly detector's four root-cause dimensions do not.
What is still unknown
AWS has not said whether the user guide exclusion is stale, whether the announcement is early, or whether coverage is rolling out account by account. It has not published a model-level dimension for Cost Anomaly Detection, so per-model attribution remains unavailable through this path. It has not stated whether models deployed through Amazon Bedrock Marketplace are treated differently from provider-hosted models on Bedrock, even though the user guide lists both in the same exclusion sentence. And no doc page updated between 19 and 21 August 2026 to reconcile the two.
FAQ
How eCorpIT can help
eCorpIT builds cost attribution for teams running generative AI on AWS: cost allocation tag design, anomaly monitors sized to the account structure, and alert routing that reaches a rota rather than an inbox. That work sits inside our multicloud security posture and cloud governance practice, delivered by senior engineering teams and backed by CMMI Level 5 and ISO 27001:2022 certification. If your Bedrock bill is a single line nobody can decompose, we can fix the attribution before the next anomaly. Talk to us at /contact-us/.
References
- AWS Cost Anomaly Detection supports third-party models on Amazon Bedrock — AWS What's New, posted 19 August 2026.
- Detecting unusual spend with AWS Cost Anomaly Detection — AWS Billing and Cost Management User Guide.
- Getting started with AWS Cost Anomaly Detection — AWS Billing and Cost Management User Guide.
- AnomalyMonitor — AWS Billing and Cost Management API Reference.
- AnomalySubscription — AWS Billing and Cost Management API Reference.
- Editing your alert preferences — AWS Billing and Cost Management User Guide.
- Using EventBridge with Cost Anomaly Detection — AWS Billing and Cost Management User Guide.
- Recent Announcements feed — AWS, retrieved 21 August 2026.
- AWS IAM now supports 20 managed policies per role by default — AWS What's New, posted 19 August 2026.
- IAM Policy Autopilot now supports Terraform plan files — AWS What's New, posted 18 August 2026.
Last updated: 21 August 2026.