Loading…
While this loads — worth knowing
ElastiCache RedisnotElastiCache Memcached
Redis has data structures — sorted sets, counters, pub/sub. Memcached has plain keys and nothing else.
Loading…
While this loads — worth knowing
Redis has data structures — sorted sets, counters, pub/sub. Memcached has plain keys and nothing else.
Keeps the right number of EC2 instances running. It replaces the ones that fail, and adds or removes instances as the load changes.
Where Auto Scaling takes you7 steps, all open
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.
Auto Scaling groupMinimum and maximumDesired capacityLaunch templateTarget trackingHealth checkTwo 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.
Capacity: 500 requests a second for each.
4 instances can take 2,000 requests a second, and 75% of that is in use.
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.
Load balancer health checks turned on for the group
CustomersServed by Web 1 and Web 2 and Web 3 and Web 4
Click a node to make it fail. The timings in the log are the real ones, played 40× faster.
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.
| Method | What moves the size | Reacts or plans | Choose it when |
|---|---|---|---|
| Target tracking | A metric held at a target value, like a thermostat | Reacts | The metric rises and falls with the number of instances, like average CPU |
| Step scaling | Adjustments sized by how far an alarm is breached | Reacts | A bigger breach should get a bigger response |
| Simple scaling | One adjustment, then a wait for the cooldown | Reacts | Rarely: AWS recommends target tracking or step scaling instead |
| Scheduled | Actions at a date and time you set | Plans | You know exactly when the load changes |
| Predictive | A forecast from daily and weekly patterns | Plans | Cyclical traffic, and instances that take long to start |
| Manual | You change the desired capacity | Neither | A one-off change |
the load balancer marks an instance unhealthy, but it is never replacedTurn on Elastic Load Balancing health checks for the group
By default the group uses EC2 status checks only and ignores what the load balancer reports.
new instances are terminated before the application has startedA longer health check grace period, or a launch lifecycle hook
Either keeps health checks from acting on an instance that is still starting.
copy the logs off an instance before it is terminatedA termination lifecycle hook
It holds the instance in a wait state, one hour by default, while the action runs.
keep average CPU at about 50 percentA target tracking scaling policy
It creates the alarms and adds or removes instances to hold the metric at the target.
traffic jumps every weekday morning and instances take ten minutes to startPredictive scaling, or a scheduled action
Both add capacity before the load arrives. Predictive scaling learns the pattern by itself.
scale the workers on the length of an SQS queueTarget tracking on backlog per instance
Queue length does not change in proportion to the number of instances; messages per instance does.
which instance goes first when the group scales inOne in the zone with the most instances
Zone balance comes first. Then the default policy prefers the oldest launch template or configuration.
one group of Spot and On-Demand Instances of several typesA launch template
Launch configurations cannot do it, and AWS recommends launch templates for every group.
an instance running a long job must not be terminated on scale-inInstance scale-in protection
A protected instance is not chosen when the group scales in.
An application runs on EC2 instances in an Auto Scaling group behind an Application Load Balancer. When the application hangs, the load balancer marks the instance unhealthy and stops sending it requests, but the instance is never replaced, and the group runs short of capacity. What should a solutions architect do?
Video files arrive on a queue at unpredictable rates. Each one takes up to 40 minutes to transcode with software installed on the machine, and the results go to S3. The number of machines must grow with the backlog, shrink when it clears, and replace any that fail. What processes the queue?
300 s in the console, 0 from the CLI: how long a new instance has before it is judged.This whole page is free right now.The AWS library is still being written, so every page of it is open to everyone while that lasts. It becomes a paid bundle later; what you read today costs you nothing.
Every fact on this page was checked against AWS’s own documentation on 15 Sept 2026. If AWS has changed something since, its page is the one to trust.