Amazon EC2 Auto Scaling: Availability, Scaling Policies, and Health Checks – SAP-C02 Study Guide

Purpose of This Lesson

Amazon EC2 Auto Scaling helps applications maintain the required amount of compute capacity while responding to changing demand and replacing unhealthy instances. An Auto Scaling Group (ASG) can scale horizontally by launching additional EC2 instances or terminating surplus instances.

For the SAP-C02 exam, understand how ASGs work with Amazon CloudWatch, Elastic Load Balancing (ELB), Amazon VPC, launch templates, and health checks. The key architectural goals are availability, elasticity, operational automation, and cost control.

Key Concepts

Auto Scaling Groups

An Auto Scaling Group defines the fleet of instances that should be maintained. Its principal capacity settings are:

• Minimum capacity: The fewest instances the group should run.
• Desired capacity: The target number of instances under normal conditions.
• Maximum capacity: The upper limit to prevent unbounded scaling and unexpected cost.

If an instance becomes unhealthy, the ASG attempts to terminate it and launch a replacement. If demand rises, the group can scale out; when demand falls, it can scale in.

An ASG is associated with subnets in one or more Availability Zones. Deploying across multiple Availability Zones improves resilience, provided the application and load-balancing design also support multi-AZ operation.

Launch Templates

A launch template defines how new instances are created. It can specify:

• Amazon Machine Image (AMI)
• Instance type
• EBS volumes
• Security groups
• IAM instance profile
• User data and bootstrap configuration
• Network settings
• Purchase options such as On-Demand or Spot Instances

Launch templates are the preferred modern mechanism. Launch configurations are a legacy alternative with fewer capabilities and should generally not be selected for new designs.

A launch template standardizes replacement and scale-out instances. If an application requires fast and consistent provisioning, bake the application and dependencies into a custom AMI or use carefully designed user data and configuration automation.

CloudWatch-Driven Scaling

EC2 publishes monitoring metrics to Amazon CloudWatch. Auto Scaling policies can use these metrics to adjust capacity. Common signals include:

• Average CPU utilization
• Application load balancer request count per target
• Network throughput
• Custom application metrics

A CloudWatch alarm can invoke an ASG scaling policy when a threshold is breached. However, threshold-based alarms are not the only scaling mechanism, and a single CPU threshold is not always a reliable representation of application demand.

EC2 monitoring affects metric frequency:

• Basic monitoring: Metrics generally available at five-minute intervals.
• Detailed monitoring: Metrics generally available at one-minute intervals for an additional charge.

Faster metrics can improve response time but do not eliminate instance launch, initialization, registration, and application warm-up delays.

Scaling Policy Types

#### Manual scaling

An operator changes the desired capacity directly. This is useful for controlled interventions but does not provide automatic demand response.

#### Dynamic scaling

Dynamic policies respond to observed metrics:

• Target tracking: Attempts to maintain a target value, such as average CPU utilization of 50% or a target request count per target. This is usually the simplest default for continuously varying demand.
• Step scaling: Applies different capacity adjustments based on how far a metric breaches a threshold.
• Simple scaling: Uses a single adjustment and cooldown behavior; it is generally less flexible than target tracking or step scaling.

#### Scheduled scaling

Scheduled actions change capacity at known times, such as increasing capacity before a predictable weekday traffic peak. Scheduled scaling is appropriate when the demand pattern is known in advance.

#### Predictive scaling

Predictive scaling uses historical usage patterns and machine learning to forecast future demand and schedule capacity changes. It is useful for recurring patterns but should be validated against actual workload behavior.

Dynamic and scheduled or predictive scaling can be combined. For example, scheduled or predictive scaling can prepare capacity for a known peak, while dynamic scaling handles unexpected variation.

Health Checks and Replacement

ASGs use EC2 status checks to determine whether an instance has an underlying system or instance failure. An ASG can also use ELB health checks when the instances serve traffic through a load balancer.

The distinction matters:

• EC2 health checks: Detect infrastructure-level or instance-level status-check failures.
• ELB health checks: Test whether the application endpoint is responding correctly from the load balancer’s perspective.

Enabling ELB health checks allows the ASG to replace an instance that is running at the EC2 level but is not serving the application correctly.

The health check grace period gives a newly launched instance time to boot, execute user data, install software, and become ready. If it is too short, healthy instances may be replaced prematurely. If it is too long, genuinely failed instances may remain in service longer than desired.

Health checks alone do not guarantee a correct replacement. The instance must also bootstrap reliably, register with the load balancer, obtain required IAM permissions, and access its dependencies.

Elastic Load Balancing Integration

When an ASG launches or terminates instances, the associated target group is updated automatically. The load balancer can then route requests to newly healthy targets and stop routing traffic to unhealthy or terminating targets.

