LinkedIn
Cut cross-zone networking costs without sacrificing reliability
High Availability Zonal Load Balancing (HAZL) keeps Kubernetes traffic in-zone to cut cross-zone data transfer charges, and sends it across zones the moment reliability needs it. The cost win without the outage risk.
Why your cross-zone bill is so high?
Cloud providers bill for traffic that crosses an availability-zone boundary, charged in each direction. Kubernetes spreads traffic as evenly as it can across pods, so in a typical 3-zone cluster about two-thirds of your traffic crosses a zone boundary and gets billed for it.
~$300/yr
$100K–$1M+/yr
Every byte that crosses a zone boundary gets billed twice, once leaving, once arriving.
AWS $0.02/GB | GCP $0.01/GB | Azure≈ $0/GB
Up to 60% less egress
~$400K/yr saved
HAZL keeps traffic zone-local, eliminating most cross-zone hops before they're billed.
Based on published AWS/GCP rates. 60% reduction reflects observed HAZL deployments. Read the full analysis ↗
What you get with HAZL
HAZL (High Availability Zonal Load Balancing) is a request-level load balancer in Buoyant Enterprise for Linkerd. It balances HTTP and gRPC traffic in environments with multiple availability zones.
In-zone by default
HAZL keeps traffic in-zone under normal load, cutting the cross-zone bytes you're billed for.
Reliability preserved
It spills cross-zone the moment load or errors demand it, then pulls back, so cost never costs you uptime.
No tuning in most cases
Works with fewer than 3 pods per zone, imbalanced traffic, and autoscaling.
0% to ~100% on the same failure
In Buoyant's demo, Topology Aware Routing dropped a zone to 0% success; HAZL held near 100%.
How does HAZL work?
Topology Aware Routing (used by open-source Linkerd and Istio) keeps traffic in-zone with a static allocation that ignores live load, latency, and health, and is binary on or off. HAZL is a request-level load balancer in Buoyant Enterprise for Linkerd (BEL) that keeps traffic local when it safely can and adds cross-zone endpoints only when local load climbs, then removes them as load drops.
Zone-aware load balancing with HAZL
Under normal load HAZL keeps requests in-zone; when the in-zone endpoint is overloaded or returning errors, it spills to another zone, then returns in-zone as load recovers.
Stop paying for traffic you don't need to
Most teams turn HAZL on with no tuning and watch steady-state cross-zone traffic drop while reliability holds. Run the demo, then point it at a real cluster and measure against your own bill.
What it doesn't
✗ Drops to 0% in-zone under failure
✗ Requires ≥3 balanced pods per zone
✗ No health-based spill logic
✗ Struggles with autoscaling
✓ Free, no license needed
✓ Built into Kubernetes
What it covers
✓ Never sacrifices reliability
✓ Works with <3 pods per zone
✓ In-band health checking (HTTP/gRPC)
✓ Reads HTTP 429 as a spill signal
✓ ~1 min recovery after overload
✓ No tuning required in most cases
Why HAZL
1. Cost
2. Reliability
3. Simplicity
Cuts cost and protects reliability
HAZL is a "request-level load balancer in Buoyant Enterprise for Linkerd that balances HTTP and gRPC traffic in environments with multiple availability zones," and unlike Topology Aware Routing "never sacrifices reliability to achieve this cost reduction."
It reacts to real load
HAZL balances on outstanding requests per endpoint and prefers local endpoints, adding cross-zone only when local load climbs. It uses in-band health checking, and reads rate-limit responses: an in-zone endpoint returning HTTP 429 is a reason to spill rather than a fast success (a BEL feature) In the same failure that dropped Topology Aware Routing to 0%, HAZL held near 100%.
It works where TAR struggles
Fewer than 3 pods per zone, imbalanced traffic, autoscaling, and "requires no tuning or configuration" in most cases. It also preserves zone affinity across cluster boundaries.
1. Cost
Cuts cost and protects reliability
HAZL is a "request-level load balancer in Buoyant Enterprise for Linkerd that balances HTTP and gRPC traffic in environments with multiple availability zones," and unlike Topology Aware Routing "never sacrifices reliability to achieve this cost reduction."
2. Reliability
It reacts to real load
HAZL balances on outstanding requests per endpoint and prefers local endpoints, adding cross-zone only when local load climbs. It uses in-band health checking, and reads rate-limit responses: an in-zone endpoint returning HTTP 429 is a reason to spill rather than a fast success (a BEL feature) In the same failure that dropped Topology Aware Routing to 0%, HAZL held near 100%.
3. Simplicity
It works where TAR struggles
Fewer than 3 pods per zone, imbalanced traffic, autoscaling, and "requires no tuning or configuration" in most cases. It also preserves zone affinity across cluster boundaries.
Show me the evidence
Every claim is backed by a reproducible demo, a published cost model, and a CNCF track record.
Reproducible demo
Run it on a 3-zone local cluster and watch HAZL hold success rate where Topology Aware Routing drops it to 0%.
Lorem ipsum Published cost model
The cost figures above are from Buoyant's published AWS model — open for review.
Frequently asked questions
What does HAZL do?
It balances HTTP and gRPC requests to keep traffic in-zone for cost savings, while sending it cross-zone when reliability requires it.