AWS CloudFormation: What It Is and When to Use It

Definition

AWS CloudFormation is AWS's native Infrastructure as Code (IaC) service. You describe the AWS resources you want — VPCs, EC2 instances, IAM roles, Lambda functions, RDS databases, S3 buckets, and thousands more — in a JSON or YAML template, submit that template to CloudFormation, and the service provisions, updates, and deletes those resources as a single unit called a stack. If anything fails during a deploy, CloudFormation automatically rolls back to the previous known-good state. Because templates live in version control, your entire infrastructure becomes reviewable, repeatable, and auditable.

How It Works

A CloudFormation template has up to nine top-level sections, but only Resources is required. The common ones are:

• Parameters — inputs supplied at deploy time (instance size, environment name, AMI ID).
• Mappings — static lookup tables (e.g., AMI per Region).
• Conditions — gate resources on environment or parameter values.
• Resources — the actual AWS objects, each with a logical ID, Type (e.g., AWS::EC2::Instance), and Properties.
• Outputs — exported values (ARNs, URLs) for cross-stack references or operator consumption.
• Transform — macros that rewrite the template before deploy, including AWS::Serverless (SAM) and AWS::Include.

You submit a template through the Console, CLI (aws cloudformation deploy), SDK, CDK, or a CI/CD pipeline. CloudFormation then:

1. Creates a Change Set (preview of adds / modifies / replacements / deletes) so you can review before applying.
2. Executes operations in dependency order, in parallel where safe.
3. On any failure, rolls back to the last stable state — the CREATE_FAILED → ROLLBACK_COMPLETE path is familiar to anyone who's used CloudFormation.
4. Records every event in the stack's event history.

Key Features and Limits

• Stacks — a single unit of create/update/delete across many resources.
• Nested stacks — a parent stack references child stacks via AWS::CloudFormation::Stack, keeping templates below the 1 MB (or 512 KB inline) limit and enabling reuse.
• Cross-stack references — Export / Fn::ImportValue share values (e.g., a VPC ID from a networking stack to an application stack). Note: exports are immutable while imported.
• StackSets — deploy the same template across many accounts and Regions from a single operation; essential for AWS Organizations landing zones.
• Change Sets — preview exactly which resources will be created, updated (no interruption), updated with interruption, replaced (delete + recreate), or deleted.
• Drift detection — compares live resources to the template and reports out-of-band changes; crucial for governance.
• SSM Parameter Store integration — reference {{resolve:ssm:/my/param}} or {{resolve:secretsmanager:...}} so templates pull runtime config and secrets instead of hardcoding them.
• Helper scripts — cfn-init, cfn-signal, cfn-hup, cfn-get-metadata for bootstrapping EC2 instances.
• Transforms — AWS::Serverless (SAM), AWS::Include, and custom macros for template-time code generation.
• Rollback triggers — link CloudWatch Alarms so a deploy rolls back when application metrics fail.
• Stack policies — JSON rules that protect production resources from accidental updates.
• Custom resources — back a resource with a Lambda function for anything CloudFormation doesn't support natively.
• Resource import — bring existing, manually-created resources under CloudFormation management without re-creating them.

Common Use Cases

1. Full application stacks — VPC + subnets + ALB + ASG + RDS in one template.
2. Landing zones — StackSets deploy baseline guardrails (CloudTrail, Config, GuardDuty) to every account in an AWS Organization.
3. Serverless applications — AWS SAM (a CloudFormation Transform) simplifies Lambda + API Gateway + DynamoDB.
4. Blue/green environments — spin up a parallel stack, cut over via DNS, delete the old stack.
5. Ephemeral per-PR environments — CI creates a stack per pull request; deletion is one command.
6. Compliance baselines — drift detection plus AWS Config rules catch manual console changes.

Pricing Model

CloudFormation itself is free for managing AWS::* resource types — you pay only for the underlying resources (EC2, RDS, etc.). Charges apply only to third-party resources registered via the CloudFormation Registry (Hashicorp, Datadog, MongoDB providers, etc.) and to some high-frequency operations:

• Third-party resources — per handler operation (create/update/delete/read/list), priced per 1,000 operations.
• No charge for Change Sets, drift detection, StackSets operations against AWS-native resource types, or exports.

