AWS Auto Scaling Groups

 

Auto Scaling Group (ASG) – Concept, Features, Benefits, Limitations, and Use Cases

 Concept

An Auto Scaling Group (ASG) is a logical grouping of EC2 instances managed by AWS Auto Scaling. It automates the launching, termination, and replacement of EC2 instances based on user-defined policies, schedules, or demand (e.g., CPU usage, request count).
Its goal is to maintain application availability and optimize cost by scaling resources dynamically.

 Key Features

Feature	Description
Automatic Scaling	Scale out (add) or scale in (remove) instances based on demand (metrics or schedules).
Self-Healing	Automatically replaces failed or unhealthy instances.
Scheduled Actions	Scale based on pre-defined schedules (e.g., increase capacity during business hours).
Dynamic Policies	Scale in/out based on CloudWatch metrics (e.g., CPUUtilization > 70%).
Launch Templates/Configs	Define instance settings (AMI, instance type, security groups, etc.).
Integration	Works with Elastic Load Balancers (ELB), SNS, CloudWatch, Lifecycle Hooks, etc.

Benefits

Benefit	Description
Cost Efficiency	Automatically removes excess instances when demand drops.
Elasticity	Scales with application load without manual intervention.
Fault Tolerance	Replaces unhealthy instances automatically, improving uptime.
Performance Optimization	Maintains performance under variable traffic by scaling out.
Automation	Reduces manual management and human error with defined rules.

 Limitations

Limitation	Description
Complex Setup	Requires correct configuration of policies, templates, and metrics.
Slow Reaction Time	Not ideal for ultra-fast traffic spikes (scaling can take a few minutes).
Statefulness	Not suitable for stateful applications without session handling mechanisms.
Metric Dependency	Poorly chosen metrics can lead to inefficient scaling behavior.
Integration Required	Needs external components (e.g., load balancers) to be truly effective.

 Use Cases

Use Case	Description
Web Applications	Automatically scale web servers based on traffic.
Mobile Backends	Handle unpredictable bursts in mobile user activity.
Dev/Test Environments	Scale down during non-business hours to save cost.
Batch Processing	Scale out compute nodes during large batch jobs, then scale in.
Disaster Recovery	Automatically recover from instance or AZ failures.

 Real-World Example (AWS)

• twtech may set minimum = 2, maximum = 10, and desired = 4.
• If CPU usage goes above 70%, it adds 2 instances (scale out).
• If usage drops below 30%, it removes 1 instance (scale in).
• If an instance becomes unhealthy, it gets replaced automatically.

Project: Hands-on

How twtech uses an launch template, to create instances with Auto Scaling group and attach the instances to a load balancer.

Go to ec2 console and navigate to Auto Scaling on menu tab.

Create Auto Scaling group: twtech-ASG

Assign a name for the auto scaling group: twtech-ASG

click on : Create a Launch template

Create a launch template: twtech-ASG-launch-template

Select the Application and OS Images (Amazon Machine Image) – required:Amzon linux 2023

Select instance type: t2.micro

Select the key pair: twtech-keyPair

Don’t include subnets in the launch template:

Select existing Security group or create one: k8s-SG

Configure capacity for: Storage

For Advanced details, navigate all the way down to: user data

Input user data

#!/bin/bash

yum update -y

yum install -y httpd

systemctl start httpd

systemctl enable httpd

echo " <h1> twtech hello-app from $(hostname -f)</h1>" > /var/www/html/index.html

Verify the summary and create launch template: twtech-ASG

NB:

Next Steps

Launch an instance

With On-Demand Instances, twtech pays for compute capacity by the second (for Linux, with a minimum of 60 seconds) or by the hour (for all other operating systems) with no long-term commitments or upfront payments. Launch an On-Demand Instance from your launch template.

Launch instance from this template

Create an Auto Scaling group from your template

Amazon EC2 Auto Scaling helps twtech maintain application availability and allows twtech to scale the Amazon EC2 capacity up or down automatically according to conditions you define. twtech can use Auto Scaling to help ensure that twtech is running the desired number of Amazon EC2 instances during demand spikes to maintain performance and decrease capacity during lulls to reduce costs.

Create Auto Scaling group

Create Spot Fleet

A Spot Instance is an unused EC2 instance that is available for less than the On-Demand price. Because Spot Instances enable you to request unused EC2 instances at steep discounts, twtech can lower the Amazon EC2 costs significantly. The hourly price for a Spot Instance (of each instance type in each Availability Zone) is set by Amazon EC2, and adjusted gradually based on the long-term supply of and demand for Spot Instances. Spot instances are well-suited for data-analysis, batch jobs, background processing, and optional tasks.

Create Spot Fleet

Go back to auto-scaling, refresh and select the launch template created: twtech-ASG-launch-template

Choose instance launch options

