Secure architecture that takes all traffic off the public Internet once Azure Application (App) Gateway is traversed. Traffic behind App Gateway is subsequently inaccessible to the public. This is due to App Gateway's use of Private Link to Azure API Management.
Diagram created with the Azure Draw.io MCP Server.
- Provide a secure pathway to API Management via Private Link from App Gateway
- Maintain private networking by integrating API Management with a VNet to communicate with Azure Container Apps. (This can also be achieved via Private Link there)
- Empower users to use Azure Container Apps, if desired
- Enable observability by sending telemetry to Azure Monitor
Adjust the user-defined parameters in this lab's Jupyter Notebook's Initialize notebook variables section.
The notebook also includes a SYSTEM CONFIGURATION flag named use_strict_nsg. It defaults to False.
We provide NSG deployment as an option for teams that want to explore subnet-level restrictions, but we intentionally keep it disabled by default. That keeps the sample focused on Application Gateway, private endpoints, and API Management without sliding too far toward Azure Landing Zone-style baseline networking complexity.
NSG behavior:
nsg-default: Generic fallback NSG for subnets that do not have a service-specific NSG. It stays intentionally generic.use_strict_nsg = False: Service subnets get permissive service-aware NSGs:nsg-appgw,nsg-apim, andnsg-aca. These preserve Azure platform requirements and avoid unnecessary ingress restrictions.use_strict_nsg = True: Service subnets get strict NSGs:nsg-appgw-strict,nsg-apim-strict, andnsg-aca-strict. These keep required platform rules but restrict ingress so traffic follows App Gateway -> APIM -> ACA.
👟 Expected Run All runtime: ~13 minutes
- Execute this lab's Jupyter Notebook step-by-step or via Run All.
Unlike Azure Front Door, App Gateway does not presently support managed certificates. This complicates the infrastructure as it either requires the user to bring their own certificate, or a self-signed certificate needs to be generated and made available to App Gateway.
We opted for the latter as it is more conducive to generate a self-signed certificate and work with its appropriate and secure limitations. This does mean that, for the purpose of this being non-production, proof of concept infrastructure, we need to trust the self-signed cert appropriately. We do so by acknowledging and subsequently ignoring the self-signed certificate warnings and using IPs paired with Host header.
Production workloads must not use this approach and, instead, be secured appropriately.