Application Gateway for Containers internal load balancer support

Question

Application Gateway for Containers internal load balancer support

HASAN HUSEYIN AKKOCA 0

Hello,

We are currently evaluating the use of Application Gateway for Containers within our AKS environment.

Based on our current understanding, the service appears to support only external load balancing scenarios at this time. We would like to confirm whether internal load balancer (private endpoint / internal exposure) support is on the product roadmap.

Could you please provide any information regarding:

Planned support for internal load balancing capabilities
Expected timelines, if available
Recommended alternatives or best practices for internal-only ingress scenarios in the meantime

This capability is critical for our architecture, as we require private, internal traffic routing within our virtual network.

Thank you in advance for your support.
User's image

Best regards,
Hasan Akkoca

0 comments

2 answers

Your answer

Answer 1

Ravi Varma Mudduluru 9,200 Microsoft External Staff Moderator

Hello @ HASAN HUSEYIN AKKOCA,

Thanks for reaching out to Microsoft Q&A.

You're correct Application Gateway for container currently supports external load balancing only. It provisions public FQDN frontends and does not support private IPs or internal frontends at this time.

There’s no public roadmap or timeline available yet for internal load-balancer support. The best place to watch for future updates is the Azure updates page.

Recommended solution for internal-only ingress:

Azure Application Gateway v2 with Application Gateway Ingress Controller (AGIC) This option fully supports internal (private) frontends and is commonly used for internal‑only or hybrid ingress scenarios in AKS. It allows you to deploy Application Gateway with a private IP and expose AKS services internally, while still benefiting from Layer‑7 routing, TLS termination, and WAF capabilities
Use the Application Routing add-on (managed NGINX). It’s fully supported in AKS, gives you both internal and external options, and is the cleanest managed alternative when you need private traffic inside your VNet.

It also supports Azure Key Vault certificates, Azure DNS (including private zones), and works great with Gateway API if you prefer that syntax.

Reference Documents:

Planned support for internal load balancing capabilities: You can share this idea in this feedback link: https://feedback.azure.com/

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

HASAN HUSEYIN AKKOCA 0 Reputation points

2026-03-31T15:35:30.28+00:00
Hello @RAVI VARMA MUDDULURU

Thank you for your detailed response.

We understand that Application Gateway for Containers currently supports only external load balancing, and that there is no confirmed roadmap for internal load balancer support at this time.

However, we would like to clarify a key concern regarding the recommended alternatives:

We are currently using the Application Routing add-on (managed NGINX) in AKS, primarily because it supports both internal and external traffic scenarios and aligns well with our requirement for private, VNet-isolated workloads.

That said, based on recent announcements from the Kubernetes SIG Network and AKS guidance, we understand that:

The Ingress NGINX project is being retired (maintenance ending March 2026)

AKS will provide support for the managed NGINX add-on only until November 2026

The long-term direction is to migrate towards the Gateway API

Given this, we have the following concerns:

The recommended Application Routing add-on (managed NGINX) is itself a transitional solution with a defined end-of-support timeline

Application Gateway for Containers, which appears to be the strategic direction, currently lacks internal load balancing support, which is a critical requirement for our architecture

The suggested alternative (Application Gateway v2 + AGIC) introduces additional operational complexity and differs from the Gateway API-based future model

Our questions are:

Is there any planned support for internal/private frontends in Application Gateway for Containers to align it with enterprise private networking requirements?

What is the recommended long-term architecture for internal-only ingress in AKS, considering the deprecation of NGINX-based solutions?

Should we consider Gateway API + another data plane implementation (e.g., Envoy-based solutions, service mesh, etc.) for internal traffic scenarios instead?

Is there any official migration path or reference architecture specifically for organizations relying on internal ingress today?

At this stage, the lack of internal load balancing support in Application Gateway for Containers creates a gap between the recommended future architecture and current enterprise requirements.

We would appreciate any clarification or guidance to help us define a sustainable long-term architecture.

Best regards,
Hasan Akkoca

Answer 2

The available documentation describes Application Gateway for Containers as an Azure‑hosted, layer‑7 ingress/load balancer for AKS that exposes workloads via frontends associated with an anycast IP, and it explicitly calls out support for HTTP/HTTPS ingress using Ingress and Gateway API resources. However, the documentation in the provided context does not state support for an internal‑only (private) mode, nor does it provide a roadmap or timelines for such a feature.

Because no roadmap or timeline information is published in the referenced documentation, there is no supported statement available here about:

Planned support for internal load balancer / private endpoint exposure
Expected delivery timelines

For internal‑only ingress scenarios today, the AKS networking guidance in the context recommends using either:

A layer‑4 Load Balancer Service for non‑HTTP traffic, or
An ingress controller for HTTP‑like traffic. Managed options called out include:
- The application routing add‑on with managed ingress‑nginx
- Istio ingress gateway
- Azure Application Gateway for Containers (recommended managed ingress option overall)

Since internal/private mode for Application Gateway for Containers is not documented in the provided material, the documented alternatives for internal‑only access are:

Use a Kubernetes LoadBalancer Service with an internal Azure Load Balancer for private, in‑VNet access to services.
Use another ingress controller option that supports internal exposure as documented in AKS application networking guidance (for example, managed NGINX via the application routing add‑on or Istio ingress gateway) while planning long‑term migration to Gateway API–based solutions.

For feature roadmap details (such as future internal mode support) and timelines, the documentation directs to:

Submit or upvote ideas on the Azure feedback channel for Application Gateway for Containers.
Open a support request in the Azure portal on the Application Gateway for Containers resource for product‑team–backed guidance.

References:

Share via

Application Gateway for Containers internal load balancer support

2 answers

Our questions are:

Your answer