The difference in one sentence
Elastic Load Balancing distributes incoming traffic; EC2 Auto Scaling manages how many instances run. A load balancer does not fix insufficient application capacity merely by spreading requests more evenly. A scaling group does not provide an HTTP entry point merely by launching servers.
| Requirement | Load balancer | EC2 Auto Scaling |
|---|---|---|
| Receive and distribute traffic | Routes requests to registered targets | Not the application entry point |
| Increase or decrease instances | Does not launch application servers | Adjusts group capacity within configured limits |
| Application health | Checks target readiness for routing | Can use ELB health results for replacement when enabled |
| Availability Zone resilience | Serves targets across enabled zones | Distributes group capacity across configured zones |
For HTTP/HTTPS routing decisions, first compare ALB, NLB and Gateway Load Balancer. Then decide how the target fleet should scale.
How a resilient web tier combines both
Consider an illustrative online-learning application. An ALB is the public entry point, while an Auto Scaling group runs stateless web instances in private subnets across two Availability Zones. The ALB target group is attached to the scaling group, so registration follows instance launches and terminations automatically.
Keep shared session and durable application state outside replaceable instances. Plan enough surviving capacity for a zone failure; a two-zone configuration alone does not prove that one zone can handle the entire workload. Test recovery behavior and launch constraints rather than treating a diagram as an availability guarantee.
Choose minimum, desired and maximum capacity deliberately. A group with no headroom below its maximum cannot add enough servers during a peak, even when its scaling signal is correct.
Choose a metric that represents work per instance
Target tracking aims to keep an appropriate utilization or throughput metric near a target. Average CPU can suit a CPU-bound service; ALBRequestCountPerTarget can suit a web tier when request volume represents useful per-target demand. Total RequestCount is different: adding servers does not reduce the number of incoming requests, so it is not a suitable direct target-tracking metric.
Illustrative capacity calculation—not a production recommendation
Suppose load testing shows one instance can sustainably process 600 comparable requests per minute with acceptable latency. At 1,800 requests per minute, three instances are a starting estimate. Add headroom and validate the request mix, downstream limits and failure tolerance. Actual scaling is not an instantaneous division operation: metric periods, warmup, capacity limits and launch time affect the result.
A database bottleneck may not improve when more web instances are added. Compare latency, errors and resource saturation before concluding that the fleet is too small.
Health check grace period, readiness and warmup
Health check grace period
Allows initialization time after an instance enters service before health results cause premature replacement. It does not suspend ALB probes. An instance leaving the EC2 running state can still be replaced during this period.
Default instance warmup
Accounts for startup stabilization in scaling decisions. New-instance metrics can otherwise distort aggregate group metrics. Choose it from measured initialization behavior; it is not a switch that makes an application ready.
The ALB target check should use the correct port, path and success criteria. A process can be running while the application cannot serve requests. Inspect target-health reason codes instead of assuming EC2 status checks cover the application.
Important exception: do not claim an ALB always routes only to healthy targets. AWS documents fail-open behavior when a target group contains only unhealthy registered targets. Application health and alarms must remain operational priorities.
Worked example: the application is unhealthy, but the instance remains
Illustrative scenario, not a claimed customer incident: one web process stops. The ALB reports that target unhealthy, but EC2 status checks pass and the group keeps the instance. The engineer expected the scaling group to replace it automatically.
- Confirm the symptom: examine target-health reasons, the health endpoint and application logs.
- Check the integration: verify the intended target group is attached and that ELB health checks are enabled for the Auto Scaling group.
- Correct the design: enable the appropriate application-health signal for replacement and set a measured grace period for normal startup.
- Validate safely: repeat a controlled failure in a non-production environment and check replacement, registration and readiness.
If every replacement fails identically, investigate the launch template, deployment artifact, network path or shared dependency. Replacing identical broken instances repeatedly is not a resolution. Record the root cause and add a release check that detects it earlier.
What should you remember for SAA-C03?
- Traffic distribution and instance-count management are complementary, not interchangeable.
- More instances help only when the bottleneck can scale horizontally.
- Readiness, health-based replacement and warmup control different decisions.
- Resilience needs capacity and failure testing, not just multiple Availability Zones.
Practice: traffic triples, all existing targets are healthy, and web CPU is saturated. Is a new load balancer the best first answer?
No. The described gap is web-tier capacity. Evaluate an appropriate scaling policy and group limits while checking downstream constraints. A second load balancer does not add application processing capacity.
Practice: EC2 reports healthy, but the application endpoint fails. What should you inspect before replacing the scaling policy?
Inspect application health, the target-group attachment and whether the group uses ELB health checks. A demand-scaling policy is not the same control as unhealthy-instance replacement.
Continue with the free SAA-C03 mock exam, review the SAA-C03 learning path, or check AWS exam voucher requirements. Practice questions are independent learning material, not live or recalled exam items.
Questions answered
Does a load balancer add EC2 instances?
No. It distributes traffic among registered targets. EC2 Auto Scaling manages instance capacity; attaching the target group lets new group instances register automatically.
Will an Auto Scaling group automatically replace every unhealthy ALB target?
Not by default based on ELB health alone. Enable Elastic Load Balancing health checks on the group so application-level health can trigger replacement, and configure an appropriate health check grace period.
Is the health check grace period the same as instance warmup?
No. Grace period protects newly in-service instances from premature health-based replacement. Warmup accounts for startup stabilization in scaling decisions and aggregated instance metrics. Neither replaces the application's readiness check.
Which request metric is suitable for target tracking?
ALBRequestCountPerTarget can represent per-instance throughput. Total load balancer RequestCount is not proportional to group size and is not suitable as a direct target-tracking utilization metric.
Official sources and further reading
- AWS: Load balancing with an Auto Scaling group
- AWS: Auto Scaling architecture benefits
- AWS: Target tracking scaling policies
- AWS: Health check grace period
- AWS: Default instance warmup
- AWS: ALB target group health checks
Use current AWS documentation and the official exam guide as the final authority. This page is independent ITCertPath study guidance.