CloudFormation stack event notifications are delivered to an SNS topic, but most people don’t realize the topic itself can be the only place you see these events if you don’t subscribe anything to it.
Let’s see this in action. First, we need a CloudFormation stack that will actually do something, so we can generate events. A simple S3 bucket creation will do.
Resources:
MyTestBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub "my-unique-test-bucket-${AWS::AccountId}"
Now, we need an SNS topic. We can create this either manually in the console or via another CloudFormation stack. For this example, let’s assume we have a topic ARN: arn:aws:sns:us-east-1:123456789012:my-cloudformation-events.
To hook up notifications, we modify the AWS::CloudFormation::Stack resource definition. This isn’t a resource within your stack, but rather a way to manage a stack from another stack. If you’re managing a single stack, you’d add these properties directly to the stack’s creation or update request, not in a Resources block. But for demonstration, let’s pretend we’re managing a nested stack:
Resources:
MyNestedStack:
Type: AWS::CloudFormation::Stack
Properties:
TemplateURL: https://my-s3-bucket-for-templates.s3.amazonaws.com/my-simple-bucket-template.yaml
Parameters:
# ... any parameters your nested stack needs ...
NotificationARNs:
- arn:aws:sns:us-east-1:123456789012:my-cloudformation-events
When CloudFormation starts creating or updating MyNestedStack, it will send events like CREATE_IN_PROGRESS, CREATE_COMPLETE, UPDATE_IN_PROGRESS, UPDATE_COMPLETE, ROLLBACK_IN_PROGRESS, and ROLLBACK_COMPLETE to the specified SNS topic.
The problem most people run into is expecting these notifications to magically appear in their inbox or a Slack channel. The NotificationARNs property only tells CloudFormation where to send the event payload. It doesn’t automatically set up a delivery mechanism.
To actually receive these notifications, you need to subscribe an endpoint to the SNS topic. The most common endpoints are:
- Email: For direct notifications.
- SQS Queue: To process notifications programmatically.
- Lambda Function: To trigger custom logic based on events.
- HTTP/S Endpoint: For webhook integrations.
Let’s focus on the most common path: email.
To subscribe an email address, you’d typically use the AWS CLI:
aws sns subscribe \
--topic-arn arn:aws:sns:us-east-1:123456789012:my-cloudformation-events \
--protocol email \
--notification-endpoint your.email@example.com
After running this, your.email@example.com will receive a confirmation email. You must click the confirmation link in that email. Until confirmed, the subscription is PendingConfirmation and will not receive messages.
Once confirmed, any subsequent CloudFormation stack events for stacks that list arn:aws:sns:us-east-1:123456789012:my-cloudformation-events in their NotificationARNs will be sent to your email. The email payload will be a JSON object detailing the event, including the stack name, region, status, and a link to the event in the AWS console.
If you’re using CloudFormation to manage the SNS topic and its subscriptions, you’d define the topic and then use a CustomResource or a separate AWS::SNS::Subscription resource. A common pattern is to use a Lambda-backed Custom Resource for subscriptions if you need dynamic endpoint configuration, as AWS::SNS::Subscription resources are often tricky to manage for dynamic subscriptions directly in CloudFormation.
The critical piece of understanding is that the NotificationARNs property on a AWS::CloudFormation::Stack resource (or directly on stack operations) is a one-way street to SNS. It’s the source of the notification data, not the destination for a human or an automated system. The SNS topic acts as a fan-out point, and it’s your responsibility to ensure there are active, confirmed subscribers listening to that fan-out.
The next step after getting event notifications is often setting up automated rollback actions based on specific event types, which requires integrating with services like AWS Config or EventBridge.