Lab 1: EC2 Auto Scaling Group Setup
🎯 Lab Objectives
- Tạo Launch Template cho EC2 instances
- Thiết lập Auto Scaling Group với multiple AZs
- Configure scaling policies và health checks
- Test auto scaling behavior
📋 Prerequisites
- AWS Account với appropriate permissions
- Basic understanding của EC2 và VPC
- AWS CLI configured (optional)
🏗️ Architecture Overview
Internet Gateway
↓
Application Load Balancer (Public Subnets)
↓
Auto Scaling Group (Private Subnets)
├── EC2 Instance (AZ-1a)
├── EC2 Instance (AZ-1b)
└── EC2 Instance (AZ-1c)
📝 Step-by-Step Implementation
Step 1: Create VPC và Subnets (if needed)
# Create VPC
aws ec2 create-vpc --cidr-block 10.0.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=SAA-Lab-VPC}]'
# Create Public Subnets
aws ec2 create-subnet --vpc-id vpc-xxxxxxxxx --cidr-block 10.0.1.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-xxxxxxxxx --cidr-block 10.0.2.0/24 --availability-zone us-east-1b
# Create Private Subnets
aws ec2 create-subnet --vpc-id vpc-xxxxxxxxx --cidr-block 10.0.11.0/24 --availability-zone us-east-1a
aws ec2 create-subnet --vpc-id vpc-xxxxxxxxx --cidr-block 10.0.12.0/24 --availability-zone us-east-1b
Step 2: Create Security Group
Security Group Configuration:
Name: SAA-Lab-WebServer-SG
Description: Security group cho web servers
VPC: SAA-Lab-VPC
Inbound Rules:
- Type: HTTP (80)
Source: ALB Security Group
Description: Allow HTTP from load balancer
- Type: HTTPS (443)
Source: ALB Security Group
Description: Allow HTTPS from load balancer
- Type: SSH (22)
Source: Your IP address
Description: SSH access for management
Outbound Rules:
- Type: All Traffic
Destination: 0.0.0.0/0
Description: Allow all outbound traffic
Step 3: Create Application Load Balancer
ALB Configuration:
Name: SAA-Lab-ALB
Scheme: Internet-facing
IP Address Type: IPv4
VPC: SAA-Lab-VPC
Subnets: Public subnets (us-east-1a, us-east-1b)
Security Group: ALB-SG (HTTP/HTTPS from Internet)
Target Group:
Name: SAA-Lab-TG
Protocol: HTTP
Port: 80
VPC: SAA-Lab-VPC
Health Check:
Protocol: HTTP
Path: /
Healthy Threshold: 2
Unhealthy Threshold: 5
Timeout: 5 seconds
Interval: 30 seconds
Step 4: Create Launch Template
Launch Template:
Name: SAA-Lab-Launch-Template
Version: 1
Instance Configuration:
AMI: Amazon Linux 2 (latest)
Instance Type: t3.micro
Key Pair: Your existing key pair
Network Settings:
VPC: SAA-Lab-VPC
Security Groups: SAA-Lab-WebServer-SG
Auto-assign Public IP: Disable
Storage:
Root Volume:
Size: 8 GiB
Volume Type: gp3
Encrypted: Yes
Advanced Details:
IAM Instance Profile: EC2-SSM-Role (optional)
User Data: |
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from $(hostname -f)</h1>" > /var/www/html/index.html
echo "<p>Instance ID: $(curl -s http://169.254.169.254/latest/meta-data/instance-id)</p>" >> /var/www/html/index.html
echo "<p>Availability Zone: $(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone)</p>" >> /var/www/html/index.html
Step 5: Create Auto Scaling Group
Auto Scaling Group:
Name: SAA-Lab-ASG
Launch Template: SAA-Lab-Launch-Template (latest version)
VPC: SAA-Lab-VPC
Subnets: Private subnets (us-east-1a, us-east-1b)
Capacity:
Desired Capacity: 2
Minimum Capacity: 1
Maximum Capacity: 6
Load Balancer:
Target Groups: SAA-Lab-TG
Health Check Type: ELB
Health Check Grace Period: 300 seconds
Tags:
- Key: Name
Value: SAA-Lab-Instance
Propagate to instances: Yes
- Key: Environment
Value: Lab
Propagate to instances: Yes
Step 6: Create Scaling Policies
Target Tracking Policy
Policy Name: SAA-Lab-Target-Tracking
Policy Type: Target Tracking Scaling
Metric Type: Average CPU Utilization
Target Value: 70%
Scale-out Cooldown: 300 seconds
Scale-in Cooldown: 300 seconds
Disable Scale-in: No
Step Scaling Policy (Optional)
Scale Out Policy:
Name: SAA-Lab-Scale-Out
Action: Add 1 instance
Cooldown: 300 seconds
Scale In Policy:
Name: SAA-Lab-Scale-In
Action: Remove 1 instance
Cooldown: 300 seconds
CloudWatch Alarms:
High CPU Alarm:
Metric: CPUUtilization
Threshold: 80%
Comparison: Greater than threshold
Period: 300 seconds
Evaluation Periods: 2
Action: Trigger Scale Out Policy
Low CPU Alarm:
Metric: CPUUtilization
Threshold: 30%
Comparison: Less than threshold
Period: 300 seconds
Evaluation Periods: 2
Action: Trigger Scale In Policy
🧪 Testing Scenarios
Test 1: Basic Functionality
# 1. Verify instances are running
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names SAA-Lab-ASG
# 2. Check load balancer targets
aws elbv2 describe-target-health --target-group-arn arn:aws:elasticloadbalancing:region:account:targetgroup/SAA-Lab-TG/xxxxx
# 3. Access application through ALB
curl -v http://your-alb-dns-name.region.elb.amazonaws.com/
Test 2: Manual Scaling
# Scale out manually
aws autoscaling set-desired-capacity --auto-scaling-group-name SAA-Lab-ASG --desired-capacity 4
# Wait và verify
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names SAA-Lab-ASG --query 'AutoScalingGroups[0].Instances[*].[InstanceId,LifecycleState,AvailabilityZone]'
# Scale in manually
aws autoscaling set-desired-capacity --auto-scaling-group-name SAA-Lab-ASG --desired-capacity 2
Test 3: Load Testing
# Install stress tool on instances
sudo amazon-linux-extras install epel -y
sudo yum install stress -y
# Generate CPU load
stress --cpu 2 --timeout 600s
# Monitor scaling activity
aws autoscaling describe-scaling-activities --auto-scaling-group-name SAA-Lab-ASG --max-items 10
Test 4: Instance Failure Simulation
# Terminate an instance
aws ec2 terminate-instances --instance-ids i-xxxxxxxxx
# Monitor replacement
aws autoscaling describe-auto-scaling-groups --auto-scaling-group-names SAA-Lab-ASG
📊 Monitoring Commands
CloudWatch Metrics
# Get CPU utilization
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 \
--metric-name CPUUtilization \
--dimensions Name=AutoScalingGroupName,Value=SAA-Lab-ASG \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T23:59:59Z \
--period 300 \
--statistics Average
# Get Auto Scaling metrics
aws cloudwatch get-metric-statistics \
--namespace AWS/AutoScaling \
--metric-name GroupDesiredCapacity \
--dimensions Name=AutoScalingGroupName,Value=SAA-Lab-ASG \
--start-time 2024-01-01T00:00:00Z \
--end-time 2024-01-01T23:59:59Z \
--period 300 \
--statistics Average
🎯 Expected Results
Successful Implementation
- [ ] ALB healthily distributes traffic across instances
- [ ] Auto Scaling Group maintains desired capacity
- [ ] New instances automatically register với target group
- [ ] Scaling policies respond to CPU utilization
- [ ] Failed instances are automatically replaced
- [ ] Traffic continues during scaling events
Target Group Health:
- All instances show "healthy" status
- Response time < 100ms
- No 5xx errors
Auto Scaling Behavior:
- Scale out time: 2-5 minutes
- Scale in time: 2-5 minutes
- Instance replacement: 2-3 minutes
Load Balancer:
- Even traffic distribution
- Sticky sessions (if configured)
- Health check passing rate: 100%
🧹 Cleanup Resources
Manual Cleanup
# Delete Auto Scaling Group
aws autoscaling delete-auto-scaling-group --auto-scaling-group-name SAA-Lab-ASG --force-delete
# Delete Launch Template
aws ec2 delete-launch-template --launch-template-name SAA-Lab-Launch-Template
# Delete Load Balancer
aws elbv2 delete-load-balancer --load-balancer-arn arn:aws:elasticloadbalancing:region:account:loadbalancer/app/SAA-Lab-ALB/xxxxx
# Delete Target Group
aws elbv2 delete-target-group --target-group-arn arn:aws:elasticloadbalancing:region:account:targetgroup/SAA-Lab-TG/xxxxx
# Delete Security Groups
aws ec2 delete-security-group --group-id sg-xxxxxxxxx
# Delete VPC components (if created for lab)
aws ec2 delete-subnet --subnet-id subnet-xxxxxxxxx
aws ec2 delete-vpc --vpc-id vpc-xxxxxxxxx
📚 Key Learnings
Auto Scaling Concepts
- Launch Templates: Modern way to specify instance configuration
- Health Checks: ELB health checks provide better application-level monitoring
- Scaling Policies: Target tracking is simpler than step scaling
- Cooldowns: Prevent thrashing during scaling events
- Multi-AZ: Provides high availability và fault tolerance
Best Practices Learned
- Use target tracking scaling cho most use cases
- Set appropriate health check grace periods
- Monitor scaling activities và metrics
- Test failure scenarios regularly
- Use least privilege IAM roles
🔍 Troubleshooting Common Issues
Instances Not Healthy
Possible Causes:
- Security group blocking health check traffic
- Application not responding on health check path
- Health check timeout too short
- Instance startup time longer than grace period
Solutions:
- Verify security group rules
- Check application logs
- Increase health check timeout
- Increase health check grace period
Scaling Not Working
Possible Causes:
- CloudWatch alarms not configured correctly
- Insufficient permissions
- Cooldown periods too long
- Scaling policies misconfigured
Solutions:
- Check alarm thresholds và periods
- Verify IAM permissions
- Adjust cooldown settings
- Test manual scaling first
🎓 Quiz Questions
- Khi nào nên sử dụng ELB health checks thay vì EC2 health checks?
- Tại sao target tracking scaling được recommend hơn step scaling?
- Làm thế nào để prevent scaling thrashing?
- Launch templates có advantages gì so với launch configurations?
- Làm thế nào để handle stateful applications trong Auto Scaling Groups?
📖 Further Reading