Lab: Implementing a High-Performance Auto-Scaling Architecture on AWS

\nThis lab guides you through identifying performance bottlenecks and implementing a remediation strategy using Amazon EC2 Auto Scaling and Application Load Balancers (ALB). You will move from a single-node architecture to a high-performing, elastic system.

Prerequisites

AWS Account: Access to an AWS account with AdministratorAccess or equivalent permissions.
AWS CLI: Installed and configured with aws configure.
VPC Knowledge: Familiarity with Public and Private subnets.
IAM Permissions: Ability to create IAM Roles, EC2 instances, and Auto Scaling groups.

Learning Objectives

Identify performance bottlenecks using Amazon CloudWatch metrics.
Configure an Application Load Balancer to distribute traffic.
Implement an Auto Scaling Group (ASG) with dynamic scaling policies.
Apply Rightsizing principles by selecting optimal instance types.

Architecture Overview

\nThe following diagram illustrates the target high-performance architecture. We use a multi-AZ deployment to ensure reliability while optimizing performance through horizontal scaling.

Loading Diagram...

[!NOTE] In a production environment, you would likely add Amazon CloudFront at the edge to further reduce latency for global users, as suggested in the SAP-C02 performance strategy.

Step-by-Step Instructions

Step 1: Create a Launch Template

\nA Launch Template defines the 'Gold Image' for your performance-optimized instances.

bash

    --launch-template-name "PerformanceLabTemplate" \\
    --version-description "v1" \\
    --launch-template-data '{"ImageId":"ami-0abcdef1234567890","InstanceType":"t3.micro","KeyName":"<YOUR_KEY_PAIR>"}'

▶Console alternative

Navigate to EC2 Dashboard > Launch Templates.
Click Create launch template.
Name it PerformanceLabTemplate.
Select Amazon Linux 2023 AMI.
Choose t3.micro (Rightsizing tip: use T3 for burstable workloads or M5 for sustained performance).
Click Create launch template.

Step 2: Provision an Application Load Balancer

\nThe ALB acts as the entry point and prevents a single instance from becoming a performance bottleneck.

bash

# Create a Target Group\naws elbv2 create-target-group \\
    --name "Performance-TG" \\
    --protocol HTTP \\
    --port 80 \\
    --vpc-id <YOUR_VPC_ID>

# Create the Load Balancer\naws elbv2 create-load-balancer \\
    --name "Performance-ALB" \\
    --subnets <SUBNET_ID_1> <SUBNET_ID_2> \\
    --security-groups <SG_ID>

▶Console alternative

Navigate to EC2 > Load Balancers > Create Load Balancer.
Select Application Load Balancer.
Name it Performance-ALB and select at least two Availability Zones.
Create a new Target Group named Performance-TG targeting 'Instances'.

Step 3: Configure the Auto Scaling Group

\nThis step enables 'Horizontal Scaling', a core principle for high-performing architectures.

bash

    --auto-scaling-group-name "Performance-ASG" \\
    --launch-template "LaunchTemplateName=PerformanceLabTemplate,Version='$Default'" \\
    --min-size 1 --max-size 4 --desired-capacity 2 \\
    --target-group-arns <TARGET_GROUP_ARN> \\
    --vpc-zone-identifier "<SUBNET_ID_1>,<SUBNET_ID_2>"

Step 4: Define a Dynamic Scaling Policy

\nWe will use a Target Tracking policy to keep average CPU utilization at 50%.

bash

    --auto-scaling-group-name "Performance-ASG" \\
    --policy-name "KeepCPUAt50" \\
    --policy-type TargetTrackingScaling \\
    --target-tracking-configuration '{"TargetValue": 50.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Checkpoints

Verify ALB Access: Copy the DNS Name of your ALB into a browser. You should see the default web server page.
Check ASG Capacity: In the CLI, run aws autoscaling describe-auto-scaling-groups. You should see 2 instances in InService state.
CloudWatch Alarm: Navigate to the CloudWatch console; verify that an alarm was automatically created by the Target Tracking policy.

Performance Visualization

\nUnderstanding the relationship between load and latency is key to determining a strategy. When load exceeds the saturation point, latency spikes exponentially.

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 1 — TikZ diagram

