Azure Firewall Basic, Standard or Premium for a landing zone hub

The firewall is the most expensive and most consequential component in the hub, and the SKU you choose decides which controls you can offer workload teams.

Azure Firewall is a managed, stateful network security service with built-in high availability. In the hub-spoke reference it is the primary egress point from spokes to the internet, can inspect inbound traffic with intrusion detection and prevention rules, and can act as a DNS proxy so that FQDN-based rules work. It comes in three SKUs:

Learn’s sizing advice is to choose the lowest SKU that meets your security and throughput requirements. Basic suits small or medium environments; Standard adds enterprise features; Premium adds advanced threat protection for sensitive workloads such as payment processing. CAF recommends Premium when you need TLS inspection, IDPS, URL filtering or web categories (web categories are also in Standard).

Several deployment details are easy to miss:

• AzureFirewallSubnet must exist, with at least /26, and it doesn’t support network security groups.
• The management NIC. CAF now recommends deploying Azure Firewall with the management NIC enabled, because features such as HTTP header insertion depend on it, not only forced tunnelling. Create AzureFirewallManagementSubnet (minimum /26) in advance, give the management NIC a public IP, and avoid associating your own route tables with that subnet. Basic firewalls and all secured-hub firewalls always have it; for Standard and Premium you must enable it manually during the create process.
• Policy at scale. Create a global firewall policy, assign it to every firewall, and delegate incremental regional policies to local security teams through Azure RBAC. Use IP Groups when the same ranges recur across rules and firewalls.
• DNS consistency. Because of how FQDN application rules work, every resource that egresses through the firewall should use the same DNS provider as the firewall; including the firewall’s DNS proxy in spoke resolution keeps them in step.

When an NVA is justified

CAF says the landing zone architecture is fully compatible with partner NVAs when an organisation prefers them or when native services don’t meet a requirement. If you go that way, follow the vendor’s guidance to confirm the deployment is supported, highly available and free of conflicting Azure configuration, deploy the NVAs in the central hub (for non-Virtual WAN topologies), and consider Azure Route Server to exchange routes with the NVA over BGP instead of maintaining route tables. The Architecture Center’s case for its own hub includes freedom over NVA sizing and the use of NVAs that Virtual WAN doesn’t support. Learn also notes that a shared Azure Firewall consumed by many workloads can save significant cost compared with other NVAs.

Common pitfall: Starting on Basic and later promising teams FQDN network rules - Basic has no DNS proxy and only application-level FQDN filtering, while FQDN filtering in network rules needs the DNS proxy; decide which controls the platform offers before choosing the SKU.

Get the whole book

This note is one section of Azure Landing Zones: Building an Azure Foundation with the Cloud Adoption Framework, an independent guide in the Ultra Transcenders Beyond the Exam series, with comparison tables, diagrams, the common pitfalls and tested companion code, plus a glossary linked to Microsoft Learn.

About the book · Azure Landing Zones terms in the glossary · All free notes from Azure Landing Zones