frontend "app gw" and backend " AKS" cross subscription connectivity

Hello Mall Ashi,

Yes, you can absolutely host an Azure Application Gateway in Subscription X (with a public IP / custom domain) and route traffic to an Azure Kubernetes Service (AKS) cluster residing in Subscription Y.

Here is a breakdown of how this architecture works, how to configure it, and the supporting Microsoft documentation.

1. How It Works (Network Connectivity)

Azure Application Gateway communicates with its backend targets over Layer 7 using Private IP addresses or FQDNs. As long as there is network route connectivity between the two Virtual Networks across the subscriptions, Application Gateway can reach the AKS pods or internal load balancer.

You have two primary ways to set up this cross-subscription topology:

Option A: Virtual Network (VNet) Peering (Most Common & Recommended)

1. Peering: Establish a VNet Peering connection between VNet A (Subscription X - App Gateway) and VNet B (Subscription Y - AKS). Cross-subscription and cross-region VNet peering are fully supported in Azure.
2. Backend Target:
   • With Azure CNI: App Gateway can route directly to AKS Pod private IPs.
   • With Kubenet / Internal Load Balancer: App Gateway routes to the internal Kubernetes Service LoadBalancer IP / Ingress Controller IP inside the AKS VNet.
3. Public Access: The Application Gateway uses its Public Frontend IP with your custom domain (and SSL certificate), while the backend communication to AKS remains completely private and secure over the peered VNet backbone.

Option B: Application Gateway Ingress Controller (AGIC) Multi-Cluster / Cross-Subscription

If you are using the Application Gateway Ingress Controller (AGIC):

• AGIC running as a pod in Subscription Y can update the Application Gateway in Subscription X, provided the AKS Managed Identity / Service Principal has the Contributor or Network Contributor role assigned on the Application Gateway resource in Subscription X.

2. Key Prerequisites & Routing Checklist

• Non-overlapping IP Ranges: Ensure the address spaces of the VNet in Subscription X and the VNet in Subscription Y do not overlap.
• Network Security Groups (NSGs): Allow inbound traffic from the Application Gateway subnet IP range to the AKS subnet on the application ports (e.g., 80, 443, 8080).
• DNS / Custom Domain: Bind your custom domain name to the Frontend Public IP of the Application Gateway in Subscription X.

3. Official Microsoft Documentation References

• Virtual Network Peering across subscriptions: Virtual network peering - Azure Virtual Network
• Application Gateway Backend Pool configuration (Cross-VNet targets): Application Gateway components and backend routing
• Set up AGIC with existing Application Gateway (including cross-VNet/Sub topologies): Install Application Gateway Ingress Controller using an existing Application Gateway

Hope this confirms your design! Let us know if you need specific guidance on the AGIC permissions or peering configuration.

Hi @Mall Ashi ,

You are asking whether an Application Gateway in subscription X can front an AKS backend in subscription Y, whether the application stays reachable over the public internet, and which Microsoft document supports that. The answer from @Janith Biman covers the peering setup. I am adding three points the thread does not cover yet: the documentation entry that answers the cross-subscription question directly, one product where the answer is different, and what is known about the AGIC add-on across subscriptions.

The documentation entry you asked for

The Application Gateway FAQ has an entry titled "Can Application Gateway communicate with instances outside of its virtual network or outside of its subscription?". It states that with IP connectivity in place, Application Gateway can communicate with instances outside the subscription it is in, and that internal-IP backend members require virtual network peering or a VPN gateway. That is the Microsoft statement for your scenario. The same FAQ confirms that AKS and the gateway may live in separate virtual networks as long as they are peered without overlapping address spaces, and that Application Gateway v2 supports a public frontend, a private frontend, or both, so public reachability is decided at the gateway frontend regardless of where the backend sits.

Where this does not hold: Application Gateway for Containers

If the gateway in question is Application Gateway for Containers rather than the classic v2 SKU, the peering approach is not available. Application Gateway for Containers must be deployed in the same virtual network as the AKS cluster; the documentation lists separate virtual networks, regional VNet peering, and global VNet peering as unsupported. A gateway VNet in subscription X with an AKS VNet in subscription Y is therefore not a supported topology for that product today.

AGIC across subscriptions: Helm versus add-on

For AGIC deployed through Helm, the gateway subscription is an explicit parameter: helm-config.yaml carries an appgw.subscriptionId field for the subscription in which the gateway resides. For the AKS-managed deployment, I found no Microsoft documentation that confirms or excludes a gateway in a different subscription. There is community evidence that it works: the reporter of issue #1737 in the AGIC repository (open, June 2025) runs the gateway and the AKS node pools in different subscriptions and peered VNets with Azure CNI, sees the gateway being updated, and reports the setup working. The one side effect is a FailedCNIConfiguration warning in the AGIC pod: AGIC attempts the kubenet route-table association, builds the route table path with the gateway's subscription ID instead of the cluster's, and receives a 403 on a resource that does not exist there. The FAQ documents this route-table step as relevant for kubenet clusters only, so on Azure CNI the warning is noise. Verify this against your own AGIC pod events before relying on it.

References

• Frequently asked questions about Application Gateway
• Container networking with Application Gateway for Containers
• Install an Application Gateway Ingress Controller using an existing Application Gateway
• AGIC route table warning in multi-subscription and Azure CNI setup (Azure/application-gateway-kubernetes-ingress issue #1737)

Drafted with help from Claude, disclosed per the Q&A AI usage policy. All technical claims checked against the Application Gateway FAQ, the Application Gateway for Containers container-networking page, the AGIC Helm installation guide on Microsoft Learn, and the referenced GitHub issue.