A coworker wants to use AWS CloudFormation to deploy an entire application and its infrastructure in one shot. A contractor provided a single monolithic template containing ECS clusters and services, RDS, S3, Lambda, API Gateway, and other resources. I'm concerned about the blast radius, mixing stateful resources with components that have very different lifecycles, and the lack of CI pipelines to validate change sets when changes are proposed. My background is mainly in Terraform, so I'd like to hear from people with substantial CloudFormation experience: what are its real limitations, and what practices make CloudFormation deployments safer and more reliable?
5 Answers
The monolithic design is a bigger concern than CloudFormation itself. Separate resources by lifecycle and ownership: for example, foundational networking and security, shared platform services, databases and other stateful resources, and application services. That reduces blast radius and makes it easier to grant developers access to application stacks without letting them modify core infrastructure. Use change sets and CI validation rather than applying large templates manually.
CloudFormation is perfectly usable at scale when it is treated as part of a disciplined delivery system. We use it for many deployments, but we keep stacks reasonably focused, review generated changes, automate deployments, and avoid putting unrelated stateful and ephemeral resources together. StackSets are also useful for applying standard configurations across accounts, although diagnosing failed instances can be painful.
StackSets are one of CloudFormation’s stronger features, especially for account or organizational-unit-wide policies. For most other workflows, teams often need CI/CD and careful stack boundaries to get the same level of control.
Vanilla templates are verbose and not especially expressive. YAML becomes difficult to read and maintain as you add conditions, mappings, nested stacks, and cross-stack references. Terraform generally has a more convenient language and plan output, while CDK lets you use a real programming language for iteration, composition, lookups, and type checking. CDK still produces CloudFormation, so it improves authoring without removing the underlying stack behavior.
Another consideration is AWS coupling. CloudFormation has excellent first-party coverage and integrates naturally with AWS, but it is a poor choice if portability across cloud providers or a broader ecosystem is important. Terraform tends to have better third-party tooling and supports more platforms. For an AWS-only environment, that trade-off may be acceptable; the important thing is to choose deliberately rather than calling one giant template an industry best practice.
The biggest operational problems are usually slow deployments, awkward failure recovery, and the way a stack becomes a single unit of change. If a deployment gets stuck because of permissions or a resource update failure, you may have to force the stack to finish failing, wait for that process, fix the issue, and then retry. CloudFormation has improved over the years, but recovery can still be frustrating.
That separation is exactly what I was concerned about. The database and application services should not be tied to the same update and rollback lifecycle.