Application Gateway for Containers association fails after traffic controller succeeds on AKS

Question

Application Gateway for Containers association fails after traffic controller succeeds on AKS

John Jones 0

I am deploying Application Gateway for Containers on AKS.

The AKS cluster is configured with:

Azure CNI Overlay

Workload Identity enabled

Gateway API / ALB add-on enabled

ApplicationLoadBalancer custom resource

Ingress API with ingressClassName: azure-alb-external

The Kubernetes resources appear to be accepted. The ingress points to the intended ALB resource:

annotations:

alb.networking.azure.io/alb-name: <alb-resource-name>

alb.networking.azure.io/alb-namespace: <alb-namespace>

spec:

ingressClassName: azure-alb-external

The ApplicationLoadBalancer resource points to a dedicated delegated subnet:

apiVersion: alb.networking.azure.io/v1

kind: ApplicationLoadBalancer

metadata:

name: <alb-resource-name>

namespace: <alb-namespace>

spec:

associations:

  - /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.Network/virtualNetworks/<vnet-name>/subnets/<alb-subnet-name>

The subnet is:

CIDR: /24

Delegation: Microsoft.ServiceNetworking/trafficControllers

ProvisioningState: Succeeded

The ALB managed identity has Network Contributor on that subnet.

Azure successfully creates the traffic controller:

Microsoft.ServiceNetworking/trafficControllers/<traffic-controller-name>

ProvisioningState: Succeeded

But the association fails:

Microsoft.ServiceNetworking/trafficControllers/<traffic-controller-name>/associations/<association-name>

ProvisioningState: Failed

Because the association fails, the Kubernetes ingress never receives an address:

kubectl get ingress

NAME CLASS ADDRESS

<ingress-name> azure-alb-external <blank>

The ingress events show it is accepted:

Normal Accepted Application Gateway for Containers

I also tried recreating the ApplicationLoadBalancer using a new clean /24 delegated subnet. The new traffic controller was created successfully, but the new subnet

association also failed.

In both attempts, Azure partially attached Microsoft-managed APPGW IP configurations to the delegated subnet, then the association entered Failed.

Attempts to delete the failed association or traffic controller return:

InternalServerError

Microsoft.ServiceNetworking/trafficControllers/associations/delete

Microsoft.ServiceNetworking/trafficControllers/delete

Venkatesan S 8,490 Reputation points Microsoft External Staff Moderator

2026-05-14T03:52:19.78+00:00

Hi John Jones,

Thank you for contacting us about the Azure Application Gateway for Containers association fails after traffic controller succeeds on AKS issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
Venkatesan S 8,490 Reputation points Microsoft External Staff Moderator

2026-05-14T04:28:27.6866667+00:00
Hi John Jones,

Thanks for reaching out in Microsoft Q&A forum,

Your setup with Azure CNI Overlay, Workload Identity, and Gateway API ALB add-on aligns perfectly with supported configurations for Application Gateway for Containers on AKS, but the association failure points to a validation quirk in the ALB controller. The partial IP configs and delete errors are classic symptoms of a stuck provisioning state after initial validation fails, sometimes exacerbated by region-specific backend issues or data-plane proxy injection problems.

The ALB controller strictly validates the delegated subnet against the VNet's first address prefix only, rejecting it if outside even if Azure Networking permits it. This explains why recreation in a "clean" subnet failed if it stayed in a secondary CIDR. Some users also report subnet associations failing with InternalServerError in regions like japaneast (succeeding in eastus), plus deeper data-plane issues when Azure injects managed proxies into the subnet.

Double-check these prerequisites before retrying:

Subnet is empty (no resources, no NSG conflicts), /24 minimum, delegated to Microsoft.ServiceNetworking/trafficControllers.

AKS uses Azure CNI Overlay (not Kubenet) in the same VNet as ALB subnet.

ALB controller installed correctly; managed identity has Network Contributor on VNet/subnet.

Resource providers registered: Microsoft.ServiceNetworking, Microsoft.Network, Microsoft.ContainerService.

Verify the below steps:

Verify VNet Prefixes: az network vnet show --resource-group <rg> --name <vnet> --query "addressSpace.addressPrefixes[0]". Move subnet to this primary CIDR.

ALB Logs: kubectl logs -n azure-alb-system deploy/alb-controller --tail=200 | grep -i "association\|subnet\|error". Look for capacity/routing rejections.

Complete Cleanup: Delete failed Traffic Controller, association, and lingering Failed-state resources. Wait 30-60min (handles transient service issues), then recreate via Azure CLI (better diagnostics than portal/Terraform). Use az network alb traffic-controller create first, then association/frontend.

Region Test: If in japaneast or similar, validate in eastus to rule out regional limits.

Official docs:

Troubleshoot Application Gateway for Containers

Components & Prerequisites

Quickstart: ALB Controller

Diagnostics & Monitoring

Kindly let us know if the above helps or you need further assistance on this issue.

Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
John Jones 0 Reputation points

2026-05-14T06:15:25.9033333+00:00

Hi Venkatesan,

Thank you for your replay.

The VNet has a single address prefix, 10.208.0.0/12. The ALB subnet 10.209.2.0/24 is within that primary prefix. The subnet is /24, delegated correctly, has no NSG, no route table, and the ALB managed identity has Network Contributor. The ALB controller runs in kube-system and shows Accepted ingress events, but no association/subnet error in logs. The Azure traffic controller succeeds, then the Microsoft.ServiceNetworking association fails after managed APPGW IP configurations are attached to the subnet. Is there any chance that this can be escalated?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

2 answers

Your answer

Venkatesan S 8,490 Reputation points Microsoft External Staff Moderator

2026-05-14T03:52:19.78+00:00

Hi John Jones,

