Learning AWS - DVA - Day 9: Auto Scaling Groups

Le Huy Ho - Oct 21 - - Dev Community

What is an Auto Scaling Group?

  • In real-life, the load of your websites and applications can be change

  • In the cloud, you can create and get rid of servers very quickly

  • The goal of an Auto Scaling Groups (ASG) is to:

    • Scale out (add EC2 intances) 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)
  • Auto Scaling Group are free - you only pay for the underlying EC2 intances.


Auto Scaling Group Attributes

  • A Launch Template, includes:

    • AMI + Instance Type
    • EC2 User Data
    • EBS Volumes
    • Security Groups
    • SSH Key Pair
    • IAM Role for your EC2 instance
    • Network + Subnet Information
    • Load Balancer Information
  • Min Size / Max Size / Initial Capacity

  • Scaling Policies


CloudWatch Alarm and Scaling

  • It is posible to scale an ASG based on CloudWatch alarms

  • An alarm monitors a metric (such as Average CPU, or a custom metric)

  • Metric 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 Policies

Dynamic Scaling

  • Target Tracking Scaling

    • Simple to set-up
    • Example: I want the average ASG CPU to stay at around 40%
  • Simple / Step Scaling

    • When a CloudWatch alarm is triggered (ex: CPU > 70%) then add 2 units
    • When a CloudWatch alarm is triggerd (ex: CPU < 30%) then remove 1

Scheduled Scaling

  • Anticipate a scaling based on known usage patterns
  • Example: increase the min capacity to 10 at 5pm on Fridays

Predictive Scaling: continously 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 your application is network bound

  • Any custom metric (that you push using CloudWatch)

. . . . . . . . . . . . . . . .