Azure Firewall its core it’s a managed, network security service that protects your Azure Virtual Network resources. It functions as a stateful firewall-as-a-service and offers built-in high availability and scalability. can centrally control, enforce and log all of your network traffic. It fully integrates with Azure Monitor too which means all of the usual logging and analytical goodness.
Deploying an Azure Firewall need a couple of things in advance. It needs a dedicated subnet, specifically named “AzureFirewallSubnet” and the minimum size it can be is a /26. It also needs at least one Static Public IP. The Public IP must be on the Standard tier. The recommendation here is to look at creating a Public IP Prefix in advance of creating your Azure Firewall. That way, if you need to delete it and redeploy, you can continue to use the same Public IP again and again. If you want to use multiple Public IPs, it supports up to 100.
What Azure Firewall (AFW) can do for in Virtual Network and deployment options.
Access
Using a single, or multiple Public IP addresses, AFW allows both source and destination NATing. it can support multiple inbound ports, such as HTTPS over 443 to different resources. Outbound SNAT helps greatly with services that require white-listing. If you are using multiple Public IPs, AFW randomly picks one for SNAT, so ensure you include all of them in your white-listing requirements.
Protection
AFW uses a Microsoft service called Threat Intelligence filtering. This allows Azure Firewall to alert and deny traffic to and from known malicious IPs and domains. You can turn this setting off, set it to just alert or to both alert and deny. All of the actions are logged.
Filtering
Finally, for filtering, AFW can use both Network Traffic and Application FQDN rules. This means that you can limit traffic to only those explicitly listed within the rule collections. For example, an application rule that only allows traffic to the FQDN – www.nkcode.xyz
understand AFW, and how to configure to your needs. it is excellently documented already and relatively easy to follow. However, there are some aspects of the configuration that warrant further detail.
Once deployed, you must create a Custom Route Table to force traffic to your AFW. In the tutorial, it shows you how to create a route for Internet traffic (0.0.0.0/0), however, you may want the AFW to be your central control point for VNET traffic too. Don’t forget, traffic between subnets is not filtered by default. Routing all traffic for each subnet to AFW could allow you to manage which subnet can route where centrally. For example, if we have three subnets, Web, App, and DB. A single route table applied to each subnet can tunnel all traffic to AFW. On the AFW you can then allow Web to the Internet and the App subnet. The App subnet can access Web and DB but not the Internet and finally, the DB subnet can only access the App subnet. This would all be achieved with a single Network Rule collection.
Similarly, can allow/block specific FQDNs with an Application Rule collection. In the tutorial, a single FQDN is allowed. This means that all others are blocked as that is the default behavior. This might not be practical for your environment and the good news is, you can implement the reverse. With the right priority order, you can allow all traffic except for blocked FQDNs.
Firewall Deployment
$1.25/Hour per firewall deployment
Data Processing
$0.016/GB Processed by the firewall.
Support & SLA
- We provide technical support for all Azure services released to general availability, including Azure Firewall. Support is available through Azure Support starting at $29/month. Billing and subscription management support is provided at no cost.
- We guarantee that Azure Firewall will be available at least 99.95% of the time. To learn more about our SLA, please visit the SLA.
