A coworker wants to use CloudFormation to deploy an entire application and its AWS infrastructure in one shot. A contractor provided a monolithic template containing ECS clusters and services, RDS, S3, Lambda, API Gateway, and other resources in a single stack. I'm concerned about the blast radius, the fact that stateful resources and short-lived application components have very different lifecycles, and the lack of CI pipelines to validate change sets when changes are proposed. The contractor claims this is industry best practice, but I'm skeptical. My background is mainly in Terraform, so I'd like practical guidance from people who use CloudFormation successfully: what are its real weaknesses, and what patterns make deployments safer and more reliable?
5 Answers
Compared with Terraform, vanilla CloudFormation is generally more verbose and less expressive. YAML templates can be difficult to read and maintain, the intrinsic-function syntax gets cumbersome, and the plan or change-set experience is often less clear. Drift and failed updates can also be frustrating to diagnose. CloudFormation does integrate tightly with AWS and supports features such as StackSets, which are useful for applying standard resources across accounts, so it is not unusable. The main issue is choosing the right scope and workflow rather than treating one huge template as the whole platform.
The biggest practical problems are CloudFormation’s speed and recovery behavior. Deployments can be slow, and a failed update—especially one involving permissions or dependencies—can leave a stack stuck in rollback or another awkward state. Sometimes you have to continue or finish the failure, wait for it to settle, fix the underlying issue, and try again. The single-stack design also creates a large blast radius, although that is more an architectural mistake than a CloudFormation-specific limitation.
Another consideration is portability. CloudFormation is tightly tied to AWS, so moving to another provider later means replacing the infrastructure tooling and usually redesigning parts of the configuration. If avoiding cloud lock-in is important, Terraform may be a better fit. If the organization is firmly AWS-only, CloudFormation’s native integration and StackSets can outweigh that concern.
If the team wants to stay in the CloudFormation ecosystem, AWS CDK is usually a more pleasant authoring experience than writing raw YAML. You get a real programming language, reusable constructs, loops, validation, and better support from an IDE, while the result is still CloudFormation. That does not eliminate the need to split stacks, protect stateful resources, review generated changes, or test deployments, but it can make the templates much easier to maintain.
I would split the system by lifecycle and ownership rather than putting everything in one giant template. Network and shared security components should be separate from databases, platform services, and application deployments. Stateful resources such as RDS should have especially conservative ownership and deletion policies, while ECS services and application code can change much more frequently. Use CI/CD to lint and synthesize templates, validate change sets, enforce approvals, and deploy with appropriately limited roles. A monolithic stack may be convenient for a demo, but it becomes difficult to reason about in a real environment.
That separation also helps with permissions. Developers can update application stacks without being able to modify the database, networking, or organization-wide security configuration.