AWS CloudFormation

AWS’s own infrastructure-as-code service: describe resources in a JSON or YAML template and CloudFormation creates them as one stack, in order, and rolls back on failure.

What it is: Infrastructure as code
Type: Managed service on AWS
Made by: Amazon Web Services
License: Proprietary
Facts checked: 23 October 2026

What it is

A template is a JSON or YAML file that lists resources such as buckets, queues, roles and databases, with their properties, plus optional parameters and outputs. You hand it to CloudFormation and it creates a stack: it works out the dependencies, calls the AWS APIs in the right order, and treats every resource in the stack as one unit that can be updated or deleted together. The state lives inside the service, so there is no state file to store or lock. To update, you create a change set: CloudFormation compares the new template with the stack and lists what it would add, modify or replace before anything happens. If a create or update fails, it rolls the stack back to the last working version.

Around that core sit features for larger estates. StackSets deploy one template to many accounts and regions. Drift detection compares a stack’s resources with the template and reports changes made outside it; drift-aware change sets (November 2025) can also put those resources back. Hooks run your own checks on resources before they are provisioned and can block non-compliant ones. The IaC generator scans an account and writes a template for resources created by hand, and stack refactoring moves resources between stacks without recreating them. The registry adds resource types beyond AWS’s own, from third parties or your own code.

CloudFormation is also the engine underneath other AWS tools: the AWS CDK synthesizes templates for it, and AWS SAM is a CloudFormation transform. It costs nothing for AWS::* resources; third-party and private resource types are billed per handler operation. In June 2026 AWS added an express mode that finishes a stack operation as soon as the configuration is applied, without waiting for resources to stabilize, and turns rollback off by default; AWS says it makes deployments up to four times faster in development.

Why teams pick it

Fully managed and free for AWS resources: no state file, no backend to run, and access controlled with IAM
Change sets show what will be added, modified or replaced before an update, and failed deployments roll back automatically
StackSets roll the same template out across many accounts and regions, which suits AWS Organizations setups
It is the deployment target of the AWS CDK and SAM, so the same stacks can be written as raw templates, shorthand or code

Watch out for

AWS only: other clouds and SaaS APIs need third-party registry types, custom resources or another tool
Quotas shape your design: 500 resources per template, 200 parameters and outputs, and templates over 51,200 bytes must go through S3
Rollbacks can themselves fail and leave a stack in UPDATE_ROLLBACK_FAILED, for example when a resource was deleted outside CloudFormation
Raw templates are verbose and have little abstraction; most teams write them through CDK, SAM or another generator

The AWS CloudFormation family

1 technologies built from or on AWS CloudFormation

Built on it

AWS Serverless Application Model (SAM)AWSA shorthand for serverless apps on top of CloudFormation, plus a CLI that builds them, runs functions and APIs locally in Docker, and deploys them.

Alternatives

What all infrastructure as code have in common →Compare side by side →

TerraformCommercialThe most widely used infrastructure-as-code tool: declare resources in HCL, review a plan, and apply it through provider plugins.

OpenTofuOpen sourceThe open-source fork of Terraform, created after HashiCorp’s 2023 licence change: same HCL, same providers, tofu instead of terraform.

How it fits with other technologies

What AWS CloudFormation uses

What uses AWS CloudFormation

Spaceliftdeploys templates throughAWS CloudFormationInfrastructure as code

A template with a queue, a bucket and an output · yaml

AWSTemplateFormatVersion: "2010-09-09"
Parameters:
  Stage:
    Type: String
    AllowedValues: [dev, prod]
Resources:
  ReceiptsQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 60
  MediaBucket:
    Type: AWS::S3::Bucket
    Properties:
      BucketName: !Sub "example-media-${Stage}"
Outputs:
  QueueUrl:
    Value: !Ref ReceiptsQueue

# aws cloudformation deploy --template-file app.yaml \
#   --stack-name media-prod --parameter-overrides Stage=prod

See it in a real stack

No architecture uses AWS CloudFormation yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2011–2026

Before 2011, setting up an application on AWS meant creating instances, load balancers, databases and security groups one by one, in the right order, and repeating that for every copy of the environment. AWS CloudFormation launched on February 25, 2011 to do it from a recipe: a JSON template that declares every resource, which CloudFormation turns into a stack and builds with the dependencies worked out for you. The next day Mitchell Hashimoto wrote that the world needed the same idea for every cloud, which became Terraform.

For its first years CloudFormation grew mainly by adding resource types. Then it changed how people work with stacks: change sets in March 2016 to preview an update, YAML templates and cross-stack references in September 2016, StackSets for many accounts and regions in July 2017, and drift detection in November 2018. Higher-level tools were built on it rather than beside it: AWS SAM in 2016 as a template transform, and the AWS CDK, generally available in 2019, which generates templates from code.

Its speed and hard-to-debug failures drew criticism: SST, which had been built on CDK and CloudFormation, moved off both in 2024. AWS’s recent releases target those problems: an IDE language server and drift-aware change sets in November 2025, cross-account stack output references in May 2026, and express mode in June 2026, which skips the wait for resources to stabilize.

Why it’s built this way

A declarative template instead of a script of API calls: Listing the desired resources and letting the service work out the order meant the same file could create identical copies of an environment, be versioned, and be reviewed.
The stack as the unit of management: Grouping resources into a stack let CloudFormation create, update and delete them together and roll the whole group back when one step fails.
Keep state inside the service: Because AWS records what each stack contains, users never handle a state file, at the cost of being tied to AWS and to CloudFormation’s own pace.
Extend through transforms and generators, not a new language: SAM’s transform and the CDK’s synthesized templates let AWS offer shorter syntax and real programming languages while reusing one deployment engine.

Timeline

2011
CloudFormation launches on February 25 with JSON templates
2016
Change sets in March; YAML and cross-stack references in September; SAM in November
2017
StackSets deploy one template across accounts and regions
2018
Drift detection finds changes made outside a stack
2025
Drift-aware change sets can revert out-of-band changes
2026
Cross-account Fn::GetStackOutput in May; express mode in June

Sources16 · facts checked 23 October 2026

Improve this page on GitHub