AWS::CloudFormation::StackSet does not allow setting Notifications SNS Topic ARNs for Stack Instances

[piersf]

2. Scope of request

Currently the newly released AWS::CloudFormation::StackSet resource does not allow setting Notifications SNS Topic ARNs for Stack Instances like the resource AWS::CloudFormation::Stack resource does for a stack.

In scenarios where we deploy a template to multiple accounts and multiple regions, being able to set a notifications SNS Topic ARN would allow us to have an event-driven way of receiving deployment updates/events from stack instances. This can be really powerful when we want to trigger further downstream actions(SNS -> Lambda) upon a stack instance completion.

3. Expected behavior

We should be able to specify a NotificationARNs property in AWS::CloudFormation::StackSet resource along with the other properties it currently supports. This NotificationARNs property would accept one or more SNS Topic ARNs which the Stack Instances would inherit as well and then those would be able to publish their deployment events to the topic (assuming the Topic policy is set so that it allows accepting messages from the stack instances).

4. Suggest specific test cases

An example of how this would like is(see at the end):

Type: AWS::CloudFormation::StackSet
Properties: 
  AdministrationRoleARN: String
  AutoDeployment: 
    AutoDeployment
  Capabilities: 
    - String
  Description: String
  ExecutionRoleName: String
  OperationPreferences: 
    OperationPreferences
  Parameters: 
    - Parameter
  PermissionModel: String
  StackInstancesGroup: 
    - StackInstances
  StackSetName: String
  Tags: 
    - Tag
  TemplateBody: String
  TemplateURL: String
  NotificationARNs:
    - SnsTopicArn1
    - SnsTopicArn2

5. Helpful Links to speed up research and evaluation

See an example of the same property used in a AWS::CloudFormation::Stack resource.

6. Category

5. Management (CloudTrail, Config...)
6. Security (IAM, KMS...)
7. Integration (MQ, SQS, SNS,...)
8. Developer Tools (CodeStar, ...)

[xiwhuang]

As this is not a coverage issue. (i.e. not a gap between CFN and API), I am removing the Coverage tag.

[piersf]

@xiwhuang do you have any updates about this request? Is it on your near future roadmap?

[xiwhuang]

Hi @piersf, thank you for following up with this feature request, the team is actively working on providing the notification mechanism for StackSets, I can't give the exact ECD at this moment though.

[indysogi]

@xiwhuang - any further updates on this please or is there a particular workaround?

[piersf]

@xiwhuang do you have updates on this feature, please? Thank you!

[xiwhuang]

Hi @piersf, thank you for checking in, the team is actively working on this.

[iainelder]

@xiwhuang would the stack set topic notify on the statuses of each stack instance?

I tend to deploy my stacks with a FailureTolerancePercentage of 100 so that an org-wide rollout is not aborted mid-deployment. But I would still like to collect information on all the instance-level failures to act to resolve them ASAP. Currently I can do this during a post-deployment analysis of the ListStackInstances output but and event-based solution could provide more flexibility.

When AutoDeployment is configured the stack set may perform instance operations automatically. Would these also be notified via the stack set topic?

For me it would be most convenient to receive all the instance-level notifications through a single stack-set-level topic.

[iainelder]

@piersf , yesterday AWS announced event notifications for stack sets.

Build event-driven applications with AWS CloudFormation StackSets event notifications in Amazon EventBridge

Today, AWS CloudFormation StackSets launches event notifications via Amazon EventBridge. You can trigger event-driven actions after creating, updating, or deleting your CloudFormation stack sets. You can achieve this without developing or maintaining custom solutions that periodically poll for changes in your CloudFormation stack sets deployments via CloudFormation APIs. With this launch, you can build your event-driven applications across multiple AWS accounts, Organizational Units (OUs), and Regions with AWS CloudFormation StackSets and Amazon EventBridge.

Customers use AWS CloudFormation StackSets to model, provision, and manage their cloud applications and infrastructure in a safe, predictable, and repeatable way across multiple AWS accounts and Regions. Customers use EventBridge to create event-driven applications by routing events between their applications, third-party SaaS applications, and other AWS services. You can now ingest event notifications, and trigger event-driven actions when deploying stack sets. For example, you can use stack set operation events to sequence your stack set deployment Region by Region. You can consume a stack set’s create and update operation events using a Lambda Function to trigger such regional deployment workflow. Furthermore, you can initiate post-provisioning operations for stack instances even before the stack set is completely deployed. For example, you can immediately setup Amazon CloudWatch for stack instances with successful deployment to collect, access, and analyze your stack instance data with visualization tools. We look forward to the cross-account and cross-region applications you will build using this feature.

