Hands-On Lab: AWS Cloud Adoption & Elasticity Strategies

Welcome to this guided hands-on lab exploring the practical applications of the AWS Cloud Adoption Framework (CAF) and cloud economics. In this lab, we will simulate migrating a workload, optimizing its cost through rightsizing (adjusting compute power to match demand), and leveraging cloud elasticity to scale our application.

Prerequisites

Before starting this lab, ensure you have the following ready:

• An active AWS Account with administrator access or full EC2 IAM permissions.
• The AWS CLI installed and configured with your credentials (aws configure).
• Basic knowledge of cloud computing concepts (Compute, Storage).
• Terminal application (Bash, PowerShell, or AWS CloudShell).

Learning Objectives

By completing this lab, you will be able to:

1. Deploy a compute workload mimicking an initial on-premises migration.
2. Apply cloud economics by rightsizing an EC2 instance to minimize fixed costs.
3. Demonstrate horizontal scalability and agility by creating and deploying an Amazon Machine Image (AMI).
4. Clean up and de-provision resources to adhere to cost-optimization best practices.

Architecture Overview

The following diagram illustrates the lifecycle of our resources in this lab, reflecting the transition from an initial deployment to a cost-optimized, elastic architecture.

The Cloud Transformation Value Chain

As you execute these technical steps, remember how AWS defines the transformation value chain within the Cloud Adoption Framework (CAF):

Step-by-Step Instructions

Step 1: Deploy the Initial "Migrated" Workload

We start by launching an Amazon EC2 instance. This represents an application that has just been lifted-and-shifted to the cloud but hasn't yet been optimized for cloud economics.

📸 Screenshot: Note the InstanceId returned in the JSON output. You will need it for the next steps.

▶Console alternative

1. Navigate to the EC2 Dashboard in the AWS Management Console.
2. Click Launch Instances.
3. Enter the name: brainybee-lab-migration-node.
4. Select Amazon Linux 2023 AMI under Application and OS Images.
5. Select t2.micro under Instance type.
6. Select Proceed without a key pair (for this lab's scope).
7. Click Launch instance.

[!TIP] In a real-world scenario, you would monitor this instance using Amazon CloudWatch to determine if its compute capacity is being fully utilized.

Step 2: Stop the Instance for Rightsizing

One of the core concepts of cloud economics is avoiding over-provisioning. If our application only requires a fraction of a t2.micro, we can rightsize it to a smaller instance type. First, we must stop the instance.

▶Console alternative

1. In the EC2 Dashboard, select your instance brainybee-lab-migration-node.
2. Click the Instance state dropdown.
3. Select Stop instance.
4. Wait until the Instance State changes to stopped.

Step 3: Rightsize the Instance

Now, we modify the instance type to a t2.nano, successfully demonstrating variable cost optimization and "rightsizing."

After modifying, start the instance back up:

▶Console alternative

1. With the stopped instance selected, click Actions > Instance settings > Change instance type.
2. In the dropdown, select t2.nano.
3. Click Apply.
4. Go back to Instance state and click Start instance.

Step 4: Create an Amazon Machine Image (AMI)

To prepare for high availability and agility, we will capture our optimized server configuration as an AMI. This is a foundational step for implementing elasticity (e.g., via Auto Scaling).

📸 Screenshot: Copy the ImageId returned by the command.

▶Console alternative

1. Select your running instance.
2. Click Actions > Image and templates > Create image.
3. Set Image name to brainybee-optimized-ami.
4. Click Create image.
5. Navigate to AMIs on the left menu and wait for the status to become Available.

Step 5: Test Agility by Launching from the AMI

Finally, we launch a brand new instance from our custom AMI. This proves that we can rapidly replicate our infrastructure on demand.

▶Console alternative

1. Navigate to AMIs in the left navigation pane.
2. Select your brainybee-optimized-ami.
3. Click Launch instance from AMI.
4. Name it brainybee-scaled-node.
5. Click Launch instance.

Checkpoints

Run these commands to verify your progress:

1. Verify Instance Types: Check that you have two instances running, both properly rightsized to t2.nano.

   bashCopy

   aws ec2 describe-instances --query "Reservations[*].Instances[*].{ID:InstanceId, Type:InstanceType, State:State.Name}" --output table

   Expected Result: Both instances show t2.nano and state running.

2. Verify AMI Availability:

   bashCopy

   aws ec2 describe-images --owners self --query "Images[*].{ID:ImageId, Name:Name, State:State}" --output table

   Expected Result: Your custom AMI shows a state of available.

Teardown / Clean-Up

[!WARNING] Remember to run the teardown commands to avoid ongoing charges. Failing to delete instances and snapshots will incur monthly storage and compute fees.

Run the following commands to destroy the lab environment:

1. Terminate all lab instances:

   bashCopy

   aws ec2 terminate-instances --instance-ids <INSTANCE_ID_1> <INSTANCE_ID_2>

2. Deregister the custom AMI:

   bashCopy

   aws ec2 deregister-image --image-id <YOUR_AMI_ID>

3. Delete the underlying EBS Snapshot (Crucial to stop storage costs): First, find the Snapshot ID:

   bashCopy

   aws ec2 describe-snapshots --owner-ids self --query "Snapshots[*].SnapshotId"

   Then, delete it:

   bashCopy

   aws ec2 delete-snapshot --snapshot-id <YOUR_SNAPSHOT_ID>

Troubleshooting

Concept Review

This lab practically applied core AWS Cloud Adoption Framework and Economics principles: