In AWS CloudFormation, what problem does a nested stack solve and what problem does a StackSet solve, and how would you choose between them when designing deployments for a large estate?

## They are not alternatives The question is asked as a comparison because the names sound similar, and the useful answer starts by refusing the framing. Nested stacks address the internal structure of one deployment. StackSets address how many places a deployment lands. You can want either, both, or neither. ## Nested stacks: decomposition with one blast radius A nested stack is an ordinary resource, `AWS::CloudFormation::Stack`, whose `TemplateURL` points at a child template stored in S3. CloudFormation creates a real, separate stack for each child and manages it as part of the parent's operation. Parameters flow down into children, and children hand values back up through their outputs. What it buys you: - **Size.** CloudFormation caps how many resources one template may contain, and a large system hits it. Nesting is the supported way past it. - **Reuse.** A network layer, a standard service scaffold, a monitoring bundle — written once, instantiated repeatedly with different parameters within the same deployment. - **Readability.** A 4,000-line template nobody reviews properly becomes a parent that reads like a table of contents. What it costs you: - **One unit of failure.** The tree deploys and rolls back together. A failure in one child rolls back the parent, which rolls back the siblings that had already succeeded. That atomicity is a feature when the pieces are genuinely one system and a liability when they are not. - **Operational coupling.** You update the parent, never a child directly; updating a child stack out of band puts the parent's record out of step with reality. - **Weaker default visibility.** A change set on the parent does not expand the children unless you ask it to with `IncludeNestedStacks`, so a replacement hiding inside a child can pass review unseen. - **Harder failure diagnosis.** The parent reports that a child stack failed; the actual reason is in the child's own event stream. The alternative to nesting is separate top-level stacks wired together by cross-stack references. That inverts the trade: independent deploys and independent blast radius, at the price of losing atomic rollback and gaining rigid coupling, because an exported value cannot change while another stack imports it. ## StackSets: one template, many targets A StackSet holds a template and a target set. From one operation, CloudFormation creates a *stack instance* — a real stack — in each target account and region. Update the StackSet and it propagates. Two permission models: - **Self-managed** — you create an `AWSCloudFormationStackSetAdministrationRole` in the admin account and an `AWSCloudFormationStackSetExecutionRole` in each target account that trusts it. Works without AWS Organizations, and every new target account is manual setup. - **Service-managed** — integrated with AWS Organizations. You target organizational units rather than listing account IDs, CloudFormation handles the roles, and a delegated administrator account can run the StackSets instead of the management account. Enabling automatic deployment means an account that joins a target OU receives the stacks automatically, and one that leaves has them removed or retained by your choice. That last property is the real reason StackSets exist for platform teams: the baseline is attached to the organizational structure, not to a list somebody must remember to update. Rollout is controlled rather than simultaneous. Operation preferences carry `FailureToleranceCount` or `FailureTolerancePercentage` — how many instances may fail before the whole operation stops — plus `MaxConcurrentCount` or `MaxConcurrentPercentage`, `RegionOrder`, and `RegionConcurrencyType` set to `SEQUENTIAL` or `PARALLEL`. A sensible org-wide change goes out with a failure tolerance of zero, one region at a time, into a canary OU first. Per-instance parameter overrides let one template adapt to accounts that legitimately differ. The limits are worth naming too: a StackSet operation is not transactional across accounts — it stops on failure, it does not undo the instances that already succeeded. Drift between instances is real, because someone with admin in a member account can edit what the StackSet delivered. ## Choosing Ask what varies: - **The deployment is large or repetitive within one account and region** → nested stacks (or separate stacks, if you would rather have independent blast radius than atomic rollback). - **The same thing must exist in many accounts or regions** → a StackSet, service-managed if you run Organizations. - **Both** → common and correct: a StackSet distributing a security or logging baseline whose template is itself composed of nested stacks. And the honest counterweight for a platform decision: a StackSet couples the whole estate to one team's operation and to CloudFormation specifically. Many organisations instead run a pipeline that deploys ordinary stacks per account from version-controlled code, trading the built-in fan-out for the review, testing and rollback discipline they already have around a pipeline. That is the tradeoff a principal is expected to weigh out loud rather than defaulting to the AWS-native answer.