You have a load balancer distributing traffic among several servers. But one question remains: who creates those servers and how many should there be? If you set 10 fixed servers, you overpay at night when there’s little traffic; if you set 2, you get overwhelmed at peak hours. The solution is the Auto Scaling Group (ASG): the component that automatically creates and removes servers according to demand. This is the other half of an elastic architecture.

The traffic of almost any application rises and falls:

If you size for the peak, you waste money most of the time. If you size for the average, you crash at the peaks. The answer is not to have a fixed number: adjust the number of servers in real time. That’s autoscaling, and it’s one of the great advantages of the cloud we saw in Chapter 1 (elasticity).

An Auto Scaling Group (ASG) is a group of EC2 instances that AWS automatically maintains and adjusts. You define some limits and rules, and the ASG takes care of creating or destroying servers to comply with them.

It is configured with three key numbers:

• Minimum: the number that will always be there, even if there’s no traffic (guarantees availability).
• Desired: how many there are at this moment; this is what the ASG adjusts.
• Maximum: the cap, so a spike (or an error) doesn’t send your bill skyrocketing.

The ASG doesn’t just scale: it also self-heals. If an instance goes down or fails its health check, the ASG detects it and creates a new one to maintain the desired number.

This is extremely powerful: combined with the load balancer from the previous subchapter, your application heals itself. If a server dies at 3 a.m., nobody has to get up: the ASG creates a new one and the load balancer starts using it as soon as it’s healthy. This is where user_data from subchapter 12.2 makes sense: every new server self-configures at birth.

How does the ASG decide when to scale? Through scaling policies based on metrics (CloudWatch data, which we’ll see in Chapter 24). The most common is CPU usage.

You tell the ASG a target and it does what’s necessary to maintain it. For example: “keep average CPU usage at 50%.”

It’s like a car’s climate control: you say “keep it at 22 degrees” and it turns the air on or off as needed. You don’t worry about the details. For its simplicity, it’s the recommended policy to start with.

An example of scheduled scaling: a ticket sales website knows that every Monday at 10:00 it releases tickets and gets a flood of users. It schedules the ASG to scale up to 20 servers at 9:55, before people arrive, instead of waiting for CPU to rise.

Policies react to metrics. The most common:

• CPU usage: the most common; high CPU = overloaded servers.
• Number of requests per server: very useful with a load balancer (requests from the Target Group).
• Memory or network usage.
• Custom metrics: for example, the number of messages in a queue (we’ll see this with SQS, Chapter 15).

Combining the three subchapters, this is the classic elastic architecture:

The load balancer distributes among the servers present; the ASG adjusts how many there are and keeps them healthy. Together they provide an application that scales and heals itself.

• An Auto Scaling Group (ASG) creates and removes servers automatically according to demand, within limits: minimum, desired, and maximum.
• The ASG also self-heals: if a server fails, it creates a new one to maintain the desired number (this is where user_data that self-configures each server shines).
• Scaling policies decide when to scale based on metrics (the most common is CPU usage).
• Target Tracking (“keep CPU at 50%”) is the simplest and recommended policy to start with; there are also Step and Scheduled (scheduled scaling for predictable spikes).
• Load Balancer + ASG = architecture that scales and heals itself.

In the last subchapter of the chapter, we’ll see two advanced techniques to fine-tune autoscaling: warm pools and lifecycle hooks.