LimitExceededException" when creating a cost anomaly monitor - hit the per-account monitor limit
Fixes the LimitExceededException AWS Cost Anomaly Detection throws when you hit the per-account monitor limit. Covers listing existing monitors, deleting stale ones, and consolidating overlapping monitors into one. Use when a create-anomaly-monitor call is refused. Not for throttling errors or monitor evaluation lag.
TL;DR
AWS allows a limited number of cost anomaly monitors per account, and you have hit it. List your monitors with ce:GetAnomalyMonitors, delete the stale or duplicate ones, or consolidate several narrow monitors into one wider monitor with multiple alert subscriptions.
An error occurred (LimitExceededException) when calling the CreateAnomalyMonitor operationUse this when
CreateAnomalyMonitorfails withLimitExceededException.- You are creating monitors per team or per service and the count keeps climbing.
- An IaC run (Terraform/CloudFormation) errors on the monitor resource.
Not for this skill when
- The call throttles (that is a rate limit, not a resource limit).
- The monitor exists but never alerts. That is an evaluation or threshold problem.
Steps
- Count your monitors:
aws ce get-anomaly-monitors --max-results 100. Verify: you see the full list and how close you are to the limit. - Find the dead weight: look for monitors with no subscriptions, monitors attached to retired services, and duplicates that overlap by 90 percent or more. Verify: you can name each monitor you plan to remove.
- Delete the stale ones:
aws ce delete-anomaly-monitor --monitor-arn [monitor arn]. Verify: the count drops. - Consolidate where you can: one account-level or one linked-account monitor with several alert subscriptions replaces five single-service monitors. Verify: the same alert recipients are covered by subscriptions on the surviving monitor.
- Retry the create call. Verify: the API returns a monitor ARN instead of the exception.
Terraform / CloudFormation variant
Same limit, different surface. Verify: terraform plan stops erroring on the awsceanomaly_monitor resource after the cleanup above.
Monitor-per-team sprawl
If each team provisions its own monitor in shared IaC, the limit is a forcing function. Verify: one monitor per linked account with tag-based subscription filters covers the same alerts.
Compatibility: AWS Cost Explorer Anomaly Detection. The limit is per management/payer context, so consolidated billing accounts share one pool.
Why it happens
Anomaly monitors are an account-level resource with a fixed quota. Teams that create one monitor per service or per environment burn through the quota in months, and IaC retries never succeed because the quota does not reset on its own.
Edge cases / pitfalls
- Deleting a monitor does not delete its alert subscriptions; orphaned subscriptions fail with UnknownMonitorException. Clean both.
- The limit counts monitors across all dimensions (account, service, tag), not per dimension.
- Requesting a quota increase through Service Quotas is possible but slow; consolidation is the fast fix.
- Check whether your IaC module creates a monitor per workspace. That multiplies the quota burn silently.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_n8iIN4pB0j45JHAUao2Byw