DEV Community

maso
maso

Posted on

DAY3 -Monitoring & Scaling

Overview

Today, I'll do a hands-on lab on monitoring and scaling EC2 instances using an ALB, an Auto Scaling Group, and CloudWatch.

Hands-on

1. Build NAT Gateway

1. Create Elastic IP to attach to the NAT Gateway

2. Build NAT Gateway

Subnet : Public subnet (either public subnets made in Day1 hands-on)
Elastic IP : IP made in the previous step.
※Best practice is to deploy a NAT Gateway per AZ for high availability. To keep costs down, I'm creating only one NAT Gateway in a single AZ by Zonal mode.

2. Add a default rule to the private route table

Add a default route to the private route table associated with private subnets so that instances in those subnets can reach the Internet.
Destination : 0.0.0.0/0
Target : NAT Gateway

3. Create two security groups.

  • Security group for ALB Inbound : HTTP 80 from 0.0.0.0/0 Outbound : All traffic (default)

  • Security group for EC2 Inbound : HTTP 80 from the ALB security group made in the previous step Outbound : All traffic (default)

4. Create Target Group

Target type : Instances
Protocol/Port : HTTP 80
VPC : the VPC made in Day1 hands-on
Health check : Path /

5. Create Launch Template

Create a launch template for the ASG.

AMI : Amazon Linux 2023
Instance type : t3.micro
Security group : the security group made in the previous step for EC2
IAM role : the IAM role has AmazonSSMManagedInstanceCore permission (we made in Day2 hands-on)
※I will use Session Manager to perform load testing
Auto-assign public IP : Disable
User data : following

#!/bin/bash
set -e

dnf -y update
dnf -y install nginx
systemctl enable --now nginx

TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
  -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
INSTANCE_ID=$(curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
  http://169.254.169.254/latest/meta-data/instance-id)

cat > /usr/share/nginx/html/index.html <<EOF
<h1>Day3: ALB + ASG (Private EC2)</h1>
<p>InstanceId: ${INSTANCE_ID}</p>
EOF
Enter fullscreen mode Exit fullscreen mode

6. Create Auto Scaling Group (ASG)

Launch template : the template made in the previous step
VPC : VPC made in Day1 hands-on
Subnets : two private subnets made in Day1 hands-on
Load balancing : attach to the target group made in the previous step
Min Desired capacity : 2
Max desired capacity : 4
Health check type : ELB
Grace period : 120 sec

7. create ALB

Schema : Internet-facing
VPC : VPC made in Day1 hands-on
Availability Zones and subnets : 2 public subnets
Security group : security group for ALB
Listener : HTTP:80
Routing action : Forward to the target group made in the previous step.

8. Functionality Verification

If you can open the ALB's DNS name in your browser, you've successfully reached the private EC2 instances through the public ALB.

Ensure the status of the target group is healthy.

9. Scaling

1. create Scaling policy

ASG → Automatic scaling → Create dynamic scaling policy.
Policy type : Target tracking scaling
Metric : Average CPU utilization
Target : 40~50%

2. Functionality Verification of the scaling

Connect to the EC2 instance by using SSM (like Day2 hands-on) and execute the following commands to install stress-ng and launch CPU workers to increase CPU usage for ten minutes.

sudo dnf -y install stress-ng
cd /tmp
stress-ng --cpu 2 --timeout 10m
Enter fullscreen mode Exit fullscreen mode

Wait for a few minutes and check scaling status.
In my case, the status of "TargetTracking" metrics in cloud watch exceeded the threshold in 5 minutes and ASG automatically launched a new instance about five minutes later.


→After the two EC2 instances configured as the minimum desired capacity, another EC2 instance is launched for load balancing.

10. Tidying up (to prevent unpredictable cost)

Please delete the resources in the following order to avoid failures in dependency order.

1. Delete ALB

2. Delete ASG

3. Delete Target group

4. Delete Launch template

5. Delete NAT Gateway

6. Release Elastic IP ←more likely to forget! Be careful!

2. For test

Key exam points related to today's services.

1. the differences between NAT Gateway and NAT instance
  • NAT Gateway is the managed service (= you don't need to manage it.) and should be associated with EIP.

  • NAT instance is the EC2 instance has EIP or public IP. You should manage countermeasures for failures and load balancing.

2. ALB vs NLB
  • ALB uses HTTP or HTTPS protocol. can route based on URL and set Lambda as target and use ACM. →when you want to route based on URL in web application or manage certificate.
  • NLB uses TCP, TLS or UDP protocol. Ultra-high speed, high throughput and use EIP. →when you want high-speed communication in the system like financial system or publish the system using a fixed IP address. #####3. Scaling of the resources
  • EC2 : ASG + ALB/NLB + scale indicator (CPU, Request Count etc)

  • Lambda : concurrent execution, manage by event source (SQS, Kinesis etc)

  • ECS/EKS : Service Auto Scale

See you soon in Day4 hands-on!

Top comments (0)