Thank you for contacting us about the Azure Application Gateway for Containers association fails after traffic controller succeeds on AKS issue. We have begun looking into it and will share our suggestions with you as soon as possible. If you have any additional details or concerns in the meantime, please let us know. We appreciate your patience while we work on this.
John Jones 0 Reputation points

2026-05-14T06:15:25.9033333+00:00

Hi Venkatesan,

Thank you for your replay.

The VNet has a single address prefix, 10.208.0.0/12. The ALB subnet 10.209.2.0/24 is within that primary prefix. The subnet is /24, delegated correctly, has no NSG, no route table, and the ALB managed identity has Network Contributor. The ALB controller runs in kube-system and shows Accepted ingress events, but no association/subnet error in logs. The Azure traffic controller succeeds, then the Microsoft.ServiceNetworking association fails after managed APPGW IP configurations are attached to the subnet. Is there any chance that this can be escalated?
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 1

The issue now seems to be even worse when I am trying to delete the whole deployment with terraform it seems everything else is getting stuck because of this.
Below is the error that terraform produced as a result of the not being able to delete the alb subnet:

Can you guys clear the below resource from the Azure side?

Error: deleting Subnet

Resource Group Name: "<aks-resource-group>"

Virtual Network Name: "<vnet-name>"

Subnet Name: "<alb-subnet-name>"

performing Delete: unexpected status 400 (400 Bad Request) with error:

InUseSubnetCannotBeDeleted:

Subnet <alb-subnet-name> is in use by:

/subscriptions/<microsoft-managed-subscription-id>/resourceGroups/<microsoft-managed-resource-group>/providers/Microsoft.Network/networkInterfaces/<microsoft-managed-

appgw-nic>/ipConfigurations/<ipconfig-name>

and cannot be deleted.

In order to delete the subnet, delete all the resources within the subnet.

See aka.ms/deletesubnet.

This subnet was used for Application Gateway for Containers. The AGC association failed, but Microsoft-managed APPGW NIC/IP configuration references remain attached to

the delegated subnet. The referenced NIC is in a Microsoft-managed subscription/resource group that I cannot access, so I cannot delete it directly.

Answer 2

Venkatesan S 8,490 Microsoft External Staff Moderator

Hi @ John Jones,

Thank you for reaching out to Microsoft Q&A.

Thanks for providing the detailed scenario and error details. The generic InternalServerError during provisioning of Application Gateway for Containers (AGC) is unfortunately quite common and usually occurs deep in the data-plane when Azure tries to inject the managed proxies into the delegated subnet.

As discussed, the issue occurs only when creating the Application Gateway for Containers and associating the subnet via Terraform. When the same configuration is created through the Azure portal, it completes successfully without any issues.

Please review your Terraform code and Kubernetes objects. Additionally, since another Application Gateway for Containers is working fine with Terraform, comparing both configurations may help identify the difference.

Kindly let us know if the above helps or you need further assistance on this issue.

Please “Accept Answer” wherever the information provided helps you, this can be beneficial to other community members.

John Jones 0 Reputation points

2026-05-15T07:45:17.7066667+00:00

This is now causing further issue when I am trying to delete the AKS through terraform as it's getting tripped up on deleting the ALB subnet. Basically I can't delete the Resource Group and resources under it because of this particular issue.

Here is the error from terraform it has been sanitised.

Error: deleting Subnet

Resource Group Name: "<aks-resource-group>"

Virtual Network Name: "<vnet-name>"

Subnet Name: "<alb-subnet-name>"

performing Delete: unexpected status 400 (400 Bad Request) with error:

InUseSubnetCannotBeDeleted:

Subnet <alb-subnet-name> is in use by:

/subscriptions/<microsoft-managed-subscription-id>/resourceGroups/<microsoft-managed-resource-group>/providers/Microsoft.Network/networkInterfaces/<microsoft-managed-

appgw-nic>/ipConfigurations/<ipconfig-name>

and cannot be deleted.

See aka.ms/deletesubnet.

This subnet was used for Application Gateway for Containers. The AGC association failed, but Microsoft-managed APPGW NIC/IP configuration references remain attached to the delegated subnet. The referenced NIC is in a Microsoft-managed subscription/resource group that I cannot access, so I cannot delete it directly.
Venkatesan S 8,490 Reputation points Microsoft External Staff Moderator

2026-05-26T03:24:50.7033333+00:00

Hi John Jones,

The Backend team successfully cleared the stuck operation from your environment. now you can able to delete the Application gateway of containers.

Kindly let us know if the above helps or you need further assistance on this issue.Please “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Venkatesan S 8,490 Reputation points Microsoft External Staff Moderator

2026-05-27T03:55:55.2933333+00:00

Hi John Jones,

Just checking in to see if you had a chance to see the previous response posted by me.

Please do not forget to and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.
Pål Andreassen 0 Reputation points

2026-05-28T07:45:42.34+00:00

The ALB controller strictly validates the delegated subnet against the VNet's first address prefix only

We recently added an AGfC to an existing Kubernetes cluster. We had to add a second address space to the VNET in order to fit the ALB subnet.

10.240.0.0/16 was the original address space, with a default subnet taking all of 10.240.0.0/16

10.241.0.0./16 was added with a 10.241.0.0/24 subnet for the ALB.

We managed to setup everything, including a WAF policy associated with the ALB. The ingress accepts requests and the WAF filters out requests.

The only thing we notice is that the property page on the WAF policy states 0 associations even when one is listed under associations and that the WAF Insights workbook does not work as it has no associations to choose from.

As I cannot shrink the default subnet, what other options than adding a second address space do I have? This is a production cluster and I don't want to tear it down.

Share via

Application Gateway for Containers association fails after traffic controller succeeds on AKS

2 answers

Your answer