CDK CLI: execute deployment on CONFIGURATION_COMPLETE event

[evgenyka]

Describe the feature

When creating a CloudFormation stack, a resource can sometimes take longer to provision, making it appear as if it’s stuck in an IN_PROGRESS state. This can be because CloudFormation is waiting for the resource to complete consistency checks during its resource stabilization step. To improve visibility into resource provisioning status, CloudFormation has introduced a new “CONFIGURATION_COMPLETE” event. This event is emitted at both the individual resource level and the overall stack level during the create workflow when resource(s) creation or configuration is complete, but stabilization is still in progress.
CDK can use this new event and speed up the deployment time.

Use Case

I'm annoyed by how long it takes to deploy or redeploy my CDK app while I'm developing and testing. I can speed it up by taking a risk with CloudFormation's stabilization phase, but it's not safe for production.

Proposed Solution

Propose new CDK CLI command or additional switch to cdk deploy to execute a new optimistic stabilization strategy to shorten stack deployment times. In this mode, CDK will continue the deployment sequence using the new CONFIGURATION_COMPLETE event and not wait for CREATE_COMPLETE.

Other Information

There's a chance that resource creation might fail during the stabilization phase, which occurs between the CONFIGURATION_COMPLETE event and the CREATE_COMPLETE event. This shouldn't be the default deployment mode, and users should be warned about the risk. CDK deploy should be capable of rolling back in case of late-arriving resource creation failures.

Acknowledgements

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

CDK version used

2.132.0

Environment details (OS name and version, etc.)

MACOS

[comcalvi]

The CDK should not take this feature. Here's a few reasons why:

1. Exiting on CONFIGURATION_COMPLETE (henceforth referred to as "exiting optimistically") is not useful, and instead actively worse, on single stack deployments. When the CLI exits, it indicates that you can perform another operation; except, exiting optimistically breaks this rule, because CFN forbids starting another update operation on a stack that is in *_IN_PROGRESS, such as CREATE_IN_PROGRESS or UPDATE_IN_PROGRESS. That means a user can deploy optimistically, have the CLI exit while the stack is still IN_PROGRESS, and then the user runs another deployment and gets an error. This is not a good dev ex.
2. This is broken for multi-stack deployments. Imagine stacks A and B, where B depends on A. The CLI first deploys stack A, and deploy exits optimistically. B begins deployment and promptly fails because the output in A that B depends on does not yet exist, because A is still CREATE_IN_PROGRESS. This is also broken for stack updates, because the outputs are not updated until the stack CREATE_COMPLETE is emitted.

For clarity, CFN's optimistic stabilization feature is always on, for the resources that support it. It's not something a user can toggle on their stack. This feature request is only about leveraging the CONFIGURATION_COMPLETE event, which is the only user-exposed part of the optimistic stabilization feature.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.