We are not short of options to deploy network security in the form of a firewall in Azure:
And earlier this year, Microsoft released a preview of the Azure Firewall, a new Azure firewall service. Unlike NSGs, Azure Firewall is intended to be a centralized deployment. And unlike the WAF, Azure Firewall is not instance-based; it operates as a true PaaS feature and doesn’t bother you with worrying about deployed instances. Instead, the Azure Firewall automatically scales under the covers to deal with your workloads. And unlike NVAs, you won’t need to license a third-party service to use the WAF.
The Azure Firewall is not a budget service; it will start at over $900 per month for a deployment, plus $0.03 per GB of inbound/outbound of data that is processed. This will give you a clue as to how Azure Firewall should be used.
Very often in the cloud, firewall services are distributed. It’s not uncommon to see NSGs on every subnet and a WAF for every application. Azure Firewall is intended to be deployed in a hub VNet that is managed by network admins or IT security. Applications can then be deployed into spoke virtual networks without a public IP address.
Note that Azure Policy could be used to restrict the creation of public IP addresses.
Each of the spoke networks can peer with the hub with IP forwarding enabled from the hub into the spoke VNets; this will allow the firewall to forward traffic into applications running in the spokes. And now, the Azure Firewall can control traffic into and between the spoke VNets.
Note that routing tables will be deployed in the subnets of the spoke VNets to direct all outbound traffic through the private/internal IP address of the Azure Firewall “appliance”.
The Azure Firewall is not instance based. The goal is that you deploy it and configure it and let Azure worry about sizing – therefore you pay for data processed. It is a highly available service that should scale to match the requirements of the applications that it protects.
By default, the Azure Firewall blocks all traffic, inbound and outbound. Outbound traffic can be allowed based on IP address, CIDR block or HTTP/HTTPS fully qualified domain names (FQDNs). All traffic leaving the spoke VNets will be translated to the Standard tier public IP address of the Azure Firewall, allowing you to identify that traffic in remote networks.
Inbound traffic can be translated to private IP addresses that are protected by the Azure Firewall – this is a new feature that was not available in the preview. Destination Network Address Translation (DNAT) is what this feature is called, and you will see the phrase “DNAT” throughout the Azure Firewall documentation. It is simply referred to as NAT in the Azure Portal.
All events that happen are integrated into Azure Monitor. You can archive these events in a storage account, Log Analytics or stream the events to an Event Hub.
The Azure Firewall preview was a limited one. I thought Microsoft would launch a public preview at the Ignite conference, so I was surprised to see it have become generally available. There are a few kinks, but this is The Cloud and things should improve quickly:
The Azure Firewall is pretty simple to deploy. I think that the main thing to consider is that this is intended to be a centrally deployed security service, so you must plan out your network architecture. Applications will be deployed into spoke VNets, possibly with application gateways and/or load balancers, and even with the Layer-7 WAF, but with private IP addresses. Routing tables will have to be deployed to control the flow out outbound traffic through the Azure Firewall, and this firewall will also control the flow of traffic between applications. And yes, NSGs will still play a role, however, Application Security Groups will probably flatten deployments that previously might have contained many subnets.
The example deployment documentation that Microsoft has shared is pretty good – you can see that some minor UI stuff changed at the last second. What I think is missing now are reference architectures to display end-to-end architectures that Microsoft will be recommending for different patterns involving the Azure Firewall.