Microsoft added a public preview of private ingress for Application Gateway for Containers to its Azure roadmap on November 3, 2026. It gives Kubernetes workloads a frontend reached through approved Azure Private Link endpoints rather than a public IP address.
A different ingress boundary
The Azure update describes private connectivity across virtual networks, subscriptions, Microsoft Entra tenants, and regions without requiring VNet peering. A single gateway resource can host both public and private frontends, allowing different exposure models for different services.
The preview retains the gateway’s application-routing role rather than replacing it with a raw private network connection. Teams can use it for internal applications, cross-cluster access, or an architecture where another service is the intended public entry point.
Approval and software versions matter
Microsoft’s documentation distinguishes private endpoint creation from connection approval. Cross-subscription and cross-tenant connections require the resource owner’s approval, while same-subscription connections may be approved automatically when permissions allow.
The guide lists prerequisites including an ALB Controller at version 1.13 or newer, REST API 2026-03-01 or later, and eligible association resources created on or after April 23, 2026. Existing deployments should check those conditions before assuming a frontend can simply be toggled private.
A documented source-IP tradeoff
When an Azure Firewall or network virtual appliance sits in front of the gateway, source network address translation can cause the gateway to see the firewall’s address rather than the original client’s. Microsoft identifies consequences for logging, location-based behavior, and IP-based rate limiting. The guide discusses alternative topologies and upstream information as design considerations.
That detail matters because a private transport path and correct application-level client attribution are different properties. Improving one does not automatically preserve the other.
What to test before moving traffic
Our network analysis is to begin with one representative service and trace its real request path. Confirm DNS resolution from each authorized client network, endpoint approval ownership, certificate handling, health probes, and the application’s authorization checks.
Test both successful and rejected access from appropriate locations. A private frontend should not accidentally leave an older public path serving the same sensitive workload. At the same time, verify that monitoring and incident responders can still inspect failures through the supported route.
Check the application’s assumptions about forwarded headers before using them for security decisions. A header becomes useful identity evidence only when the upstream chain is controlled and the application knows which proxy supplied it. Changing the ingress topology is a reason to retest those assumptions.
The preview offers an important network design option, especially for shared enterprise services. Its readiness for a particular workload depends on the documented version constraints, actual connectivity, and preservation of the application controls above the network layer.