Amazon EC2 Auto Scaling

What it is

Amazon EC2 Auto Scaling keeps the right number of healthy EC2 instances running for your application. You put instances in an Auto Scaling group, set the minimum, maximum, and desired number, and Auto Scaling does two jobs:

Self-healing: it replaces any instance that fails a Health checkA regular test, such as a request to a web page, that a load balancer, an Auto Scaling group, or Route 53 makes to see whether a resource is working. Unhealthy resources stop receiving traffic or are replaced.Glossary entry, so the group always has its desired capacity.
Scaling: it adds instances when demand rises and removes them when it falls, so you pay only for the capacity you need.

An Auto Scaling group spans several AZ (Availability Zone)An isolated location within an AWS Region, made up of one or more data centers with their own power, cooling, and networking. The AZs in a Region are linked by fast, low-latency connections, so spreading resources across them protects against the failure of one site.Glossary entry in one AWS RegionA separate geographic area where AWS runs its services, such as us-east-1 in Northern Virginia, made up of several Availability Zones. Most resources live in one Region; you choose Regions for latency, data residency, and the services you need.Glossary entry and keeps instances balanced across them, so losing one Availability Zone does not take the application down. Together with a load balancer, it is the standard way to make an EC2 tier HA (High availability)The ability of a system to keep serving users when parts of it fail, usually by running redundant copies across Availability Zones and failing over automatically. It is often stated as a percentage of uptime, such as 99.99%.Glossary entry and elastic.

Core concepts

Launch template: what to launch, including the AMI (Amazon Machine Image)A template for launching EC2 instances: the operating system, software, and settings to copy onto the new instance's volumes, plus who may launch it. AMIs come from AWS, AWS Marketplace, or the community, or you create your own from an instance.Glossary entry, instance type, Security groupA stateful virtual firewall for network interfaces, such as an EC2 instance's, whose rules can only allow traffic. Return traffic for allowed connections is allowed automatically, and a rule can refer to another security group instead of IP addresses.Glossary entry, IAM instance profile, and user data. Launch templates have versions and are required for newer features such as mixed instance types and Spot. AWS recommends them over the older launch configurations.
Capacity limits: minimum (never fewer), maximum (never more), and desired (what the group aims for now). Scaling policies change the desired capacity within the limits.
Load balancer integration: attach the group to an Elastic Load Balancing target group, and new instances are registered automatically and removed instances deregistered.

Scaling options

Option	How it works	Choose when
Target tracking	Keep a metric at a target, such as average CPU at 50% or `ALBRequestCountPerTarget` at 1,000; Auto Scaling creates and manages the CloudWatch alarms	Most workloads; AWS recommends it
Step scaling	Add or remove different amounts depending on how far a CloudWatch alarm is breached	You need a stronger response to bigger spikes
Simple scaling	One adjustment per alarm, then wait for the cooldown (300 seconds by default)	Rarely; prefer target tracking or step scaling
Scheduled scaling	Change capacity at set times, such as before business hours	Load changes at known times
Predictive scaling	Forecasts load from history and launches capacity ahead of it	Cyclical daily or weekly patterns, and applications that take long to start
Manual	You change the desired capacity	One-off changes

Points the exam likes to test:

Target tracking scales out quickly and scales in gradually, to protect availability.
With several target tracking policies, the group scales out if any policy wants to, and scales in only if all of them do.
Not every metric suits target tracking: the total RequestCount or a raw queue length does not change with the number of instances. For an SQS queue, track backlog per instance instead.
An instance warmup time keeps new instances out of the group's metrics until they are ready, so the group doesn't over-scale.
Turn on detailed monitoring (1-minute metrics) so scaling reacts faster.

Health checks

By default, the group uses EC2 status checks. Turn on Elastic Load Balancing health checks so an instance whose application stops responding is also replaced, not only one whose hardware fails. EBS, VPC Lattice, and custom health checks are also available.
The health check grace period gives new instances time to start before health checks count; it defaults to 300 seconds in the console.
An unhealthy instance is terminated and replaced with a new one from the launch template.

Lifecycle hooks

A lifecycle hook pauses an instance as it launches or terminates, for one hour by default, so you can run custom actions:

On launch: install software or pull configuration, and only then put the instance in service and register it with the load balancer.
On termination: copy logs or data off the instance, or drain work, before it is terminated.

Auto Scaling sends lifecycle events to Amazon EventBridge, where a rule can invoke a Lambda function. When the action finishes, call complete-lifecycle-action to continue.

Termination and scale-in

When scaling in, Auto Scaling first keeps the Availability Zones balanced, then by default terminates instances with the oldest launch template or configuration.
Other termination policies include OldestInstance, NewestInstance, and AllocationStrategy.
Instance scale-in protection keeps chosen instances, such as ones processing long jobs, from being terminated by scale-in.

Mixed instances and Spot

One group can combine several instance types and On-Demand and Spot Instances:

Set an On-Demand base and the percentage of On-Demand above it; the rest is Spot. For example, two On-Demand instances always, then 20% On-Demand and 80% Spot.
For Spot, use the price-capacity-optimized allocation strategy (recommended), which picks pools with the lowest interruption risk at a low price.
Capacity Rebalancing launches a replacement when a Spot Instance gets a rebalance recommendation, before it is interrupted.
Attribute-based instance type selection lets you specify vCPU and memory needs instead of listing instance types.

Updating and speeding up the group