Choose the VPC network environment that twtech instances are launched into, and customize the instance types and purchase options.

NB:

Instance purchase options if oviride lauch template is used: 100% On Demand

Instances distribution

To run fault-tolerant workloads at low cost, twtech defines a percentage of instances that will be Spot Instances. Spot Instances are spare EC2 capacity that offer steep discounts compared to On-Demand prices that AWS can interrupt with a 2-minute notification.

Select the vpc and multiple AZ to launch instance to:

Integrate with other services - optional

Attach to an existing load balancer target group: twtech-alb-tg

Health checks: twtech always enable health checks to its instances

Configure group size and scaling - optional

Automatic scaling - optional

Choose whether to use a target tracking policyInfo

twtech can set up other metric-based scaling policies and scheduled scaling after creating the Auto Scaling group.

Instance maintenance policy

Control  Auto Scaling group’s availability during instance replacement events. This includes health checks, instance refreshes, maximum instance lifetime features and events that happen automatically to keep the group balanced, called rebalancing events.

Choose a replacement behavior depending on the availability requirements

Add notifications - optional

Add tags - optional

Add tags to help twtech search, filter, and track the Auto Scaling group across AWS. twtech can also choose to automatically add these tags to instances when they are launched

Name: twtech-ASG

Review & launch ASG: twtech-ASG

This should create and add an ec2 instance to the exiting ones:

How twtech Checks the health status of instance from: target group console

Give the instance a couple of minutes to fully bootstrap.

Successufully twtech can now route traffic to its three instances via a load balancer (ALB/NLB) configured for auto-scaling

Instance-1: twtech-AGS

Instance-1: twtech-webserver1

Instance-1: twtech-webserver2

How twtech may manually scale out(increase instances) or scale in(reduce instances) the number of instances to meet traffic needs:

By editing the auto scaling group

From: 

To:

Save changes: update

Verify if another instance has been added: from ASG activity history

Verify if another instance has been added: on ec2 console

Yes: bootstrapping and initializing

Instance is now Fully bootstrapped and initialized:

twtech-alb-tg: target

Routing traffic now goes to four healthy instances:

twtech-insights:

An instance with a health check enabled can continuously remain in an unhealthy state due to several reasons. Here are the most common causes, categorized by the type of health check:

Common Causes of Unhealthy State (Across All Check Types)

1.     Service/Application Not Running

o   The app or service expected by the health check is not running.

o   Example: The HTTP server is down, so port 80 check fails.

2.     Incorrect Health Check Configuration

o   Wrong port, protocol (HTTP/HTTPS/TCP), or path specified in the health check.

o   Example: Health check is looking for /healthz but the app exposes /status.

3.     Firewall/Security Group Rules

o   The health check source (e.g., load balancer or monitoring service) is blocked by security groups or NACLs.

4.     Startup Time Issues

o   The instance or service takes longer to start than the grace period defined in the health check.

5.     Resource Constraints

o   High CPU, memory, or disk usage prevents the app from responding properly.

6.     DNS Resolution Failure

o   If DNS is used in the check and fails intermittently or completely, the check fails.

 EC2 Load Balancer Health Checks (ELB/NLB/ALB)

1.     EC2 Instance Not Responding

o   ELB sends requests but does not get a response within the timeout.

2.     Wrong Target Port

o   Instance listens on port 3000, but health check is configured for port 80.

3.     Target Group Health Check Path Issue

o   For ALB/NLB, the target group health check path is invalid or returns 4xx/5xx status codes.

4.     Unhealthy Threshold Met

o   The number of consecutive failed checks meets or exceeds the threshold configured.

 Auto Scaling Group (ASG) Health Checks

1.     Failing ELB Health Checks

o   If integrated with ELB, ELB health checks are used to mark the instance unhealthy.

2.     EC2 Status Check Failures

o   System-level issues like failed instance reachability or hardware issues.

 Application-Level Health Checks (e.g., Kubernetes, Custom Scripts)

1.     Health Endpoint Returns Bad Response

o   Non-200 HTTP status codes, incorrect content, or empty response.

2.     Misconfigured Probe Timing

o   Probe interval or timeout is too aggressive for the application startup time.

3.     Dependencies Not Available

o   The app itself may be up, but its dependencies (DB, API, etc.) are down, causing the health check to fail.

Troubleshooting Steps

1.     Check Logs

o   App logs, instance system logs, and load balancer logs.

2.     Test Health Endpoint Manually

o   Use curl or similar tools to hit the health check endpoint from within the instance or externally.

3.     Check Load Balancer/ASG Metrics

o   Look at CloudWatch metrics or the load balancer’s health tab.

4.     Verify Security Groups/NACLs

o   Ensure inbound rules allow traffic on health check ports from the source (like ELB).

5.     Update Health Check Configuration

o   Adjust path, port, protocol, thresholds, and timeouts.