Support CloudFormation rollback triggers

[nakedible]

CloudFormation supports specifying 0-5 rollback triggers as CloudWatch Metric Alarms, which when triggered will automatically cause the stack update to be cancelled. Also a monitoring time of 0-180 minutes can be specified, which means a pause time CloudFormation will wait for any of the alarms to be triggered, or a rollback to be manually triggered, before cleaning up any resources.

There should be a way to use these with AWS CDK.

Use Case

Rollback triggers have obvious uses to make stack updates more reliable.

Proposed Solution

Similar to --notification-arns currently in deploy command, add --rollback-trigger-alarm-arns option to be able to list 1-5 CloudWatch Alarms that automatically trigger a rollback. Also add --monitoring-time-minutes option which can be used to add 0-180 minutes of pause time after a stack update before the cleanup phase starts. Both options can be specified independently, as they are useful on their own.

Other

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-rollback-triggers.html
https://docs.aws.amazon.com/AWSCloudFormation/latest/APIReference/API_RollbackConfiguration.html

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[rix0rrr]

Feels to me that it makes sense to encode the rollback triggers in the modeled app, rather than requiring to pass them on the command-line on every invocation, as every deployment would probably require the same triggers.

Thoughts?

[eladb]

@rix0rrr absolutely agree but the challenge is going to be how we propagate these instructions to things like CI/CD

[rix0rrr]

It seems CodePipeline hasn't implemented that particular parameter yet in their deploy action (yet).

So the question is, do we model as CLI parameters so that no person would expect the behavior would extend to CI/CD deployments (at the risk of a worse user experience), or do we model in the application to improve the user experience and note the rollbacks won't be supported for CI/CD (risking getting bug-ticketed by people not reading the disclaimer)?

Not an easy choice :/

[nakedible]

I think there are places where it makes sense to encode this in the application, and places where it makes sense to have it externally specified. Just like notification ARNs, there are also many places where those should be encoded in the app - but they are currently a command line option. Notification ARNs are also not supported by CodePipeline.

Personally, I'd suggest adding this as a command line option so people can use them in their own tooling (as we would) - and worry about CI/CD later on. Who knows maybe CodePipeline will end up adding these missing features at some point...

[jusiskin]

These are per-deployment parameters as they are passed as arguments of the CreateStack/UpdateStack/CreateChangeSet CloudFormation APIs.

That being said, it doesn't limit the approach CDK takes for exposing that functionality to CDK users. Does it make sense to use a search order for resolving the parameters:

1. Use command-line argument from cdk deploy
2. Use environment variables
3. Use CDK stack configuration
4. Use CDK app configuration

[mattsains]

Hello! I am interested in helping move this feature request forward, but I'm not too familiar with the CDK's process on this.

I think what @jusiskin suggested makes sense.

Since this is (in my opinion) a pretty important feature for safe CDK deployments, maybe we could target a "minimum viable product" of adding a command line argument that takes in a list of up to five cloudwatch alarm ARNs, as well as a parameter for the length of bake time after a deployment, something like this:

cdk deploy --rollback-triggers arn:aws:cloudwatch:us-west-2:123456:alarm:MyAlarm1,arn:aws:cloudwatch:us-west-2:123456:alarm:MyAlarm2 --monitoringTime 10

It would also be nice if you could specify an alarm within the stack by its logical ID, but I'm not sure about that.

I am interested in whether others think this is a good enough experience to move forward with a PR.