Instance refresh replaces instances in rolling batches after you change the launch template, for example to roll out a new AMI. You set a minimum healthy percentage, and can add checkpoints and automatic rollback.
Maximum instance lifetime replaces instances older than a set age.
Warm pools keep pre-initialized instances stopped, hibernated, or running, so scale-out is fast for applications with long boot times. Stopped instances cost only their EBS volumes and Elastic IP (Internet Protocol)The protocol that addresses and routes packets between networks. Each device has an IP address: IPv4 addresses look like 192.0.2.1, and IPv6 addresses are longer, like 2001:db8::1.Glossary entry.

Security, resilience, performance, and cost

Security

IAM controls who can create and change groups and launch templates. Auto Scaling uses a service-linked role to launch and terminate instances for you.
Instances get their own permissions from the instance profile in the launch template; set security groups and IMDSv2 there too.

Resilience

Spread the group across at least two Availability Zones; Auto Scaling rebalances if a zone becomes unbalanced.
Use ELB health checks so failed applications are replaced.
To keep the needed capacity immediately after losing one of N Availability Zones, without waiting for launches, size the group so the remaining zones carry the load: needed capacity × N ÷ (N − 1). For example, 6 instances needed across 3 zones means 9 instances, 3 per zone.
For software that can run only as one instance, an Auto Scaling group with minimum, maximum, and desired capacity of 1 across several Availability Zones replaces the instance, in another zone if needed. EC2 automatic instance recovery, by contrast, stays in the same Availability Zone.
Design instances to be StatelessKeeping no memory of earlier requests, so that each one is handled on its own. Any copy of a stateless web server can handle any request, which makes scaling easy; a stateless firewall, such as a network ACL, needs a rule for return traffic too.Glossary entry, keeping sessions and data in services such as ElastiCache, DynamoDB, RDS, or S3, so any instance can be replaced.

A three-tier web application in a VPC across two Availability Zones. Users connect over HTTPS to an Application Load Balancer in public subnets in both zones. It sends requests to an Auto Scaling group of EC2 app servers in private subnets, one in each zone, with a minimum of 2, desired capacity of 2, and maximum of 6. The app servers use an Amazon RDS Multi-AZ database: the primary in zone A handles reads and writes and replicates synchronously to a standby in zone B that takes no traffic until a failover. With ELB health checks turned on, the Auto Scaling group replaces an instance that fails the load balancer health check.

Performance

Bake software into a golden AMI, use warm pools, or use predictive scaling when instances take long to become ready.
Use target tracking on a metric that reflects load per instance, such as CPU or requests per target.

Cost

EC2 Auto Scaling is free; you pay for the EC2 instances, EBS volumes, and CloudWatch alarms it uses.
Scale in when demand drops, mix in Spot for Fault toleranceThe ability of a system to keep working without interruption when a component fails, because enough redundant capacity is already running. It goes further than high availability, which may allow a short failover.Glossary entry capacity, and cover the steady minimum with Savings Plans.

Monitoring

Group metrics in CloudWatch, such as GroupDesiredCapacity, GroupInServiceInstances, and GroupPendingInstances, are available every minute at no charge, but you must enable them.
Scaling activities show why each instance was launched or terminated.
Amazon EventBridge receives events for successful and failed launches and terminations, and lifecycle actions; AWS CloudTrail records API (Application programming interface)A defined way for one program to ask another for data or actions, such as a set of HTTPS requests and responses. Every AWS service is controlled through its API, which the console, the CLI, and the SDKs call for you.Glossary entry calls.

Auto Scaling or another service?

If the requirement is	Choose
Keep a fleet of EC2 instances healthy and sized to demand	Amazon EC2 Auto Scaling
Scale other resources, such as ECS services, DynamoDB tables, or Aurora replicas	Application Auto Scaling
Distribute traffic across the instances	Elastic Load Balancing
Scale code without managing instances	AWS Lambda
Recover a single instance on failed hardware	EC2 automatic instance recovery

Reverse mindmap: when the question points here

Is it EC2 Auto Scaling?

Yes, when the question says
- Replace failed instances automatically leads to Auto Scaling group with health checks
- Instances stay up but the application is unhealthy leads to Turn on ELB health checks
- Survive the loss of an Availability Zone leads to Group across several Availability Zones
- Full capacity at once after losing one of N zones leads to Size the group to needed × N ÷ (N − 1)
- Single instance that must self-heal across zones leads to Group with min, max, and desired of 1
Choose the scaling policy
- Keep CPU around 50% leads to Target tracking
- Scale on requests to the load balancer leads to Target tracking on ALBRequestCountPerTarget
- Traffic rises every weekday morning leads to Scheduled or predictive scaling
- Workers reading an SQS queue leads to Target tracking on backlog per instance
Customize the lifecycle
- Install software before serving traffic leads to Launch lifecycle hook
- Copy logs before an instance terminates leads to Termination lifecycle hook
- Long boot time slows scale-out leads to Warm pool or golden AMI
- Roll out a new AMI to the group leads to Instance refresh
Save money
- Mix On-Demand and Spot in one group leads to Mixed instances policy
- Replace Spot Instances at risk of interruption leads to Capacity Rebalancing
- Protect an instance running a long job leads to Scale-in protection

Key takeaways

An Auto Scaling group keeps desired capacity between minimum and maximum, across several Availability Zones, and replaces unhealthy instances.
Target tracking is the default choice; step for graded responses, scheduled for known times, predictive for repeating patterns.
Turn on ELB health checks; use lifecycle hooks for custom launch and termination actions.
Mixed instances policies combine On-Demand and Spot; Capacity Rebalancing replaces Spot Instances before interruption.
Instance refresh rolls out changes; warm pools speed up scale-out; Auto Scaling itself is free.