CloudFormation.

Where CloudFormation fits on a long engagement.

Being AWS's own service is the practical argument. New resource types are supported at launch rather than after a provider update, and the service knows how to roll a failed stack back to its previous state — which Terraform, holding state separately, handles less cleanly.

The template language is the cost. YAML with intrinsic functions is verbose and awkward for anything conditional, and large templates become difficult to read. The CDK, which generates CloudFormation from real code, exists precisely because writing it by hand at scale is unpleasant.

What an assigned team does with CloudFormation.

Stack boundaries are the decision that ages worst. Everything in one stack means every change risks everything; too many stacks means cross-stack references that are painful to modify. Both are expensive to correct once resources are live.

Getting that boundary right at the start is worth real design time, and it is the kind of foundational decision a standing assignment is there to make deliberately rather than inherit. How that works is described in how an assignment runs.

What we use CloudFormation for.

• Day-one support for new AWS services Resources available as soon as AWS ships them, with no provider lag.
• Failed deployments rolled back automatically Stack-level rollback, so a partial failure does not leave infrastructure half-applied.
• Change sets reviewed before applying A preview of what will actually change, which is the difference between a plan and a hope.

How CloudFormation capacity is assigned.

CloudFormation work is assigned under devops as a service, with stack boundaries designed at scoping rather than allowed to accrete.