CloudFormation StackSets themselves are free; you pay only for the deployed resources in each target account.

Pros and Cons

Pros

• Native AWS service — no extra agent, no state file to manage, no vendor lock-in beyond AWS itself.
• Automatic rollback on failure and full event history.
• StackSets for multi-account/multi-Region fan-out are best-in-class on AWS.
• Change Sets preview changes before applying — essential for production.
• Free for AWS resources.

Cons

• YAML/JSON is verbose compared to CDK or Terraform HCL.
• New AWS service features sometimes land in CloudFormation weeks or months after launch.
• Cross-stack Export values cannot be changed while referenced — a common operational headache.
• Circular dependencies and replacement behavior (e.g., changing an RDS parameter that forces recreation) can bite without Change Set review.
• Limits: 500 resources per stack, 200 parameters, 200 outputs (raise via nested stacks).

Comparison with Alternatives

| | CloudFormation | AWS CDK | Terraform | AWS SAM | | --- | --- | --- | --- | --- | | Language | JSON / YAML | TypeScript, Python, Java, Go, .NET | HCL | YAML (SAM macro) | | Execution engine | CloudFormation | Synthesizes to CloudFormation | Terraform engine + state file | CloudFormation | | AWS feature coverage | First-party | First-party | Usually a lag | Serverless only | | Multi-cloud | AWS only | AWS only (also CDKTF) | Multi-cloud | AWS only | | State management | Service-managed | Service-managed | Self-managed (S3/Cloud) | Service-managed | | Best for | Declarative AWS IaC, governance | AWS teams wanting a real programming language | Multi-cloud, rich module ecosystem | Serverless applications |

Exam Relevance

• Solutions Architect Associate (SAA-C03) — know what a stack is, how Parameters / Outputs / Resources work, nested stacks vs cross-stack references.
• Developer Associate (DVA-C02) — SAM transforms, helper scripts (cfn-init, cfn-signal), custom resources backed by Lambda.
• SysOps Administrator (SOA-C02) — drift detection, stack policies, Change Sets, StackSets operations, troubleshooting ROLLBACK_FAILED.
• DevOps Professional (DOP-C02) — heavy coverage: StackSets across AWS Organizations, nested stacks for large templates, pipeline integration, rollback triggers with CloudWatch Alarms, multi-account landing zones.

Exam trap: confusing Export/ImportValue (cross-stack references, tight coupling) with AWS::CloudFormation::Stack nested stacks (parent/child composition). Another: remembering that resource updates that require replacement (changing an RDS DBInstanceIdentifier) delete-then-create, which can drop data.

Frequently Asked Questions

Q: What's the difference between nested stacks and cross-stack references?

A: Nested stacks are parent–child: the parent template includes AWS::CloudFormation::Stack resources that point to child templates in S3. Updates flow top-down; the whole tree deploys together. Cross-stack references are peer-to-peer: stack A Exports a value, stack B ImportValues it. They're loosely coupled but create a hard constraint — you can't modify or delete an exported value while any other stack references it. Use nested stacks for reusable building blocks inside a single application; use cross-stack references for stable shared infrastructure (e.g., a VPC stack shared by many app stacks).

Q: What is drift detection, and when should I run it?

A: Drift detection compares the live configuration of resources in a stack against the template. It reports each resource as IN_SYNC, MODIFIED, or DELETED, and shows the exact property diff. Run it on a schedule (via EventBridge + Lambda) for every production stack — console tweaks and emergency fixes create drift that later UpdateStack calls may silently overwrite. Drift cannot currently be auto-corrected, but pairing detection with AWS Config rules gives you alerting and a history of manual changes.

Q: How do StackSets work across AWS Organizations?

A: StackSets deploy a template to multiple target accounts and Regions from a single operation. You choose a service-managed deployment model (trust AWS Organizations and deploy to organizational units automatically, including new accounts) or a self-managed model (explicit execution role per target account). Operations run with a configurable concurrency and failure tolerance. StackSets are the standard pattern for landing-zone guardrails: CloudTrail, Config, GuardDuty, IAM password policies, and default VPC removal all rolled out org-wide.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS CloudFormation documentation before making production decisions.