We use an Azure hub-and-spoke environment with vWAN. Traffic entering or leaving each spoke is routed through the hub and inspected by Azure Firewall Premium, while traffic within a spoke is controlled with NSGs. Our current internet-facing application is published through Azure Firewall, and an external WAF sits in front of it. The firewall only permits inbound connections from the WAF's IP addresses.
We expect to deploy more public-facing applications and would prefer not to keep adding public IPs to Azure Firewall. The WAF can forward only HTTP and HTTPS traffic on ports 80 and 443. One upcoming application will run in Azure Container Apps and be managed by a third party.
Would there be a significant security or operational disadvantage to using this design?
Client → External WAF → Container App with external ingress
The Container App environment would still access other components in the VNet under NSG control, and traffic leaving the spoke would continue through Azure Firewall for inspection.
The alternative is to place an Application Gateway behind the WAF and route inbound traffic through Azure Firewall before reaching a Container App with internal ingress:
Client → External WAF → Application Gateway → Azure Firewall → Container App
This would keep Azure Firewall in the inbound path, but it is unclear what additional protection it provides when the external WAF already performs Layer 7 inspection. Is there a compelling reason to keep Azure Firewall between the WAF and the application, or is direct WAF-to-Container-App routing a reasonable design?
3 Answers
Both patterns can be valid. The main additional reason to keep Azure Firewall in the inbound path is to use Premium features such as IDPS/IPS, centralized firewall policy, and the associated logging. Security requirements should determine whether that extra inspection is needed. If the external WAF is considered sufficient and the traffic remains encrypted between the WAF and Azure, Azure Firewall may add little beyond network- and transport-level filtering unless TLS inspection is enabled.
If the WAF already authenticates the expected source, filters the request, and protects the application at Layer 7, sending the same web traffic through Azure Firewall is not automatically more secure. It can provide defense in depth, IPS detection, TLS inspection, centralized logging, and a consistent policy boundary, but those benefits come with additional cost and operational complexity.
Direct WAF-to-Container-App ingress is therefore reasonable when the WAF is properly restricted, the Container App is hardened, and the security team accepts the loss of any firewall-specific inspection. Keep Azure Firewall in the path for outbound and non-web traffic where its controls provide clear value.
For multiple public web applications, a shared Application Gateway can consolidate HTTP and HTTPS entry points. Host-based listeners and SNI let it route different domains to different backends through one public IP, so you avoid adding a public IP to Azure Firewall for every application.
A common design is to let the WAF and Application Gateway handle inbound web traffic while Azure Firewall handles outbound traffic and other protocols that need inspection. If the external WAF is trusted and its source IPs are locked down, the same principle can generally apply to a third-party WAF.
A shared Application Gateway does introduce some blast-radius and change-management considerations. Listener or routing changes should be tightly controlled and tested, but adding a separate listener normally does not affect existing sites when the configuration is correct. Separate gateways may still be appropriate where workloads need stronger isolation, independent ownership, or different policies.
That makes sense. The key decision for us is whether Security specifically requires IPS inspection on this traffic, rather than assuming every inbound flow must follow the traditional perimeter pattern.