Azure Application Gateway in front of an external Azure Container Apps environment

by

Summary

The 404 errors occur because Azure Container Apps (ACA) with internal ingress only accepts traffic originating from within its own ACA-managed environment, not from other subnets in the same VNET. An Application Gateway placed in a different subnet cannot reach those internal endpoints, even though they share the same VNET.

Root Cause

The failure is caused by ACA internal ingress isolation, which enforces strict network boundaries:

  • Internal ingress exposes the app only inside the ACA environment, not the entire VNET.
  • Application Gateway sits outside the ACA environment boundary, even if it is in the same VNET.
  • ACA internal endpoints are not standard VNET IPs; they are internal to the ACA-managed infrastructure.
  • Application Gateway therefore receives a 404 because it cannot route to an endpoint that ACA does not expose.

Why This Happens in Real Systems

This behavior is common in modern PaaS networking models:

  • Internal ingress is not equivalent to VNET-internal access; it is scoped to the ACA environment only.
  • Managed environments abstract the underlying network, preventing direct subnet-to-subnet access.
  • Application Gateway expects routable IPs or private endpoints, which ACA internal ingress does not provide.
  • Security boundaries are intentionally strict to prevent accidental exposure of microservices.

Real-World Impact

Teams often encounter:

  • Unexpected 404 or unreachable services when integrating ACA with Application Gateway or API Gateway.
  • Misleading assumptions that “same VNET = reachable,” which is not true for ACA internal ingress.
  • Architectural blockers when trying to expose internal-only microservices through a central gateway.
  • Delays in production rollout due to rework of networking and ingress configuration.

Example or Code (if necessary and relevant)

A typical failing setup looks like this:

AppGateway (Subnet A) --> ACA Internal Ingress (Subnet B) --> 404

This fails because the internal ingress endpoint is not a VNET-routable IP.

A working setup requires external ingress or private endpoints:

AppGateway --> ACA External Ingress (private IP) --> App

How Senior Engineers Fix It

Experienced engineers use one of these patterns:

  • Switch ACA ingress to external with a private IP

    • Application Gateway can route to the private IP.
    • Still not publicly exposed if WAF is the only public entry point.

  • Use an internal ACA environment instead of external

    • Internal environments support VNET integration more naturally.

  • Place Application Gateway behind a Private Endpoint

    • ACA external ingress + private endpoint = secure, VNET-routable target.

  • Use Azure API Management (APIM) with VNET integration

    • APIM can reach ACA internal endpoints when properly integrated.

  • Redesign service boundaries

    • Expose only the services that must be reachable through the gateway.

Why Juniors Miss It

Less experienced engineers often assume:

  • “Internal ingress = private VNET access”, which is incorrect.
  • All resources in the same VNET can talk to each other, which is not true for managed PaaS.
  • ACA behaves like AKS, but ACA abstracts networking differently.
  • Application Gateway can route to anything with a private IP, but ACA internal ingress does not provide one.

They also may not realize that ACA internal ingress is not a VNET feature—it is an ACA-environment feature, which is a subtle but critical distinction.

Would you like the postmortem rewritten as a more formal incident report or adapted for internal engineering documentation?

Leave a Comment