In this design, the Azure Firewall will be deployed once into a hub virtual network. Applications or services will be deployed in spoke virtual networks. VNet peering (global peering is not supported), will connect the hub, where the firewall is hosted, to the peers, where the applications/services are hosted.
The benefits of this design are:
This is a very simple virtual network – a single subnet, that must be called AzureFirewallSubnet, is required to host the Azure Firewall. The firewall has a single public IP address, which you should note for the “destination address” in NAT rules, and a single internal IP address, which you should note for creating route tables in the application/services subnets.
If your applications will be internet facing and they require a dedicated public IP address (see web application gateway/firewall), then traffic from the Internet will come into those services without flowing through the firewall. However, traffic between applications must flow through the firewall, and this level of isolation will contain risks and enable full logging with centralized oversight & control.
NAT rules will allow you to present applications to the Internet via the PIP of the firewall. Application and/or network rules will allow you to control the flow of traffic between the subnets and out to the external world.
There are three things to consider here:
You will do a lot of routing management if you choose to deploy Azure Firewall, and you will do massive amounts of routing management if you deploy the Azure Firewall into hub-and-spoke architecture. This is, so far, where I have spent most of my network troubleshooting time – usually it’s a route table that I have forgotten to associate with a subnet.
If you create a route table for each subnet with a simple route to 0.0.0.0/24 via the internal IP address of the Azure Firewall. It would appear that all traffic will route via the Azure Firewall, but in reality:
In reality, you will need greater control. One could create a route with a destination of 10.0.0.0/16 via the internal address of the Azure Firewall. That route will direct all traffic inside the VNets through the firewall but allow services to respond out through their respective inbound routes. However, this micro-segmentation will send all traffic across the peering connections and that could increase network costs substantially.
A balancing act will be to send all inter-VNet traffic through the Azure Firewall but leave all intra-VNet traffic to stay inside the VNet – and still be filtered by the NSGs. To do this, you will need more complex route tables. Each route table will need a route for each VNet or subnet that it must communicate with. For example, the route table on 10.1.1.0/24 might have a route to 10.2.0.0/16 that passes through the Azure Firewall’s internal IP address.
The final piece of the puzzle is VNet peering. Each application VNet has peered with the Azure Firewall’s hub VNet. You should consider a few things here:
If you require a bastion host to enable secured remote access to your virtual machines then place it into another spoke virtual network. You should then allow traffic from it to the other subnets using network rules in the Azure Firewall. Here are two things to think about: