Skip to main content
In this lesson, you’ll learn how AWS CloudFormation lets you define, deploy, and manage AWS infrastructure as code (IaC) so deployments are repeatable, reviewable, and automatable. Traditionally, teams provisioned infrastructure using ad-hoc scripts and manual procedures, often recorded in runbooks or scattered across a version control system. That approach frequently produced inconsistencies: manual steps go out of sync, are hard to review, and are not reliably repeatable.
A slide titled "Traditional Approach" showing a DevOps engineer and automated scripts with arrows pointing to a boxed "AWS Resources" area. Inside the AWS box are icons representing storage, compute, security, and database services.
Infrastructure as code (IaC) replaces manual provisioning with declarative templates or scripts. Instead of clicking through the console, engineers express the desired resources and configuration in a human- and machine-readable file, store it in version control, and use automation to apply it. Think of templates as blueprints and automation as the construction crew that builds the infrastructure from those blueprints.
A slide titled "Infrastructure as Code" showing two horizontal rows where role/tool icons on the left (e.g., operator/tools and developer/doc) point via arrows to infrastructure icons on the right (a building and a server).
What CloudFormation does and how it works:
  • Write a template that declares the AWS resources you need (for example, EC2 instances, RDS databases, VPCs, subnets).
  • Submit that template to AWS CloudFormation.
  • CloudFormation provisions and configures the resources automatically, tracking them as a single unit called a stack.
CloudFormation templates can be authored in JSON or YAML and saved with .json, .yaml, or .yml extensions. Templates group resources into a stack; you manage all the resources through stack operations (create, update, delete). When you update a template and submit it again, CloudFormation creates a change set showing what will be added, modified, or removed—so you can review changes before they are applied.
Tip: Use aws cloudformation validate-template and linters (like cfn-lint) to catch syntax errors and common issues before submitting templates to CloudFormation.
Example: a minimal YAML template that creates an S3 bucket
When you submit a template, CloudFormation builds or updates the stack and produces a change set that summarizes the impact before applying changes.
A simple AWS CloudFormation flow diagram showing a developer editing a template, submitting it to AWS CloudFormation, and producing/updating a change set and stack. Icons and labels read "Template", "AWS CloudFormation", and "Change set" with arrows indicating the process.
Change sets are a crucial safety feature: always review a change set before executing it. Unreviewed changes may delete or modify resources that other systems depend on.
Key features and benefits of CloudFormation:
  • Infrastructure as Code (IaC): Templates express your infrastructure as code that can be reviewed and version-controlled.
  • Consistent and Repeatable Deployments: The same template produces the same architecture across environments.
  • Resource Tracking: CloudFormation knows which resources belong to a stack and manages their lifecycle.
  • Version Control and Auditing: Store templates in Git-like systems for history, code review, and rollback.
  • Time and Cost Efficiency: Automation reduces manual work and human error, accelerating provisioning.
You can also view the features in a quick reference table:
A slide titled "Features" with five numbered cards showing icons and labels for: Infrastructure as Code (IaC), Consistent and Repeatable Deployments, Version Control, Resource Tracking, and Cost and Time Efficiency. Each card has a colorful circular icon above the text.
Because templates are code, you can integrate CloudFormation into the same developer workflows and CI/CD pipelines used for application code. Store templates in a repository (for example, AWS CodeCommit or GitHub), validate them during CI, and use pipelines to automatically create or update stacks. This enables repeatable, auditable infrastructure changes that follow the same review and release practices as application development. Links and references

Watch Video