Per-Spoke Azure Firewall Deployments Instead of a Shared Hub Firewall

In decentralized estates, application teams or landing zone templates instead deploy a separate firewall inside each spoke or application virtual network. Every one of those firewalls carries its own fixed hourly deployment fee, so an estate with several firewalls in the same region pays the fee several times for inspection that one firewall could provide.

Microsoft's Azure Firewall FAQ describes the hub-and-spoke model as the typical deployment and notes that it offers cost savings by avoiding a firewall in each virtual network, and the Well-Architected guide lists sharing the same Azure Firewall instance as a cost optimization. The saving is not free: routing spoke traffic through a hub adds virtual network peering data charges, so the consolidation case has to be evaluated against traffic volumes.

Each firewall is billed independently, so the number of deployments drives the fixed part of the bill.

Deployment hour

A fixed hourly fee per firewall deployment by SKU, charged regardless of scale or traffic; partial hours are billed as full hours

Data processed

A per-GB fee for traffic the firewall processes, which moves to the shared firewall on consolidation rather than disappearing

Virtual network peering

Traffic from spokes to a hub firewall crosses peering, which is billed per GB inbound and outbound at both ends, and must be weighed against the removed deployment fees

Firewall policy

A Firewall Manager policy with zero or one firewall association is free; a policy associated with multiple firewalls is billed at a fixed rate

• In Azure Resource Graph, list Microsoft.Network/azureFirewalls with location, SKU tier and the virtual network parsed from properties.ipConfigurations subnet IDs, and count firewalls per region
• Flag regions with more than one firewall where the firewall virtual networks are spokes peered to a common hub, or could be
• For each firewall, find route tables whose routes use the firewall's private IP as next hop to see which subnets actually depend on it and how much traffic each carries (DataProcessed metric)
• Check for unexpected cross-region traffic through firewalls, which the Well-Architected guide calls out when sharing instances
• In Cost Management, total the fixed deployment-hour charges of firewalls in the same region to size the saving from consolidation

• Consolidate to one firewall per region in the hub virtual network or a Virtual WAN secured hub, and point spoke subnets at it with user-defined routes or Virtual WAN routing intent
• Keep team-specific rules by using Firewall Manager policy hierarchy, with a central base policy and child policies per application, instead of separate firewalls
• Model the added virtual network peering charges for spoke traffic that will now traverse the hub before decommissioning spoke firewalls
• Keep one firewall per region in multi-region designs, as the Well-Architected reliability guidance recommends, rather than routing across regions to a single firewall
• Deallocate and delete the spoke firewalls after cut-over, and remove their public IPs

• Architecture Best Practices for Azure Firewall - Microsoft Azure Well-Architected Frameworklearn.microsoft.com
• Azure Firewall FAQlearn.microsoft.com
• Pricing - Azure Firewallazure.microsoft.com
• FinOps best practices for Networkinglearn.microsoft.com
• Monitoring data reference for Azure Firewalllearn.microsoft.com