Troubleshooting

Issue	Possible Cause	Fix
ALB Health Check Failing	Security Group mismatch	Ensure Instance SG allows traffic from ALB SG on port 80.
ASG not scaling out	Permissions/Limits	Check IAM role for `autoscaling:ExecuteScalingPolicy` and account quotas.
High Latency	Rightsizing issue	If CPU is low but latency is high, check for Memory/IOPS bottlenecks.

Clean-Up / Teardown

[!WARNING] Always delete resources in order to avoid orphaned costs.

Delete ASG: aws autoscaling delete-auto-scaling-group --auto-scaling-group-name "Performance-ASG" --force-delete
Delete ALB: aws elbv2 delete-load-balancer --load-balancer-arn <ALB_ARN>
Delete Target Group: aws elbv2 delete-target-group --target-group-arn <TG_ARN>
Delete Launch Template: aws ec2 delete-launch-template --launch-template-name "PerformanceLabTemplate"

Challenge

Scenario: Your application is now CPU-optimized, but users report slow database queries. Goal: Identify a strategy to move from an EC2-hosted MySQL database to a managed high-performance service.

▶Hint

\nConsider Amazon Aurora with Read Replicas to offload read traffic, improving overall application throughput.

Cost Estimate

EC2 t3.micro: $0.0104/hour (Free Tier eligible).
ALB: ~$0.0225/hour + LCU charges.
CloudWatch: Standard metrics are free; alarms are ~$0.10/month.
Estimated 30-min Lab Cost: < $0.10 (well within Free Tier if applicable).

Concept Review

Strategy	Description	Performance Benefit
Horizontal Scaling	Adding more instances (ASG).	Increases total throughput (Requests/sec).
Vertical Scaling	Upgrading instance size (Rightsizing).	Reduces latency for single-threaded tasks.
Edge Computing	Using CloudFront/Global Accelerator.	Reduces network latency via AWS Global Backbone.
Managed Services	Using RDS/Aurora instead of self-managed.	Offloads performance tuning and maintenance to AWS.
"word_count": 950,
"suggested_title": "AWS Performance Strategy Lab (SAP-C02)"
}

Lab: Implementing a High-Performance Auto-Scaling Architecture on AWS

Prerequisites

AWS Account: Access to an AWS account with AdministratorAccess or equivalent permissions.
AWS CLI: Installed and configured with aws configure.
VPC Knowledge: Familiarity with Public and Private subnets.
IAM Permissions: Ability to create IAM Roles, EC2 instances, and Auto Scaling groups.

Learning Objectives

Identify performance bottlenecks using Amazon CloudWatch metrics.
Configure an Application Load Balancer to distribute traffic.
Implement an Auto Scaling Group (ASG) with dynamic scaling policies.
Apply Rightsizing principles by selecting optimal instance types.

Architecture Overview

\nThe following diagram illustrates the target high-performance architecture. We use a multi-AZ deployment to ensure reliability while optimizing performance through horizontal scaling.

Loading Diagram...

[!NOTE] In a production environment, you would likely add Amazon CloudFront at the edge to further reduce latency for global users, as suggested in the SAP-C02 performance strategy.

Step-by-Step Instructions

Step 1: Create a Launch Template

\nA Launch Template defines the 'Gold Image' for your performance-optimized instances.

bash

    --launch-template-name "PerformanceLabTemplate" \\
    --version-description "v1" \\
    --launch-template-data '{"ImageId":"ami-0abcdef1234567890","InstanceType":"t3.micro","KeyName":"<YOUR_KEY_PAIR>"}'

▶Console alternative

Navigate to EC2 Dashboard > Launch Templates.
Click Create launch template.
Name it PerformanceLabTemplate.
Select Amazon Linux 2023 AMI.
Choose t3.micro (Rightsizing tip: use T3 for burstable workloads or M5 for sustained performance).
Click Create launch template.

Step 2: Provision an Application Load Balancer

\nThe ALB acts as the entry point and prevents a single instance from becoming a performance bottleneck.

bash