Sounds like this is the solution we have been waiting for.

I know in my team we are excited to try it out in favor of the various custom monitoring solutions we have proposed.

Thanks @xiwhuang for the CloudFormation team's efforts on this.

[thesuavehog]

@iainelder The Security Hub control CloudFormation.1 requires that all CloudFormation Stacks are integrated with SNS notifications. Without the ability to specify an SNS notification topic for each stack in the StackSet (or 1 central topic for all to send notifications to), this control cannot be achieved.

The EventBridge solution does not allow Security Hub to recognize that notifications are being sent and received by "someone" therefore, currently, it is not a complete solution.

[iainelder]

@thesuavehog , good point.

EventBridge complies with the spirit of CloudFormation.1 if not the letter.

This is why the control exists:

Configuring an SNS notification with your CloudFormation stack helps immediately notify stakeholders of any events or changes occurring with the stack.

If you need literal compliance, then AWS can help by implementing the requested feature.

If you need CloudFormation to notify you one way or another, then you can use EventBridge and disable CloudFormation.1.

You can a disable a control via the UpdateStandardsControl Security Hub API and via the DisabledStandardsControls property of the CloudFormation type AWS::SecurityHub::Standard.

It would be great to get some guidance from the CloudFormation service team on the topic now that there are two ways to get notifications.

• Does AWS prefer that we use EventBridge over SNS?
• Would Security Hub add a control to detect a rule for CloudFormation events?

[thesuavehog]

I'm not sure a rule can be added by Security Hub to detect individual stack notification handling.

A rule could detect that there exists an EventBridge rule which would match the pattern of a CloudFormation event, and that that rule has a target specified, but since the events are for all CloudFormation stacks, the rule would not really be an effective control.

(Or else you would have to create a stack-specific rule prior to creating the stack... which is just annoying enough for no one to do it)

Possibly the CloudFormation team recommends moving to EventBridge rules for notifications instead of using the SNS notification topic, but I hope not because I know a lot of people where the effort required to set that up vs just specify a common SNS topic would result in them just not bothering with notifications (and thereby decreasing their security posture).

Hopefully there could be a improvement made to StackSets to allow providing an SNS topic that is passed through to the individual stack instances (or a topic ARN per region, or topic name where said topic would have to already exist in the account).

[iainelder]

@thesuavehog, conformance with CloudFormation.1 is now a moot point. AWS is retiring the control.

I paraphrase the Change log for Security Hub controls: "As part of a regular review of controls, Security Hub is removing CloudFormation.1 from all security standards starting on March 16, 2024. Integrating AWS CloudFormation stacks with SNS topics is no longer a security best practice. While integrating important AWS CloudFormation stacks with SNS topics can be useful, it is not required for all stacks."

[thesuavehog]

I agree that the CloudFormation.1 control is no longer a reason to implement this feature.

The use case still stands though. I have had to implement an EventBridge Pipe + Lambda Transformer + Slack API connection (in EventBridge) to replicate effectively what the SNS topic -> AWS ChatBot already does (on a regular CloudFormation stack) to capture and notify on StackSet events.

It works, but was a lot of work vs just setting an SNS topic and using existing AWS functionality.

[iainelder]

Yeah, I can see why you still want the feature. An SNS topic is sometimes more convenient than the other options for plumbing notifications.

The original question asks for the AWS::CloudFormation::StackSet resource to get a new NotificationARNs property.

A prerequisite would be support via the StackSets API, and I don't see that yet either.

I don't see any way to pass an SNS topic to these StackSets actions:

• CreateStackSet
• UpdateStackSet
• CreateStackInstances
• UpdateStackInstances

So it's not just a missing resource property but a missing service feature.

[thesuavehog]

Yes, maybe I misunderstood this repo for coverage as I thought it was for the CloudFormation service (to which the template files map YAML/JSON properties) rather than just the JSON/YAML definitions coverage.

Anyway, yeah, wherever this feature fits into the overall CloudFormation capabilities it would be nice to normalize the treatment of stack instances in StackSets as much as possible to the capabilities/functionality of independent Stacks.... notifications being the current pain point :)

[iainelder]

Yes, I'm not sure if there is a GitHub repo for CloudFormation service features as such. The closest I can think of would be cfn-language-discussion, but even there it seems out of scope.

To raise the importance of your use case to AWS, you can open a support case in your AWS account and make the feature request.

If you have a technical acount manager (TAM), you can raise the use case with your TAM too.