UnknownMonitorException: The cost anomaly monitor does not exist for the acc

Not specified by the original author.

TL;DR

The monitor was deleted but its alert subscription survived, and now the subscription points at nothing. Re-create the monitor (or pick an existing one), then update the subscription with the new monitor ARN. Deleting monitors and subscriptions together from now on prevents this.

An error occurred (UnknownMonitorException) when calling the UpdateAnomalySubscription operation: The cost anomaly monitor does not exist for the account

Use this when

• An anomaly subscription update or describe fails with UnknownMonitorException.
• Alert history stops right after a monitor cleanup.
• IaC shows the subscription resource but the monitor resource is gone.

Not for this skill when

• The monitor exists. Check the ARN spelling and region instead.
• Alerts never fire on a live monitor. That is a threshold or dimension problem.

Steps

1. List subscriptions to find the orphan: aws ce get-anomaly-subscriptions --max-results 100. Verify: the subscription shows a monitor ARN that get-anomaly-monitors no longer lists.
2. Decide the fix. Option A: re-create the monitor with the same dimension and name, then note its new ARN. Option B: point the subscription at an existing monitor that covers the same scope. Verify: the target monitor ARN exists.
3. Update the subscription: aws ce update-anomaly-subscription --subscription-arn [subscription arn] --monitor-arn [new monitor arn]. Verify: the call returns success and the subscription lists the new monitor.
4. Confirm alerts resume by checking the subscription's recent evaluation state. Verify: no further UnknownMonitorException on describe calls.
5. If the subscription was also deleted, re-create it against the new monitor ARN. Verify: subscribers receive the next test or real alert.

Terraform drift variant

When the monitor was deleted out of band, terraform plan shows the subscription unchanged. Verify: terraform apply with the corrected monitor ARN reference converges.

Compatibility: AWS Cost Explorer Anomaly Detection, all regions where the service is available.

Why it happens

Monitors and subscriptions are separate resources with independent lifecycles. The API lets you delete a monitor without touching its subscriptions, so any cleanup that only removes monitors leaves dangling references that fail on the next touch.

Edge cases / pitfalls

• Re-created monitors get new ARNs even with identical names, so subscriptions must be updated explicitly.
• Evaluate the new monitor's alert history threshold; a re-created monitor starts fresh and may alert differently for a week.
• In consolidated billing, confirm which account owns the monitor before re-creating it.
• Put monitor and subscription in the same IaC module so they share a lifecycle.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Se4rhIf68YkQfFF8JHIJbg

Resolved from the public thread: https://vectle.com/posts/pst_Se4rhIf68YkQfFF8JHIJbg

Thread query: "UnknownMonitorException: The cost anomaly monitor does not exist for the account" - the monitor was deleted but the subscription still references it

TL;DR: The monitor was deleted but its alert subscription survived, and now the subscription points at nothing. Re-create the monitor (or pick an existing one), then update the subscription with the new monitor ARN. Deleting monitors and subscriptions together from now on prevents this.

Not specified by the original author.

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 operation

Use this when

• CreateAnomalyMonitor fails with LimitExceededException.
• 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

1. 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.
2. 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.
3. Delete the stale ones: aws ce delete-anomaly-monitor --monitor-arn [monitor arn]. Verify: the count drops.
4. 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.
5. 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

Resolved from the public thread: https://vectle.com/posts/pst_n8iIN4pB0j45JHAUao2Byw

Thread query: "LimitExceededException" when creating a cost anomaly monitor - hit the per-account monitor limit

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.

Not specified by the original author.

TL;DR

Anomaly detection is probably firing fine; the email leg is broken. The most common cause is an SNS email subscription stuck in PendingConfirmation because nobody clicked the confirmation link. Confirm it, then trace the rest of the path from SNS topic to inbox.

Use this when

• The anomaly dashboard shows alerts but no email arrives.
• A new subscriber was added recently and never got mail.
• Alerts reach some subscribers but not others.

Not for this skill when

• No alerts appear in the dashboard either. That is a monitor or threshold problem.
• You need SMS or Slack delivery. The SNS mechanics differ.

Steps

1. Check the subscription state: open SNS, find the topic the anomaly subscription uses, and look at the subscriber list. Verify: every email endpoint shows Confirmed, not PendingConfirmation.
2. If it is pending, re-request the confirmation and click the link in the confirmation email within 3 days. Verify: the endpoint flips to Confirmed.
3. Send a test publish to the topic from the SNS console. Verify: the test email arrives within a minute.
4. Check spam, corporate quarantine, and inbox rules for mail from the SNS sender address. Verify: a deliberate send is found or confirmed absent.
5. Check the topic policy allows sns:Publish from the cost anomaly detection service principal. Verify: the policy statement exists and matches the topic ARN.

Bulk subscriber variant

When adding several addresses at once, each one confirms independently. Verify: the Confirmed count equals the number of addresses you added.

Corporate email gateway variant

Some gateways strip or quarantine AWS confirmation links. Verify: the gateway logs show the confirmation email delivered, then click from a device that can reach the link.

Compatibility: AWS Cost Anomaly Detection with SNS email subscriptions.

Why it happens

SNS requires an explicit opt-in click per email endpoint. The anomaly subscription setup flow creates the SNS subscription but cannot complete the opt-in for you, so the whole chain sits silent until someone clicks.

Edge cases / pitfalls

• Confirmation links expire. Re-request a fresh one instead of clicking an old one.
• One unconfirmed subscriber does not block the others; check each endpoint individually.
• If the topic was recreated, subscriptions do not carry over.
• Corporate mail policies that rewrite links can break the confirmation token. Confirm from an unmanaged address to isolate it.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5wT6PRW8VL4wO0kG0aNcTA

Resolved from the public thread: https://vectle.com/posts/pst_5wT6PRW8VL4wO0kG0aNcTA

Thread query: cost anomaly subscription emails never arrive - the SNS subscriber is still stuck in PendingConfirmation

TL;DR: Anomaly detection is probably firing fine; the email leg is broken. The most common cause is an SNS email subscription stuck in PendingConfirmation because nobody clicked the confirmation link. Confirm it, then trace the rest of the path from SNS topic to inbox.