SNS notifications on stack events

[logemann]

❓ General Issue

I am playing around with different ways to hook into lifecycle events of Stacks / Components. Of course there is the AwsCustomResource or ProviderFramework way. While AwsCustomResource is only viable for a simple SDK calls, ProviderFramework offers a lot more but with more complexity involved.

Now i noticed notificationArns on Stack level. What i recall you can attach them via command line on deployment (not what i am looking for) or programatically via NestedStack Construct. I wonder why this requirement is in place? Why cant we add them on our main stacks? (i think you can only read them)

This way one could easily setup a topic and a consumer and one should be able to hook into those lifecycle events pretty easily.

proposed idea

Why not having a method like this on Stack construct:

let myStack = new MyStack(app,...);
myStack.addNotificationArns(...);

Not sure why this method is not available in the construct when at the end it will synth to AWS::CloudFormation::Stack

[eladb]

Relabeled as feature. This is something we should be able to support.

[yashghatti]

@rix0rrr any update on this?

[AustinZhu]

+1

[domfie]

AFAIK: Currently only possible through the cli:
cdk deploy stackID --notification-arns='arn:aws:sns:{region}:{aws-id}:{sns-name}'
(Replace the placeholders with your values)

On subsequent calls the arn can be omitted.

[logemann]

Thats why it would make up a good feature Request. Think should be part of the AWS CDK.

[kornicameister]

Wouldn't this be a bit of chicken & egg problem? I mean something gotta provide SNS topic?

[domfie]

Wouldn't this be a bit of chicken & egg problem? I mean something gotta provide SNS topic?

Not really since you first need to deploy the sns with another stack or create it by hand. A check if this sns exists and a corresponding error message should not be the problem

[kornicameister]

Given that it seems to be already supported on nested stack it shouldn't bee to much of a trouble to add this for top-level stacks, right?

[shubhamk1997]

Any updates on this ? I agree this should be a part of the Stack construct rather than the NestedStack construct.

[tedgonzalez]

+1

[driseley]

Now that this has been added to the Security Best Practices:

https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-fsbp-controls.html#fsbp-cloudformation-1

it would be great to see better support for this.

As a simpler fix, could the notification arns be configurable in the cdk.json file, so that defaults can be configured without having to always supply them on the command line for each new stack:

https://docs.aws.amazon.com/cdk/v2/guide/cli.html#cli-config

[antonio-masotti]

Is there an update on this? Both the integration in the CDK or in the context file seem very good features for me.

It would be great, especially for projects where many devs are working on the same cdk app.

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[iamgabeortiz]

+1

[tim-g-provectusalgae]

Yes, this is being picked up by KICS as a MEDIUM severity issue and our pipelines are failing. We will have to outright ignore CloudFormation.1, which is a against AWS Security Best Practices.

[nickroberts]

Any word on this? Or a workaround?

[shazib-summar]

Its been 2 and a half years and still no update on this????

[markusl]

Hey! Is this on the roadmap? We'd like to use this in certain stacks which have a security impact

[rix0rrr]

Closed in #31107

[github-actions]

Comments on closed issues and PRs are hard for our team to see.
If you need help, please open a new issue that references this one.