Azure Firewall vs NSGs: When the Free Option Actually Costs More

A post made the rounds on LinkedIn recently arguing that Azure Firewall is a waste of money for most organizations. The claim: NSGs handle 80% of what the firewall does, for free. Drop the firewall, save $11,000 a year, reduce latency.

It is a compelling argument. It is also incomplete.

I have deployed Azure Firewall in hub-spoke environments and I have ripped it out of environments where it didn’t belong. Both decisions were right in their context. The nuance matters more than the headline.

Where the LinkedIn post is right

Azure Firewall Standard costs around $912/month just to exist, before you process a single byte. That is real money. If your firewall logs show nothing but L3/L4 allow/deny rules on IPs and ports, you are paying premium pricing for something NSGs do natively at no cost.

Spoke-to-spoke traffic routed through a hub firewall adds 2-3ms of latency per hop. For microservices calling each other across spokes, that compounds. Direct VNet peering between spokes eliminates that overhead.

And yes, many teams deploy Azure Firewall because the Cloud Adoption Framework reference architecture includes it, not because they evaluated whether they need it. “It was in the diagram” is not an architecture decision.

All fair points.

Where it falls apart

NSGs cannot filter egress by FQDN

This is the single biggest gap. An NSG rule can allow or deny traffic based on IP addresses, service tags, and ports. It cannot say “allow outbound HTTPS to *.blob.core.windows.net and deny everything else.”

Azure Firewall application rules can. That distinction matters as soon as you care about controlling what your workloads talk to on the internet. A VM that can reach any IP on port 443 is a VM that can exfiltrate data to any HTTPS endpoint in the world. An NSG with Allow 443 Outbound is not a security control in any meaningful sense. It is a door propped open.

For NIS2-regulated environments, unrestricted outbound connectivity is a compliance finding. The auditor will ask how you prevent data exfiltration. “We have NSGs” is not the answer they want.

NSG logging is not equivalent

Azure Firewall logs every connection attempt with the matched rule name, source, destination, FQDN (for application rules), protocol, and action. These logs flow to Log Analytics and are queryable with KQL immediately.

NSG flow logs exist, but they are a different beast. They log at the network interface level, they require a separate storage account and either Traffic Analytics or a custom pipeline to make them useful, and they do not capture FQDNs. The raw flow log format is a compact CSV that needs parsing before you can answer basic questions like “what external domains did this VM connect to yesterday?”

The firewall gives you that answer in one KQL query:

AzureDiagnostics
| where Category == "AzureFirewallApplicationRule"
| where TimeGenerated > ago(24h)
| where msg_s has "to"
| parse msg_s with * "request from " srcIp ":" srcPort " to " destFqdn ":" destPort ". Action: " action "."
| summarize count() by destFqdn, action
| order by count_ desc

Try getting the equivalent from NSG flow logs. You will end up building a pipeline that costs more in engineering time than the firewall costs in monthly fees.

Distributed NSG management does not scale

The LinkedIn post compares one firewall to one NSG. In practice, a hub-spoke environment with 10 spokes has 30-50 NSGs across application subnets, data subnets, and management subnets. Each NSG has its own rule set. Each rule set needs to stay consistent with your security baseline.

Azure Firewall gives you one policy, applied centrally. Firewall Policy supports rule collection groups with priority ordering, and Firewall Manager extends that across multiple VNets and regions. Changes happen in one place.

With NSGs, you either manage each one individually (drift guaranteed) or you build automation to sync rules across all of them (congratulations, you just built a firewall management plane with extra steps). Azure Policy can enforce baseline NSG rules, but that covers the “deny” side. Centralized allow-listing of approved destinations is what the firewall does.

Threat intelligence and IDPS are not optional extras

The LinkedIn post acknowledges that Azure Firewall provides threat intelligence and IDPS but treats them as nice-to-haves. For internal line-of-business apps with no regulatory requirements, maybe.

For anything else: Azure Firewall’s threat intelligence feed automatically blocks known-malicious IPs and domains. IDPS (available on Premium) inspects traffic for exploit patterns. These are not features you replicate with NSGs at any price. You either have them or you don’t.

