2.3 EC2 Auto Scaling, Target Tracking & Health Checks
Design elastic compute architectures using EC2 Auto Scaling Groups, Application Load Balancers, Target Tracking policies, and cross-zone traffic balancing.
🎯 Key AWS SAA-C03 Architectural Takeaways
- Target Tracking Scaling policies automatically add or remove instances to maintain a specific metric value, such as ALBRequestCountPerTarget or average CPU utilization.
- Changing the ASG Health Check Type from EC2 to ELB ensures the Auto Scaling Group replaces instances failing HTTP application health checks even if hypervisor checks pass.
- Cross-Zone Load Balancing on Network Load Balancers distributes traffic evenly across all backend targets in all enabled AZs, preventing unbalanced instance utilization.
- Auto Scaling Group launch templates define instance configuration, AMI, IAM profile, user data, and security groups with versioning support.
Horizontal elasticity allows cloud applications to match compute capacity directly to real-time user demand. Amazon EC2 Auto Scaling Groups (ASGs) automatically maintain fleet availability by launching instances across multiple Availability Zones according to launch templates and scaling policies.
Target Tracking Scaling policies operate like a thermostat. Instead of defining static thresholds, architects configure a target metric—such as maintaining 1,000 requests per target instance via ALBRequestCountPerTarget. The Auto Scaling service automatically calculates the necessary instance count and scales out or in dynamically to maintain stable workload density.
Instance health verification requires application-level awareness. By default, Auto Scaling Groups only perform EC2 status checks (verifying hardware, network connectivity, and kernel responsiveness). If an Apache or Node.js process deadlocks with HTTP 500 errors, EC2 checks report OK. Configuring the ASG Health Check Type to 'ELB' enables the load balancer's HTTP health checks to dictate instance lifecycle, automatically terminating and replacing failed targets.
When traffic arrives at load balancers, Cross-Zone Load Balancing ensures optimal distribution. For Network Load Balancers, cross-zone load balancing routes connections across all registered instances across all enabled AZs. Without cross-zone balancing, each NLB node only routes to local targets, causing severe utilization imbalances if one AZ contains fewer instances.
⚠️ Common Pearson VUE / AWS Exam Traps
- Leaving ASG health checks set to EC2 only — if a web server software process crashes but the OS stays alive, the ASG will never replace the broken instance.
- Using Simple Scaling with fixed instance steps during volatile traffic spikes — Target Tracking scales out proportionally to load faster.
- Attempting to stretch a single EBS volume across multiple Availability Zones to support Auto Scaling instances without a shared file system like EFS.
A web application experiences sudden, unpredictable surges in traffic during flash marketing campaigns. The application is CPU-bound, but CPU utilization alone is too lagging of an indicator to prevent HTTP 504 gateway timeout errors during rapid spikes. The architect wants the EC2 Auto Scaling Group to dynamically scale out proportional to incoming request volume. Which scaling policy is most appropriate?