SAA-C03 - Design High-Performing Architectures (24% of the exam) - Section 3.4

Improve performance through load distribution and scaling using Elastic Load Balancing, Auto Scaling and placement groups.

Describe how Elastic Load Balancing spreads traffic across healthy targets and integrates with Auto Scaling to add or remove capacity in response to demand. Compare EC2 placement group strategies - cluster for low-latency HPC, spread for fault isolation, and partition for large distributed systems - and explain how connection draining allows in-flight requests to complete before an instance is deregistered.

Elastic Load BalancingAuto ScalingPlacement groupsConnection draining

Practice question for this objective

Free sampleDesign High-Performing Architecturesmedium

An Application Load Balancer spans two Availability Zones, and cross-zone load balancing is currently disabled on its target group. One zone has eight registered targets and the other has only two because an Auto Scaling event left the zones uneven. Operators see the two targets in the smaller zone running far hotter than the eight in the larger zone, because each Availability Zone receives an equal share of requests that is then divided among only the targets in that zone. The team wants every healthy target across both zones to receive a roughly equal share of requests regardless of how many targets each zone holds. Which configuration achieves this?

AAttach the targets to a Network Load Balancer instead, because its per-flow hashing automatically equalises the request load across all targets in every Availability Zone by default.
BRe-enable cross-zone load balancing on the target group so every request is distributed evenly across all healthy registered targets regardless of which zone each target is in. Correct
CConfigure an Auto Scaling target tracking policy on CPU so the hotter zone gains instances, which over time evens out the target count between the two Availability Zones during peaks.
DCreate a weighted target group routing rule that sends more traffic to the smaller zone, manually compensating for its lower target count so its instances stop running hotter than the rest.

Enable cross-zone load balancing so requests are spread evenly across all targets when Availability Zones hold uneven target counts. For an Application Load Balancer, cross-zone load balancing is set per target group and is on by default. With it disabled, the load balancer splits traffic evenly per zone, so a zone with fewer targets overloads each one. Re-enabling it distributes each request across all healthy targets in every zone, equalising the per-target load.

Why A is wrong: Network Load Balancer disables cross-zone balancing by default, so it would still keep traffic within each zone and overload the two targets in the smaller zone just as the current setup does.

Why B is correct: Cross-zone load balancing spreads each request across all healthy targets in every zone, so the two targets in the smaller zone receive the same per-target share as the eight in the larger zone.

Why C is wrong: Scaling on CPU may add instances, but it does not change how the load balancer divides requests between zones, so the imbalance recurs whenever the zones drift apart in target count.

Why D is wrong: Manual weighting is brittle and breaks every time Auto Scaling changes the per-zone counts, so it cannot keep the per-target share equal as the fleet shifts the way cross-zone balancing does.

See more SAA-C03 practice questions, answers explained.

Exam traps in Design High-Performing Architectures

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAA-C03 bank for this domain.

Enable sticky sessions on the target group so each download stays bound to one instance and is therefore protected from being interrupted during scale-in.
Why it is wrong: Sticky sessions only pin a client to the same target for the life of a session; they do nothing to keep in-flight requests alive when that target is deregistered, so the download is still dropped.
Increase the Auto Scaling group health check grace period so the group waits longer before evaluating the new instance, giving the preparation step time to finish on its own.
Why it is wrong: The grace period only delays health evaluation; the instance is still registered and marked in service immediately, so the load balancer sends traffic before the cache is warm and users still see errors.
Launch the Auto Scaling group's instances into a single cluster placement group so they sit close together and absorb the morning surge with lower inter-instance latency.
Why it is wrong: Cluster placement groups optimise inter-node network latency for tightly coupled workloads, not health detection or pre-emptive scaling, and packing into one rack would reduce Availability Zone resilience.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.