Skip to main content
Welcome. This guide provides a clear, practical overview of AWS CloudFormation — the native Infrastructure as Code (IaC) service that lets you define, deploy, and manage AWS infrastructure using versionable templates. Use this as a concise reference for templates, stacks, change sets, drift detection, rollback behavior, and CI/CD integration. At a high level:
  • Author a CloudFormation template (YAML or JSON) that describes the architecture you want.
  • Deploy that template to create a stack — the running collection of AWS resources.
  • Manage updates and detect configuration drift using change sets and drift detection.
Key benefits compared to manual click-ops:
  • Repeatability: deploy the same template across environments by changing stack names or parameters.
  • Version control & auditability: store templates in Git and integrate with CI/CD.
  • Speed & consistency: automated provisioning reduces human error and improves deployment velocity.
Core concepts
  • Template: the declarative source file you version and store that describes your infrastructure.
  • Stack: the deployed instance of a template — a single manageable unit of resources.
  • Change set: a preview of differences between a proposed template and the current stack.
  • StackSets: deploy a single stack across multiple AWS accounts and/or regions.
A slide titled "AWS CloudFormation Core Components" showing four illustrated tiles labeled Template, Stack, Change Set, and Stack Sets. Each tile contains a simple colorful icon representing that component.
StackSets work like a menu selection: choose the stack (template) and target accounts/regions (for example, Mumbai, Europe, South Africa, South America, US) to deploy the same architecture consistently across AWS organization boundaries. Template anatomy CloudFormation templates are most commonly written in YAML (JSON is supported). Templates describe resources and include auxiliary sections that help parameterize and customize deployments. For exam focus: Parameters, Resources, and Outputs are the most important sections to understand. AWSTemplateFormatVersion is often present but optional; Description, Conditions, and Mappings are secondary; Metadata and Transform are specialized.
A diagram titled "CloudFormation Templates Section" showing a YAML template icon linked to a boxed layout. The box contains blue rounded rectangles listing template sections like AWSTemplateFormatVersion, Description, Parameters, Resources, Outputs, Conditions, Mappings, Metadata, and Transform.
Minimal template example This compact YAML example highlights four common sections: AWSTemplateFormatVersion, Description, Resources, and Outputs.
AMI IDs are region-specific and change frequently. The ImageId in examples is illustrative — always use a region-appropriate AMI or a mapping that selects the correct AMI per region.
Notes:
  • Many templates include only a subset of sections. The Resources section is usually essential.
  • Consider using Parameters and Mappings instead of hard-coding values such as AMI IDs.
Stacks and the CloudFormation console A stack is the runtime result of deploying a template. The CloudFormation console exposes views that help you operate and troubleshoot stacks:
  • Events: chronological events for stack operations.
  • Resources: list of created resources and their statuses.
  • Outputs: exported values for other stacks or operators.
  • Parameters: values supplied at stack creation time.
  • Template: the template associated with the stack.
  • Change sets: proposed updates awaiting execution.
The image shows an AWS CloudFormation Stack console screenshot with the Resources tab open. It lists a SimpleEC2Instance (AWS::EC2::Instance) resource with status CREATE_COMPLETE and a stack icon on the left.
Stack timeline and diagnostics CloudFormation provides a timeline showing resource-level events and status transitions (for example, CREATE_IN_PROGRESS → CREATE_COMPLETE). Use the timeline and event details to pinpoint failures and investigate resource diagnostics.
A screenshot of a CloudFormation Stack Timeline showing the latest deployment for a resource named "SimpleEC2Instance." A horizontal timeline bar uses blue, amber, and green segments (In progress, Consistency check, Complete) with timestamps along the top.
Change sets and drift detection Change sets let you preview what will change before applying updates. This is useful when you intend to modify resources (for example, changing an instance type from t2.micro to t3.micro) and want to review the impact first. Use cases:
  • Planned updates: create a change set to review and validate changes before execution.
  • Drift detection: detect configuration or property changes made outside of CloudFormation and generate a plan to reconcile drift.
