Azure Firewall is a stateful firewall service with built-in high availability and automatic scaling; it creates and logs network- and application-level policies, filters with threat intelligence, integrates with Azure Monitor and can sit behind VPN/ExpressRoute gateways for hybrid setups.
flowchart TB I["Internet"] --> FW["Hub VNet<br/>Azure Firewall (AzureFirewallSubnet)"] FW --> D["Spoke Dev"] FW --> T["Spoke Test"] FW --> P["Spoke Prod"] OP["On-prem (VPN)"] --> FW %% step I: Inbound internet traffic reaches Azure Firewall in the hub VNet, in the subnet named AzureFirewallSubnet. %% step FW: The firewall applies its DNAT, network and application rules and forwards only allowed traffic. %% step D: Spoke VNets (Dev, Test, Prod) peer with the hub. Peering is not transitive, so spoke-to-spoke traffic goes through the firewall. %% step OP: On-prem traffic arrives over the VPN and is inspected by the same firewall.
The recommended design is hub-spoke: the firewall and shared services sit in the hub, each environment in a spoke peered to the hub; spoke route tables send traffic through the firewall.
| Rule type | Used for |
|---|---|
| DNAT rule | Translating inbound connections (firewall public IP:port → internal IP:port) |
| Network rule | Filtering by source, protocol, destination port and address (L3/L4) |
| Application rule | Allowing outbound FQDNs (for example *.ubuntu.com) from a subnet (L7, HTTP/S) |
| NSG | Azure Firewall | |
|---|---|---|
| Placement | Attached to each subnet/NIC | Central service in the hub |
| Layer | L3/L4 | L3–L7, FQDN filtering, threat intelligence |
| Cost | Free | Paid per hour and per data processed |
In the CLI, the az network firewall group lives in the azure-firewall extension (installed automatically on first use, or ahead of time with az extension add --name azure-firewall). The firewall needs a subnet named exactly AzureFirewallSubnet.
| Command | Meaning |
|---|---|
az extension add --name azure-firewall |
Install the extension |
az network firewall list -g rg-devops-lab -o table |
List firewalls |
SKUs
| SKU | Suited for | Adds |
|---|---|---|
| Basic | Small businesses, low throughput | Core L3–L7 filtering and threat intelligence alerts |
| Standard | Most enterprise hubs | Threat intelligence deny mode, DNS proxy, web categories, autoscaling |
| Premium | Regulated or sensitive workloads | TLS inspection, IDPS (signature-based intrusion detection), URL filtering |
Firewall Policy
Rules live in a Firewall Policy resource rather than on the firewall itself. A policy contains rule collection groups, each with rule collections that have a priority and an allow or deny action. One policy can be shared by several firewalls, and a child policy can inherit a parent's base rules, which suits a central security team with local exceptions. Azure Firewall Manager manages policies across regions and subscriptions.
Processing order matters: DNAT rules are applied first, then network rules, then application rules. If a network rule allows the traffic, application rules are not checked for it.
Routing traffic through it
A firewall only filters traffic that reaches it. Spoke subnets need a route table with 0.0.0.0/0 (and often other spokes' ranges) pointing to the firewall's private IP as a virtual appliance. Forced tunnelling sends internet-bound traffic onward to an on-premises device when policy requires it.
Logs and cost
Send firewall logs to Log Analytics through a diagnostic setting; the structured resource-specific tables make queries like "top denied destinations" easy with KQL. A firewall bills per hour even when idle, so a lab firewall can be stopped with Azure PowerShell ($fw.Deallocate() followed by Set-AzFirewall) and started again later. Third-party network virtual appliances (NVAs) from vendors such as Palo Alto or Fortinet are an alternative when a team already uses those products.