4.1.3. CloudFormation: Templates, Stacks, and StackSets

💡 First Principle: CloudFormation treats infrastructure as a state machine. You declare the desired end state in a template, and CloudFormation figures out how to get there — creating, updating, or deleting resources in the right order, handling dependencies automatically. This is fundamentally different from scripting (where you tell it how to do it) — CloudFormation lets you describe what you want.

Without CloudFormation, provisioning a three-tier application means: create VPC, create subnets, create security groups, create RDS, create EC2, configure ELB — in the right order, with the right parameters. Make a mistake and you have to manually undo it. With CloudFormation, you declare all of that in one template, and CloudFormation handles creation, ordering, rollback on failure, and deletion.

Template Anatomy:

Stack Operations:

Change Sets: Before executing an update, create a change set to preview exactly which resources will be added, modified, or deleted. This prevents surprise deletions — particularly critical for databases and stateful resources.

DeletionPolicy: Controls what happens to a resource when its stack is deleted or the resource is removed from the template:

CloudFormation Helper Scripts run inside EC2 instances to integrate instance initialization with stack creation:

CreationPolicy and WaitCondition: These tell CloudFormation to wait for a signal before marking a resource as successfully created. Without them, CloudFormation marks an EC2 instance as created the moment the API call succeeds — before the instance has actually finished its initialization script.

Resources:
  WebServer:
    Type: AWS::EC2::Instance
    CreationPolicy:
      ResourceSignal:
        Timeout: PT15M  # Wait up to 15 minutes for signal
        Count: 1
    Metadata:
      AWS::CloudFormation::Init:
        config:
          packages:
            yum:
              httpd: []
          commands:
            start_apache:
              command: "systemctl start httpd"

Drift Detection: Identifies configuration changes made outside CloudFormation (console changes, CLI changes, AWS Config remediations). Running drift detection shows you which resources have drifted and what changed. It does not automatically remediate drift — you must decide whether to update the template or revert the resource.

Nested Stacks and Cross-Stack References:

StackSets are critical for multi-account deployments. From the management account (or a delegated admin account), you define a StackSet and target it at OUs or account lists. CloudFormation deploys the stack in every targeted account and region automatically.

⚠️ Exam Trap: CloudFormation cannot update a resource that requires replacement (e.g., changing an RDS instance's DB engine) without deleting and recreating it. Changing certain properties triggers replacement, which means downtime for stateful resources. Always check the "Update requires" field in the CloudFormation documentation before updating production stacks, and use DeletionPolicy: Snapshot to protect data.

Reflection Question: A CloudFormation stack creates an EC2 instance. The stack creation completes successfully in the console, but the application on the instance isn't working because the bootstrap script failed silently. What CloudFormation mechanism should have been used to catch this, and how does it work?