ESA supports three load balancing policies — failover steering, weighted steering, and geo steering — so you can route traffic based on availability, load, or geographic location.
Policy types
Edge Security Acceleration (ESA) supports three load balancing policies. Use the following table to choose the right one for your use case.
|
Policy |
Best for |
Traffic distribution |
|
Failover steering |
High availability, data consistency |
Routes all traffic to the highest-priority pool; fails over to the next pool only when the primary is unhealthy |
|
Weighted steering |
Distributing load across multiple clusters, A/B testing, canary deployments |
Splits traffic across pools based on assigned weights |
|
Geo steering |
International or regional traffic routing |
Routes requests to pools based on the user's country or region |
Failover steering
Failover steering is the default policy. Assign a priority to each origin pool — all traffic goes to the highest-priority pool. If that pool fails its health check or is disabled, ESA automatically routes traffic to the healthy pool with the next highest priority. When the primary pool recovers and passes its health check, traffic automatically returns to it.
Weighted steering
Use weighted steering to distribute traffic across multiple origin server clusters — for example, to balance load under high concurrency or to run a canary deployment.
Assign a weight from 1 to 100 to each origin pool. Edge Security Acceleration (ESA) routes traffic proportionally based on these weights. For example, if Pool A has a weight of 70 and Pool B has a weight of 30, Pool A receives 70% of requests and Pool B receives 30%.
Set the weight of an origin pool to 0 to stop routing traffic to it without removing the pool.
Geo steering
Use geo steering to route international or regional traffic to origin pools closest to your users.
Route requests to different origin pools based on the user's country or region. Typically, all origin servers in a single pool are co-located in the same country or region. For the full list of supported regions, see Load balancing global region definitions.
When you configure a secondary region, it takes precedence over the primary region.
Session persistence and retry
Session persistence
Session persistence is disabled by default. Enable it for stateful applications where a single user session must stay on the same origin server throughout its duration.
Without session persistence, a user's requests can reach different origin servers on each round trip — causing issues like lost login state or an empty shopping cart. With session persistence enabled, ESA consistently routes requests from the same client to the same origin server, maintaining session state and data integrity.
Retry
When a connection to an origin server fails, ESA retries the request according to the configured retry policy. Two policies are available.
Retry within an origin pool (default): Retries the request with a different server in the same origin pool.
Retry across origin pools: Routes the request to the origin pool with the next highest priority and retries with a healthy server in that pool.