# Create a Target Group\naws elbv2 create-target-group \\
    --name "Performance-TG" \\
    --protocol HTTP \\
    --port 80 \\
    --vpc-id <YOUR_VPC_ID>

# Create the Load Balancer\naws elbv2 create-load-balancer \\
    --name "Performance-ALB" \\
    --subnets <SUBNET_ID_1> <SUBNET_ID_2> \\
    --security-groups <SG_ID>

▶Console alternative

Navigate to EC2 > Load Balancers > Create Load Balancer.
Select Application Load Balancer.
Name it Performance-ALB and select at least two Availability Zones.
Create a new Target Group named Performance-TG targeting 'Instances'.

Step 3: Configure the Auto Scaling Group

\nThis step enables 'Horizontal Scaling', a core principle for high-performing architectures.

bash

    --auto-scaling-group-name "Performance-ASG" \\
    --launch-template "LaunchTemplateName=PerformanceLabTemplate,Version='$Default'" \\
    --min-size 1 --max-size 4 --desired-capacity 2 \\
    --target-group-arns <TARGET_GROUP_ARN> \\
    --vpc-zone-identifier "<SUBNET_ID_1>,<SUBNET_ID_2>"

Step 4: Define a Dynamic Scaling Policy

\nWe will use a Target Tracking policy to keep average CPU utilization at 50%.

bash

    --auto-scaling-group-name "Performance-ASG" \\
    --policy-name "KeepCPUAt50" \\
    --policy-type TargetTrackingScaling \\
    --target-tracking-configuration '{"TargetValue": 50.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"}}'

Checkpoints

Verify ALB Access: Copy the DNS Name of your ALB into a browser. You should see the default web server page.
Check ASG Capacity: In the CLI, run aws autoscaling describe-auto-scaling-groups. You should see 2 instances in InService state.
CloudWatch Alarm: Navigate to the CloudWatch console; verify that an alarm was automatically created by the Target Tracking policy.

Performance Visualization

\nUnderstanding the relationship between load and latency is key to determining a strategy. When load exceeds the saturation point, latency spikes exponentially.

Compiling TikZ diagram…

⏳

Running TeX engine…

This may take a few seconds

Figure 1 — TikZ diagram

Troubleshooting

Issue	Possible Cause	Fix
ALB Health Check Failing	Security Group mismatch	Ensure Instance SG allows traffic from ALB SG on port 80.
ASG not scaling out	Permissions/Limits	Check IAM role for `autoscaling:ExecuteScalingPolicy` and account quotas.
High Latency	Rightsizing issue	If CPU is low but latency is high, check for Memory/IOPS bottlenecks.

Clean-Up / Teardown

[!WARNING] Always delete resources in order to avoid orphaned costs.

Delete ASG: aws autoscaling delete-auto-scaling-group --auto-scaling-group-name "Performance-ASG" --force-delete
Delete ALB: aws elbv2 delete-load-balancer --load-balancer-arn <ALB_ARN>
Delete Target Group: aws elbv2 delete-target-group --target-group-arn <TG_ARN>
Delete Launch Template: aws ec2 delete-launch-template --launch-template-name "PerformanceLabTemplate"

Challenge

▶Hint

\nConsider Amazon Aurora with Read Replicas to offload read traffic, improving overall application throughput.

Cost Estimate

EC2 t3.micro: $0.0104/hour (Free Tier eligible).
ALB: ~$0.0225/hour + LCU charges.
CloudWatch: Standard metrics are free; alarms are ~$0.10/month.
Estimated 30-min Lab Cost: < $0.10 (well within Free Tier if applicable).

Concept Review

Strategy	Description	Performance Benefit
Horizontal Scaling	Adding more instances (ASG).	Increases total throughput (Requests/sec).
Vertical Scaling	Upgrading instance size (Rightsizing).	Reduces latency for single-threaded tasks.
Edge Computing	Using CloudFront/Global Accelerator.	Reduces network latency via AWS Global Backbone.
Managed Services	Using RDS/Aurora instead of self-managed.	Offloads performance tuning and maintenance to AWS.
"word_count": 950,
"suggested_title": "AWS Performance Strategy Lab (SAP-C02)"
}