NestedStacks 和 Constructs 之间的权衡是什么？

Question

I'm trying to understand the use case of Nested Stacks vs. Constructs specifically in CDK. The AWS docs say the following:

Stacks are the unit of deployment: everything in a stack is deployed together. So when building your application's higher-level logical units from multiple AWS resources, represent each logical unit as a Construct, not as a Stack. Use stacks only to describe how your constructs should be composed and connected for your various deployment scenarios.

This makes sense when evaluating whether to use a Construct or Stack, but what about Nested Stacks? Both Constructs and Nested Stacks solve the problems of:

• reusability of component architectures
• controlled information sharing between components / mitigating import and export (deadly embrace) issues
• and both Constructs and Nested Stacks are deployed together from the root Stack (from what I understand, NestedStacks are rarely deployed alone and are intended to be deployed as part of a group of NestedStacks under one parent Stack)

So what's the benefit of using Nested Stacks over Constructs besides working around the resource limitations of a single Stack (ie when should I use one over the other)?

Answer 1

It's instructive how differently the CloudFormation docs and CDK docs present Nested Stacks. The CloudFormation docs focus on their role in component resuse. The CDK docs don't mention reuse, instead presenting them as a workaround for the per-stack resource limit. Of course, Nested Stacks do both things.

CDK Constructs are more composable and portable than the Nested Stacks it inherited from CloudFormation. The CDK docs recommend Constructs for composition here and here .

Apart from overcoming the per-stack resource limit, there is a backwards compatability rationale for using Nested Stacks when including existing CloudFormation templates into CDK apps.