Azure Firewall & egress control

Central FQDN allowlists, threat intel, IDPS.

NSGs filter by IP, port, and ASG, but they cannot reason about domains or inspect application-layer traffic. Azure Firewall adds the centralized, FQDN-aware egress control and threat intelligence that turn a compromised workload’s outbound channel from open to blocked-and-logged.

Centralized egress with FQDN rules

Deploy Azure Firewall in a hub VNet and route spoke traffic through it, so all egress passes one enforcement and logging point. Application rules allow outbound only to approved FQDNs (a package mirror, an internal API, a partner endpoint) and deny the rest; network rules handle non-HTTP flows; threat-intelligence filtering blocks traffic to known-malicious IPs and domains. For most workloads the legitimate egress list is short, which makes an allowlist practical — and any attempt to reach an unlisted destination becomes an immediate signal.

# Application rule collection: allow only approved outbound FQDNs from the spoke.
az network firewall application-rule create -g rg -f hub-fw \
  --collection-name egress-allow --name approved --priority 100 --action Allow \
  --protocols Https=443 --source-addresses 10.1.0.0/16 \
  --target-fqdns *.ubuntu.com *.github.com login.microsoftonline.com
 
# Enable threat-intel filtering to alert+deny known-bad destinations.
az network firewall update -g rg -n hub-fw --threat-intel-mode Deny

Why egress is the neglected half

Almost everyone filters inbound and leaves outbound wide open, yet exfiltration and command-and-control both leave through egress. A default-open outbound policy assumes everything inside the VNet is trustworthy — the exact assumption modern attacks break. Combine the firewall allowlist with DNS Proxy and query logging to catch tunnelling, and the IDPS features of the Premium tier for signature-based detection of exfil and C2 patterns. Default-deny egress is one of the highest-leverage and most commonly missing controls.