Configure AWS Cost Anomaly Detection Alert Subscriptions

Overview

Configure Cost Anomaly Detection so that cost spikes are consistently detected and routed to the right people and systems. The plan inventories your existing anomaly monitors and subscriptions, guides you through choosing thresholds and recipients, sets up or updates SNS topics and subscriptions as needed, then validates that everything is wired correctly and ready to send alerts when anomalies occur.

Execution Details

Assessment

This phase focuses on understanding your current Cost Anomaly Detection setup and designing the target alerting configuration.

Inventory existing monitors

• Gather a complete list of all Cost Anomaly Detection monitors in the account.
• Capture key attributes for each monitor, including name, ARN, type (DIMENSIONAL, CUSTOM, etc.), monitored scope (such as SERVICE, LINKED_ACCOUNT, COST_CATEGORY, TAG), creation and last update times, and current status.
• Identify whether monitors are global or scoped to specific services or accounts, and compile this information in a structured format for later use.

Inventory existing anomaly alert subscriptions

• Retrieve all existing Cost Anomaly Detection alert subscriptions.
• For each subscription, record its name, identifier/ARN, associated monitor ARNs, subscription type or scope, threshold type and numeric value, and alert frequency (IMMEDIATE, DAILY, etc.).
• Document configured notification channels, including all email recipients and SNS topic ARNs, along with subscription status.
• Map subscriptions back to their monitors to highlight any monitors that currently lack alerting coverage.

Guide user to select monitors and alert thresholds

• Present the full monitor inventory, including which monitors currently have alert subscriptions.
• Guide the user to choose which monitors must have alerts configured, updated, or disabled.
• For each selected monitor, collect the desired threshold type (e.g., ABSOLUTE or PERCENTAGE), threshold value, alert frequency, any naming/tagging preferences, and which monitors should stop generating alerts.
• Document and confirm the final monitor-to-threshold and frequency design before proceeding.

Guide user to define notification recipients and channels

• Present currently configured notification channels from existing subscriptions (email addresses and SNS topics), along with a list of existing SNS topics that might be reused.
• Help the user choose which email addresses and SNS topics should receive anomaly notifications, and whether new SNS topics are needed for particular audiences (e.g., finance, operations, incident management).
• Work with the user to decide whether notifications are shared across all monitors or targeted per monitor/monitor group, and whether any channels should receive only specific kinds of alerts (such as only high-value anomalies).
• Finalize and obtain sign-off on the mapping from monitors (or monitor groups) to email and SNS notification channels.

Inventory SNS topics for anomaly notifications

• Compile a catalog of SNS topics that are suitable for anomaly notifications, focusing on cost and operations–related topics.
• For each topic, record its name, ARN, region, display name, existing subscriptions (protocols and endpoints), and key elements of its access policy (who can publish and subscribe).
• Identify which topics are already used by Cost Anomaly Detection and highlight good candidates for reuse based on naming and current purpose.
• Produce a structured SNS topic inventory to support the configuration phase.

Configuration

This phase builds or updates the notification infrastructure and Cost Anomaly Detection subscriptions based on the agreed design.

Create SNS topics for anomaly alerts (as needed)

• Determine which new SNS topics are required according to the approved notification design.
• Define topic names consistent with organizational naming standards and choose appropriate regions.
• Create any required topics, optionally setting clear display names for readability in notifications.
• Apply least-privilege access policies that allow intended publishers and managers only.
• Record ARNs, regions, and topic details centrally for use when configuring subscriptions.

Configure SNS subscriptions for recipients

• For each SNS topic designated for anomaly alerts, determine the full list of recipients and endpoints from the approved mapping.
• Create or confirm SNS subscriptions for the required protocols (email/email-json, SMS, HTTP/HTTPS, Lambda, SQS, etc.), ensuring endpoints are correctly specified.
• Ensure that any confirmation steps (like email opt-in) are triggered and tracked.
• Record the active subscriptions per topic and verify they align with the intended audiences and purposes.

Adjust SNS topic policies for Cost Anomaly Detection publishing

• Identify all SNS topics that will be referenced by Cost Anomaly Detection alert subscriptions.
• Review current access policies for these topics and determine which AWS Billing and Cost Management service principals or accounts must be allowed to publish.
• Update topic policies to grant precise publish permissions for Cost Anomaly Detection while preserving existing protections and avoiding unnecessary access expansion.
• Validate and record the updated policies, confirming that all intended topics can receive anomaly notifications.

Create Cost Anomaly Detection subscriptions

• Using the finalized design, identify monitors that need new alert subscriptions because they lack coverage or do not meet requirements.
• For each new subscription, define an appropriate name, associate the correct monitor ARN(s), and configure threshold type, threshold value, and alert frequency per user input.
• Attach the agreed email recipients and SNS topics to each subscription, along with any additional properties supported by Cost Anomaly Detection that reflect user intent.
• Create the subscriptions, then capture their identifiers/ARNs and confirm that they are active and correctly associated with the intended monitors and channels.

Update existing anomaly subscriptions

• From the inventory, find existing subscriptions tied to user-selected monitors that require changes.
• Compare current thresholds, frequencies, and notification channels against the approved configuration.
• Update thresholds, frequencies, email recipients, and SNS topics as needed so subscriptions match the desired state.
• Where required, disable or remove subscriptions for monitors that should no longer generate alerts.
• Record the final configuration of all updated subscriptions and confirm that each is in the correct active or disabled state.

Validation

Validate Cost Anomaly Detection subscriptions and notification paths

• Retrieve the current list of monitors and alert subscriptions after all changes.
• Confirm that every monitor the user designated for alerting now has at least one active subscription, with threshold type, threshold value, and alert frequency matching the approved design.
• Verify that each subscription has exactly the intended email recipients and SNS topics, with no unexpected destinations.
• Ensure that SNS topic policies still allow Cost Anomaly Detection to publish to all referenced topics.
• Where feasible, test at least one SNS notification path (e.g., by sending a non–anomaly test message to a relevant topic) to confirm end-to-end delivery.
• Document the final mapping of monitors, subscriptions, thresholds, frequencies, and notification channels, and validate that the configuration meets the original goal of reliably alerting on detected cost anomalies.