Reliability and Continuity · Topic 1 of 5
Auto Scaling and Elasticity
Build elastic workloads with EC2 Auto Scaling groups, scaling policies, lifecycle hooks and warm pools, and know how Lambda and DynamoDB scale for SOA-C03.
- 5 min
- An ASG has minimum, desired and maximum capacity and uses a launch template.
- Spread the group across at least two Availability Zones for resilience.
- Enable ELB health checks on the ASG when it sits behind a load balancer.
What it is
Scalability means a system can handle more load by adding resources. Elasticity means it also removes them when load falls, so you pay only for what you need.
On EC2 (Elastic Compute Cloud), an Auto Scaling group (ASG) is the main tool. It keeps a number of instances running, replaces unhealthy ones, and adds or removes instances based on rules.
How it works
Group settings
An ASG has a minimum, desired and maximum size. It launches instances from a launch template, which names the AMI (Amazon Machine Image), instance type, security groups and more. The group spans subnets in several Availability Zones and balances instances between them.
Health checks decide when to replace an instance. The default is the EC2 status check. If the group is attached to a load balancer, turn on ELB health checks too, so an instance that fails the application check is replaced.
Scaling policies
| Policy | How it behaves | Use when |
|---|---|---|
| Target tracking | Keeps a metric near a target, such as 50 percent average CPU | Most cases, simplest to run |
| Step scaling | Adds or removes different amounts depending on alarm size | You need finer control of response |
| Simple scaling | One adjustment per alarm, then waits for a cooldown | Older style, rarely the best answer |
| Scheduled | Changes capacity at set times | Known patterns, such as business hours |
| Predictive | Forecasts load from history and scales ahead of it | Regular daily or weekly cycles |
# AWS CLI: keep average CPU near 50 percent
aws autoscaling put-scaling-policy \
--auto-scaling-group-name web-asg \
--policy-name cpu50 \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'A target tracking policy for a web tier often uses the request count per target from an Application Load Balancer, because it follows demand more directly than CPU. Instance warmup tells the group how long a new instance takes to start contributing metrics, so it does not scale again too early.
Lifecycle hooks and warm pools
A lifecycle hook pauses an instance while it launches or terminates so you can run custom actions. Examples are installing software before the instance takes traffic, or draining logs before it is removed.
A warm pool keeps pre initialised instances ready, which shortens scale out time for applications with a long start up.
Replacing and protecting instances
- Instance refresh rolls out a new launch template version by replacing instances in batches.
- Scale in protection stops chosen instances from being terminated by scale in.
- Standby takes an instance out of service for maintenance without it being replaced.
- Termination policies pick which instance goes first on scale in. The default aims to keep zones balanced.
Scaling outside EC2
AWS Lambda scales by creating more execution environments as requests arrive, within concurrency limits. Amazon DynamoDB has on demand mode, or provisioned mode with Application Auto Scaling that adjusts read and write capacity. Aurora can add or remove read replicas with Application Auto Scaling, and ECS services can scale their task count the same way.
When scaling does not work
If instances do not launch, check these:
- The launch template references an AMI, key pair or security group that no longer exists.
- The account has reached an instance quota, or the chosen type has no capacity in that zone.
- The subnets have no free IP addresses.
- The instance profile or encryption key permissions block the launch.
The activity history of the ASG shows the failure reason.
For a stateless web tier, the best exam answer is usually an ASG across several Availability Zones behind a load balancer, with a target tracking policy.
What to remember for the exam
- An ASG has minimum, desired and maximum capacity and uses a launch template.
- Spread the group across at least two Availability Zones for resilience.
- Enable ELB health checks on the ASG when it sits behind a load balancer.
- Target tracking is the simplest policy and the usual best answer.
- Scheduled scaling suits predictable peaks, and predictive scaling learns repeating patterns.
- Lifecycle hooks pause launch or termination for custom actions.
- Warm pools shorten scale out time for slow starting applications.
- Instance refresh replaces instances after a launch template change.
- Application Auto Scaling covers DynamoDB, Aurora replicas and ECS services.
Common mistakes
Relying on EC2 health checks only. An instance can be running while its application is dead. ELB health checks catch that.
Scaling on a metric that does not reflect load. CPU is a poor signal for a memory bound or queue driven workload.
Setting maximum too low. The group cannot grow past its maximum, however high the load.
Ignoring warmup. Without a sensible warmup the group may overshoot and launch too many instances.
Forgetting the group is only one Availability Zone. A group in one zone is not resilient, even with a load balancer.
A scale in policy that terminates instances holding session data can log users out. Store sessions outside the instance, for example in ElastiCache or DynamoDB.
Check yourself
Try these questions.
Which policy type keeps a metric close to a chosen value with the least setup?
Target tracking.
How can you run a script before a new instance receives traffic?
Use a lifecycle hook on the launch event, which pauses the instance until the action completes.
Why enable ELB health checks on an ASG?
So instances that fail the application level check behind the load balancer are replaced, not only those that fail EC2 status checks.
Topic 1 of 5 in Reliability and Continuity
Test yourself on Reliability and Continuity
The full AWS SOA-C03 question bank has 850 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by AWS. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.