9.2 Azure Firewall Manager & DDoS Protection

Azure Firewall Manager & DDoS Protection

As enterprise cloud footprints expand across hundreds of subscriptions, multiple geographical regions, and diverse business units, managing decentralized firewall instances and network perimeter defenses becomes operationally untenable. Individual route table misconfigurations, inconsistent firewall rule definitions, and uncoordinated perimeter security introduce severe compliance vulnerabilities.

Azure Firewall Manager provides a centralized security management service that streamlines the configuration of Azure Firewall Policies, Web Application Firewall (WAF) policies, third-party Security-as-a-Service (SECaaS) integrations, and DDoS protection across hybrid and multi-hub topologies. Combined with Azure DDoS Protection, organizations can enforce comprehensive, automated defense-in-depth from Layer 3 up to Layer 7.

1. Azure Firewall Manager Architecture & Hub Types

Azure Firewall Manager manages two distinct architectural hub topologies:

+-----------------------------------------------------------------------------+
|                   AZURE FIREWALL MANAGER HUB TOPOLOGY MODELS                |
|                                                                             |
|   MODEL 1: Hub Virtual Network (Classic)   MODEL 2: Secured Virtual Hub     |
|                                                     (Virtual WAN)           |
|   +------------------------------------+   +----------------------------+   |
|   | Standard Customer-Managed VNet     |   | Azure Virtual WAN Hub      |   |
|   | - Customer provisions subnets      |   | - Microsoft-managed hub    |   |
|   | - Peered to Spoke VNets            |   | - Built-in SD-WAN router   |   |
|   | - Routing managed via manual UDRs  |   | - Automated Routing Intent |   |
|   | - Azure Firewall in dedicated      |   | - Firewall provisioned in  |   |
|   |   AzureFirewallSubnet              |   |   managed hub core         |   |
|   +------------------------------------+   +----------------------------+   |
|                     |                                     |                 |
|                     v                                     v                 |
|   [ Centralized Azure Firewall Policy ] <--- Managed by Firewall Manager    |
+-----------------------------------------------------------------------------+

Hub Virtual Network vs. Secured Virtual Hub Comparison

2. Firewall Policy Inheritance & Rule Hierarchy

Azure Firewall Policy introduces a hierarchical governance model that allows central security operations (SecOps) teams to enforce global compliance baselines while delegating application-specific rule authoring to decentralized workload teams.

+-----------------------------------------------------------------------------+
|                     FIREWALL POLICY INHERITANCE HIERARCHY                   |
|                                                                             |
|   [ PARENT POLICY: Global Corporate Baseline (SecOps Team) ]                |
|   - Threat Intelligence: Alert and Deny                                     |
|   - IDPS: Alert and Deny                                                    |
|   - Parent Network RCG (Priority 100): Deny Malicious Ports (23, 135, 445)  |
|   - Parent Application RCG (Priority 200): Enforce Corporate Proxy FQDNs    |
|                                                                             |
|             |-----------------------------------|                           |
|             v (Inherits Global Baseline)        v (Inherits Global Baseline)|
|   [ CHILD POLICY: Production-EastUS ]   [ CHILD POLICY: Dev-WestEurope ]    |
|   - Workload App RCG (Priority 300):    - Dev Network RCG (Priority 300):   |
|     Allow *.production-api.com            Allow Port 8080 to Internal Lab   |
|   - Local RCGs CANNOT override Parent   - Local RCGs CANNOT override Parent |
+-----------------------------------------------------------------------------+

Rule Evaluation Sequence Across Policy Hierarchies

When a child policy inherits from a parent policy, the Azure Firewall engine merges the rule collections into a single logical processing pipeline, strictly prioritizing the Parent Policy:

1. Parent DNAT Rules (in order of priority)
2. Child DNAT Rules (in order of priority)
3. Parent Network Rules (in order of priority)
4. Child Network Rules (in order of priority)
5. Parent Application Rules (in order of priority)
6. Child Application Rules (in order of priority)
7. Implicit Default Deny

[!IMPORTANT] Parent Rule Immutability: A child policy can never bypass or override a Deny rule defined in a Parent Policy. Because all Parent Network rules execute before any Child Network or Application rules, a global corporate Deny rule (e.g., dropping all outbound UDP port 53 to public resolvers) will immediately terminate packet processing before any child Allow rule is evaluated.

3. Routing Intent & Routing Policies in Secured Virtual Hubs

In standard hub-and-spoke networks, steering traffic through a firewall requires configuring and maintaining User-Defined Route (UDR) tables across dozens or hundreds of spoke subnets. If an address space changes or a new spoke is peered, routes must be updated manually, creating high operational overhead and risk of routing loops.

Routing Intent and Routing Policies in Azure Virtual WAN eliminate spoke UDR management entirely. By configuring Routing Intent on a Secured Virtual Hub via Azure Firewall Manager, the Virtual WAN SDN fabric automatically programs and advertises the necessary route tables across all connected spoke virtual networks and branch gateways.

