Configure AWS Cost Anomaly Detection Alerts

Overview

Configure cost anomaly detection to catch unusual spend across your account and linked accounts. The plan first inventories existing anomaly monitors, notification channels, linked accounts and cost categories to surface current configuration, risky or missing pieces (disabled monitors, missing owner tags, cross-account topics, KMS/policy blockers). It then guides you to define and approve a new monitor (scope, sensitivity, notifications), creates the monitor and attaches notification subscriptions, and finally validates the created configuration and notification delivery. Throughout the process the plan produces machine-readable artifacts and auditable logs, flags items needing manual remediation, and provides remediation guidance (policy/KMS snippets, confirmation instructions, cross-account approval notes).

Execution Details

High-level phases and the main tasks performed in each.

Assessment

Purpose: Build a complete, auditable inventory and surface issues and options before any changes.

• Enumerate existing anomaly monitors

  • Collect identifying fields, lifecycle metadata, scope/filter definitions, sensitivity and detection settings, tags/owner info and any subscription references.
  • Detect risky attributes (disabled monitors, zero sensitivity, cross-account scopes, overlapping scopes, missing owner tags) and attach a short rationale for each flag.
  • Produce a machine-readable inventory (one JSON entry per monitor) and summary aggregates (counts by type, enabled vs disabled, flagged items).
  • Record any read errors or partial responses and mark affected items for re-check.

• Inventory SNS topics and notification channels

  • List topics and capture attributes (policy, delivery settings, encryption/KMS info) and enumerate subscriptions with validation of endpoints (email, URLs, ARNs).
  • Analyze topic policies for publish permissions and detect policy or KMS restrictions that would block anomaly alerts; flag cross-account topics and missing topic references.
  • Produce a machine-readable mapping TopicArn -> {attributes, KMS/policy findings, subscription list, validation status} and summary aggregates (SSE-KMS usage, publishable topics, unconfirmed subscriptions).
  • Provide remediation guidance (policy snippets, KMS hints, confirmation instructions) for topics not immediately usable.

• List linked accounts and cost categories

  • Collect linked/billing account IDs and status, organization/unit membership where available, and whether billing is consolidated.
  • Capture cost category definitions and available dimension values (services, regions, tags) usable for monitor scopes.
  • Flag constraints for organization-level or cross-account monitors and produce a machine-readable inventory plus summary counts and flags.

• Present assessment artifacts to user

  • Surface inventories and recommended scope options, highlighting flagged issues (missing topics, cross-account considerations, unconfirmed endpoints).
  • This set of artifacts is the basis for the user approval step.

User input and approval

Purpose: Gather explicit, validated inputs and approvals required to create the monitor and notifications.

• Guide the user through selecting scope and detection choices

  • Collect MonitorName, Description, MonitorType/Scope (service, linked-account, cost-category, tag-based), exact resource selectors (account IDs, service codes, regions, cost categories, tag selectors).
  • Present sensitivity options: sensitivity level or percentage thresholds, absolute cost deltas, lookback window, recurrence/frequency, aggregation choices.

• Collect operational and notification preferences

  • Desired enabled state, tags (owner/team/cost-center), any IAM/assume-role details for organization-level monitors.
  • Notification preferences: attach existing TopicARNs or request creation of new topics (topic parameters including KMS preference), preferred frequency, and endpoint lists for new topics.
  • Subscription-level filters if supported (severity, confidence, cost threshold), and test/delivery preferences (test publish, require confirmations).

• Approvals and constraints

  • Collect change window, blackout windows, error-handling policy (stop-on-first-error vs continue), cross-account approvals or owner confirmations, and approver identity and timestamp.
  • Validate inputs syntactically and against discovered inventories (e.g., referenced TopicARNs must exist or be requested for creation). Return validation errors for correction.
  • Persist a machine-readable approval artifact containing the complete monitor definition, subscription decisions, approvals, and a recommended next step (e.g., create topics before creating monitor).

Configuration

Purpose: Create the monitor and apply notification subscriptions according to the approved artifact, with auditability and verification metadata.

• Create the monitor

  • Load and validate the approval artifact; validate scope selectors against discovered accounts and cost categories.
  • Prepare the creation payload (name, scope, detection settings, lookback, recurrence, tags, enabled state) and validate payload against service constraints.
  • If organization-level roles are required, ensure role ARNs are present or escalate.
  • Create the monitor, persist the raw response and create an auditable creation log (monitor ID/ARN, payload, response, approver identity).
  • Verify enabled state and tags post-creation and produce a machine-readable create-result artifact containing the final monitor JSON, API metadata and any warnings.

• Create or attach notification subscriptions

  • Read the create-result and the approval artifact to obtain monitor IDs and subscription choices.
  • Ensure referenced TopicARNs are usable (exist and have required policy/KMS permissions); for new topics, ensure topic creation succeeded before attaching.
  • Prepare subscription payloads (MonitorId, TopicARNs, Frequency, subscription filters), validate against service limits and merge with existing subscriptions where updates are requested while preserving previous state for rollback/audit.
  • Apply subscription changes within the approved change window and according to error-handling preference; record API responses and confirmation states for confirmation-based endpoints.
  • Capture failures (policy/KMS/cross-account) with remediation steps and persist a machine-readable change-result artifact summarizing per-monitor subscription outcomes and next actions.

Validation

Purpose: Confirm the monitor and notification configuration match intent and that notifications can be delivered.

• Re-fetch and compare persisted state

  • Retrieve final monitor JSON and subscription JSON for each modified monitor and compare field-by-field against the approval artifact; record diffs and produce a PASS/FAIL per-monitor verification.
  • Re-check topic attributes and KMS/policy state for topics used by subscriptions and list any topics requiring policy or key changes.

• Confirm subscriptions and test publishes

  • List subscription confirmation states and identify unconfirmed endpoints with instructions.
  • If test publishes were requested, include delivery evidence (message IDs, timestamps) and capture any delivery errors.

• Produce verification reports

  • Generate a machine-readable verification report per monitor containing final persisted JSONs, diffs, confirmation states, API request metadata, and precise remediation actions (policy/KMS payloads, re-run steps, cross-account approval notes).
  • Provide summary aggregates (total validated, passed, failed, unconfirmed subscriptions, topics needing remediation) and attach the verification report to change-result artifacts.

Artifacts and Auditability

• Assessment artifacts: monitor inventory JSON, SNS inventory mapping, linked accounts and cost categories inventory, plus summary aggregates and flagged issues.
• Approval artifact: validated, signed user approval containing full monitor definition, notification choices, approvals and change constraints.
• Create-result and change-result artifacts: creation responses, subscription outcomes, API metadata, and auditable logs (IDs, payloads, timestamps, approver identity).
• Verification report: per-monitor PASS/FAIL results, diffs, confirmation states, delivery/test evidence, remediation payloads/snippets, and consolidated summaries.

These artifacts enable traceability, automated remediation guidance, and manual follow-up for policy/KMS/cross-account issues.