Skip to main content
This lesson explains how to provision an Amazon EC2 instance using AWS CloudFormation and describes how the pieces fit together. You’ll see the end-to-end flow, the key EC2 properties you typically declare in a template, a minimal example template, and notes on stack lifecycle, updates, and best practices. High-level flow
  • Author an AWS CloudFormation template that declares an AWS::EC2::Instance resource and any supporting resources (Security Groups, EBS Volumes, IAM Roles/InstanceProfiles, etc.).
  • Deploy the template to AWS CloudFormation by creating a stack.
  • CloudFormation provisions the declared resources and launches the EC2 instance as part of the stack.
  • Update or delete the stack to change or remove the instance and its related resources; CloudFormation manages dependencies and lifecycle transitions.
CloudFormation resources are declared in the template using resource types and properties. For EC2 instances, the most common properties you will set include the instance type, AMI, key pair, security groups, volumes, user data, tags, and IAM instance profile. Common EC2 properties in CloudFormation
PropertyPurposeExample / Notes
InstanceTypeVM size (CPU/Memory)t3.micro
ImageIdAMI ID (region-specific)ami-0abcdef1234567890
KeyNameEC2 key pair for SSH accessmy-keypair
SecurityGroupIds / SecurityGroupsNetwork access controls. Use SecurityGroupIds with VPCs.!Ref InstanceSecurityGroup
BlockDeviceMappingsRoot or additional EBS volumesConfigure size, volume type, delete-on-termination
UserDataBootstrapping scripts (base64-encoded)Use !Base64 or Fn::Base64
TagsMetadata for identificationKey/Value tags for cost center, env, etc.
IamInstanceProfileIAM role attached to the instanceAttach for instance permissions
Minimal EC2 resource example (YAML) Place resources under the Resources section of your CloudFormation template. Use !Base64 (Fn::Base64) for UserData so CloudFormation encodes it correctly: 
Resources:
  MyInstance:
    Type: AWS::EC2::Instance
    Properties:
      InstanceType: t3.micro
      ImageId: ami-0abcdef1234567890
      KeyName: my-keypair
      SecurityGroupIds:
        - !Ref InstanceSecurityGroup
      UserData: !Base64 |
        #!/bin/bash
        yum update -y
        yum install -y httpd
        systemctl enable httpd
        systemctl start httpd
CloudFormation stack lifecycle (create/update/delete) When you create a stack from the template:
  1. CloudFormation validates the template format and parameters.
  2. It creates the stack and provisions resources in dependency order.
  3. CloudFormation reports status updates (for example, CREATE_IN_PROGRESS, CREATE_COMPLETE, CREATE_FAILED).
  4. If creation fails, CloudFormation typically rolls back the stack to the previous stable state (or deletes it if it was the initial create), unless rollbacks were disabled.
Common stack status values
StatusMeaning
CREATE_IN_PROGRESSStack creation is underway
CREATE_COMPLETEStack created successfully
CREATE_FAILEDCreation failed (may trigger rollback)
UPDATE_IN_PROGRESSAn update is being applied
UPDATE_COMPLETEUpdate finished successfully
ROLLBACK_IN_PROGRESSCloudFormation is undoing changes after a failure
Updating stacks and instance replacement behavior
  • You can update a stack by submitting a modified template and/or changing parameters.
  • CloudFormation attempts to update resources in place when possible, but some property changes force replacement (delete + create).
  • For EC2 instances, many changes—such as altering ImageId, certain network properties, or instance type in some contexts—may trigger instance replacement.
  • Plan for replacement: persist important data externally (EBS snapshots, separate EBS volumes mounted with DeleteOnTermination=false, or S3) and prepare for downtime or use Auto Scaling Groups for more controlled rolling replacement.
Choose the AMI (ImageId) that matches your region and instance architecture. AMI IDs are region-specific; avoid hard-coding an AMI from another region unless you implement mapping logic (for example, Parameterized mappings or SSM ParameterStore lookups).
Some EC2 property changes in CloudFormation will replace the instance. Plan for downtime and persist critical data outside the instance (EBS snapshots, separate EBS volumes, or Amazon S3) to avoid data loss.
Practical tips and best practices
  • Use Fn::Base64 / !Base64 for UserData to ensure proper encoding.
  • Use CloudFormation metadata plus cfn-init and cfn-signal for structured bootstrapping and to support CreationPolicy/WaitCondition semantics.
  • Provide CloudFormation with sufficient IAM permissions. Use a CloudFormation service role for cross-account or fine-grained provisioning control, or run operations with a user/role that has the necessary permissions.
  • Separate mutable artifacts (application code, configuration) from the AMI/instance lifecycle. Consider baking AMIs with Packer or use Auto Scaling Groups and configuration management tools for immutability.
  • Use CloudFormation mappings or SSM Parameter Store to resolve region-specific AMIs rather than hard-coding AMI IDs.
  • For production, tag resources consistently for cost tracking and operational clarity.
Links and references Summary Define an AWS::EC2::Instance in your CloudFormation template alongside its Security Groups, IAM InstanceProfile, volumes, and UserData. Deploy the template to create a stack; CloudFormation will manage resource creation, updates, replacements, and deletion according to the template and stack operations. Follow best practices for AMI management, bootstrapping, permissions, and data persistence to avoid surprises during updates.

Watch Video