Application Gateway for Containers (AGC) subnet association fails with InternalServerError in japaneast — same steps succeed in eastus

Summary

azurerm_application_load_balancer_subnet_association / az network alb association create / ALB Controller managed-mode association creation all fail with a generic InternalServerError in Japan East. Identical commands against East US succeed on the first try. I'm hitting a hard block on AGC data-plane setup (Gateway listeners never reach Programmed=True).

Environment

• Subscription: Azure subscription under tenant 8717a5f5-...
• Affected region: Japan East (officially listed as supported for Microsoft.ServiceNetworking/trafficControllers/associations)
• Reproduced: 2026-04-21 JST
• Tools tried (all fail identically in japaneast):
  • Terraform hashicorp/azurerm provider v4.68.x / v4.69.x (azurerm_application_load_balancer_subnet_association)
  • Azure CLI az network alb association create (alb extension, latest)
  • ALB Controller v1.7.9 in managed mode (creates its own association via ApplicationLoadBalancer CRD)
• AKS version: 1.35, Azure CNI Overlay, Workload Identity + OIDC Issuer enabled
• RP Microsoft.ServiceNetworking is Registered

Reproduction (fully scripted, identical for both regions)

REGION=<japaneast|eastus>

RG="test-agc-${REGION}"

az group create --name $RG --location $REGION

az network vnet create --resource-group $RG --name test-vnet \

  --address-prefixes 10.200.0.0/16 \

  --subnet-name test-agc-subnet --subnet-prefixes 10.200.0.0/24 \

  --location $REGION

az network vnet subnet update --resource-group $RG --vnet-name test-vnet \

  --name test-agc-subnet \

  --delegations Microsoft.ServiceNetworking/trafficControllers

az network alb create --resource-group $RG --name test-agc --location $REGION

SUBNET_ID=$(az network vnet subnet show --resource-group $RG \

  --vnet-name test-vnet --name test-agc-subnet --query id -o tsv)

az network alb association create --resource-group $RG --alb-name test-agc \

  --name test-assoc --subnet $SUBNET_ID --location $REGION

Result

East US — Succeeded ✅

1. RG:          name=test-agc-eastus state=Succeeded

2. VNet/Subnet: delegation=Microsoft.ServiceNetworking/trafficControllers state=Succeeded

3. AGC:         name=test-agc state=Succeeded

4. Association: provisioningState=Succeeded

Japan East — Failed ❌ (identical steps)

1. RG:          name=test-agc-japaneast state=Succeeded

2. VNet/Subnet: delegation=Microsoft.ServiceNetworking/trafficControllers state=Succeeded

3. AGC:         name=test-agc state=Succeeded

4. Association: ERROR (InternalServerError) Internal Server Error

   Code: InternalServerError

   Message: Internal Server Error

Final state:

  provisioningState: Failed

Activity Log:

  03:37:40 Create or update AGC Association — Started

  03:37:41 Create or update AGC Association — Accepted (HTTP 202)

  03:37:52 Get AGC Association — Running

  (transitions to Failed shortly after)

Activity Log statusMessage:

{

  "status": "Failed",

  "error": {

    "code": "ResourceOperationFailure",

    "message": "The resource operation completed with terminal provisioning state 'Failed'.",

    "details": [

      { "code": "InternalServerError", "message": "Internal Server Error" }

    ]

  }

}

What I've already verified

All of the commonly-cited prerequisites are satisfied on the Japan East setup:

1. ✅ Subnet delegated to Microsoft.ServiceNetworking/trafficControllers (both an existing 10.20.48.0/24 and a freshly created 10.200.0.0/24)
2. ✅ Subnet is /24 (256 IPs, meets the minimum)
3. ✅ No NSG, no route table, no service endpoints, no other IP configurations on the subnet; privateEndpointNetworkPolicies=Disabled
4. ✅ AGC resource and subnet are both in japaneast
5. ✅ ALB Controller UAI has:
   • Reader on the AGC resource group
   • AppGw for Containers Configuration Manager on the AGC resource group
   • Network Contributor on the delegated subnet
6. ✅ AKS is in japaneast (supported per az provider show --namespace Microsoft.ServiceNetworking), Azure CNI Overlay, Workload Identity enabled, OIDC Issuer enabled
7. ✅ Microsoft.ServiceNetworking resource provider is Registered on the subscription
8. ✅ Azure Service Health API (/providers/Microsoft.ResourceHealth/events) returns 0 events — no officially acknowledged incident

The failure is consistent across:

• Multiple tools (Terraform, az CLI, ALB Controller managed-mode)
• Multiple subnets (existing one from infra cycle + a freshly created isolated one)
• Multiple resource groups (platform network RG + AKS MC_ RG)
• Multiple AGC instances (BYO and managed-mode creations)

And the failure does not happen in East US using byte-identical commands — strong signal this is a region-scoped backend issue rather than a client-side misconfiguration.

Question

1. Is there a known platform issue with Microsoft.ServiceNetworking/trafficControllers/associations creation in japaneast right now?
2. Is there a way to retrieve more actionable detail from the InternalServerError than what the Activity Log exposes?
3. Is there any workaround (different API version, specific subnet setting, per-subscription feature flag) that I should try while waiting for resolution?

Any pointer — Service Health advisory I'm missing, a known issue page, or an updated doc — would be very much appreciated.

Cleanup

Test resources (test-agc-japaneast, test-agc-eastus) were deleted after capturing outputs.