Keep Istio Traffic Within the Same Region with Locality-Aware Load Balancing (2026)

Istio’s locality-aware load balancing isn’t just about picking the closest healthy pod; it’s fundamentally about minimizing latency and cost by keeping traffic within the same geographic region whenever possible.

Let’s see this in action. Imagine we have a simple frontend service talking to a backend service.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: backend
spec:
  host: backend
  trafficPolicy:
    loadBalancer:
      localityLbSetting:
        enabled: true
        distribute:
        - from:
          - us-east-1
          enableFailover: true
          to:
          - us-east-1:50
        - from:
          - us-west-2
          enableFailover: true
          to:
          - us-west-2:50

Here, we’ve configured backend to prefer traffic within its own region. If a frontend pod in us-east-1 needs to reach backend, it will only consider backend pods also in us-east-1. If us-east-1 backend pods are unavailable, then it will consider failing over to us-west-2. The distribute section shows a 50/50 split if we had multiple zones within a region, but the core idea is regional affinity.

The Problem: Latency and Cost of Cross-Region Calls

When services are deployed across multiple cloud regions (e.g., us-east-1 and us-west-2), default load balancing might send a request from a frontend in us-east-1 to a backend in us-west-2. This introduces unnecessary latency due to the physical distance the data travels. More importantly, most cloud providers charge significantly for data transfer between regions. For a high-traffic application, these costs can skyrocket.

How Istio Does It: The Envoy Sidecar and DestinationRule

Istio leverages Envoy, the high-performance proxy that runs as a sidecar alongside your application pods. When a request leaves your application, it first hits the Envoy sidecar. This sidecar is configured by Istio’s control plane (specifically, the istiod component) via DestinationRule resources.

The DestinationRule tells Envoy how to load balance traffic to a specific service. For locality-aware load balancing, the key is the localityLbSetting.

• localityLbSetting.enabled: true: This flag tells Envoy to consider the "locality" (region and zone) of both the source pod and the destination pods.
• localityLbSetting.distribute: This is where the magic happens. It’s a list of rules that define how traffic should be distributed based on the source locality.
  • Each entry in distribute has a from field, specifying the source locality (e.g., us-east-1).
  • It also has a to field, which is a list of destination localities and their desired traffic percentage.
  • enableFailover: true is crucial; it means if no healthy endpoints are found in the preferred to locality, Envoy will attempt to find endpoints in other localities.

Istio automatically annotates your pods with their region and zone labels (e.g., topology.kubernetes.io/region=us-east-1). When istiod programs Envoy, it reads these labels and constructs the localityLbSetting configurations to match your DestinationRule. Envoy then uses this information during the request routing phase to select the most appropriate destination pod.

Configuration Levers

1. DestinationRule: The primary configuration point.

   • host: The service you’re configuring.
   • trafficPolicy.loadBalancer.localityLbSetting.enabled: Turn it on.
   • trafficPolicy.loadBalancer.localityLbSetting.distribute: Define your regional preference.
     • from: Source region.
     • to: Destination region(s) and their weight.
     • enableFailover: Whether to cross regions if local is unavailable.

2. Pod Labels: Ensure your Kubernetes nodes and pods are correctly labeled with topology.kubernetes.io/region and topology.kubernetes.io/zone. These are typically populated automatically by cloud providers or your Kubernetes distribution. If not, you’ll need to add them.

3. Istio Control Plane (istiod): istiod is responsible for reading your DestinationRule and pod labels, and then generating the correct Envoy configuration.

The Nuance: Failover Behavior and Load Distribution

When enableFailover: true, Envoy will first try to send traffic to endpoints in the same region as the source pod. If there are no healthy endpoints in that region, it will then attempt to send traffic to endpoints in other regions. The distribute list dictates the initial preference. If you have multiple distribute entries for the same source region, Envoy will pick one based on the order and the available endpoints. The weights in the to field determine the proportion of traffic sent to each destination locality if multiple are available and preferred. For instance, if from: us-east-1 has two to entries: us-east-1:70 and us-west-2:30, and us-east-1 has healthy endpoints, 70% of traffic will go to us-east-1 endpoints and 30% to us-west-2 endpoints. However, if us-east-1 has no healthy endpoints, all traffic will then be directed to us-west-2 (assuming enableFailover is true for the us-west-2 entry or a general failover is configured).

The next step is understanding how to manage egress traffic from your mesh.