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 the ability to evaluate effective security rules, which shows the actual combined result of NSG rules, security admin rules, and any other layered network controls affecting a specific network interface, cutting through the complexity of multiple overlapping rule sources.

⚠️ Exam Trap: When several network security layers are in play (NSG, security admin rules, Azure Firewall) and traffic behavior doesn't match what any single rule set seems to indicate, checking each layer manually is slow and error-prone — Network Watcher's effective security rules view exists specifically to show the actual combined outcome without requiring you to mentally merge multiple rule sources yourself.

Reflection Question: Given the layered rule sources introduced across this section — NSGs, Virtual Network Manager security admin rules, and Azure Firewall — why is a single "effective rules" diagnostic view more reliable than manually reviewing each layer separately?