Blog Post

Azure Networking Blog
4 MIN READ

Redefining Application Load Balancing in Azure Application Gateway

vnamani's avatar
vnamani
Icon for Microsoft rankMicrosoft
Nov 11, 2026

By Jay Soni (Senior Product Manager) and Jordi Rey (Product Manager), Azure Application Gateway

Advanced routing rules and advanced load balancing in Azure Application Gateway

Modern applications change quickly. Teams run A/B experiments, version their APIs, tailor experiences by client and tenant, and serve AI models across reserved and pay-as-you-go capacity. Azure Application Gateway now gives you more precise control over where each request goes and how traffic is distributed once it gets there.

Two new capabilities are now in public preview. Use them on their own or together:

  • Advanced routing rules: Match requests on path, header, query string, HTTP method and client IP, with regular expression support. A single rule can now cover request patterns that previously needed several.
  • Advanced load balancing: Choose backend pools by weight or priority, then choose servers within each pool using round robin, weighted round robin or least connections.

The rest of this post explains how these capabilities work and the scenarios they enable, from blue-green deployments and client-aware experiences to multi-tenant SaaS and a single entry point for your AI endpoints.

What's new

CapabilityDetails
What a rule can matchPath, HTTP header, query string, HTTP method and client IP
How values are matchedExact values, or RE2 regular expressions for path, header and query string
How conditions combineUp to five conditions per rule, joined with AND and evaluated in priority order
Load balancing across poolsMultiple pools per rule, selected by weight or by priority
Load balancing within a poolRound robin, weighted round robin or least connections, set per pool
Failover between poolsPriority-based failover driven by a configurable Minimum Healthy Percent

Advanced routing rules: more control over request routing

Define conditions on URL paths, HTTP headers, query strings, HTTP methods and client IP addresses to send each request to the right backend pool. Combine conditions in one rule to support scenarios such as API versioning, tenant-specific routing and feature-based deployments. Rules are evaluated in priority order, and the first matching rule determines the destination. Requests that don't match any rule go to the configured default backend pool.

Path, header and query-string conditions support RE2 regular expressions, so a single pattern can match many request variations. For example, ^/api/orders(/.*)?$ matches /api/orders and all of its subpaths. Each rule can also apply a rewrite rule set as part of routing.

Advanced load balancing: traffic distribution that fits your workload

Advanced load balancing gives you control at two levels:

  • Across pools: Use weighted distribution to split traffic by relative weight, such as 80/20 for a gradual rollout. Or use priority to keep traffic on a primary pool and fail over to the next pool when the primary pool's healthy servers drop below your Minimum Healthy Percent.
  • Within a pool: Each pool uses its own algorithm. Round robin spreads requests evenly. Weighted round robin sends more requests to larger servers. Least connections sends each request to the healthy server with the fewest active connections, so a server still working through long-running requests receives less new traffic.

Figure 1: Advanced routing rules match the request; advanced load balancing selects a pool by weight or priority, then a server within the pool

Figure 1. Advanced routing rules match the request. Advanced load balancing then selects a pool by weight or priority, and a server within that pool.

Scenarios you can build

Canary and blue-green releases

Route requests that carry an x-release: canary header to a new version, or send 10% of all traffic to the green pool and raise its weight as confidence grows. Taking a pool out of rotation is a weight change, not a redeployment, and your customer-facing endpoint never changes.

Read/write split

Send GET requests to a pool of read replicas or cache-heavy nodes, and send POST, PUT and DELETE requests to the primary write tier.

Client-aware experiences

Route mobile clients to an optimized backend based on a client header such as x-client-type: mobile or a User-Agent pattern, while web traffic continues to the standard pool.

Internal and partner traffic

Route requests from corporate or partner IP ranges to dedicated backend pools, such as staging or administrative environments. Combine client IP-based routing with Web Application Firewall (WAF) protection and appropriate authentication and authorization controls to help secure access to these applications.

Multi-tenant SaaS

Route by tenant hostname to dedicated pools for premium tenants and shared pools for everyone else. Tenant tiers become a routing decision, not an infrastructure redesign.

API versioning without URL changes

Route ?api-version=2026-01 or an api-version header to the right backend. Clients keep a stable URL while you run several versions side by side, and one regular expression condition can cover a whole family of versioned paths.

One entry point for your AI endpoints

AI applications often span several endpoints, mixing reserved Provisioned Throughput Unit (PTU) capacity and pay-as-you-go capacity across regions. Rather than having every application track which endpoint to call and what to do when reserved capacity runs out, Application Gateway can serve as the central entry point for all of them: one address, with TLS, WAF and private connectivity managed in one place.

Route by deployment, spill over automatically. Route AI requests to the appropriate backend pools based on deployment paths, team identifiers or application-specific headers. Put PTU endpoints in a priority 1 pool and pay-as-you-go endpoints in a priority 2 pool. Traffic moves to pay-as-you-go only when the share of healthy reserved endpoints drops below your Minimum Healthy Percent, with no change for the client.

Figure 2: Application Gateway as one entry point for AI endpoints with priority failover from PTU to pay-as-you-go

Figure 2. One entry point for your AI endpoints: route by deployment path or header, and fail over by priority.

Get started

Advanced routing rules and advanced load balancing are available for both new and existing Application Gateway deployments. To get started, see the Application Gateway documentation for advanced routing rules and advanced load balancing.

Note: Requires API version 2026-03-01 or later. During preview, weighted distribution doesn't check pool health, so set a pool's weight to 0 to take it out of rotation.

This feature is in public preview. Previews are provided without a service-level agreement and aren't recommended for production workloads. For more information, see the Supplemental Terms of Use for Microsoft Azure Previews.

Updated Nov 11, 2026
Version 1.0