AWS CloudFormation
CloudFormation is AWS's infrastructure-as-code service. You write a template in YAML or JSON describing the resources you want; CloudFormation creates them in dependency order, manages their lifecycle as a single stack, and updates or rolls back when the template changes.
It is the foundation that the AWS CDK generates and that many AWS services use internally — one of three main IaC choices on AWS alongside CDK and Terraform.
Templates, Stacks, and Change Sets
A template declares resources, parameters, mappings, conditions, and outputs. A stack is the deployed template in one Region of one account, tracking every resource as a unit — deleting the stack deletes its resources.
A change set previews what an update would do before applying it — showing which resources will be created, updated, or replaced. Change sets are the right pattern for any production update.
Resource Lifecycle and Drift
Updates behave in one of three ways: no interruption (in place), some interruption (briefly unavailable), or replacement (new resource created, old deleted). The change set tells you which before you commit. Deletion policies (Retain, Snapshot) control what happens to stateful resources when removed.
Drift detection compares live state to the template and flags differences — a tag added in the console, a security-group rule edited by hand — so you can reconcile or back them out.
StackSets
A StackSet deploys the same template across many accounts and Regions in an Organization. You update the StackSet and CloudFormation propagates the change to every instance — the standard way to roll out organization-wide baselines like CloudTrail, IAM roles, and logging.
CloudFormation — declarative YAML/JSON IaC, AWS-native and free for AWS resources. The foundation CDK builds on.
AWS CDK — the same deployment via real programming languages — loops, abstractions, tests — synthesized to CloudFormation.
Terraform — multi-cloud IaC when you need one tool across AWS and other providers.
- Pushing a production update directly without a change set, then being surprised when a property change replaces a stateful resource.
- Leaving stateful resources without a
DeletionPolicy: Retain, so an accidental stack deletion destroys the database or bucket. - Hard-coding values instead of using parameters and intrinsic functions, so the template only works in one environment.
- Letting templates grow into thousands of unmaintainable lines instead of splitting into nested stacks or moving to CDK.
- Deploying organization-wide baselines by hand to each account instead of using StackSets.
- Never running drift detection, so manual console edits silently diverge from the template.
- Use change sets in production — never apply an update blind.
- Keep templates in version control and review them like application code.
- Set DeletionPolicy: Retain (or Snapshot) for databases and buckets you cannot lose.
- Use StackSets for multi-account baselines via AWS Organizations.
- Split complex stacks into nested stacks, or move to CDK for ergonomics.
- Run drift detection periodically and reconcile differences.
Knowledge Check
What does a CloudFormation change set provide?
- A preview of what an update will create, modify, or replace before you apply it
- A point-in-time backup of all of the stack's resources
- A second copy of the stack deployed in another Region
- Automatic rollback to the last good state when a deploy goes wrong partway through
How do you protect a database from being destroyed if its stack is accidentally deleted?
- Set DeletionPolicy: Retain (or Snapshot) on the resource
- Enable drift detection so the deletion is blocked
- Use a StackSet to replicate the database elsewhere
- Hard-code the database name in the template so it cannot be removed
What is a StackSet used for?
- Deploying one template across many accounts and Regions from a single place
- Previewing the exact resource changes an update would make before you apply them
- Detecting configuration drift from the declared template
- Converting an existing template into CDK constructs
What does drift detection report?
- Differences between the live state of resources and what the template declares
- Which resources in the stack cost the most each month, ranked by spend
- Whether the stack has been replicated into another Region for disaster recovery
- The order in which resources will be created on the next deploy, by their dependencies
You got correct