Auto ScalingAmazon EC2 Auto Scaling

Amazon EC2 Auto Scaling keeps a set of EC2 instances, called an Auto Scaling group, at the size you ask for. You set a minimum, a maximum and a desired capacity. The group never goes below the minimum or above the maximum, and it launches or terminates instances to stay at the desired number.

It does two jobs. It replaces instances that fail their health checks, so a group of any size heals itself. With scaling policies, it also moves the desired capacity up and down as the load changes. Auto Scaling itself costs nothing extra: you pay for the instances it runs and the CloudWatch alarms it uses.

A shop manager keeps enough staff on the floor. A minimum are always in, the shop holds only so many, and there is a number working today. Anyone who falls ill is replaced without being asked. When the queue at the tills grows, more come in; when it shrinks, some go home.

Two zones at least. The group keeps its instances balanced across the zones it uses, so losing one zone costs part of the capacity, not the application.

Let the group see what the load balancer sees. By default the group judges health by EC2 status checks alone and ignores the load balancer. Turn on Elastic Load Balancing health checks for the group, and an instance the load balancer reports unhealthy is replaced, not just skipped.

Put a new instance to work only when it is ready. A launch lifecycle hook can hold it until its start-up script has finished, so it joins the load balancer ready to take requests.

Target tracking is what AWS recommends. Pick a metric and a value, such as average CPU at 50 percent. The group adds instances when the metric is above the target and removes them when it falls below, and it creates and manages the CloudWatch alarms itself.

The numbers in this simulation are made up to show the shape, not the capacity of any real instance type. The minimum is two, one in each zone.

Scale workers on backlog per instance, not queue length. The number of messages waiting does not change in proportion to the number of instances, so a target tracking policy cannot hold it. Messages per instance does, and the target is how many each can have waiting before the delay is too long.

Warm-up. A new instance does not count towards the group's metrics until its warm-up time has passed, so the group does not keep adding instances for load the first ones are about to take.

Where the time goes. The load balancer checks every 30 seconds and takes a target out after two failures in a row, so about a minute. The group then terminates the instance and launches another. The simulation gives that three minutes; the real time depends on your AMI and how long the application takes to start.

Without load balancer health checks, the load balancer still stops sending requests to a hung instance, but the group sees a running instance that passes its EC2 status checks and never replaces it. The capacity is simply lost.

Replacements are paced. If the group is 10 percent or more below its desired capacity while a scaling activity is under way, it finishes that first. After that it replaces at most 10 percent of the desired capacity at a time, by default.

While a zone is down, nothing starts in it. That is why the group spans at least two.

Credentials come from the launch template. Give it an instance profile with an IAM role, so every instance the group launches gets temporary credentials, and no keys live in the AMI or the user data.

Launching needs permission to launch. Whoever creates or updates the group must be allowed to use the launch template and what it names. Without that, the group is refused with a not-authorised error.

Replace rather than patch in place. Instance refresh rolls a new AMI or launch template through the group, and can try it on a few instances first.

Keep nothing on an instance that you cannot lose. A replacement is a new instance: an Elastic IP address or EBS volume from the old one does not follow it unless a lifecycle hook moves it.

Auto Scaling is free. There is no fee for it: you pay for the EC2 instances it runs, the CloudWatch alarms its policies use and any other resources they use.

Scaling in is where it saves. Removing instances when the load falls is the saving, so set the minimum to what the quietest hour needs.

Mix purchase options. One group can run several instance types and both Spot and On-Demand Instances, and Savings Plans and Reserved Instance discounts apply to its On-Demand Instances.

Prices change, so none are printed here. Check the EC2 pricing pages on aws.amazon.com.