This integration supports both availability and elasticity, but it does not make an application stateful design safe automatically. Session state, uploaded files, and other shared data should be externalized when instances can be replaced or scaled in.

VPC and Availability Zones

An ASG launches instances into configured subnets within a VPC. For resilient production architectures:

• Use subnets in multiple Availability Zones.
• Ensure each subnet has sufficient IP capacity.
• Use private subnets for application instances when public internet access is unnecessary.
• Provide NAT gateways or VPC endpoints where private instances need access to AWS services or external repositories.
• Verify that the load balancer, route tables, security groups, and network ACLs support the intended traffic flow.

An ASG does not automatically make a workload multi-AZ if it is configured with subnets from only one Availability Zone.

Exam-Relevant Takeaways

• An ASG maintains capacity within configured minimum, desired, and maximum limits.
• ASGs replace unhealthy instances and can scale in or out based on policies.
• Use a launch template for current EC2 Auto Scaling designs; launch configurations are legacy.
• EC2 status checks detect infrastructure or instance health problems; ELB health checks can detect application failures.
• Configure a health check grace period long enough for bootstrapping and application startup.
• Use multiple Availability Zones for high availability, not merely a larger instance count in one zone.
• Target tracking is often the most direct answer when the requirement is to maintain a metric near a target.
• Scheduled scaling is useful for predictable traffic patterns; predictive scaling uses historical patterns to anticipate demand.
• Set a maximum capacity to control cost and protect against runaway scaling.
• Choose the metric that reflects demand. CPU utilization may be a poor scaling signal for I/O-bound or queue-driven applications.
• ASGs can use Spot Instances for cost optimization, but workloads must tolerate interruption and replacement.
• Load balancer registration and health checks are essential when automatically changing the instance fleet.

Architecture Decision Guide

Requirement	Recommended approach	Important considerations
Maintain a fixed number of instances	Set minimum, desired, and maximum capacity appropriately	This provides replacement, but not demand-based scaling
Keep average CPU near a target	Target tracking policy	Select a meaningful target and allow time for instances to initialize
Apply different actions for different alarm severities	Step scaling	Useful when small and large breaches require different adjustments
Increase capacity before known business peaks	Scheduled scaling	Schedule enough lead time for instance launch and application readiness
Anticipate recurring traffic patterns	Predictive scaling	Requires representative historical metrics and monitoring
Detect an application that is running but not serving traffic	Enable ELB health checks for the ASG	Configure an accurate target group health endpoint
Replace failed infrastructure automatically	EC2 health checks	Does not test application-level functionality
Minimize cost for interruptible batch or stateless work	Include Spot capacity, often through a mixed instances policy	Use diversification and ensure interruption tolerance
Maintain application availability during an AZ failure	Configure subnets across multiple AZs	Check capacity, routing, load balancing, and data-layer resilience
Standardize new and replacement instances	Use a launch template and versioned AMIs	Test user data, IAM permissions, and startup dependencies

Common Exam Traps

• Confusing desired capacity with maximum capacity: Desired capacity is the current target; maximum capacity is the scaling ceiling.
• Assuming an ASG distributes across all AZs automatically: It only uses the subnets and AZs configured for it.
• Using EC2 health checks for application failure detection: EC2 status checks do not verify that the application endpoint works.
• Choosing a very short grace period: Bootstrapping and registration may not complete before health evaluation begins.
• Assuming scaling is instantaneous: New instances need to launch, initialize, pass health checks, and register with the load balancer.
• Scaling only on CPU by default: CPU is not always correlated with request volume, queue depth, latency, or throughput.
• Treating Auto Scaling as a replacement for load balancing: The ASG changes fleet capacity; ELB distributes traffic and performs target health checks.
• Selecting launch configurations for a new design: Launch templates provide the current feature set and are the preferred choice.
• Ignoring scale-in data loss: Locally stored sessions or files can disappear when an instance is terminated.
• Setting no maximum capacity: A faulty metric, application issue, or unexpected traffic pattern can cause excessive instance launches and cost.

Real-World Engineer Notes

• Design instances to be disposable. Store durable data in services such as Amazon S3, Amazon EFS, or an appropriate database rather than on instance-local storage.
• Make bootstrap operations idempotent. A replacement instance may run the same initialization logic repeatedly.
• Use lifecycle hooks when initialization or graceful shutdown requires additional coordination. For example, an instance can be held in a pending state while it registers with configuration management, or drain connections before termination.
• Use a load balancer health endpoint that checks meaningful application readiness, not just whether a web process is listening.
• Allow for warm-up time in scaling policies. Scaling too aggressively can create oscillation; scaling too slowly can cause latency during a surge.
• Monitor scaling activities, instance launch failures, insufficient subnet IP addresses, failed health checks, and capacity errors.
• For Spot capacity, use diversified instance types and Availability Zones where possible, and retain On-Demand capacity for critical baseline availability.
• Consider warm pools or prebuilt AMIs when instance startup time is a significant part of the availability or scaling requirement.

