Home / Azure

AzureHow-toAdvanced

Optimization: Azure Firewall policy clean-up, SKU choice and cost control

Firewall policies collect years of one-off rules, and every environment runs a Premium firewall around the clock. Use Policy Analytics and logs to find unused and overlapping rules, restructure collections with IP Groups, match the SKU to the features you use, and deallocate non-production firewalls out of hours.

Deepak Bhardwaj4 min read

Applies toAzure Firewall Basic, Standard and Premium with Firewall Policy; Azure Firewall structured logs in Log Analytics; Policy Analytics

What builds up

  • Hundreds of rules, many allowing * ports "temporarily".
  • Duplicate rules in different collections; rules for decommissioned servers.
  • Premium SKU everywhere, but TLS inspection and IDPS used nowhere.
  • Dev/test firewalls billed 24×7.

1. Turn on the right logs

Use resource-specific (structured) logs to Log Analytics: AZFWNetworkRule, AZFWApplicationRule, AZFWNatRule, AZFWThreatIntel, AZFWIdpsSignature, plus the Fat flow and Flow trace logs only when needed (they're verbose). Enable Policy Analytics on the firewall policy.

2. Find unused and hot rules

Rule hit counts from logs (30–90 days):

AZFWNetworkRule
| where TimeGenerated > ago(30d)
| summarize hits = count() by Policy, RuleCollectionGroup, RuleCollection, Rule, Action
| sort by hits asc

Compare against the full rule list exported from the policy (az network firewall policy rule-collection-group list). Rules with zero hits over a full business cycle (including month-end and patch windows) are candidates for removal. Policy Analytics also shows rule hits, overlapping/shadowed rules and suggestions.

3. Clean up safely

Finding Action
Zero hits for 90 days Confirm with the owner, then remove (the policy export below is your rollback)
Overly broad (* ports, /16 ranges) with low real use Replace with the actual ports/destinations seen in logs
Duplicates across collections Keep one, in the collection matching its purpose
Hard-coded IP lists repeated in many rules Move to IP Groups
FQDN rules for SaaS services Use FQDN tags / service tags where available

Export the policy as a template before each clean-up so you can restore a rule quickly:

az network firewall policy show -g rg-hub -n fwpol-prod -o json > fwpol-prod-$(date +%F).json
az network firewall policy rule-collection-group list -g rg-hub --policy-name fwpol-prod -o json >> fwpol-prod-$(date +%F).json

4. Structure for performance and sanity

  • Rule collection priority: put the highest-hit allow collections first; processing stops at the first match.
  • Group by application or spoke, with clear names and descriptions linking to the owner/ticket.
  • Parent/child policies: global baseline (deny lists, shared services) in the parent, per-environment rules in children.
  • Keep the number of IP addresses and FQDNs reasonable. Very large rule sets slow down deployments; check the documented limits.

5. Match SKU to features

Need SKU
Small/branch, low throughput, basic filtering Basic
Standard L3–L7 filtering, threat intel, DNS proxy, FQDN filtering Standard
TLS inspection, IDPS, URL filtering, web categories Premium

If Premium features are off in policy, you're paying for nothing. Moving between Standard and Premium is supported with a documented upgrade/downgrade process (policy tier must match).

6. Deallocate non-production out of hours

# stop
$fw = Get-AzFirewall -Name fw-dev -ResourceGroupName rg-dev-hub
$fw.Deallocate()
Set-AzFirewall -AzureFirewall $fw

# start (VNet and public IP must be supplied again)
$vnet = Get-AzVirtualNetwork -Name vnet-dev-hub -ResourceGroupName rg-dev-hub
$pip  = Get-AzPublicIpAddress -Name pip-fw-dev -ResourceGroupName rg-dev-hub
$fw.Allocate($vnet, $pip)        # forced-tunnel/management-NIC setups use the overload with the management PIP
Set-AzFirewall -AzureFirewall $fw

Run from Azure Automation on a schedule. Everything routed through the firewall stops while it's deallocated, so do this only where that's acceptable.

7. Watch capacity

Metrics: Throughput, SNATPortUtilization, FirewallHealth, FirewallLatencyPng. High SNAT use means adding public IPs or a NAT Gateway (see the SNAT exhaustion Sev1 post); throughput near SKU limits means scaling consideration before cost cuts.

Caution

Never delete a rule only because it had zero hits for two weeks. Quarterly jobs, DR tests and annual processes are exactly the flows that break months later. Use 90 days plus owner confirmation.

Checklist

  • Structured logs and Policy Analytics on
  • Rule hit counts reviewed over 90 days
  • Unused, broad and duplicate rules cleaned with owner sign-off
  • IP Groups and clear collection structure
  • SKU matches features used
  • Non-prod firewalls deallocated out of hours

Related fixes