Azure Firewall
Azure Firewall is a managed cloud-native network security service. It is commonly deployed in a hub VNet or secured Virtual WAN hub and used for centralized ingress, egress, and east-west inspection.
Firewall SKUs
| SKU | Use when |
|---|---|
| Basic | Small and medium environments with simpler filtering requirements. |
| Standard | Production network and application rules, threat intelligence, DNS proxy, and central inspection. |
| Premium | You need TLS inspection, IDPS, URL filtering, or web categories. |
Firewall Rules
- DNAT rules translate and allow inbound traffic to private resources.
- Network rules control non-HTTP/S traffic by IP, port, and protocol.
- Application rules control HTTP/S and FQDN-based outbound access.
- Rule collection groups contain rule collections and priorities.
- Threat intelligence can alert or deny known malicious sources and destinations.
Firewall Manager
Azure Firewall Manager centrally manages firewall policies across Azure Firewall deployments. It is used with hub VNets and secured Virtual WAN hubs. Know policy hierarchy, inherited rules, child policies, and secured hub deployment patterns.
Secure Hub Design
- Deploy Azure Firewall into a Virtual WAN hub when using secured virtual hub architecture.
- Use routing intent and hub route tables to steer traffic through security inspection.
- Use Firewall Manager policies for consistent rule governance.
Web Application Firewall
WAF protects HTTP and HTTPS applications on Application Gateway and Azure Front Door. It uses managed rule sets and custom rules to detect or block web attacks.
| Placement | Use when |
|---|---|
| Application Gateway WAF | Regional layer 7 app delivery and VNet-integrated backends. |
| Front Door WAF | Global edge protection and internet-facing application acceleration. |
WAF Configuration
- Detection mode logs matched rules without blocking.
- Prevention mode blocks matched malicious requests.
- Managed rule sets cover common vulnerabilities such as OWASP categories.
- Custom rules can match IP, geo, headers, URI, method, or request properties.
- Exclusions should be precise and based on log evidence.
Feature Deep Dive
Azure Firewall Rule Processing
Azure Firewall evaluates rule collection groups by priority, then rule collections, then rules. DNAT, network, and application rules serve different purposes. If you publish an internal service inbound, think DNAT. If you allow TCP or UDP by IP and port, think network rule. If you allow outbound HTTP/S by FQDN, think application rule.
DNS Proxy
Azure Firewall DNS proxy lets clients use the firewall as a DNS forwarder. This matters when FQDN-based rules need consistent DNS resolution. If clients resolve a name differently than the firewall, application rules can behave unexpectedly.
TLS Inspection and IDPS
Azure Firewall Premium adds deeper inspection capabilities. TLS inspection allows the firewall to inspect encrypted outbound traffic when certificates are deployed correctly. IDPS can detect and block suspicious traffic patterns. These features are common differentiators when a scenario requires more than basic IP, port, or FQDN filtering.
Firewall Policy
Firewall Policy separates rules from a single firewall instance and makes centralized governance easier. Parent and child policies let platform teams enforce global rules while application teams manage local allow rules within delegated boundaries.
WAF Rule Tuning
Start WAF in detection mode for new applications so you can observe false positives. Move to prevention mode after tuning. Exclusions should be narrow: exclude a specific variable or rule only when logs prove it is safe. Broad exclusions reduce the value of WAF.
Firewall vs NSG vs WAF
| Control | Best at | Not best at |
|---|---|---|
| NSG | Subnet and NIC traffic filtering | Centralized L7 or FQDN-aware inspection |
| Azure Firewall | Central network inspection, egress control, DNAT, threat intelligence | Application-specific OWASP web protection |
| WAF | HTTP/S application-layer protection | General network routing or non-web protocol filtering |
Final Review Checklist
- I can design address spaces and subnet layouts for gateways, firewalls, Bastion, private endpoints, and Application Gateway.
- I can explain Azure DNS, Private DNS, and DNS Private Resolver in hybrid private endpoint scenarios.
- I can troubleshoot routing with effective routes, next hop, UDRs, BGP, and route specificity.
- I can choose between VPN, ExpressRoute, Virtual WAN, VNet peering, Route Server, and NAT Gateway.
- I can choose between Load Balancer, Traffic Manager, Gateway Load Balancer, Application Gateway, and Front Door.
- I can implement Private Endpoint, Private Link service, service endpoints, and service endpoint policies.
- I can configure NSGs, ASGs, flow logs, Bastion, Azure Firewall, Firewall Manager, and WAF.
- I can use Network Watcher and Azure Monitor to diagnose connectivity and security problems.
Last-Day Cram
- Review every service selection table in this series.
- Draw a hub-spoke design with VPN, ExpressRoute, Azure Firewall, private endpoints, Application Gateway, and Front Door.
- Explain DNS and routing for the drawing without notes.
- Take the official Microsoft practice assessment.
- Rework the weakest domain first, not the easiest one.
Scenario Workshop: Centralized Egress With Azure Firewall
Scenario: A hub-spoke environment must inspect all spoke internet egress, allow only approved FQDNs, log all denied traffic, and prevent direct public IP exposure from workload VMs.
| Requirement | Design answer |
|---|---|
| Inspect all spoke egress | Associate spoke subnet route tables with 0.0.0.0/0 next hop to Azure Firewall private IP. |
| Allow approved FQDNs | Use application rules and DNS proxy design. |
| Log denied traffic | Enable Azure Firewall diagnostics to Log Analytics. |
| Prevent direct VM internet exposure | No public IPs on workload VMs; use NAT through firewall or controlled egress path. |
| Central policy | Use Firewall Policy and Firewall Manager when multiple firewalls or secured hubs exist. |
Scenario Workshop: WAF False Positive
Scenario: After enabling WAF prevention mode, a legitimate checkout request is blocked. The wrong answer is to disable WAF. The right process is to inspect WAF logs, identify the managed rule and match variable, validate that the request is legitimate, and create the narrowest possible exclusion or custom rule.
- Find the WAF log entry and rule ID.
- Identify which request field matched the rule.
- Confirm the request is expected application behavior.
- Create a narrow exclusion for that field and rule, not a broad bypass.
- Retest in detection mode or controlled rollout before relying on prevention.
Final Service Comparison
| Need | Service | Reason |
|---|---|---|
| Subnet traffic filtering | NSG | Simple L3/L4 allow/deny close to workloads. |
| Central egress and ingress inspection | Azure Firewall | Managed firewall with rules, threat intelligence, logging, and policy. |
| HTTP attack protection | WAF | Application-layer managed and custom web rules. |
| Global HTTP protection | Front Door WAF | Protects at Microsoft edge. |
| Regional HTTP protection | Application Gateway WAF | Protects regional app delivery. |