AWS CloudFormation
Defining your infrastructure as a version-controlled template instead of clicking through the Console — repeatable, reviewable, and rollback-able.
Want a visual for this topic?
Generate a diagram tailored to AWS CloudFormation — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain why Infrastructure as Code is preferred over manual Console configuration for production systems
- •Explain what a CloudFormation Stack is and how it tracks resources
- •Explain what a Change Set does and why you'd review one before applying it
- •Explain how CloudFormation handles rollback on a failed deployment
What is it?
AWS CloudFormation lets you define your AWS infrastructure — EC2 instances, VPCs, databases, IAM roles, and virtually every other resource type — as a declarative text template (JSON or YAML), which CloudFormation then provisions, updates, and can tear down as a single managed unit called a Stack.
Why it exists
Manually clicking through the Console to create infrastructure is fine for a one-off experiment, but breaks down for anything you need to reproduce reliably (a second environment, a disaster recovery Region), review before applying (like code review for infrastructure changes), track in version control (knowing exactly what changed, when, and why), or reliably tear down completely (manual cleanup easily misses something, leaving orphaned, costly resources behind). CloudFormation exists to make infrastructure changes as disciplined, reviewable, and repeatable as application code changes.
Problem it solves
It solves the reproducibility problem (the exact same template reliably produces the exact same infrastructure every time, in any Region or account), the drift problem (CloudFormation tracks exactly what it created and can detect when someone has manually changed something outside of the template), the review problem (a Change Set shows exactly what will change before it's actually applied, enabling review similar to a code review), and the cleanup problem (deleting a Stack cleanly removes every resource it created, avoiding orphaned resources left behind by manual teardown).
Intuition
Manually configuring infrastructure through the Console is like building a piece of furniture freehand without instructions — it might turn out fine, but reproducing that exact same result a second time, or explaining exactly what you did to someone else, is genuinely hard. CloudFormation is like a detailed, precise assembly instruction sheet: anyone (or an automated process) can follow it and get the identical result every time, and if a step needs to change, you edit the instructions rather than trying to remember and manually redo what you built by hand.
Analogy
An architectural blueprint versus a building constructed by verbal instruction and memory alone: a blueprint (a CloudFormation template) can be reviewed before construction begins, reproduced exactly for a second identical building, and referenced later to know precisely what was built and why — building purely from memory and verbal instruction makes all of that far harder and more error-prone.
Technical explanation
A template's Resources section defines each infrastructure component with a logical ID (used for internal template references) and its resource-specific properties; the Parameters section allows values to be supplied at deployment time (e.g. environment name, instance size) rather than hardcoded, making one template reusable across dev/staging/prod. A Change Set computes and displays the specific changes a template update would make (which resources would be added, modified, or replaced/destroyed) BEFORE actually applying them — critical because some property changes require replacing a resource entirely (destroying and recreating it, potentially causing data loss for a stateful resource like a database) rather than a simple in-place update, and a Change Set surfaces this distinction clearly before you commit to it. On a failed deployment, CloudFormation automatically rolls back to the last known-good state by default, undoing any partial changes already applied — preventing a stack from being left in an inconsistent, partially-updated state.
Architecture
A team maintains their entire application infrastructure (VPC, subnets, security groups, an Auto Scaling Group, an RDS instance, IAM roles) as a set of CloudFormation templates in version control, with parameters for environment-specific values. Deploying a new environment (staging, a new Region for expansion) is simply running the same templates with different parameter values, guaranteeing environment consistency that manual Console configuration could never reliably achieve. Every infrastructure change goes through a pull request reviewing the template diff, followed by reviewing the generated Change Set before actually applying it to production.
Workflow
- Write infrastructure definitions as CloudFormation templates (YAML is generally more readable than JSON for this purpose), using Parameters for anything that should vary between environments. 2) Store templates in version control alongside application code, subject to the same review process. 3) Before applying a template update to an existing stack, generate and review a Change Set to understand exactly what will change, especially watching for any resource that would be replaced rather than updated in place. 4) Apply the Change Set (or the initial template for a new stack) and monitor the deployment; rely on CloudFormation's automatic rollback if something fails partway through. 5) Delete entire environments cleanly via stack deletion when no longer needed, rather than manually hunting down and removing individual resources.
Example
A team's production database accidentally would have been replaced (destroyed and recreated, losing all data) by a seemingly innocent template change altering one of its properties — reviewing the Change Set before applying it clearly flagged this specific resource as 'Replacement: True,' letting the team catch and avoid this potentially catastrophic change before it was ever actually applied to the live production stack, simply by having the discipline to review the Change Set rather than applying the update blindly.
Real-world usage
CloudFormation is AWS's own native Infrastructure as Code service, extensively used across AWS customers of all sizes, and underlies many of AWS's own quick-start reference architecture templates that customers can deploy directly; the discipline of reviewing Change Sets before applying production infrastructure changes is a standard best practice explicitly recommended in AWS's own operational excellence guidance.
Trade-offs
Writing infrastructure as CloudFormation templates takes more upfront effort than clicking through the Console for a quick one-off resource, but pays for itself many times over for anything needing to be reproduced, reviewed, or reliably torn down — the tradeoff is deliberate, disciplined effort now versus real risk and inconsistency later. Reviewing every Change Set before applying adds a small amount of friction to each deployment, but that friction is exactly what catches dangerous changes (like an unintended resource replacement) before they happen instead of after.
Visual explanation
Picture a YAML template describing several resources (a VPC, a subnet, an EC2 instance, a security group) with logical names and dependencies between them (the EC2 instance references the subnet's logical ID, not a hardcoded value). CloudFormation reads this template and creates a Stack, provisioning each resource in the correct dependency order, tracking every created resource as belonging to that stack. Updating the template and re-deploying causes CloudFormation to calculate exactly what needs to change (a Change Set), and deleting the stack tears down every resource it originally created, cleanly.
Advantages
- —
Infrastructure changes become reviewable, version-controlled, and reproducible, mirroring the discipline already applied to application code
- —
Change Sets let you see exactly what will happen — including dangerous resource replacements — before actually applying a change
- —
Automatic rollback on failure prevents a stack from being left in a broken, partially-updated state
- —
Deleting a stack cleanly removes every resource it created, eliminating orphaned resources left behind by manual cleanup
Disadvantages
- —
Raw CloudFormation YAML/JSON templates can become verbose and repetitive for complex infrastructure, a common motivation for teams to adopt AWS CDK (covered separately) instead
- —
Some resource property changes unavoidably require replacement (destroy and recreate) rather than in-place update — this is a genuine constraint of certain resource types, not a CloudFormation limitation, but it demands care regardless
- —
Manually-made changes outside of CloudFormation (someone editing a resource directly in the Console) cause drift between the template and actual reality, which needs active detection and reconciliation
- —
Learning to write correct, well-structured templates (proper use of parameters, outputs, cross-stack references) has a real learning curve
Common mistakes
- —
Manually editing a resource created by CloudFormation directly in the Console, causing drift between the template's definition and the resource's actual live configuration
- —
Applying a template update directly without first reviewing the generated Change Set, missing a resource replacement that would destroy and recreate a stateful resource like a database
- —
Hardcoding environment-specific values directly in a template instead of using Parameters, preventing the same template from being cleanly reused across dev/staging/prod
- —
Not understanding which specific property changes on a given resource type trigger replacement versus in-place update, being caught by surprise when a seemingly minor change turns out to be destructive
- —
Building extremely large, monolithic single-stack templates instead of splitting logically-related infrastructure into separate, cross-referenced stacks, making the template harder to review and reason about as it grows
In the AWS Console
- 1
AWS Console → CloudFormation → Stacks → Create stack
Upload or write a template (YAML/JSON), fill in any defined Parameters, and review the resources CloudFormation will create before confirming.
Review the 'Resources' section of the console preview carefully — this is your last checkpoint before actual resource creation begins.
- 2
CloudFormation → [your stack] → Change sets → Create change set
For an update to an existing stack, create a Change Set from the updated template, and review the displayed list of Add/Modify/Remove actions before executing it.
Pay close attention to any resource marked for 'Replacement' — this means CloudFormation will destroy and recreate that resource, a potentially data-destructive operation for stateful resources.
- 3
CloudFormation → [your stack] → Drift detection → Detect drift
Run drift detection to identify any resources that have been manually modified outside of CloudFormation since the stack was last deployed.
Regular drift detection catches configuration that's silently diverged from the template, which would otherwise go unnoticed until it causes an unexpected problem.
🎤 Interview questions
Why would a team use CloudFormation instead of manually configuring infrastructure through the Console? (Listen for: reproducibility, reviewability (Change Sets), version control alongside application code, reliable cleanup via stack deletion, and consistency across environments.)
What's a CloudFormation Change Set, and why would you review one before applying it? (Listen for: shows exactly what will be added/modified/removed before actually applying an update; critical for catching a resource replacement (destroy+recreate) that could cause data loss on a stateful resource.)
What happens if a CloudFormation stack update fails partway through? (Listen for: automatic rollback to the last known-good state by default, preventing the stack from being left in a broken, partially-applied state.)
What is 'drift,' and why does it matter? (Listen for: divergence between a template's defined configuration and a resource's actual live configuration, typically caused by manual out-of-band changes; matters because it undermines the reliability of the template as the source of truth.)
Give an example of a change that might unexpectedly require CloudFormation to replace a resource rather than update it in place. (Listen for: any concrete, plausible example — e.g. changing certain immutable properties of a resource — showing understanding that this distinction is a real, consequential risk to watch for.)