Study guide
Technical reference and lesson notes
Purpose of This Lesson
Cross-zone load balancing determines whether an Elastic Load Balancing (ELB) node sends requests only to targets in its own Availability Zone or to healthy registered targets across all enabled Availability Zones.
This setting is especially important when target counts differ between Availability Zones. Without cross-zone balancing, each load balancer node distributes traffic locally, which can create uneven target utilization even when the load balancer itself receives traffic evenly across Availability Zones.
Key Concepts
Load balancer nodes and Availability Zones
When an Elastic Load Balancer is configured for multiple Availability Zones, AWS provisions load balancer nodes in the selected subnets. Clients send traffic to the load balancer, and the nodes route requests to registered, healthy targets in their target groups.
The effect of cross-zone load balancing depends on the scope of each node’s target selection:
- Disabled: A node routes traffic only to healthy targets in its own Availability Zone.
- Enabled: A node can route traffic to healthy registered targets in all enabled Availability Zones.
This setting does not change where the load balancer nodes are deployed. It changes how those nodes select targets.
Traffic distribution without cross-zone balancing
Assume two Availability Zones receive equal amounts of incoming traffic:
- Availability Zone A has three targets.
- Availability Zone B has two targets.
- Each load balancer node receives approximately 50% of the total traffic.
- Cross-zone load balancing is disabled.
The node in Availability Zone A distributes its 50% among three targets, giving each approximately 16.7% of total traffic. The node in Availability Zone B distributes its 50% among two targets, giving each approximately 25% of total traffic.
The target count is uneven, so the targets do not receive equal traffic overall.
Traffic distribution with cross-zone balancing
With cross-zone load balancing enabled, both nodes can distribute requests across all five healthy targets. Assuming equivalent target capacity and request weighting, each target receives approximately 20% of the total traffic.
Cross-zone balancing can therefore improve utilization when:
- Target counts differ between Availability Zones.
- Auto Scaling has temporarily created different numbers of instances in each zone.
- Capacity is intentionally distributed unevenly.
- One Availability Zone has fewer healthy targets than another.
Service defaults
The important default behavior for the exam is:
- Application Load Balancer (ALB): Cross-zone load balancing is always enabled.
- Network Load Balancer (NLB): Cross-zone load balancing is disabled by default and can be enabled.
- Gateway Load Balancer (GWLB): Cross-zone load balancing is disabled by default and can be enabled.
Always verify the behavior and current service documentation when designing a production solution, but these defaults are central to common SAP-C02 scenarios.
Relationship to Auto Scaling
An EC2 Auto Scaling group generally attempts to maintain an even distribution of instances across enabled Availability Zones. As a result, cross-zone balancing may not be necessary when:
- The Auto Scaling group is balanced across zones.
- Instances have equivalent capacity.
- The application is not sensitive to moderate differences in request volume.
However, temporary imbalance can occur during scale-out, scale-in, instance replacement, impaired Availability Zones, or capacity constraints. Cross-zone balancing can reduce the impact of these situations for supported load balancers.
Exam-Relevant Takeaways
- Cross-zone load balancing is a traffic distribution feature, not a mechanism for deploying load balancer nodes into more Availability Zones.
- With the feature disabled, each load balancer node routes only to targets in its own Availability Zone.
- With the feature enabled, nodes can route to healthy targets across all enabled Availability Zones.
- ALB always has cross-zone load balancing enabled.
- NLB and GWLB have it disabled by default.
- Uneven target counts can produce uneven per-target traffic when cross-zone balancing is disabled.
- Cross-zone balancing can cause requests to cross Availability Zone boundaries.
- For NLB and GWLB, evaluate the additional cross-AZ data transfer and data processing cost implications before enabling the feature.
- Cross-zone balancing does not eliminate the need for multi-AZ deployment, health checks, capacity planning, or application resiliency.
- The relevant balancing scope is the set of healthy, registered targets. Unhealthy targets are not expected to receive normal load-balanced traffic.
Architecture Decision Guide
| Situation | Preferred approach | Reasoning |
|---|---|---|
| ALB distributes requests across EC2 targets in multiple Availability Zones | Use the default behavior | ALB cross-zone load balancing is always enabled. |
| NLB has equal target capacity in every Availability Zone and minimizing cross-AZ traffic is important | Leave cross-zone balancing disabled unless requirements dictate otherwise | Each node keeps traffic local, which can reduce cross-AZ data transfer. |
| NLB target counts or capacity differ significantly between Availability Zones | Consider enabling cross-zone balancing | Traffic can be distributed across the full healthy target population. |
| GWLB appliances are unevenly distributed across zones | Consider cross-zone balancing after cost and appliance-state analysis | It may improve utilization, but appliance traffic flows and cross-AZ costs must be evaluated. |
| An Auto Scaling group is normally balanced but temporarily uneven during scaling | Use the load balancer behavior that best matches the cost and utilization requirements | Temporary imbalance may be acceptable, or cross-zone balancing may smooth utilization. |
| A strict Availability Zone locality requirement exists | Keep cross-zone balancing disabled where configurable | Local routing avoids sending traffic to targets in another zone. |
Common Exam Traps
- Assuming every ELB type has the same default: ALB, NLB, and GWLB differ. ALB is always cross-zone enabled; NLB and GWLB are disabled by default.
- Confusing node distribution with target distribution: Enabling cross-zone balancing does not move or add load balancer nodes. It expands the target selection scope of each node.
- Assuming equal traffic to load balancer nodes guarantees equal traffic to targets: Without cross-zone balancing, unequal target counts can still create unequal per-target traffic.
- Ignoring cross-AZ cost: Cross-zone routing may improve utilization but can introduce additional regional data transfer and service-specific processing costs, particularly for NLB and GWLB designs.
- Treating cross-zone balancing as a resiliency feature by itself: It can help route around target imbalance, but high availability still requires healthy targets and load balancer nodes in multiple Availability Zones.
- Forgetting target health: Cross-zone balancing distributes among eligible healthy targets, not every registered target regardless of health.
- Assuming Auto Scaling always makes the issue irrelevant: Auto Scaling generally attempts zone balance, but deployments can be temporarily or persistently uneven because of capacity, lifecycle, or zonal failure conditions.
Real-World Engineer Notes
- Cross-zone balancing is most valuable when target capacity is uneven, not merely when the architecture spans multiple Availability Zones.
- For stateful or zonally optimized workloads, local routing may be preferable even if it produces modestly uneven utilization.
- For stateless applications, broader target selection is usually easier to operate, provided the application tolerates cross-AZ requests.
- Check whether the target application uses zonal caches, local storage, or stateful connections before enabling cross-zone routing.
- Monitor per-target request counts, latency, error rates, and cross-AZ data transfer rather than relying only on aggregate load balancer metrics.
- If one Availability Zone loses targets, disabled cross-zone balancing can leave the surviving node handling traffic only for its local targets, depending on the load balancer and failure behavior. Design health checks and capacity margins for this case.
- When using NLB or GWLB, compare the cost of cross-AZ traffic with the operational cost of keeping target capacity evenly distributed.
Quick Reference Summary
- Disabled: Each load balancer node sends traffic to local healthy targets only.
- Enabled: Each node can send traffic to healthy targets in all enabled Availability Zones.
- ALB: Always enabled.
- NLB: Disabled by default; configurable.
- GWLB: Disabled by default; configurable.
- Main benefit: More even target utilization when Availability Zone target populations differ.
- Main tradeoff: Potential cross-AZ traffic, cost, latency, and loss of strict zonal locality.
Flashcards
- Q: What does cross-zone load balancing control?
A: Whether each load balancer node can route to targets in all enabled Availability Zones or only to targets in its own Availability Zone.
- Q: Is cross-zone load balancing always enabled for an ALB?
A: Yes. ALB cross-zone load balancing is always enabled.
- Q: What is the default NLB cross-zone setting?
A: Disabled by default, but it can be enabled.
- Q: What is the default GWLB cross-zone setting?
A: Disabled by default, but it can be enabled.
- Q: Why can disabled cross-zone balancing cause uneven target traffic?
A: Each node distributes only its local share of traffic among local targets, so zones with fewer targets give each target a larger share.
- Q: Does enabling cross-zone balancing deploy additional load balancer nodes?
A: No. It changes target selection; node placement is still determined by the load balancer’s enabled subnets and Availability Zones.
- Q: Which targets receive cross-zone traffic?
A: Eligible healthy targets registered with the relevant target group.
- Q: What is a key cost concern with cross-zone balancing?
A: Traffic may cross Availability Zone boundaries, potentially increasing regional data transfer and service-specific processing charges.
- Q: Does an Auto Scaling group guarantee perfectly equal target traffic?
A: No. It generally attempts to balance instance counts across zones, but temporary or persistent capacity differences can occur.
- Q: When might disabled cross-zone balancing be intentional?
A: When strict zonal locality, lower cross-AZ cost, or zonally optimized application behavior is more important than perfectly even target utilization.
Practice Questions
Question 1
An organization uses an Application Load Balancer across two Availability Zones. One zone has three healthy EC2 targets and the other has two. The architect wants requests distributed across all healthy targets rather than limited by the local target population. Which statement is correct?
A. Enable cross-zone load balancing on the ALB.
B. Add a second target group in each Availability Zone.
C. Enable cross-zone load balancing on the Auto Scaling group.
D. Replace the ALB with a Gateway Load Balancer.
Correct answer: A
Explanation: ALB cross-zone load balancing is always enabled. The ALB can distribute requests across healthy targets in both Availability Zones; no additional setting is required.
Question 2
A company uses an NLB with equal traffic arriving at nodes in two Availability Zones. Zone A has three targets, and Zone B has two. Cross-zone load balancing is disabled. Which result is most likely?
A. Every target receives exactly 20% of total traffic.
B. Each target in Zone A receives approximately 16.7% and each target in Zone B approximately 25% of total traffic.
C. All traffic is sent to the targets in Zone A because it has more targets.
D. The NLB automatically moves targets between Availability Zones.
Correct answer: B
Explanation: Each node first receives its local share of traffic and then distributes that traffic among local targets. With equal node traffic, three targets split Zone A’s 50%, while two targets split Zone B’s 50%.
Question 3
A workload uses an NLB and has substantially more appliance capacity in one Availability Zone than another. The architect wants to improve utilization across all healthy appliances but must also control cross-AZ data transfer costs. What is the best approach?
A. Enable cross-zone load balancing without evaluating costs.
B. Disable health checks so all registered appliances receive traffic.
C. Evaluate enabling cross-zone load balancing, including cross-AZ cost and appliance-flow behavior.
D. Add public IP addresses to the appliances.
Correct answer: C
Explanation: Cross-zone balancing may smooth utilization across the full target set, but NLB designs must account for cross-AZ transfer, processing charges, latency, and appliance traffic behavior.
Question 4
A multi-AZ Auto Scaling group is usually balanced, but during scale-out one Availability Zone temporarily has fewer instances. The application is stateless and the team prioritizes even utilization over strict zonal locality. Which consideration is most relevant?
A. Cross-zone load balancing can reduce uneven per-instance traffic during the imbalance.
B. Auto Scaling prevents any temporary difference in instance counts.
C. Cross-zone load balancing changes the number of Availability Zones used by the Auto Scaling group.
D. Cross-zone load balancing routes only to unhealthy targets during scale-out.
Correct answer: A
Explanation: Cross-zone balancing allows load balancer nodes to use healthy targets across zones, which can smooth traffic when target counts are temporarily uneven. It does not alter Auto Scaling group placement or target health behavior.
Question 5
A security-sensitive application requires requests to remain within the originating Availability Zone whenever possible, and target capacity is evenly distributed. Which configuration is most aligned with this requirement for a configurable load balancer?
A. Enable cross-zone load balancing.
B. Disable cross-zone load balancing.
C. Remove all health checks.
D. Register targets from only one Availability Zone.
Correct answer: B
Explanation: Disabling cross-zone balancing keeps each node’s target selection local, supporting zonal locality. The design must still provide sufficient healthy capacity in every enabled Availability Zone.