If your security team runs Microsoft Sentinel, the Firewall diagnostic logs feed directly into your SIEM with structured fields. That integration is worth more than the $912/month for many SOC teams.

The “80% network rules” argument is backwards

The post argues that if 80% of your firewall rules are network rules (L3/L4), you should move that traffic to NSGs. I would argue the opposite: if 80% of your rules are L3/L4, you haven’t started using the capabilities that justify the firewall.

The firewall’s value is in application rules (L7 with FQDN filtering), not in duplicating what NSGs already do. If your firewall policy is just IP allow/deny, the problem is not the firewall. The problem is that nobody configured it properly.

Run this query to see what your firewall is actually doing:

AzureDiagnostics
| where TimeGenerated > ago(7d)
| where Category startswith "AzureFirewall"
| summarize count() by Category

If AzureFirewallApplicationRule is nearly empty and AzureFirewallNetworkRule dominates, your firewall is underused. The fix is adding application rules for egress control, not removing the firewall.

When to actually skip Azure Firewall

There are legitimate cases where Azure Firewall is overkill:

You have a small environment (1-3 VNets) with no internet-facing workloads and no compliance requirements for egress filtering. NSGs with service tags cover your needs. Direct peering between VNets keeps things simple.

You run a dev/test environment where the cost of the firewall exceeds the value of the workloads it protects. NSGs for basic isolation, no centralized inspection.

Your workloads are PaaS-only (App Service, Functions, Container Apps) and all backend connectivity goes through private endpoints. There is no VM-to-internet traffic to filter. NSGs on the integration subnets handle the basics.

In these cases, Azure Firewall is genuine waste. Save the $11K/year.

When you need it

You have compliance requirements (NIS2, DORA, ISO 27001, CIS) that mandate egress filtering and centralized logging. NSGs alone will not satisfy the auditor.

You run IaaS workloads that initiate outbound connections and you need to control which external destinations they can reach. FQDN filtering is the baseline expectation.

You operate at scale (10+ VNets) and need centralized policy management. Distributed NSG management becomes its own operational burden.

Your security team relies on Azure Firewall logs for threat detection and incident response in Sentinel. Removing the firewall creates a visibility gap.

The hub-spoke model needs something in the middle

There is a more fundamental point the LinkedIn post skips over. Hub-spoke networking exists because you need centralized control of traffic between spokes and between spokes and the internet. NSGs sit on subnets inside each spoke. They are not a replacement for the central routing and inspection layer in the hub.

If you remove Azure Firewall from the hub, you still need something there. Your options are:

An Azure Virtual WAN hub with routing intent, which gives you centralized routing but still requires a firewall (Azure Firewall or a third-party NVA) for inspection. You haven’t avoided the cost; you have moved it.

A third-party NVA (Palo Alto, Fortinet, Check Point) in the hub. These typically cost more than Azure Firewall Standard once you factor in licensing, VM compute, high availability pairs, and management overhead. You gain deeper inspection capabilities but at 2-3x the price.

Direct VNet peering between all spokes with NSGs only. This works for small environments but creates an N-to-N peering mesh that becomes unmanageable at scale. You lose centralized logging, centralized policy, and any ability to inspect east-west traffic. At 10+ spokes, you are maintaining 45+ peering connections and hoping every NSG is configured correctly.

The “just use NSGs” argument implicitly assumes you don’t need a hub at all. For some environments that is true. For most enterprise deployments with compliance requirements, it is not.

The real decision framework

The question is not “Azure Firewall or NSGs.” You always have NSGs. They protect at the subnet/NIC level and they are free. The question is whether you also need a centralized inspection point in your hub, and which one.

If your workloads only talk to other Azure services over private endpoints and never initiate outbound internet connections, you probably don’t. If your VMs need to reach external APIs, pull packages from the internet, or send data anywhere outside your VNet, you probably do.

Azure Firewall Basic at roughly $288/month is the middle ground that the LinkedIn post mentioned but dismissed too quickly. It gives you FQDN filtering and centralized logging without the IDPS and TLS inspection costs of Standard or Premium. For environments that need egress control but don’t need deep packet inspection, Basic is often the right tier.

The most expensive firewall is the one that sits in your hub doing nothing useful. The second most expensive option is not having one when the auditor asks how you control egress traffic.