Skip to content
Ask AI about this
Help improve this page

CloudFormation stacks should have notifications enabled

CloudFormation stack operations can fail silently or trigger unintended resource changes. Without SNS notifications, engineers miss rollback events, failed updates, and drift-related operations until they manually inspect the console or CLI. That delay can extend outages and leave partially deployed infrastructure undetected.

Attaching an SNS topic to every stack creates a push-based alerting path that feeds into incident management tools, ChatOps channels, or ticketing systems. It also gives security teams near-real-time visibility into infrastructure changes, which matters when investigating unauthorized modifications.

Retrofit consideration

Updating notification_arns on an existing stack triggers a stack update, which may cause brief disruption depending on the stack's change set behavior. Test in non-production first.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_cloudformation_stack.

resource "aws_cloudformation_stack" "this" {
  disable_rollback  = false
  name              = "pofix-abc123"
  notification_arns = ["arn:aws:sns:us-east-1:123456789012:example-topic"]
  template_body     = jsonencode({ AWSTemplateFormatVersion = "2010-09-09", Description = "Empty stack", Resources = { NullResource = { Type = "AWS::CloudFormation::WaitConditionHandle" } } })
}

What this control checks

The control checks that the aws_cloudformation_stack resource includes the notification_arns argument with at least one valid SNS topic ARN. A stack passes when notification_arns contains one or more ARN strings, e.g. notification_arns = [aws_sns_topic.stack_events.arn]. It fails when notification_arns is omitted or set to an empty list []. The SNS topic must exist before the stack is created or updated, so declare the aws_sns_topic resource and reference its arn attribute. For stack sets managed via aws_cloudformation_stack_set, note that aws_cloudformation_stack_set does not directly expose notification_arns; configure notifications through the stack operations that create or update stack instances, or through organizational automation.

Common pitfalls

  • Empty list passes Terraform validation but fails the control

    An empty notification_arns = [] is syntactically valid and will apply without error, but the control treats it the same as a missing argument. Pass at least one ARN.

  • SNS topic in a different region or account

    Cross-region ARNs in notification_arns cause stack operations to fail outright. CloudFormation requires the SNS topic to be in the same region as the stack. Cross-account topics may work, but only when the SNS topic policy explicitly allows the CloudFormation service principal and the relevant caller context.

  • Stack sets do not propagate notification_arns to instances

    For stack sets, notification configuration has to happen at the instance level. aws_cloudformation_stack_set has no notification_arns argument, so the setting must be applied through individual stack instance operations or a service-managed deployment that wraps each instance with the appropriate notification settings.

  • Deleted or unsubscribed SNS topic

    If the SNS topic referenced in notification_arns is deleted after stack creation, CloudFormation silently drops notifications. The stack still shows the ARN but no events are delivered. Check for orphaned topic ARNs as part of routine audits.

Audit evidence

Auditors will want compliance evaluation results from AWS Config custom or organization rules, or equivalent policy tooling, showing all in-scope stacks as compliant. Console evidence means navigating to each CloudFormation stack's settings and confirming the "SNS topic" field contains a valid ARN. For programmatic evidence, run aws cloudformation describe-stacks and verify the NotificationARNs array is non-empty for every stack in scope.

CloudTrail logs for CreateStack and UpdateStack API calls should show the NotificationARNs parameter populated. Prowler or Steampipe report output showing this check passing across all accounts and regions in scope also works.

Framework-specific interpretation

PCI DSS v4.0: For systems in the cardholder data environment, Requirement 10 asks for automated monitoring of all infrastructure changes, and Requirement 12.10 ties that monitoring to incident response readiness. Automated SNS alerts on stack operations cover both. Examiners will want to see that change events from CDE-adjacent stacks are reaching someone who can act on them.

NIST SP 800-53 Rev 5: SI-4 (System Monitoring) and IR-6 (Incident Reporting) expect automated alerting when infrastructure changes occur. Attaching an SNS topic to every stack gives monitoring and incident response teams a direct feed of stack events without requiring manual console checks.

NIST Cybersecurity Framework v2.0: DE.CM and DE.AE both call for continuous monitoring and analysis of events that could signal an adverse condition. SNS notifications on CloudFormation stacks feed that requirement directly, pushing infrastructure change events into whatever monitoring pipeline the team is already running.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: cloudformation_stack_notifications_enabled

  • AWS Config Managed Rule: CLOUDFORMATION_STACK_NOTIFICATION_CHECK

  • Checkov Check: CKV_AWS_124

  • Powerpipe Control: aws_compliance.control.cloudformation_stack_notifications_enabled

  • KICS Query: b72d0026-f649-4c91-a9ea-15d8f681ac09

Last reviewed: 2026-03-08