Automating Deployments with AWS CloudFormation

Deploy the base stack (VPC + Security Group)

• Downloaded task1.yaml and inspected the three sections: two CIDR parameters (VPC and Subnet) under Parameters, eight resources under Resources, and one Security Group ID under Outputs.
• In the CloudFormation console, chose Create stack → With new resources (standard), selected Upload a template file, and uploaded task1.yaml.
• Set the stack name to Lab. Kept the default CIDR values from the template parameters. Acknowledged the IAM capability prompt on the review page (some resources use custom names).
• The stack entered CREATE_IN_PROGRESS. CloudFormation determined the optimal creation order automatically — the VPC before any resource that depends on its ID, the IGW before its VPCGatewayAttachment, and so on.
• After roughly one minute, the status moved to CREATE_COMPLETE with all 8 resources in the green state.

Add an S3 bucket via stack update

• Edited task1.yaml locally and appended the minimum-viable S3 resource under Resources. Two lines total — logical ID and type:

Resources:
  # ... existing VPC / Subnet / SG resources above ...

  S3Bucket:
    Type: AWS::S3::Bucket

• In the console, selected the Lab stack, clicked Update, chose Replace current template, and uploaded the edited file.
• CloudFormation calculated a change set and showed exactly one change: Add a new resource of type AWS::S3::Bucket. Every other resource was marked unchanged, confirming no redeployment of the networking layer.
• Executed the change set. Stack moved UPDATE_IN_PROGRESS → UPDATE_COMPLETE in under a minute. The bucket appeared in the Resources tab with a CloudFormation-generated physical name.

Add an EC2 instance with cross-referenced resources

EC2 is harder than S3 because the instance depends on three other resources in the same template (AMI, Security Group, Subnet). The lab introduces two techniques to solve that cleanly.

3a. SSM-backed AMI parameter (region-agnostic)

Hard-coding an AMI ID would tie the template to a single region. Instead, the AMI is resolved at deploy time from the SSM public parameter store:

Parameters:
  AmazonLinuxAMIID:
    Type: AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>
    Default: /aws/service/ami-amazon-linux-latest/amzn2-ami-hvm-x86_64-gp2

The same template will now resolve to the correct Amazon Linux 2 AMI in any region CloudFormation deploys to. The AMI ID never appears in the template itself.

3b. The EC2 resource (5 properties, three !Refs)

AppServer:
  Type: AWS::EC2::Instance
  Properties:
    ImageId: !Ref AmazonLinuxAMIID
    InstanceType: t3.micro
    SecurityGroupIds:
      - !Ref AppSecurityGroup
    SubnetId: !Ref PublicSubnet
    Tags:
      - Key: Name
        Value: App Server

• SecurityGroupIds is a list — even with a single SG, the YAML uses the hyphen list syntax. This was the most common gotcha flagged in the lab tips.
• The three !Ref calls (AmazonLinuxAMIID, AppSecurityGroup, PublicSubnet) create implicit dependencies. CloudFormation guarantees the referenced resources exist before EC2 launch.
• Uploaded the revised template via Update stack → Replace current template. The change set showed one Add action for the EC2 instance and no replacements on existing resources. Executed and the stack reached UPDATE_COMPLETE.

Delete the stack — automatic teardown

• In the CloudFormation console, selected the Lab stack and clicked Delete. Confirmed in the modal.
• Stack moved to DELETE_IN_PROGRESS. CloudFormation deleted resources in reverse dependency order: EC2 instance and S3 bucket first, then route table association, route, route table, IGW attachment, IGW, subnet, security group, and finally the VPC.
• The deletion timeline in the console showed each of the 8 networking resources decommissioning in sequence between 06:01 and 06:08 UTC-0500. After the timeline finished, the stack disappeared from the active stacks list.

Create the stack (Task 1)

aws cloudformation create-stack \
  --stack-name Lab \
  --template-body file://task1.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-west-2

# Block until the stack reaches CREATE_COMPLETE
aws cloudformation wait stack-create-complete \
  --stack-name Lab --region us-west-2

# Inspect the result
aws cloudformation describe-stacks \
  --stack-name Lab --region us-west-2 \
  --query 'Stacks[0].{Status:StackStatus,Outputs:Outputs}'

Preview an update via change set (Tasks 2 & 3)

# Create a change set against the running stack
aws cloudformation create-change-set \
  --stack-name Lab \
  --change-set-name add-s3-bucket \
  --template-body file://task2.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-west-2

# Inspect what will change before applying
aws cloudformation describe-change-set \
  --stack-name Lab \
  --change-set-name add-s3-bucket \
  --region us-west-2 \
  --query 'Changes[*].ResourceChange.{Action:Action,Logical:LogicalResourceId,Type:ResourceType}'

# Apply the change set
aws cloudformation execute-change-set \
  --stack-name Lab \
  --change-set-name add-s3-bucket \
  --region us-west-2

aws cloudformation wait stack-update-complete \
  --stack-name Lab --region us-west-2

Watch the lifecycle in real time

# Stream the most recent stack events (timestamps + resource status)
aws cloudformation describe-stack-events \
  --stack-name Lab --region us-west-2 \
  --query 'StackEvents[*].{T:Timestamp,Status:ResourceStatus,Logical:LogicalResourceId,Reason:ResourceStatusReason}' \
  --output table

# List resources currently managed by the stack
aws cloudformation list-stack-resources \
  --stack-name Lab --region us-west-2 \
  --output table

Tear down the stack (Task 4)

aws cloudformation delete-stack \
  --stack-name Lab --region us-west-2

aws cloudformation wait stack-delete-complete \
  --stack-name Lab --region us-west-2

# Confirm the stack is gone (DELETE_COMPLETE stacks are filtered out by default)
aws cloudformation list-stacks \
  --region us-west-2 \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE \
  --query 'StackSummaries[?StackName==`Lab`]'