3.3.5. Azure Firewall and Network Watcher Diagnostics

💡 First Principle: NSGs decide whether a packet's source, destination, and port are allowed; Azure Firewall goes further and can decide based on what the traffic actually is — the destination FQDN, application-layer content, and known-malicious indicators — which is why it operates at a different, more capable layer than NSGs rather than replacing them.

Azure Firewall is a managed, stateful firewall-as-a-service supporting network rules (L3-L4), application rules with FQDN filtering (allowing traffic to *.microsoft.com by name rather than a brittle IP range), and threat intelligence-based filtering that blocks traffic to and from known malicious IP addresses and domains. It's typically deployed centrally in a hub VNet (often paired with Virtual WAN, 3.3.2) so all spoke traffic is inspected consistently. Azure Network Watcher provides diagnostic tooling, including effective security rules: the aggregated inbound and outbound rules applied to a network interface, combining the NSG on the NIC, the NSG on its subnet, and any Azure Virtual Network Manager security admin rules. It doesn't evaluate Azure Firewall rules; the firewall's own logs answer that question.

⚠️ Exam Trap: When NSGs at two levels and security admin rules all touch the same traffic and the result doesn't match any single rule set, effective security rules shows the combined outcome on that NIC without you merging the rule sets by hand. If Azure Firewall is also in the path, check it separately; the effective rules view doesn't include it.

Reflection Question: Effective security rules combines NSG and security admin rules but not Azure Firewall. How would you work out whether a blocked flow is being stopped by a security admin rule, a subnet NSG, or the hub firewall?