CloudFormation Templates — AWS-Native Infrastructure as Code Done Right

CloudFormation is the right choice when your team is exclusively on AWS and wants zero third-party dependencies in their infrastructure toolchain. Every new AWS service gets CloudFormation support on launch day — often before Terraform providers catch up. Features like drift detection, change sets, and automatic rollback are built into the platform, not bolted on via plugins.

The trade-off is verbosity. CloudFormation templates are more verbose than equivalent Terraform or Pulumi code, especially for complex conditional logic. But the ecosystem has matured significantly. AWS CDK lets you generate CloudFormation from TypeScript or Python if the YAML/JSON syntax is a dealbreaker. AWS SAM extends CloudFormation for serverless workloads with simpler syntax for Lambda, API Gateway, and DynamoDB.

CloudFormation's killer feature is stack rollback. If a resource creation fails mid-deploy, CloudFormation rolls back the entire stack to the previous state automatically. Terraform requires manual intervention in the same scenario. For teams without deep IaC experience, this safety net is significant.

We implement CloudFormation for teams that want AWS-native tooling with the reliability guarantees that come from the cloud provider managing the deployment engine directly.

We organize templates into nested stacks by infrastructure layer: networking, compute, data, security, and monitoring. The root stack orchestrates these layers with cross-stack references using Fn::ImportValue and exported outputs. This keeps each template under 500 resources (CloudFormation's practical limit for manageable deployments) and allows independent updates when layers do not affect each other.

Parameters use AWS::SSM::Parameter::Value types for dynamic references and AWS::CloudFormation::Interface metadata for organized parameter groups. Secrets reference AWS::SecretsManager::Secret dynamic references — never hardcoded in templates. We define Mappings for region-specific and environment-specific values, keeping templates portable across accounts.

Change sets are mandatory. We never run create-stack or update-stack directly. The CI/CD pipeline creates a change set, posts the diff for review, and executes only after approval. This mirrors the Terraform plan/apply workflow but uses CloudFormation's native mechanism, which also handles resource replacement detection more accurately.

Drift detection runs on a schedule via a Lambda function that checks all stacks weekly and sends alerts when manual changes are detected. This catches the inevitable console-based hotfixes and creates tickets to bring the templates back in sync.

A production-grade CloudFormation setup for your AWS infrastructure:

• Nested stack architecture — networking, compute, data, and security layers with cross-stack references
• Parameterized templates — SSM Parameter Store integration for dynamic configuration
• Change set workflow — CI/CD pipeline that creates change sets, posts diffs, and requires approval
• Drift detection — scheduled Lambda function that alerts on infrastructure drift
• Stack policies — protection rules preventing accidental deletion of critical resources
• Template linting — cfn-lint and cfn-nag integrated into the PR workflow
• Secrets management — Secrets Manager references, no plaintext credentials anywhere
• Runbook — operational guide for stack updates, rollbacks, and troubleshooting failed deployments