Azure Firewall Manager and Policies
Centralise firewall management with Azure Firewall Manager β policy hierarchy, parent/child inheritance, secure virtual hubs, and routing intent.
Azure Firewall Manager and Policies
When you manage Azure Firewall at scale β multiple firewalls, multiple regions, different teams β you need centralised policy management. Azure Firewall Manager and firewall policies solve this.
π¬ Video coming soon
Firewall Manager and Policies
Firewall Manager and Policies
~11:00Firewall Manager is your firewallβs control tower β instead of configuring each firewall individually, you create policies centrally and apply them across multiple firewalls. It also lets you create secure hubs β Virtual WAN hubs with Azure Firewall built in.
Firewall Policies
Firewall policies replaced the older βclassic rulesβ model. A policy is a standalone Azure resource that contains all your firewall rules and settings, and can be associated with one or more firewalls.
Parent/child inheritance:
Parent Policy (Global)
βββ Base rules: Deny known-bad IPs, Allow Azure management
βββ Threat intel settings: Alert and Deny
βββ DNS settings: Custom DNS servers
β
βββ Child Policy (Production)
β βββ Inherits all parent rules
β βββ Additional rules: Allow prod workloads
β βββ Cannot delete or modify parent rules
β
βββ Child Policy (Development)
βββ Inherits all parent rules
βββ Additional rules: Allow broader internet (less restrictive)
βββ Cannot delete or modify parent rules
Key inheritance rules:
- Child policies inherit all rules from the parent
- Child policies can add rules but cannot remove or override parent rules
- Parent rules are processed before child rules (lower priority numbers)
- A policy can have only one parent but a parent can have multiple children
- You can change a policyβs parent, but rules from the old parent are removed
Rule Collection Group Hierarchy
Within a policy, rules are organised in a three-level hierarchy:
Firewall Policy
βββ Rule Collection Group (priority: 100-65000)
βββ Rule Collection (priority within group)
βββ Individual Rules
Rule collection groups contain multiple rule collections and are processed by priority. Within each group, rule collections are processed by their priority. Within each collection, individual rules are processed.
Rule type processing still applies: DNAT collections process first, then Network collections, then Application collections β regardless of rule collection group priority.
π Aishaβs policy design:
| Rule Collection Group | Priority | Contents |
|---|---|---|
| Platform (parent policy) | 100 | Deny known-bad IPs, Allow Azure management |
| Infrastructure | 200 | Allow DNS, NTP, Windows Update |
| Workload - Finance | 300 | Allow Finance app traffic patterns |
| Workload - HR | 400 | Allow HR app traffic patterns |
| Internet | 500 | Allow approved internet destinations |
Secure Virtual Hubs
A secure virtual hub is a Virtual WAN hub with Azure Firewall (or a partner security provider) deployed in it, managed through Firewall Manager.
| Feature | Hub VNet with Firewall | Secure Virtual Hub (VWAN) |
|---|---|---|
| Hub location | Your own VNet that you create and manage | Virtual WAN managed hub infrastructure |
| Routing | Manual UDRs on every spoke subnet | Routing intent automates traffic through firewall |
| Management | Direct policy association with firewall | Firewall Manager associates policies per hub |
| Multi-region | Manual VNet peering between hubs | Automatic inter-hub connectivity via VWAN |
| Third-party NVA support | Deploy NVAs in the hub VNet manually | Partner security providers (Zscaler, iBoss, Check Point) |
| Best for | Small deployments (under 10 VNets), full routing control | Large-scale or multi-region with VWAN, automated routing |
Routing intent (covered in Module 12) works with secure virtual hubs to automatically route:
- Internet traffic: All VNet-to-internet routes through the hubβs firewall
- Private traffic: All VNet-to-VNet and VNet-to-branch routes through the hubβs firewall
This eliminates manual UDR management β Firewall Manager and routing intent handle it automatically.
Hub VNet vs Secure Virtual Hub β When to Choose
Choose Hub VNet + Firewall when:
- You have a small number of VNets (under 10)
- You need full control over routing and VNet configuration
- You donβt use Virtual WAN
- You want to manage everything manually for maximum customisation
Choose Secure Virtual Hub when:
- You use Virtual WAN for multi-site, multi-region connectivity
- You want automated routing (routing intent)
- You need centralised policy management across multiple hubs
- You want to integrate third-party security providers
- You have 10+ VNets or multiple regions
Exam context: If the scenario mentions Virtual WAN, the answer likely involves a secure virtual hub. If itβs a custom hub-and-spoke without VWAN, itβs a hub VNet with firewall.
Key Takeaways
- Firewall policies are standalone resources with parent/child inheritance
- Child policies inherit and cannot override parent rules
- Rule collection groups organise rules with priority-based processing
- DNAT rules always process before Network, which process before Application
- Secure virtual hubs combine VWAN + Firewall Manager with routing intent
Test Your Knowledge
Aisha wants a base set of deny rules that all firewalls must follow, with teams adding their own workload-specific rules. What should she configure?
Elena uses Virtual WAN with multiple regional hubs and wants all traffic routed through Azure Firewall in each hub without manual UDRs. What should she deploy?
Next up: Web Application Firewall (WAF) β Protect web applications from OWASP attacks with WAF on Application Gateway and Front Door.