To secure Azure application workloads, you use protective measures, such as authentication and encryption, in the applications themselves. You can also add security layers to the virtual machine (VM) networks that host the applications. The layers protect inbound flows from users. They also protect outbound flows to the internet that your application might require. This article describes Azure Virtual Network security services like Azure Firewall and Azure Application Gateway, when to use each service, and network design options that combine both.
Azure Firewall is a managed next-generation firewall that offers network address translation (NAT). Azure Firewall bases packet filtering on Internet Protocol (IP) addresses and Transmission Control Protocol and User Datagram Protocol (TCP/UDP) ports, or on application-based HTTP(S) or SQL attributes. Azure Firewall also applies Microsoft threat intelligence to identify malicious IP addresses.
Azure Firewall Premium includes all functionality of Azure Firewall Standard and other features, such as TLS-inspection and Intrusion Detection and Protection System (IDPS).
Azure Application Gateway is a managed web traffic load balancer and HTTP(S) full reverse proxy that can do Secure Socket Layer (SSL) encryption and decryption. Application Gateway also uses Web Application Firewall to inspect web traffic and detect attacks at the HTTP layer.
Azure Web Application Firewall (WAF) is an optional addition to Azure Application Gateway. It provides inspection of HTTP requests, and it prevents malicious attacks at the web layer, such as SQL Injection or Cross-Site Scripting.
Azure Firewall and Azure Application Gateway use different technologies, and they support securitization of different flows :
Depending on the network flows an application requires, the design can be different on a per-application basis. The following diagram offers a simplified decision tree that helps choosing the recommended approach for an application. The decision depends on whether the application is published via HTTP(S) or some other protocol :
This article will cover the widely recommended designs from the flow chart, and others that are applicable in less common scenarios:
Azure Firewall alone, when there are no web applications in the virtual network. It will control both inbound traffic to the applications and outbound traffic.
Application Gateway alone, when only web applications are in the virtual network, and network security groups (NSGs) provide sufficient output filtering. This scenario is typically not recommended because of the rich functionality of Azure Firewall over NSGs. That functionality can prevent many attack scenarios (such as data exfiltration), so this scenario isn't documented in the flow chart above.
Azure Firewall and Application Gateway in parallel, which is one of the most common designs. Use this combination when you want Azure Application Gateway to protect HTTP(S) applications from web attacks, and Azure Firewall to protect all other workloads and filter outbound traffic.
Application Gateway in front of Azure Firewall, when you want Azure Firewall to inspect all traffic, WAF to protect web traffic, and the application to know the client's source IP address. With Azure Firewall Premium and TLS inspection, this design supports the end-to-end SSL scenario as well.
Azure Firewall in front of Application Gateway, when you want Azure Firewall to inspect and filter traffic before it reaches the Application Gateway. Because the Azure Firewall isn't going to decrypt HTTPS traffic, the functionality that it's adding to the Application Gateway is limited. This scenario isn't documented in the flow chart above.
Azure Firewall only
If there are no web-based workloads in the virtual network that can benefit from WAF, you can use Azure Firewall only. The design in this case is simple, but reviewing the packet flow will help understand more complex designs. In this design, all inbound traffic is sent to the Azure Firewall via UDRs (for connections from on-premises or other Azure VNets), or it is addressed to the Azure Firewall's public IP address (for connections from the public internet, as the diagram below shows). Outbound traffic from Azure VNets is sent to the Firewall via UDRs, as shown in the dialog below.
The following table summarizes the traffic flows for this scenario:
Application Gateway only
This design covers the situation where only web applications exist in the virtual network, and inspecting outbound traffic with NSGs is sufficient to protect outbound flows to the internet.
The following table summarizes traffic flows
Firewall and Application Gateway in parallel
Because of its simplicity and flexibility, running Application Gateway and Azure Firewall in parallel is often the best scenario.
Implement this design if there's a mix of web and non-web workloads in the virtual network. Azure WAF protects inbound traffic to the web workloads, and the Azure Firewall inspects inbound traffic for the other applications. The Azure Firewall will cover outbound flows from both workload types.
The following table summarizes the traffic flows for this scenario
The following diagram illustrates the traffic flow for inbound connections from an outside client
The following diagram illustrates the traffic flow for outbound connections from the network VMs to the internet. One example is to connect to backend systems or get operating system updates
The packet flow steps for each service are the same as in the previous standalone design options.
Application Gateway before Firewall
In this option, inbound web traffic goes through both Azure Firewall and WAF. The WAF provides protection at the web application layer. Azure Firewall acts as a central logging and control point, and it inspects traffic between the Application Gateway and the backend servers. The Application Gateway and Azure Firewall aren't sitting in parallel, but one after the other.
The following table summarizes the traffic flows for this scenario
Application Gateway after firewall
This design lets Azure Firewall filter and discard malicious traffic before it reaches the Application Gateway. For example, it can apply features like threat intelligence-based filtering. Another benefit is that the application gets the same public IP address for both inbound and outbound traffic. However, Azure Firewall SNATs the incoming traffic, so the application will not have visibility to the original IP address of the HTTP requests.
The following table summarizes the traffic flows for this scenario
On-premises clients
The preceding designs all show application clients coming from the public internet. On-premises networks also access applications. Most of the preceding information and traffic flows are the same as for internet clients
Hub and spoke topology
The designs in this article still apply in a hub and spoke topology. Shared resources in a central hub virtual network connect to applications in separate spoke virtual networks through virtual network peering.