Quick Reference Summary

• ASG purpose: Maintain, replace, and elastically scale EC2 capacity.
• Capacity controls: Minimum, desired, and maximum.
• Instance definition: Launch template, preferably with a versioned AMI.
• Scaling signals: CloudWatch metrics, schedules, and predictive forecasts.
• Health signals: EC2 status checks and optional ELB health checks.
• Resilience: Configure subnets in multiple Availability Zones.
• Traffic distribution: Attach an ELB target group so healthy instances receive requests.
• Cost control: Scale in when demand falls, cap maximum capacity, and consider Spot for suitable workloads.
• Operational priority: Make startup, health checks, connection draining, and state management reliable.

Flashcards

1. Q: What does an EC2 Auto Scaling Group maintain?

A: A fleet of EC2 instances within configured minimum, desired, and maximum capacity limits.

1. Q: What happens when an ASG instance fails an EC2 status check?

A: The ASG can terminate the unhealthy instance and launch a replacement.

1. Q: Why use ELB health checks with an ASG?

A: They allow the ASG to detect application-level failures that EC2 status checks may not detect.

1. Q: What is the preferred replacement for a launch configuration?

A: An EC2 launch template.

1. Q: What is target tracking designed to do?

A: Adjust ASG capacity to maintain a selected metric near a target value.

1. Q: When is scheduled scaling appropriate?

A: When demand increases or decreases at predictable times.

1. Q: What is the purpose of a health check grace period?

A: To allow a newly launched instance to boot and become ready before health evaluation affects replacement decisions.

1. Q: Why configure an ASG across multiple Availability Zones?

A: To reduce dependence on a single AZ and improve application availability.

1. Q: What is the role of desired capacity?

A: It specifies the number of instances the ASG should currently try to maintain.

1. Q: Why can CPU utilization be a poor scaling metric?

A: Some workloads are constrained by request rate, latency, memory, network, or queue depth rather than CPU.

1. Q: What does predictive scaling use?

A: Historical usage patterns and forecasting to schedule capacity for expected demand.

1. Q: What is a key requirement when using Spot Instances in an ASG?

A: The workload must tolerate interruptions and instance replacement.

Practice Questions

Question 1

A web application runs on EC2 instances behind an Application Load Balancer. Instances sometimes remain in service according to EC2 status checks, but the application process has deadlocked and returns errors. The solution must automatically replace these instances. What should the architect do?

Correct answer: Configure an ELB target group health check and enable ELB health checks for the Auto Scaling Group.

Explanation: EC2 status checks detect underlying instance and system problems, not all application failures. ELB health checks test the application endpoint and can provide failure information to the ASG for replacement.

Question 2

A retail application has predictable traffic increases every weekday at 08:00. New instances take several minutes to initialize. The architect wants capacity available before the increase begins while retaining the ability to handle unexpected demand. Which design is most appropriate?

Correct answer: Use scheduled or predictive scaling to increase baseline capacity before 08:00, combined with dynamic scaling for unexpected changes.

Explanation: Scheduled scaling handles known demand patterns ahead of time. Dynamic scaling provides a reactive safety mechanism for demand that differs from the forecast.

Question 3

A company configures an ASG with a minimum of two, desired capacity of four, and maximum of eight instances. A scaling policy is triggered while four instances are running. What is the maximum number of instances the policy can request?

Correct answer: Eight.

Explanation: The maximum capacity is the upper boundary. The desired capacity is the current target and may be increased by a scaling policy, but it cannot exceed the configured maximum.

Question 4

An ASG launches replacement instances, but the load balancer marks them unhealthy before their application startup script completes. The instances are repeatedly terminated and relaunched. What is the most likely corrective action?

Correct answer: Increase the ASG health check grace period and ensure the load balancer health check accurately represents application readiness.

Explanation: The grace period prevents premature replacement during startup. The health check should also target a reliable readiness endpoint and allow sufficient time for initialization.

Question 5

A stateless batch workload can tolerate interruption. The company wants to reduce compute cost while maintaining a minimum amount of reliable capacity. Which EC2 Auto Scaling design best fits?

Correct answer: Use a mixed instances policy with a baseline of On-Demand capacity and additional diversified Spot capacity.

Explanation: On-Demand instances provide dependable baseline capacity, while Spot Instances reduce cost for interruptible work. Diversification across instance types and Availability Zones can reduce interruption and capacity risks.