Azure Firewall: SKUs and Deployment
Master Azure Firewall SKU comparison (Basic, Standard, Premium), rule types and processing order, FQDN filtering, and hub VNet deployment patterns.
Azure Firewall: SKUs and Deployment
Azure Firewall is a managed, cloud-native, stateful firewall service. Unlike NSGs (which filter at the subnet/NIC level), Azure Firewall sits in the hub VNet and inspects all traffic flowing through it β including east-west (VNet-to-VNet) and north-south (internet-to-VNet).
π¬ Video coming soon
Azure Firewall SKUs and Rules
Azure Firewall SKUs and Rules
~13:00Azure Firewall is a security guard at the front gate of your network β it inspects every packet and decides whether to allow it. Unlike NSGs (subnet/NIC level), Azure Firewall sits at the network perimeter providing centralised control: URL filtering, threat intelligence, FQDN filtering, and NAT.
Azure Firewall SKUs
| Feature | Basic | Standard | Premium |
|---|---|---|---|
| Throughput | 250 Mbps | 30 Gbps | 100 Gbps |
| Threat intelligence | Alert only | Alert and deny | Alert and deny |
| FQDN filtering | Yes | Yes | Yes |
| Network rules (L3/L4) | Yes | Yes | Yes |
| Application rules (L7) | Limited | Yes | Yes |
| DNS proxy | No | Yes | Yes |
| TLS inspection | No | No | Yes |
| IDPS (intrusion detection) | No | No | Yes |
| URL filtering | Basic | FQDN-based | Full URL with categories |
| Web categories | No | No | Yes |
| Forced tunneling | No | Yes | Yes |
| Best for | Small/dev workloads | Production workloads | Highly regulated environments |
Exam Tip: The three Premium-only features to remember: TLS inspection, IDPS (Intrusion Detection and Prevention System), and web categories with full URL filtering. If the exam mentions inspecting encrypted traffic or detecting intrusions, the answer is Premium.
Rule Types and Processing Order
Azure Firewall processes rules in this strict order:
1. DNAT rules (highest priority) Destination NAT rules translate incoming traffic from the firewallβs public IP to backend private IPs. Think: inbound port forwarding.
2. Network rules (middle priority) Layer 3/4 rules based on source IP, destination IP, port, and protocol. Allow or deny traffic.
3. Application rules (lowest priority)
Layer 7 rules based on FQDNs. Can filter by domain name (e.g., allow *.microsoft.com) or FQDN tag.
Within each rule type, rule collections are processed by priority (lowest number first, like NSGs). Within a collection, rules are processed by priority.
Important processing behaviour:
- If a network rule allows traffic, application rules are not evaluated for that traffic
- Application rules only evaluate traffic that wasnβt matched by network rules
- DNAT rules always process first for inbound traffic to the firewallβs public IPs
Example processing:
- Inbound to firewall public IP on port 443 β DNAT rule translates to backend 10.20.1.5:443
- VM at 10.20.1.10 wants to reach 10.30.1.20 on port 1433 (SQL) β Network rule allows
- VM at 10.20.1.10 wants to reach
update.microsoft.comon port 443 β Application rule allows (FQDN tag)
FQDN Tags vs FQDNs
FQDN tags are predefined groups of FQDNs maintained by Microsoft:
| FQDN Tag | What It Includes |
|---|---|
| WindowsUpdate | All FQDNs needed for Windows Update |
| AzureBackup | FQDNs for Azure Backup service |
| WindowsDiagnostics | Windows diagnostic data endpoints |
| MicrosoftActiveProtectionService | Windows Defender endpoints |
| AzureKubernetesService | AKS required endpoints |
Individual FQDNs let you specify exact domains:
*.github.comβ wildcard matchingupdate.microsoft.comβ exact match
Use FQDN tags when available β Microsoft maintains the list as endpoints change. Use individual FQDNs for custom application needs.
Important: FQDN-based filtering (both tags and individual) only works in application rules, not network rules. Network rules use IP addresses and service tags.
Deployment Pattern β Hub VNet
π Aishaβs deployment: Sentinel Banking deploys Azure Firewall in the hub VNet:
Internet
β
Azure Firewall (AzureFirewallSubnet, 10.10.1.0/26)
β Private IP: 10.10.1.4
βββ Hub VNet (10.10.0.0/16)
β βββ SharedServices subnet
βββ Spoke 1 β Finance (10.20.0.0/16)
β βββ Route table: 0.0.0.0/0 β 10.10.1.4
βββ Spoke 2 β HR (10.30.0.0/16)
βββ Route table: 0.0.0.0/0 β 10.10.1.4
Configuration steps:
- Deploy Azure Firewall in AzureFirewallSubnet (minimum /26)
- Note the firewallβs private IP (automatically assigned)
- Create UDRs on spoke subnets: 0.0.0.0/0 β Virtual appliance β firewall private IP
- Create UDRs for spoke-to-spoke: 10.20.0.0/16 and 10.30.0.0/16 β Virtual appliance β firewall private IP
- Create firewall rules (DNAT, network, application) to allow required traffic
- Configure firewall diagnostic settings for logging
DNS proxy configuration: When enabled on Standard or Premium, the firewall becomes the DNS proxy for the VNet. Point VNet DNS settings to the firewallβs private IP. This enables FQDN-based network rules (normally network rules only support IPs).
Key Takeaways
- Basic for dev/test, Standard for production, Premium for regulated (TLS inspection, IDPS)
- Rule processing order: DNAT first, Network second, Application third
- If a network rule matches, application rules are skipped for that traffic
- FQDN filtering only works in application rules (not network rules β unless DNS proxy is enabled)
- Deploy in hub VNet with UDRs on spoke subnets pointing to the firewallβs private IP
Test Your Knowledge
Aisha needs to inspect encrypted HTTPS traffic flowing through Azure Firewall and detect intrusion attempts. Which SKU does she need?
A VM's outbound traffic to update.microsoft.com on port 443 is being blocked by Azure Firewall, even though there's an application rule allowing it. A network rule at higher priority denies port 443. Why?
Next up: Azure Firewall Manager and Policies β Centralise firewall management with policies, parent/child inheritance, and secure virtual hubs.