The image is a diagram titled "CloudFormation Change Set" showing a change set icon and text that it identifies changes between current and proposed infrastructure. It illustrates an Old Amazon EC2 instance (t2.micro) being changed to a New Amazon EC2 instance (t3.micro).
Rollback behavior and deletion policies CloudFormation failure behavior is configurable:
  • Default behavior: CloudFormation rolls back to the previous stable state on failure.
  • Disable rollback: useful during debugging to preserve partially created resources for inspection.
  • Update rollback behavior: control whether newly created resources are deleted if an update fails.
  • DeletionPolicy attribute: controls resource disposal on stack deletion — options include Retain, Snapshot, and Delete.
A screenshot of an AWS CloudFormation "Execute change set?" dialog showing radio-button options for rollback behavior and whether to delete newly created resources during a rollback. The slide is titled "CloudFormation Change Set" and shows "Cancel" and "Execute change set" buttons.
How CloudFormation works — quick flow
  1. Write a CloudFormation template (YAML/JSON).
  2. Deploy the template as a stack.
  3. Modify/update the stack using template changes or change sets.
  4. Monitor stack events, detect drift, and reconcile differences.
A slide titled "How AWS CloudFormation Works" showing a four-step horizontal flow. The steps are: 01 Write the CloudFormation template, 02 Deploy the template as a stack, 03 Modify and update the stack, and 04 Monitor and detect drift.
CloudFormation in CI/CD CloudFormation integrates into CI/CD pipelines to enable automated, repeatable deployments. Use any Git provider (GitHub, GitLab, Bitbucket, or AWS CodeCommit) as the source for templates and connect to build/deploy stages (for example, CodeBuild and CodePipeline). A typical workflow:
  • Author templates in Git and open pull requests for changes.
  • CI validates templates (linting, unit tests, policy checks).
  • CD executes change sets and applies stack updates in controlled environments.
For example, integrate with AWS CodePipeline and CodeBuild to automatically validate and deploy templates whenever changes are merged.
A diagram titled "Applying CloudFormation in CI/CD" showing a developer committing code to AWS CodeCommit, then passing through AWS CodeBuild and finally deploying with AWS CloudFormation inside an AWS CodePipeline.
Best practices
Store templates in source control, parameterize templates, enable rollback on failure, and modularize where practical (e.g., separate IAM, networking, and shared services). Automate deployments using CI/CD and avoid ad hoc manual edits to deployed resources—update the template and apply a change set instead.
Additional practical advice:
  • Avoid hard-coding values unless immutable. Use Parameters and Mappings for flexibility.
  • Enable rollback on failure to avoid inconsistent partial provisioning.
  • Modularize large templates with nested stacks to reduce complexity.
  • Store templates in Git and connect to pipelines to enable automated deployment and audit trails.
  • Prefer template-driven updates and change sets; manual resource edits create drift and complicate management.
Native AWS workflows recommend CloudFormation and the AWS CDK (which synthesizes CloudFormation templates). Third-party tools such as Terraform, Pulumi, or Crossplane are popular alternatives, but AWS-native exam questions typically focus on CloudFormation/CDK concepts and operations. References
A presentation slide titled "AWS CloudFormation – Best Practices." It lists recommendations like avoid hardcoding values, enable rollback on failure, use modular/nested templates, store templates in GitHub, automate deployments with CodePipeline + CloudFormation, and avoid manual configuration drift.
Recap
  • CloudFormation is AWS’s native IaC tool for defining and managing infrastructure declaratively.
  • Focus on clean templates (Parameters, Resources, Outputs), use change sets to preview updates, and enable drift detection to maintain consistency.
  • Integrate templates with CI/CD pipelines to validate and automate deployments across environments.
For hands-on learning, try authoring templates that:
  • Parameterize instance types and AMIs via Mappings.
  • Use nested stacks to separate networking and application layers.
  • Implement change set workflows in a CodePipeline to preview and apply updates.

Watch Video