+-----------------------------------------------------------------------------+
|                 ROUTING INTENT TRAFFIC POLICIES IN VWAN                     |
|                                                                             |
|   [ Secured Virtual Hub ]                                                   |
|   +---------------------------------------------------------------------+   |
|   | POLICY 1: Internet Traffic Routing Policy                           |   |
|   | - Next Hop: Azure Firewall (or Trusted Security Partner)            |   |
|   | - Action: Automatically injects 0.0.0.0/0 into all connected spokes. |   |
|   | - Result: All spoke-to-Internet traffic is inspected automatically. |   |
|   +---------------------------------------------------------------------+   |
|   +---------------------------------------------------------------------+   |
|   | POLICY 2: Private Traffic Routing Policy                            |   |
|   | - Next Hop: Azure Firewall                                          |   |
|   | - Action: Injects RFC 1918 prefixes (10.0.0.0/8, 172.16.0.0/12,     |   |
|   |           192.168.0.0/16) and branch prefixes into all spokes.      |   |
|   | - Result: Inter-Spoke, Spoke-to-Branch, and Cross-Hub private flows |   |
|   |           are inspected by Azure Firewall without manual UDRs.      |   |
|   +---------------------------------------------------------------------+   |
+-----------------------------------------------------------------------------+

Benefits of Routing Intent:

1. Zero Spoke UDR Maintenance: Spoke subnets require zero attached route tables. The Virtual WAN fabric dynamically injects default and private routes directly into the virtual network's default system routing table.
2. Deterministic Inter-Hub Routing: In multi-hub global deployments, private routing policies ensure traffic between a spoke in East US and a spoke in West Europe is cleanly inspected by regional firewalls without asymmetric routing.
3. Branch-to-Spoke Security: On-premises branches connecting via ExpressRoute or VPN have their inbound traffic inspected by the secured hub firewall before reaching any spoke workload.

4. Azure DDoS Protection: Network Protection vs. IP Protection

Distributed Denial of Service (DDoS) attacks represent one of the most severe availability threats to public-facing cloud infrastructure. Azure provides multi-layered DDoS defense to protect applications against volumetric Layer 3 (e.g., UDP floods, ICMP floods) and protocol Layer 4 (e.g., TCP SYN floods, ACK reflection) attacks.

The DDoS Defense Spectrum

• Azure Infrastructure DDoS Protection (Default / Free): Active globally across all Azure regions. It protects Microsoft's shared platform infrastructure and drops massive multi-terabit attacks before they impact the Azure backbone. However, its mitigation thresholds are tuned to protect the datacenter fabric, not individual customer workloads, and it offers no customer metrics, alerting, or SLA.
• Azure DDoS Network Protection (Enterprise VNet Scope): Comprehensive protection plan associated with virtual networks, offering adaptive machine learning tuning, real-time analytics, dedicated rapid response support, and cost protection.
• Azure DDoS IP Protection (Targeted Public IP Scope): Cost-effective, pay-per-IP protection designed for single-IP or small deployments requiring enterprise-grade Layer 3/4 mitigation without a tenant-wide plan commitment.

+-----------------------------------------------------------------------------+
|                 AZURE DDOS PROTECTION SKU COMPARISON MATRIX                 |
|                                                                             |
|   Feature / Capability       DDoS IP Protection     DDoS Network Protection |
|   ------------------------   --------------------   ----------------------- |
|   Target Scope               Single Public IP       Virtual Network (Multi) |
|   Adaptive Traffic Profiling Supported (L3/L4)      Supported (L3/L4)       |
|   Azure Monitor Telemetry    Supported              Supported               |
|   Attack Mitigation Alerts   Supported              Supported               |
|   DDoS Rapid Response (DRR)  NOT Supported          SUPPORTED (24/7 Access) |
|   Cost Protection Guarantee  NOT Supported          SUPPORTED (Resource Cr) |
|   WAF Discount Integration   NOT Supported          SUPPORTED (App GW WAF)  |
|   Central Firewall Manager   NOT Supported          SUPPORTED               |
|   Billing Model              Per Public IP / Month  Fixed Fee (100 IPs inc) |
+-----------------------------------------------------------------------------+

Deep-Dive: DDoS Network Protection Core Capabilities

1. Adaptive Traffic Profiling & Intelligent Mitigation:
   • Rather than relying on generic static thresholds, Azure DDoS Network Protection uses machine learning to analyze your application's normal traffic patterns over time.
   • It establishes dynamic mitigation thresholds: when traffic spikes exceed the learned baseline, mitigation engages instantly, redirecting attacking traffic to Azure scrubbing centers while permitting legitimate user requests.
2. Telemetry, Metrics & Attack Analytics:
   • Exposes detailed real-time metrics in Azure Monitor (e.g., Bytes Dropped DDoS, Bytes Forwarded DDoS, Packets Dropped DDoS).
   • Integrates with Log Analytics to provide rich post-attack forensic reports, identifying source IP geographic distribution, protocol breakdowns, and attack vectors.
3. DDoS Rapid Response (DRR):
   • During an active, critical DDoS attack, customers with DDoS Network Protection can engage the Microsoft DDoS Rapid Response team directly.
   • Microsoft DDoS engineers assist with root-cause analysis, custom mitigation rule authoring, and specialized telemetry evaluation during the active emergency.
4. Cost Protection Guarantee:
   • If a DDoS attack causes backend compute resources to scale out automatically (e.g., Virtual Machine Scale Sets scaling from 4 to 50 instances, or Azure App Service plans spiking), Microsoft provides financial billing credits for the scale-out compute costs incurred during the verified attack.

Architectural Decision Framework

• Select DDoS Network Protection when: You manage a multi-VNet, enterprise-scale environment with more than a few public IPs, require 24/7 direct engagement with Microsoft DDoS experts (DRR), demand financial cost protection against scale-out billing spikes, or manage security policies centrally via Azure Firewall Manager.
• Select DDoS IP Protection when: You have a small environment with 1 to 3 standalone Standard Public IP addresses (e.g., a single public Azure Firewall or standalone Load Balancer) where the fixed monthly fee of Network Protection is cost-prohibitive, but adaptive Layer 3/4 mitigation and Azure Monitor alerting are still strictly required.