I. Introduction

1. Auto Scaling Groups (ASG) can manage resources with user traffic.

2. The goal of ASG is:

   1. Scale out (add instances)
   2. Scale in (remove instances)
   3. Ensure there's a min/max for both ends
   4. Automatically register instances to ELB

3. All ASGs have a launch config (old) or a launch template (new)

   1. A launch configuration

      1. AMI + Instant Type
      2. EC2 user data
      3. EBS volumes
      4. Security Groups
      5. SSH Key Pair

   2. Min/Max size, initial capacity

   3. Network + Subnet information

   4. Load balancer information

   5. Scaling policies

4. It is possible to scale ASG based on CloudWatch alarms

5. It is now possible to define better auto scaling rules that are directly managed by EC2

   1. Target average CPU usage
   2. Number of request on ELB per instance
   3. Average network in/out

6. We can also scale based on custom metric e.g. number of connected users

   1. Send custom metric from app on EC2 to CloudWatch (PutMetric API)
   2. Create CloudWatch alarm to react to low/high values
   3. Use the alarm as scaling policy for ASG

7. ASG will automatically create a new instance when an existing instance is down or unhealthy (+ terminate the unhealthy instance).

II. Scaling Policies

1. Target-tracking scaling

   1. Most simple and easy set up e.g. I want average ASG CPU to stay around 50%
   2. Increase or decrease the current capacity of the group based on a target value for a specific metric.
   3. This is similar to the way that your thermostat maintains the temperature of your home.
   4. If you are scaling based on a utilization metric that increases or decreases proportionally to the number of instances in an Auto Scaling group, then it is recommended that you use target tracking scaling policies. Otherwise, it is better to use step scaling policies instead.

2. Step scaling

   1. When a CloudWatch alarm is triggered (CPU > 70%) → add 2 units
   2. Increase or decrease the current capacity of the group based on a set of scaling adjustments, known as step adjustments, that vary based on the size of the alarm breach.

3. Simple scaling

   1. Increase or decrease the current capacity of the group based on a single scaling adjustment.

4. Scheduled scaling

   1. Anticipate a scaling event based on historical data e.g. add 2 units on Fridays

5. Scaling cool-downs

   1. The cool-down period helps ensure that the ASG doesn't launch or terminate before the previous scaling activity takes place.
   2. In addition to default cooldowns, we can create cooldowns that apply to a specific simple scaling policy. This would override the default cooldown period.
   3. If the default cooldown period of 300s is too long, you can reduce costs by applying a scaling-specific period of 180 seconds to the scale-in policy.
   4. If your app is scaling up and down multiple times each hour, modify the ASG cool-down timers and CloudWatch alarm periods that trigger the scaling.

III. Health checks

1. If using an ELB, it is best to enable ELB health checks as otherwise EC2 status checks may show an instance as being healthy that the ELB has determined is unhealthy. In this case the instance will be removed from service by the ELB but will not be terminated by Auto Scaling Group.
2. ASG uses EC2 health checks by default. It can also use ELB health checks and custom health checks. ELB health checks are in addition to the EC2 status checks.
3. If any ASG health check returns an unhealthy status then the instance will be terminated.
4. When a ELB marks an instance as unhealthy, it reports it as OutOfService