LinkedIn
Cut cross-zone networking costs without sacrificing reliability
High Availability Zonal Load Balancing (HAZL) keeps Kubernetes traffic inside an availability zone while the endpoints there are healthy, and sends it across zones the moment load or errors demand it. Reduce your data transfer bill without betting uptime on a static routing rule.
The causes of high cross-zone bills
AWS and GCP bill traffic that crosses an availability-zone boundary, in each direction: $0.02/GB on AWS and $0.01/GB on GCP. Kubernetes spreads requests 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
~$30 /yr
$10K+ / yr
HAZL keeps traffic zone-local, eliminating most cross-zone hops before they're billed.
AWS $0.02/GB | GCP $0.01/GB | Azure≈ $0/GB
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 (BEL). 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
When in-zone endpoints are overloaded or returning errors, HAZL adds cross-zone endpoints, then removes them as load recovers. Cost savings never come at the price of failed requests.
No tuning in most cases
Works with fewer than 3 pods per zone, imbalanced traffic, and autoscaling – the situations where Topology Aware Routing can’t help.
Near 100% success rate
In our published demo, HAZL held at near 100% success for the same zone failure that took Topology Aware Routing to a 0% success rate.
How does HAZL work?
Topology Aware Routing, the Kubernetes-native mechanism available to all clusters and meshes, keeps traffic in-zone with a static allocation. It can't see live load, latency, or endpoint health, and it's either on or off.
HAZL balances load based on outstanding requests per endpoint. It prefers in-zone endpoints, adds cross-zone endpoints only when local load climbs, and drops them as load recedes. It also runs in-band health checks and treats an HTTP 429 from an in-zone endpoint as a reason to cross zones, rather than a fast success.
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
HAZL requires no tuning in most cases: enable it, watch steady-state cross-zone traffic drop, and measure the result against your own bill. The true answer to "how much will I save?" is to model it against your traffic and your costs, which we can help with when you contact us.
Without HAZL in place
✗ Drops to 0% in-zone under failure
✗ Requires ≥3 balanced pods per zone
✗ Can't act on L7 success metrics
✗ Struggles with autoscaling
✓ Free, no license needed
✓ Built into Kubernetes
With HAZL in place
✓ 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 use HAZL?
1
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. Since HAZL acts at L7, it never sacrifices reliability to achieve this cost reduction: HAZL can keep success rates near 100% even when entire clusters fail.
2
It reacts to real load
HAZL balances load on outstanding requests per endpoint and prefers local endpoints, adding cross-zone endpoints only when local load climbs. It uses in-band health checking and understands rate limiting: an in-zone endpoint returning HTTP 429 is a reason to cross zones rather than a fast success.
3
It works where TAR can’t help
Fewer than three pods per zone, imbalanced traffic, autoscaling, and "requires no tuning or configuration" in most cases. It also preserves zone affinity across cluster boundaries.
Linkerd customers realize huge cost savings
Linkerd helps customers with large mutli-zone deployments save money on cross-zone traffic costs while preserving reliability. Check out our case studies to learn more.
Trusted in production
Trusted in production by Tradeshift, Expel and teams at Walmart, HP, and Expedia.
Outages caught before impact
loveholidays caught hundreds of failed deployments before they became outages, using SLIs and SLOs built on Linkerd's metrics.
40% networking cost reduction
Imagine Learning cut cross-zone networking costs by 40% while keeping reliability rock-solid across hundreds of thousands of daily users.
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.