Teams usually run into the same Azure networking problem: they need stronger traffic control, but they do not want to bolt on a heavy security design that slows everything down. Azure Firewall and Network Security Groups (NSGs) solve different parts of that problem, and choosing the wrong one creates either gaps in protection or unnecessary complexity.
AZ-104 Microsoft Azure Administrator Certification
Learn essential Azure administration skills to manage identity, storage, networking, and security effectively and confidently in real-world scenarios.
View Course →Quick Answer
Azure Firewall is the better choice when you need centralized, stateful network security with logging, threat intelligence, and controlled outbound access. NSGs are better for lightweight subnet and NIC filtering. As of August 2026, most Azure environments use both together: NSGs for segmentation and Azure Firewall for governance, inspection, and compliance evidence.
| Primary role | Centralized stateful network security and traffic inspection |
|---|---|
| Deployment scope | Virtual network hub, secured egress, inbound DNAT, and routed traffic control |
| Rule model | Network rules, application rules, and DNAT rules |
| Best fit | Enterprise governance, outbound control, and compliance logging |
| Operational style | Managed, centralized policy surface with Azure Monitor integration |
| Visibility | Detailed traffic logs and analysis through Log Analytics |
| Typical companion control | NSGs for workload-level segmentation |
| Criterion | Azure Firewall | Network Security Groups |
|---|---|---|
| Cost (as of August 2026) | Higher service and logging cost because it is a managed security layer | Lower-cost foundational network control with minimal overhead |
| Best for | Centralized egress control, threat filtering, and audit-ready policy | Subnet and NIC segmentation, port control, and quick guardrails |
| Key strength | Stateful inspection with application rules, DNAT, and threat intelligence | Simple, fast, distributed packet filtering close to the workload |
| Main limitation | Requires routing design and adds architectural and cost overhead | Does not provide deep inspection, centralized policy, or advanced threat awareness |
| Verdict | Pick when you need one policy plane for governed traffic control | Pick when you need lightweight filtering at the subnet or NIC level |
What Is Azure Firewall, and Why Do Teams Use It?
Azure Firewall is a managed, cloud-native network security service that controls inbound and outbound traffic in Microsoft Azure. It is built for centralized policy enforcement, which means one security team can manage traffic rules across many workloads without deploying and maintaining a traditional virtual appliance.
That matters because cloud network security is not just about blocking ports. It is also about controlling where workloads can connect, documenting those controls, and proving that the rules are being enforced consistently. Azure Firewall supports network rules, application rules, and DNAT for inbound translation, so it can handle both basic transport-layer filtering and more specific destination-based policies.
How Azure Firewall works in practice
In a hub-and-spoke design, traffic from spoke virtual networks is often routed through a central hub where Azure Firewall sits as the inspection point. That gives architects a single place to enforce internet egress policy, block risky destinations, and log traffic for investigation. This is one reason Azure Firewall shows up in enterprise landing zones and secured virtual WAN designs.
Azure Firewall also includes built-in threat intelligence filtering, which can alert on or deny known malicious destinations. Microsoft documents the service and its rule model in Azure guidance, and the service integrates with Azure Monitor and Log Analytics for operational visibility.
Azure Firewall is not just a port filter. It is a managed control point for governed traffic, logging, and outbound policy enforcement.
- Network rules control traffic by IP, port, and protocol.
- Application rules control outbound web access using fully qualified domain names.
- DNAT rules translate inbound traffic to internal private addresses.
- Threat intelligence helps identify risky destinations before they become an incident.
For administrators preparing for the AZ-104 Microsoft Azure Administrator Certification, this topic matters because Azure network design is never isolated from operations. If you understand when to use Azure Firewall, you are already thinking like the person who has to keep the environment secure, supportable, and auditable.
Microsoft’s official Azure Firewall documentation is the best reference for current feature behavior and configuration guidance: Microsoft Learn: Azure Firewall. For logging and diagnostics, Microsoft’s monitoring guidance is equally important: Microsoft Learn: Azure Monitor.
What Are Network Security Groups, and What Are They Designed to Do?
Network Security Groups (NSGs) are distributed traffic-filtering controls in Azure that apply at the subnet or network interface level. They are designed for simple allow-and-deny decisions based on source, destination, port, and protocol. In plain terms, they are the lightweight guardrails that keep workloads separated and reduce unnecessary exposure.
NSGs are usually the first network security control teams learn in Azure because they are easy to create and easy to attach. A subnet NSG can block inbound RDP or SSH, restrict access between app tiers, and limit east-west traffic between workloads. A NIC-level NSG can add a more specific control layer for a single virtual machine or workload.
Why NSGs are so common
NSGs are popular because they are fast to deploy and close to the workload. That makes them ideal for basic segmentation, especially when a team needs to harden a subnet without redesigning the entire network. They are also a good fit for teams that want local control instead of a centralized inspection path.
Azure evaluates NSG rules in priority order, and the most specific rule wins based on the rule set and direction. Microsoft documents the rules and evaluation behavior in its official network security guidance: Microsoft Learn: Network Security Groups overview.
Note
NSGs are excellent for segmentation, but they are not a replacement for centralized inspection, policy governance, or threat-aware outbound control.
- Subnet-level NSGs help define boundaries for groups of workloads.
- NIC-level NSGs help lock down a single VM or service endpoint.
- Allow and deny rules provide basic traffic control without deep inspection.
- Priority ordering keeps the rule model predictable when designed carefully.
NSGs are a foundational Azure control, not a full enterprise firewall strategy. That is why many environments use them alongside Azure Firewall instead of treating them as competing products.
For anyone studying Azure architecture, it helps to think of NSGs as local enforcement and Azure Firewall as centralized governance. That mental model makes design decisions much clearer.
How Do Azure Firewall and NSGs Differ in Scope and Enforcement?
The biggest difference is scope. Azure Firewall enforces policy from a centralized location, while NSGs enforce rules at the subnet or network interface. Azure Firewall is designed for broad traffic governance. NSGs are designed for local filtering at the boundary of a workload or subnet.
That difference changes how each tool fits into an Azure architecture. Azure Firewall is usually placed in a hub network or secured egress path, where it can examine traffic moving between spokes, to the internet, or toward shared services. NSGs live much closer to the workload, so they are ideal for blocking ports or restricting lateral movement inside a segment.
| Azure Firewall | Centralized control for routed traffic, egress policy, and inspection |
|---|---|
| NSGs | Distributed control for subnet and NIC boundaries |
This is why the two services are not substitutes. They solve different enforcement problems. Azure Firewall answers, “What traffic should be allowed across the network boundary?” NSGs answer, “What traffic should be allowed into this subnet or VM?”
A good cloud security design often uses both. For example, a finance application might use NSGs to isolate the web, app, and data tiers, while Azure Firewall controls outbound internet access and logs all traffic to approved destinations. That layered approach improves cloud security without making every rule change a major event.
Centralized and distributed enforcement are not rivals. They are two layers of the same security model.
Microsoft’s Azure networking architecture guidance explains how routed designs, hub-and-spoke topologies, and security boundaries fit together: Microsoft Learn: Azure networking architecture. That guidance is useful when deciding where the firewall belongs and where NSGs are enough.
Which Option Is Easier to Manage at Scale?
Azure Firewall is usually easier to govern at scale because it gives teams one policy plane for many workloads. NSGs can be simple at first, but they become harder to manage when every subnet, NIC, or application team creates its own rule set. That is where rule sprawl starts to undermine consistency.
Centralized rule management matters when you have multiple subscriptions, shared services, and different operational teams. A security team can own Azure Firewall policy, while platform teams use NSGs to handle local segmentation. That division of labor helps reduce duplication and makes change control more predictable.
When NSG management becomes messy
NSGs are perfectly fine in a small environment with a few subnets. The problem appears when the environment grows and every workload needs a custom exception. Suddenly, the same port is being opened in five places, ownership is unclear, and nobody is confident that the rules still match the intended design.
Azure Firewall reduces that burden by letting teams centralize common rules such as internet destinations, known application endpoints, and approved partner services. It does not remove the need for governance, but it does make governance practical. The policy model is easier to standardize, audit, and review.
Pro Tip
If different teams are editing their own NSGs every week, you already have a governance problem. That is usually the point where centralized policy starts paying for itself.
- Use Azure Firewall for shared outbound policy and enterprise standards.
- Use NSGs for local, workload-specific filtering.
- Separate ownership when security and platform teams need different control planes.
- Reduce duplication by standardizing common rules where possible.
If you are studying for AZ-104, this is exactly the kind of tradeoff a real Azure administrator has to explain in a design review. You are not just memorizing services. You are choosing the right operating model.
Microsoft’s official guidance on Azure governance and network design pairs well with the broader Azure Firewall documentation already cited. For administrators, that combination is more useful than any feature list alone.
Does Azure Firewall Provide Better Security Depth Than NSGs?
Yes, Azure Firewall provides deeper security capabilities than NSGs because it can inspect traffic at a more policy-driven level. NSGs only make allow-or-deny decisions based on source, destination, port, and protocol. Azure Firewall can also enforce application-level rules and evaluate destinations more intelligently.
That matters most for outbound traffic. A simple NSG rule might allow HTTPS to anywhere on port 443. Azure Firewall can be configured to allow access only to specific fully qualified domain names, which is much more controlled than broad port access. That difference is important for malware prevention, data exfiltration reduction, and application governance.
Azure Firewall also adds threat intelligence filtering. Microsoft can flag or block traffic to destinations associated with known malicious activity, which helps organizations raise their baseline defense without building a custom threat feed integration. NSGs do not provide that kind of awareness.
Basic filtering stops obvious traffic. Centralized firewall policy helps stop risky traffic from looking “normal” just because it uses an allowed port.
This is one reason regulated environments often prefer Azure Firewall for egress governance. If you need to prove that outbound traffic is constrained, logged, and reviewed, a centralized firewall is far easier to justify than scattered NSG rules. That does not make NSGs less useful. It just makes them the wrong tool for the deeper control problem.
For threat modeling and control design, it is also helpful to compare Azure Firewall with industry frameworks such as NIST guidance and CIS Controls. Those frameworks consistently emphasize least privilege, segmentation, logging, and monitoring rather than relying on a single point control.
From an Azure administrator’s perspective, the takeaway is simple: NSGs keep traffic narrow. Azure Firewall helps keep traffic intentional.
How Do Logging and Audit Requirements Change the Decision?
Logging is one of the strongest reasons to choose Azure Firewall over NSGs for enterprise security design. Azure Firewall integrates with Azure Monitor and Log Analytics, which gives teams richer visibility into traffic patterns, denied connections, and rule matches. That makes it easier to investigate incidents, validate changes, and support audit requests.
NSGs can be logged, but the operational value is usually lower for broad security analysis. They are useful for confirming that traffic was allowed or denied, but they do not provide the same centralized view of application destinations, routed flows, or policy context. For audits, that difference matters because auditors often want evidence of who accessed what, when, and under which rule.
What good audit evidence looks like
Good evidence answers specific questions quickly. Which rule allowed the traffic? Was the connection expected? Was it denied because of a known malicious destination? Was the policy changed recently? Azure Firewall logs make those answers much easier to produce because the control point is centralized.
That also helps incident response. When a suspicious server starts making unexpected outbound connections, the firewall logs can show the destination, the rule that matched, and the time of the event. That is much more helpful than trying to piece together scattered subnet-level decisions from multiple NSGs.
Warning
If you need audit-ready traffic evidence, do not assume NSGs alone will give you enough context. Build logging requirements into the design before the deployment goes live.
- Azure Firewall logs are better for centralized investigation and change review.
- NSG logs are better for narrow rule validation and local troubleshooting.
- Log Analytics helps preserve queryable evidence over time.
- Incident response improves when the control point is centralized.
For compliance-minded teams, this distinction matters as much as the traffic rules themselves. Security controls that cannot be explained or evidenced are harder to defend during review.
What About Performance, Latency, and Network Design?
NSGs are lightweight because they are applied close to the workload and do not require traffic hairpinning through a central inspection path. That makes them a low-friction option when the main goal is simple segmentation and minimal overhead. Azure Firewall adds more processing, more routing complexity, and more architectural planning because traffic must be directed through the firewall path when inspection is required.
This routing design is not a flaw. It is the tradeoff you accept when centralized control matters more than simplicity. In a hub-and-spoke model, user-defined routes often steer traffic through Azure Firewall before it reaches the internet or another network segment. That gives you governance, but it also means you need to think carefully about path length, throughput, and application sensitivity.
When performance matters most
Performance planning becomes especially important when all outbound traffic is forced through a firewall for inspection. If an application is latency-sensitive or generates high-volume east-west traffic, the architecture should be designed deliberately. The point is not to avoid Azure Firewall. The point is to place it where the inspection benefit justifies the traffic path.
NSGs are often preferred for local boundaries because they do not change routing behavior in the same way. That makes them easier to deploy in environments where simplicity and speed matter more than centralized inspection. Still, they cannot replace the policy depth that a firewall provides.
| NSGs | Minimal routing impact and fast local enforcement |
|---|---|
| Azure Firewall | More control and visibility, but more design and routing overhead |
Microsoft’s Azure architecture documentation is the best place to evaluate routing patterns, hub design, and traffic flow implications: Microsoft Learn: Azure architecture center. That resource helps you connect security design to workload performance instead of treating them as separate problems.
How Do Cost and Operational Investment Compare?
NSGs are usually the lower-cost option because they are a basic network control rather than a full managed security service. Azure Firewall is a larger investment because it adds centralized policy enforcement, logging, and deeper inspection. In other words, you are paying for governance, not just a rule engine.
The real cost discussion is not just service pricing. It also includes logging volume, routing complexity, operations time, and the overhead of managing exceptions. A firewall can reduce long-term administrative cost if it replaces dozens of duplicated rule sets and makes audits easier. An NSG can be cheaper up front but more expensive to manage if the environment becomes messy.
How to think about total cost of ownership
When architects evaluate network security in Azure, they should ask what kind of cost they are trying to minimize. If the goal is simply to enforce basic segmentation, NSGs are hard to beat. If the goal is to reduce risk, standardize policy, and produce centralized evidence, Azure Firewall often becomes the better business decision.
This is where compliance and operational overhead intersect. A tool that saves money on day one can become expensive if it creates drift, duplicated effort, or audit remediation later. Azure Firewall is often chosen because it reduces that hidden operational cost.
The cheapest control is not always the least expensive one to run.
- NSGs usually win on direct cost.
- Azure Firewall often wins on control, consistency, and evidence.
- Logging can become a major part of the real cost model.
- Operational ownership should be defined before deployment.
For enterprise decision-making, the question is not “Which tool costs less?” It is “Which tool costs less to operate correctly over time?” That is a much better fit for Azure architecture reviews.
When Should You Pick NSGs?
Pick NSGs when your main requirement is basic segmentation and port-level filtering close to the workload. They are a strong choice for smaller environments, simple application layouts, and teams that want quick guardrails without a central routing design. If the goal is to block management ports, isolate tiers, or limit east-west traffic inside a subnet, NSGs are often enough.
NSGs are especially useful when you do not need deep inspection or centralized outbound governance. A common example is a three-tier application where the web tier, app tier, and data tier each need specific inbound rules, but the organization is not yet ready to centralize all internet egress through a firewall. In that case, NSGs give you immediate value with low implementation overhead.
Typical NSG-friendly scenarios
- Small or medium Azure environments with clear subnet boundaries.
- Workload isolation between app tiers.
- Administrative port restriction such as blocking RDP or SSH.
- Simple east-west control where broad policy governance is not required.
NSGs are also a sensible first line of defense in a well-designed Azure environment. They help teams establish secure defaults early, before more advanced policy layers are needed. That makes them practical for fast-moving projects that still want a baseline security posture.
If you are learning Azure administration through the AZ-104 Microsoft Azure Administrator Certification path, this is one of the core design judgments you should be able to explain: use NSGs for local control when the security requirement is narrow and the network design is simple.
When Should You Pick Azure Firewall?
Pick Azure Firewall when your organization needs centralized outbound control, stronger logging, or consistent policy enforcement across many workloads. It is the better choice for enterprise environments with multiple subscriptions, shared services, regulated data, or a need to prove that traffic is being controlled and reviewed.
Azure Firewall shines when the environment needs one place to manage egress policy. If security, operations, and compliance teams need to know which destinations are allowed, why they are allowed, and how that rule is logged, Azure Firewall is the more appropriate tool. It is also the better option when application-level filtering matters, such as allowing only specific FQDNs instead of broad port access.
Typical Azure Firewall use cases
- Centralized internet egress control across multiple spokes or subscriptions.
- Inbound DNAT for carefully managed public exposure.
- Application-level allow lists for controlled web access.
- Compliance evidence through centralized logs and traffic records.
- Threat-aware filtering for known malicious destinations.
Azure Firewall is also the right choice when rule duplication is becoming a problem. If every team is copying similar NSG rules into new subnets, you have drift. A centralized firewall policy can reduce that drift and make governance much easier to enforce.
For organizations that care about audit readiness and consistent enforcement, Azure Firewall gives a stronger story than a pile of local rules ever will. That is why it is so common in landing zones, enterprise connectivity designs, and security-first Azure deployments.
Microsoft’s official firewall documentation remains the best source for current configuration guidance and supported scenarios: Microsoft Learn: Azure Firewall.
Why Do Many Organizations Use Azure Firewall and NSGs Together?
Most mature Azure environments use both because they solve different problems. Azure Firewall gives centralized inspection and governance. NSGs give local segmentation and workload-level guardrails. Used together, they create a layered defense model that is stronger than either service alone.
A common pattern is to use NSGs to restrict traffic between subnets and NICs, while Azure Firewall handles shared outbound traffic and central internet access. That setup keeps the workload boundaries tight without forcing every single decision into one tool. It also gives security teams a single policy layer for the rules that truly need centralized control.
This layered approach is especially useful in hub-and-spoke architectures. Shared services can be protected by NSGs, spoke workloads can be isolated from each other, and Azure Firewall can inspect traffic entering or leaving the hub. The result is cleaner governance with less risk of overlapping control gaps.
Use NSGs where traffic needs local boundaries. Use Azure Firewall where traffic needs centralized judgment.
That division also helps different teams work more effectively. Platform teams can own subnet design and workload hardening. Security teams can own the broader outbound policy and threat controls. The outcome is usually better than forcing one team to manage everything in one control surface.
If your Azure architecture feels too simple for a firewall, start with NSGs. If it feels too fragmented for local-only rules, add Azure Firewall. Many organizations arrive at the same conclusion from opposite directions.
How Do You Decide Which Control Is Right for Your Organization?
The right decision starts with the problem you are actually trying to solve. If you need basic segmentation, NSGs are usually enough. If you need centralized security governance, richer logging, or controlled outbound policy, Azure Firewall is the better fit. If you need both local control and enterprise oversight, use both.
Decision factors that usually change the answer
- Use case: segmentation versus centralized policy.
- Scale: a few subnets versus many subscriptions and spokes.
- Compliance: basic hardening versus audit-ready evidence.
- Operations: distributed ownership versus centralized governance.
- Architecture: direct subnet control versus routed hub-and-spoke design.
One simple rule works well in practice: use NSGs for local control, Azure Firewall for centralized policy, and both when the environment needs layered protection. That rule is easy to remember and matches how Azure is commonly designed in production.
| Choose NSGs first when… | You need fast, low-cost, workload-level filtering |
|---|---|
| Choose Azure Firewall first when… | You need centralized egress policy, logging, and threat filtering |
For design reviews, this framework works well: ask whether the control must be centralized, whether logging must be audit-ready, and whether the traffic needs deep policy enforcement. If the answer to those questions is yes, Azure Firewall moves to the front of the line.
What Are the Most Common Mistakes to Avoid?
The most common mistake is treating Azure Firewall and NSGs as interchangeable. They are not. NSGs are not a replacement for a firewall, and a firewall is not a substitute for good subnet-level segmentation. Confusing those roles leads to weak designs and messy rule ownership.
Another mistake is overusing NSGs in a large environment without a governance model. It is easy to create dozens of one-off exceptions and lose track of what each rule was meant to protect. When that happens, the network may still be “secure” on paper, but it is no longer maintainable.
Other mistakes that show up often
- Ignoring routing when designing Azure Firewall placement.
- Skipping logging and then struggling during an audit or incident.
- Choosing based on cost alone instead of total operational impact.
- Letting teams duplicate rules across subnets and subscriptions.
Designing network security in Azure also means understanding the broader architecture. If you place Azure Firewall without planning routes, policy ownership, and log retention, you may end up with a technically correct deployment that nobody can operate cleanly. That is a bad trade.
For reference, the Microsoft Azure architecture center and Azure Firewall documentation both provide the practical context needed to avoid those mistakes. They are the right sources to consult before you commit to a specific pattern.
Why Does This Matter for AZ-104 and Real Azure Design Work?
This comparison matters because Azure administrators are often asked to make real tradeoffs, not just configure resources. The AZ-104 Microsoft Azure Administrator Certification focuses on the kind of operational judgment that determines whether a network design is maintainable, secure, and supportable.
In interviews and design discussions, you may be asked which control should be used for subnet segmentation, which should be used for centralized egress, and why. The correct answer is rarely “one or the other.” More often, it is a layered design that balances local filtering with centralized governance. That is exactly the kind of thinking expected in real Azure operations.
Good Azure design is not about picking the strongest tool. It is about picking the simplest tool that fully meets the requirement.
This topic also reinforces a broader administrator skill: understanding scope. NSGs control local boundaries. Azure Firewall controls centralized policy. If you can explain that clearly, you are already communicating at the level expected in architecture reviews and day-to-day cloud operations.
For supporting study and practical implementation guidance, Microsoft Learn remains the authoritative source for Azure networking and security services. That is the right place to verify current behavior before you implement anything in production.
Key Takeaway
Azure Firewall is the right tool for centralized, stateful traffic control with logging and threat intelligence.
NSGs are the right tool for lightweight subnet and NIC filtering close to the workload.
Most production Azure environments use both to combine segmentation with governed inspection.
Centralized logging and audit evidence usually push the decision toward Azure Firewall.
Simple segmentation and low overhead usually push the decision toward NSGs.
AZ-104 Microsoft Azure Administrator Certification
Learn essential Azure administration skills to manage identity, storage, networking, and security effectively and confidently in real-world scenarios.
View Course →Conclusion
Azure Firewall and NSGs are not competing replacements. They are different controls for different levels of the Azure network stack. Azure Firewall gives you centralized, stateful, logged security control. NSGs give you lightweight local filtering for subnets and network interfaces.
The right choice depends on scale, compliance needs, architecture, and how much operational ownership your team can support. If you only need basic segmentation, NSGs are usually enough. If you need centralized policy, outbound governance, or stronger audit evidence, Azure Firewall is the better fit. In many organizations, the strongest design is not one or the other but both together.
Pick Azure Firewall when you need centralized governance and audit-ready traffic control; pick NSGs when you need simple workload-level segmentation and low overhead. If you want to build that judgment into practical Azure administration skills, the AZ-104 Microsoft Azure Administrator Certification path is a strong place to sharpen it.
Microsoft® and Azure are trademarks of Microsoft Corporation.
