CloudFormation
AWS's native infrastructure-as-code service — declarative stacks with managed state and automatic rollback, at the cost of YAML verbosity and AWS lock-in.
What is CloudFormation?
CloudFormation is AWS’s native infrastructure-as-code service: describe resources in a JSON/YAML template, and CloudFormation provisions and tracks them as a stack, computing the changes needed to reach your declared state. Its defining advantages over rolling your own are managed state (AWS stores it — no Terraform-style state file to secure and lock) and automatic rollback (a failed deployment reverts the whole stack rather than leaving half-built wreckage).
CloudFormation versus Terraform — the real decision
The perennial choice. CloudFormation: AWS-native, no state-file management, deep and immediate support for new AWS features, IAM-integrated. Terraform: multi-cloud, far larger module ecosystem, HCL that most engineers find more readable than CloudFormation YAML, but you own the state backend and its locking. The honest split: single-cloud AWS shops that value native integration and hate state management lean CloudFormation; multi-cloud or teams wanting Terraform’s ecosystem and expressiveness lean Terraform. CDK (Cloud Development Kit) reframes the question — write infrastructure in TypeScript/Python and synthesize CloudFormation templates, escaping raw YAML while keeping CloudFormation’s engine, and it’s now how many AWS-native teams actually build.
The operational sharp edges
Change sets preview what an update will do before it does it — the CloudFormation equivalent of terraform plan, and skipping them is how surprise deletions happen (note that some updates replace resources, meaning downtime or data loss on stateful ones — read the change set’s replacement column). Drift detection flags manual console changes that diverge from the template. Stuck stacks (a resource that won’t create or delete cleanly) are the classic incident, sometimes needing manual intervention to unwedge — the price of managed state is less control when it goes wrong.
What people get wrong
- Applying updates without change sets and discovering “update” meant “replace and lose data.”
- Console edits to CloudFormation-managed resources, creating drift that the next deploy fights.
- Monolithic mega-stacks: one giant stack makes every change slow and risky; split by lifecycle and blast radius.
Primary source: AWS CloudFormation documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.