Azure Front Door Active-Active routing not distributing traffic evenly between two AKS regions

Question

Azure Front Door Active-Active routing not distributing traffic evenly between two AKS regions

Patel, Jayeshkumar 0

Hi Microsoft Azure Community,

We have an Azure Front Door Premium setup for an Active-Active application deployed in two Azure regions:

Region 1: East US 2
Region 2: Central US
Both regions have identical application workloads running on private AKS clusters
Traffic flow is approximately:

Client → Azure Front Door → Private Link → Regional Load Balancer → AKS workload

We configured Azure Front Door with both regional origins enabled and are trying to achieve an Active-Active configuration with approximately 50% / 50% traffic distribution between the two regions.

However, we are observing that most of the traffic is being routed to the East US 2 region, while Central US receives significantly less traffic.

Current Front Door configuration

Both origins are healthy.
Both origins have the same priority.
Both origins have the same weight.
We are using weighted routing for the Active-Active configuration.
Weight: 50 / 50
Health probes are successful for both origins.
Sample size: 4
Successful samples required: 3
Latency sensitivity: 500 ms
Session affinity is not intended to be used for this scenario.

We have verified the backend/application side and can see that the traffic distribution is not approximately 50/50.

Expected behavior

For an Active-Active deployment, we expect both regions to actively receive traffic, approximately:

East US 2 → ~50%
Central US → ~50%

Observed behavior

Instead, a significantly higher percentage of requests are reaching East US 2.

We understand that Azure Front Door first evaluates origin health and latency, and that weights are applied to the origins that are selected based on the latency-sensitivity configuration.

According to the Azure Front Door documentation, weighted routing should distribute traffic according to the configured weights when the origins are within the configured latency-sensitivity range.

Questions:

With two healthy origins configured with the same priority and 50/50 weights, should we expect approximately 50/50 traffic distribution when latency sensitivity is set to 500 ms?
Could Front Door's latency measurements between its individual POPs and the two regional origins cause one region to receive significantly more traffic even when the weights are equal?
Is there a recommended Front Door configuration for achieving Active-Active 50/50 regional traffic distribution?
Are there any additional Front Door settings, such as latency sensitivity, origin priority, session affinity, or health-probe configuration, that we should change?
How can we determine from Azure Front Door logs/metrics which origin-selection decision caused a request to be routed to East US 2 instead of Central US?
Are there any known limitations where equal weights do not result in approximately equal regional traffic distribution for this type of architecture?

We would appreciate guidance on the correct Azure Front Door configuration for a two-region Active-Active AKS architecture with approximately 50/50 traffic distribution.

Thanks, JayeshHi Microsoft Azure Community,

We have an Azure Front Door Premium setup for an Active-Active application deployed in two Azure regions:

Region 1: East US 2
Region 2: Central US
Both regions have identical application workloads running on private AKS clusters
Traffic flow is approximately:

Client → Azure Front Door → Private Link → Regional Load Balancer → AKS workload

We configured Azure Front Door with both regional origins enabled and are trying to achieve an Active-Active configuration with approximately 50% / 50% traffic distribution between the two regions.

However, we are observing that most of the traffic is being routed to the East US 2 region, while Central US receives significantly less traffic.

Current Front Door configuration

Both origins are healthy.
Both origins have the same priority.
Both origins have the same weight.
We are using weighted routing for the Active-Active configuration.
Weight: 50 / 50
Health probes are successful for both origins.
Sample size: 4
Successful samples required: 3
Latency sensitivity: 500 ms
Session affinity is not intended to be used for this scenario.

We have verified the backend/application side and can see that the traffic distribution is not approximately 50/50.

Expected behavior

For an Active-Active deployment, we expect both regions to actively receive traffic, approximately:

East US 2 → ~50%
Central US → ~50%

Observed behavior

Instead, a significantly higher percentage of requests are reaching East US 2.

We understand that Azure Front Door first evaluates origin health and latency, and that weights are applied to the origins that are selected based on the latency-sensitivity configuration.

According to the Azure Front Door documentation, weighted routing should distribute traffic according to the configured weights when the origins are within the configured latency-sensitivity range.

Questions:

With two healthy origins configured with the same priority and 50/50 weights, should we expect approximately 50/50 traffic distribution when latency sensitivity is set to 500 ms?
Could Front Door's latency measurements between its individual POPs and the two regional origins cause one region to receive significantly more traffic even when the weights are equal?
Is there a recommended Front Door configuration for achieving Active-Active 50/50 regional traffic distribution?
Are there any additional Front Door settings, such as latency sensitivity, origin priority, session affinity, or health-probe configuration, that we should change?
How can we determine from Azure Front Door logs/metrics which origin-selection decision caused a request to be routed to East US 2 instead of Central US?
Are there any known limitations where equal weights do not result in approximately equal regional traffic distribution for this type of architecture?

We would appreciate guidance on the correct Azure Front Door configuration for a two-region Active-Active AKS architecture with approximately 50/50 traffic distribution.

Thanks,
Jayesh

Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-14T07:04:38.58+00:00

Hi Patel, Jayeshkumar,

Based on the configuration shared, equal origin weights do not guarantee a strict global 50/50 traffic distribution in Azure Front Door. Origin selection is influenced by multiple factors, including origin health, latency evaluation, and request routing through distributed Front Door POPs.

With both origins configured with the same priority and weight, Azure Front Door first evaluates origin health and latency, and then applies weights across the eligible origins. As a result, traffic distribution may not always appear as an exact 50/50 split, even when both origins are healthy.

