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


.png&blockId=8bb60f06-19ab-4061-920b-1b40276db9b6)
.png&blockId=8bb60f06-19ab-4061-920b-1b40276db9b6&width=256)


