Microsoft announced advanced routing rules and advanced load balancing for Azure Application Gateway in public preview on November 11, 2026. The update adds finer request matching and more control over backend selection. Microsoft announcement.
My proposed pilot would separate three questions: which rule matches, which pool receives the request, and what happens when a backend becomes unhealthy. Record an expected result for each before changing a test gateway.
Start with a Request Decision Sheet
Rules can match paths, headers, query strings, methods, and client IPs. Microsoft documents up to five AND-combined conditions, priority evaluation, and a default backend for unmatched requests. Path, header, and query conditions support RE2 expressions. Routing behavior.
I would create a small decision sheet containing representative requests and their intended destinations. Include an ordinary request, an intentionally selected test cohort, a request that satisfies overlapping rules, and one that should reach the default destination.
Have the application owner review that sheet before implementation. Preserve the relationship between the business intent and the proposed rule so another engineer can explain why each request belongs at its destination.
Prove the Boundary Around a Match
My test set would include values immediately outside the intended match. For a versioned endpoint, that might mean a nearby path, a missing version header, and an unsupported version value.
Use synthetic requests with identifiers that can be traced in the test application's diagnostics. Compare the observed destination with the prewritten expectation and retain both the request description and configuration revision.
Assign any ambiguous result to a named reviewer. A rule is ready for wider evaluation when the team can explain its accepted and rejected cases, including the behavior of the fallback destination.
Review Distribution and Failure Independently
Across pools, the preview supports weighting or priority. Within a pool, options include round robin, weighted round robin, and least connections. Priority failover uses a configurable Minimum Healthy Percent. Load-balancing choices.
I would first observe distribution under an agreed, representative request pattern. Record the sample size, connection behavior, backend responses, and observation window before drawing a conclusion about the selected policy.
Then run the approved failure scenario separately. The acceptance record should describe the condition introduced, expected destination, observed error behavior, and the operator's recovery steps. Compare the result with the application's availability expectations.
Make the Weighted Preview Limit Explicit
Microsoft warns that weighted distribution does not check pool health during preview. Its guidance is to set a pool's weight to zero to remove it from rotation. Preview limitation.
That belongs in the pilot runbook. I would name the person responsible for identifying an unsuitable pool and applying the approved removal procedure, then rehearse the action using disposable backends.
Preserve evidence of the restored state as well. The operator should be able to establish which configuration is active, which destination receives the test requests, and whether the intended distribution has resumed after recovery.
Keep Routing and Access Decisions Clear
For a hypothetical tenant-specific application, my review would ask the service owner to identify which controls establish identity and authorize the operation. Record those controls alongside the routing proposal.
Include a deliberately unauthorized synthetic request in the approved test plan and verify the application's expected response. Keep that acceptance result attached to the gateway decision sheet so future maintainers understand the complete request path.
The announcement requires API version 2026-03-01 or later and says the preview has no SLA and is not recommended for production workloads. Availability and prerequisites.
Practical Cloud Engineer Takeaway
Define expected destinations before implementing the rules.
Exercise overlapping matches and the default backend.
Evaluate distribution and failure handling in separate scenarios.
Document the weighted preview's manual pool-removal procedure.
Preserve the previous configuration and rehearse recovery.
Who Should Care?
Azure network engineers, application platform teams, and service owners evaluating request-based routing, staged releases, or differentiated backend handling.
Bottom Line
The preview expands Application Gateway's routing choices. A useful evaluation proves rule behavior, backend selection, failure handling, and operator recovery against the application's written expectations.
No Application Gateway, routing rule, backend pool, authentication setting, or Azure resource was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments