What does cross-zone load balancing do in Elastic Load Balancing, and how does its default differ between an Application Load Balancer and a Network Load Balancer?

## The mechanism Enabling an Availability Zone on a load balancer creates a load balancer **node** in that zone with its own address. The load balancer's DNS name resolves to one address per enabled zone, and clients pick among them — with DNS round robin plus caching, that lands close to an even split **per zone**, not per target. Cross-zone load balancing decides what a node does next: - **Disabled** — a node forwards only to targets registered in its own zone. Traffic per zone is even; traffic per target is even only if every zone holds the same number of targets. - **Enabled** — every node forwards to every healthy target in every enabled zone. Traffic per target is even regardless of how targets are distributed. The classic illustration: 10 targets, 2 in `eu-west-1a` and 8 in `eu-west-1b`, with cross-zone off. Each zone's node receives about 50% of requests, so each `1a` target handles about 25% and each `1b` target about 6.25% — a fourfold imbalance created purely by placement. ## The defaults, per load balancer type - **Application Load Balancer** — cross-zone is on and cannot be disabled at the load balancer level. Since late 2023 it can be disabled **per target group** with the attribute `load_balancing.cross_zone.enabled`, whose values are `true`, `false` and `use_load_balancer_configuration`. - **Network Load Balancer** and **Gateway Load Balancer** — off by default; you enable it on the load balancer, and it can also be set per target group. ```bash aws elbv2 modify-target-group-attributes --target-group-arn "$TG_ARN" \ --attributes Key=load_balancing.cross_zone.enabled,Value=false ``` ## Cost, which is the part people miss For an ALB, traffic sent across Availability Zones by the load balancer is not charged as inter-AZ data transfer. For an NLB with cross-zone enabled, it is — regular inter-AZ data-transfer rates apply to the traffic the load balancer sends to targets in another zone. On a high-throughput NLB fronting a chatty internal service, that line item is easy to notice on the bill and easy to miss when planning. This asymmetry is the single most-quoted fact about the setting, and it is why NLB ships with cross-zone off. ## The availability argument Cost is not the only reason to leave it off. With cross-zone disabled, a request that entered through the `1a` node is served by a `1a` target: a failure confined to one zone — a bad deploy that only reached that zone's instances, a zonal dependency outage, a saturated zonal cache — stays confined to the clients that resolved to that zone's node. Cross-zone enabled means every node can send traffic into the sick zone, so a zonal problem becomes a fleet-wide error rate. This is the reasoning behind zonal-isolation architectures and behind zonal shift, which moves traffic away from an impaired zone by withdrawing that zone's load balancer node from DNS. The cost of that isolation is the imbalance above, plus reduced headroom: with cross-zone off, each zone must independently hold enough capacity to serve its share, so you cannot borrow idle capacity from a neighbour during a spike. ## Making the choice Keep it enabled when target counts per zone are uneven or change unpredictably, when the fleet is small enough that per-target imbalance matters, or when you value smooth utilisation over isolation. Turn it off when zonal blast-radius containment is an explicit goal, when the inter-AZ bill on an NLB is material, or when you have deliberately built independent per-zone stacks — and in that case make sure your Auto Scaling group or service scheduler actually balances targets evenly across zones, because without cross-zone that even placement is what keeps per-target load even. ## A related detail Disabling cross-zone also changes health semantics slightly: with it off, a zone whose targets are all unhealthy has no healthy target for its own node to use, and the clients that resolved to that node are affected specifically. Watch `HealthyHostCount` **per Availability Zone**, not just in aggregate — the aggregate looks fine right up until one zone empties.