Azure Firewall, network security groups (NSGs), and Web Application Firewall (WAF) all enforce security policy, but they protect different layers and scopes. NSGs provide distributed Layer 3 and Layer 4 filtering at subnet or network-interface boundaries. Azure Firewall provides centralized, stateful network security and broader outbound/inbound policy. WAF specializes in protecting HTTP and HTTPS applications from application-layer attacks.
For AZ-700, the architectural decision is usually not “which one should I buy?” It is where a security decision must be enforced and what information that control must understand. A subnet rule based on source IP and destination port is an NSG problem. Centralized egress inspection is an Azure Firewall problem. Blocking malicious HTTP request patterns is a WAF problem.
Strong Azure designs often use more than one of these controls because network segmentation, centralized inspection, and web-application protection address different attack paths.
NSGs provide distributed subnet and NIC filtering
An NSG contains allow and deny rules evaluated against attributes such as source and destination IP, port, protocol, and traffic direction.
NSGs can be associated with subnets and network interfaces, which makes them useful for placing controls close to workloads.
Examples include:
- allow HTTPS from an application subnet to a service subnet
- deny direct database access from user networks
- allow management traffic only from a designated administrative range
- restrict inbound traffic to the ports a workload actually needs
NSGs are stateful, so return traffic for an allowed connection is handled appropriately without requiring a mirrored rule for the response flow.
The broader concept of firewalls helps explain stateful policy. In Azure architecture, NSGs apply that principle as a distributed segmentation control rather than as a centralized inspection appliance.
NSGs do not provide application-aware web protection
An NSG can distinguish TCP from UDP and port 443 from port 22. It does not understand whether an HTTPS request contains SQL injection, cross-site scripting, a malicious path, or an abusive request body.
That boundary is important. Encrypting web traffic with TLS does not make an NSG “Layer 7 aware.” From the NSG’s perspective, the flow is still primarily a network connection described by addresses, ports, protocol, and direction.
NSGs also do not provide centralized FQDN-based outbound policy or the same cross-network inspection role as Azure Firewall.
This does not make NSGs weak. It makes them precise tools for segmentation. They are most effective when used to enforce least-privilege connectivity between network zones and workload tiers.
Azure Firewall centralizes broader network policy
Azure Firewall is a managed, stateful firewall service designed to protect virtual-network and branch traffic at a central enforcement point.
It becomes useful when many networks need shared policy such as:
- centralized internet egress
- branch-to-Azure inspection
- spoke-to-spoke inspection
- DNAT and SNAT behavior
- application rules based on FQDNs
- network rules for ports and protocols
- threat-intelligence filtering
- premium inspection features where required
This centralized model is common in hub-and-spoke and Virtual WAN architectures. Rather than duplicating every egress rule across dozens of spokes, the organization routes selected traffic through Azure Firewall and manages policy centrally.
The crucial word is routes. Azure Firewall protects only traffic that reaches it. If a route allows two VNets to communicate directly or a workload sends internet traffic through another path, the firewall does not inspect that flow merely because the firewall exists in the hub.
For larger estates, Azure Firewall Policy can centralize and inherit rule collections across multiple firewall instances. That is useful when enterprise-wide deny or allow requirements should remain consistent while regional or application-specific rules are delegated. Policy hierarchy should be designed carefully so local teams know which controls they can change and which parent rules are intentionally non-negotiable.
WAF protects HTTP and HTTPS applications at Layer 7
Azure WAF is specialized for web application traffic. It can inspect HTTP/S requests and apply managed or custom rules intended to detect application-layer attacks.
WAF is available with services such as Application Gateway and Azure Front Door. That gives architects two common placement models:
- regional WAF near Azure workloads through Application Gateway
- global edge WAF through Azure Front Door
WAF is the appropriate control when the requirement involves web-specific threats such as malicious request patterns, protocol anomalies, or common OWASP attack categories.
It is not a general replacement for network segmentation. A WAF does not decide which VM may open an SSH session to a management subnet, nor does it replace centralized outbound policy for arbitrary protocols.
WAF deployments also need a tuning lifecycle. Managed rules are valuable because they recognize common attack patterns, but production applications can trigger false positives. A safe rollout often starts with monitoring or detection, analyzes legitimate traffic that matches rules, and then moves toward blocking with narrowly scoped exclusions where necessary. Broadly disabling rule groups to solve one application issue weakens every request that depends on those protections.
Azure Firewall and WAF can protect the same application for different reasons
A web application can legitimately use both Azure Firewall and WAF.
Microsoft’s architecture guidance documents patterns in which Application Gateway WAF protects HTTP/S applications while Azure Firewall protects broader inbound, outbound, and east-west traffic.
For example:
- Front Door or Application Gateway WAF examines incoming web requests.
- Azure Firewall controls outbound access from application components.
- NSGs restrict which subnets and NICs may communicate.
These controls form defense in depth because each sees a different part of the traffic and understands different attributes.
The architecture should avoid redundant controls that add latency and troubleshooting difficulty without reducing a meaningful risk. Multiple layers are justified when their enforcement responsibilities are distinct.
Placement determines what the control can see
Security products cannot inspect traffic that bypasses them.
With Azure Firewall, the route table, Virtual WAN routing intent, or gateway design must direct the required traffic through the firewall. With WAF, the application’s public or private ingress path must terminate on the WAF-enabled service. With NSGs, the association must be on the correct subnet or NIC and the effective rules must permit or deny the intended flow.
This creates a useful troubleshooting model:
- Determine the actual source and destination.
- Identify the route the packet follows.
- List every enforcement point on that path.
- Determine which layer is capable of making the required decision.
- Inspect logs at the control that should have enforced the policy.
A rule can be correct and still ineffective if the traffic never encounters it.
Outbound security is where Azure Firewall often adds the most value
Many architectures focus on inbound protection while allowing workloads broad internet access.
Azure Firewall can centralize outbound application and network rules, allowing the organization to define which destinations or services workloads may reach. Microsoft specifically notes that Azure Firewall can reduce data-exfiltration risk by enforcing approved outbound destinations in ways NSGs cannot, because NSGs are limited to Layer 3 and Layer 4 attributes and do not provide the same FQDN-oriented application rules.
That capability is especially useful for spoke networks where application teams should not independently create unrestricted egress paths.
Outbound policy should still be practical. Overly granular allow lists without change-management automation can create operational pressure to bypass the firewall entirely.
Logging and policy ownership are part of the design
Each layer produces different evidence.
NSG flow information and related network telemetry can help determine whether subnet-level policy allowed a flow. Azure Firewall logs can show network and application rule decisions, threat-intelligence behavior, and other inspection events. WAF logs show application-layer matches and actions.
Centralized logging is important because incident responders often need to reconstruct the same request across several controls.
Policy ownership should also be separated clearly:
- platform networking teams may own shared Azure Firewall policy
- application teams may request specific allowed destinations
- workload teams may own subnet intent within guardrails
- security teams may own WAF managed-rule posture and exceptions
Change review should consider shadowed or conflicting rules as well as obvious allows. In layered security, an NSG might allow a flow that Azure Firewall later denies, or a WAF might block a request after the network controls have already permitted the connection. Observability needs enough context to identify the enforcement point that actually made the final decision.
Without ownership, rule sets accumulate stale entries and emergency exceptions that weaken the design over time.
Select by enforcement layer and scope
Use NSGs when the rule belongs close to the workload and can be expressed with IP address, port, protocol, and direction.
Use Azure Firewall when policy should be centralized across many networks, when broad stateful inspection or outbound control is required, or when hub/branch traffic must pass through a managed enforcement point.
Use WAF when the protected service is HTTP/S and the security requirement depends on Layer 7 web semantics.
Use them together when a workload has multiple requirements. A common layered design is WAF for malicious web requests, Azure Firewall for centralized network and egress policy, and NSGs for least-privilege subnet segmentation. The important architectural question is not how many controls exist, but whether each control has a distinct job on the real traffic path.