To better understand the observed behavior, it can be helpful to review Azure Front Door metrics and diagnostic logs, including origin health status and request distribution patterns. This can provide additional visibility into how routing decisions are being made across the configured origins.
Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-24T02:43:10.85+00:00

Hello ,

Hope you are doing well !

I just wanted to follow up on my previous email, hope you had a chance to go through it, if so do let us know, so that we can move ahead accordingly.

Please feel free to let us know if you have any queries or concerns and we will be happy to assist you.

Awaiting your response.
Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-26T03:48:01.63+00:00

Hello ,

Hope you are doing well !

I just wanted to follow up on my previous email, hope you had a chance to go through it, if so do let us know, so that we can move ahead accordingly.

Please feel free to let us know if you have any queries or concerns and we will be happy to assist you.

Awaiting your response.

2 answers

Your answer

Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-14T07:04:38.58+00:00

Hi Patel, Jayeshkumar,

Based on the configuration shared, equal origin weights do not guarantee a strict global 50/50 traffic distribution in Azure Front Door. Origin selection is influenced by multiple factors, including origin health, latency evaluation, and request routing through distributed Front Door POPs.

With both origins configured with the same priority and weight, Azure Front Door first evaluates origin health and latency, and then applies weights across the eligible origins. As a result, traffic distribution may not always appear as an exact 50/50 split, even when both origins are healthy.

To better understand the observed behavior, it can be helpful to review Azure Front Door metrics and diagnostic logs, including origin health status and request distribution patterns. This can provide additional visibility into how routing decisions are being made across the configured origins.
Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-24T02:43:10.85+00:00

Hello ,

Hope you are doing well !

I just wanted to follow up on my previous email, hope you had a chance to go through it, if so do let us know, so that we can move ahead accordingly.

Please feel free to let us know if you have any queries or concerns and we will be happy to assist you.

Awaiting your response.
Bhavani Kamidi 0 Reputation points Microsoft External Staff

2026-08-26T03:48:01.63+00:00

Hello ,

Hope you are doing well !

I just wanted to follow up on my previous email, hope you had a chance to go through it, if so do let us know, so that we can move ahead accordingly.

Please feel free to let us know if you have any queries or concerns and we will be happy to assist you.

Awaiting your response.

Answer 1

Hello @Patel, Jayeshkumar

What you're observing can be expected with Azure Front Door, even when both origins have the same priority and equal weights.

Azure Front Door doesn't apply the 50/50 weight globally before making any other routing decision. Origin selection happens in stages:

Front Door removes unhealthy origins.

It selects origins at the highest available priority.

It evaluates origin latency from the Front Door POP handling the request.

Only origins within the configured latency sensitivity range remain eligible.

The configured weights are then applied across those eligible origins.

Microsoft documents this behavior in the Front Door traffic-routing algorithm.

Therefore, setting both origins to priority 1 and equal weights means equal weighting among origins that are eligible for a particular Front Door location, not a guaranteed global 50/50 traffic split.

With your current 500-ms latency sensitivity, both East US 2 and Central US would normally remain candidates if their measured latency difference is within that range. However, Front Door operates across distributed POPs, and routing decisions aren't made by one centralized load balancer maintaining a global 50/50 counter.

Microsoft also specifically notes that, particularly at low request rates, Front Door cannot guarantee that configured weights will be strictly followed because requests are handled across distributed Front Door POPs and machines.

For your configuration, I would recommend:

Keep both origins at the same priority.
Keep the origins at equal weight (for example, 1000/1000; the ratio is what matters).
Keep session affinity disabled if you don't require sticky sessions. Session affinity intentionally keeps subsequent requests from a client on the initially selected origin and can therefore make the observed distribution less even.
Verify that both origins remain healthy from Front Door's perspective, not just from the AKS/application side.
Test distribution using a sufficiently large request volume and, ideally, clients from multiple locations rather than traffic from a single client/location.

I wouldn't reduce latency sensitivity to 0 ms to try to force 50/50 distribution. Microsoft states that when latency sensitivity is zero, weights only take effect when origins have identical measured network latency. That can actually make one origin dominate more often.

For troubleshooting, enable Azure Front Door diagnostic logging and review the Origin Health Percentage metric and health probe logs. Microsoft specifically recommends the health-probe logs when traffic unexpectedly reaches only a subset of configured origins; these can identify whether an origin was considered unhealthy during the affected period.

One useful test would be to compare:

Request count reaching East US 2

Request count reaching Central US

Origin Health Percentage for each origin

Health probe failures

Client/POP geographic distribution

over the same time interval.

If both origins consistently show healthy status, session affinity is disabled, the test contains a sufficiently large number of requests, and you're still seeing something extreme such as 90/10 or 95/5 over a sustained period, I would open an Azure support case. Microsoft can inspect Front Door's backend telemetry to determine whether the imbalance is coming from POP-level origin selection, latency measurements, or another service-side condition.

So, to your main question: 50/50 weights should produce approximately equal distribution across eligible origins over a sufficiently large and representative traffic sample, but Azure Front Door doesn't provide a strict global 50/50 guarantee.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Answer 2

Allan Solomon Mejia 6,240

Hello @Patel, Jayeshkumar

Please let us know if you need any further assistance. Otherwise, if the information provided resolved your issue, please click “Accept Answer” to help others who may encounter the same problem.

Thank you!

0 comments