Search

ASG - Auto Scaling Group

Note

ASG (Auto Scaling Group)
ASG automates the Scale Out and Scale In
ASG with Load Balancer: here
ASG with CloudWatch Alarm & Scaling: here
ASG Dynamic Scaling Policies: here
Target Tracking Scaling
Simple / Step Scaling
Scheduled Actions
Predictive scaling
Scale on Metrics: here

Auto Scaling Group

In real-life, the load on your websites and application can change
In the cloud, you can create and get rid of servers very quickly
The goal of an Auto Scaling Group (ASG) is to:
Scale out (add EC2 instances) to match an increased load
Scale in (remove EC2 instances) to match a decreased load
Ensure we have a minimum and a maximum number of EC2 instances running
Automatically register new instances to a load balancer
Re-create an EC2 instance in case a previous one is terminated (ex: if unhealthy)
ASG are free (you only pay for the underlying EC2 instances)

Auto Scaling Group in AWS with Load Balancer

ELB (Elastic Load Balancer) can run a health check
Health check can passed on to the ASG (Auto Scaling Group)
Terminate the instances that is unhealthy
Can run ELB and ASG synchronously

Auto Scaling Group Attributes

Have to create a Launch Template
AMI + Instance Type
EC2 User Data
EBS Volumes
Security Groups
SSH Key Pair
IAM Roles for your EC2 Instances
Network + Subnets Information
Load Balancer Information
Min Size / Max Size / Initial Capacity
Scaling Policies

Auto Scaling - CloudWatch Alarms & Scaling

It is possible to scale an ASG based on CloudWatch alarms
An alarm monitors a metric (such as Average CPU, or a custom metric)
Metrics such as Average CPU are computed for the overall ASG instances
Based on the alarm:
We can create scale-out policies (increase the number of instances)
We can create scale-in policies (decrease the number of instances)

Auto Scaling Groups - Dynamic Scaling Policies

Target Tracking Scaling
Most simple and easy to setup
Example: I want the average ASG CPU to stay at around 40%
Simple / Step Scaling
When a CloudWatch alarm is triggered, then add 2 units
When a CloudWatch alarm is triggered, then remove I
Scheduled Actions
Anticipate a scaling based on known usage patterns
Example: increase the min capacity to 10 at 5pm on Fridays
Predictive scaling
Continuously forecast load and schedule scaling ahead

Good Metrics to Scale On

CPUUtilization: Average CPU utilization across your instances
RequestCountPerTarget: to make sure the number of requests per EC2 instances is stable
Average Network In/Out (if you’re application is network bound)
Any customer metric (that you push using CloudWatch)

Scaling Cooldowns

After a scaling activity happens, you are in the cooldown period
During the cooldown period, the ASG will not launch or terminate additional instances (to allow for metrics to stabilize)
Use a ready-to-use AMI to reduce configuration time in order to be serving request faster and reduce the cooldown period

Instance Refresh

Goal: update launch template and then re-creating all EC2 instances
For this we can use the native feature of Instance Refresh
Setting of minimum healthy percentage
Specify warm-up time (how long until the instance is ready to use)d