Design 20: Azure Firewall

Summary

This design implements Azure Firewall as the central security checkpoint.

Topology: The Firewall is deployed in the Hub VNet. All traffic from Spoke VNets (Egress to Internet, or Spoke-to-Spoke) is routed through this Firewall for inspection.

1. Key Design Decisions (ADR)

ADR-01: Placement

Decision: Deploy in Hub VNet.
Rationale: Centralize inspection. Avoid deploying a $1000/month firewall in every spoke.

ADR-02: Routing

Decision: Use User Defined Routes (UDR).
Rationale: We must force Spoke traffic to go to the Firewall. By default, it goes directly to the Internet.

2. High-Level Design (HLD)

+--------------+           +--------------------------+           +--------------+
|  Internet    |           |        HUB VNet          |           |  SPOKE VNet  |
|  (Malicious) |<--------->|   [Azure Firewall]       |<--------->|  [Workload]  |
|              |  Filter   |   (10.0.1.4)             |  Peering  |  (UDR: 0/0)  |
+--------------+           +--------------------------+           +--------------+

3. Low-Level Design (LLD)

                               PRIMARY REGION (East US)
+-----------------------------------------------------------------------+
| HUB VNet: vnet-hub (10.0.0.0/16)                                      |
|   +-----------------------+                                           |
|   | AzureFirewallSubnet   |                                           |
|   | (10.0.1.0/24)         |                                           |
|   | [Azure Firewall]      |                                           |
|   | (PIP: 20.x.x.x)       |                                           |
|   +-----------|-----------+                                           |
|               |                                                       |
|               v (Peering)                                             |
+---------------|-------------------------------------------------------+
                |
+---------------|-------------------------------------------------------+
| SPOKE VNet: vnet-spoke (10.1.0.0/16)                                  |
|   +-----------------------+                                           |
|   | Subnet: Workload      |                                           |
|   | Route Table: rt-spoke |                                           |
|   | (0.0.0.0/0 -> FW IP)  |                                           |
|   | [VM]                  |                                           |
|   +-----------------------+                                           |
+---------------|-------------------------------------------------------+
                |
                | (Policy Replication)
                v
+-----------------------------------------------------------------------+
| SECONDARY REGION (West US) - DR Site                                  |
|                                                                       |
|   +-----------------------+       +-----------------------+           |
|   | Firewall Policy       |       | Azure Firewall        |           |
|   | (Global Resource)     |       | (Standby)             |           |
|   +-----------------------+       +-----------------------+           |
+-----------------------------------------------------------------------+

4. Component Rationale

AzureFirewallSubnet: Must be named exactly this.
Firewall Policy: A separate resource containing the rules. Can be shared across East and West Firewalls (Global Policy).

5. Strategy: High Availability (HA)

Built-in: Azure Firewall is a managed PaaS. It auto-scales and is highly available (99.95%).
Zones: Can be deployed across Availability Zones for 99.99%.

6. Strategy: Disaster Recovery (DR)

Implementation: Active-Passive.
Process:

* Deploy Firewall in West US Hub.

* Attach the Same Firewall Policy to the West US Firewall.

* This ensures rules are identical in both regions.

7. Strategy: Backup

Config: Backup the Firewall Policy (it's code/JSON).

8. Strategy: Security

Filtering:

* Network Rules: Allow IP to IP (e.g., Spoke -> DNS).

* Application Rules: Allow FQDNs (e.g., *.ubuntu.com for updates).

Threat Intel: Automatically blocks known malicious IPs.

9. Well-Architected Framework Analysis

Reliability: High.
Security: Excellent. Centralized egress control.
Cost Optimization: Low. Expensive (~$1.25/hr). But cheaper than data breach.
Operational Excellence: High. Centralized logging to Sentinel.
Performance Efficiency: High. Throughput scales automatically (up to 30 Gbps).

10. Detailed Traffic Flow

1. VM: Tries to go to google.com.

2. UDR: Route table sees 0.0.0.0/0 -> Next Hop 10.0.1.4 (Firewall).

3. Peering: Packet sent to Hub.

4. Firewall: Checks Application Rules. "Is google.com allowed?" -> Yes.

5. NAT: Firewall SNATs the traffic (Source becomes Firewall Public IP).

6. Internet: Packet goes to Google.

7. Return: Google replies to Firewall. Firewall forwards to VM.

11. Runbook: Deployment Guide (Azure Portal)

Phase 1: Create Subnet in Hub

1. Go to vnet-hub.

2. Subnets -> + Subnet.

3. Name: AzureFirewallSubnet (Exact spelling required).

4. Subnet address range: 10.0.1.0/24 (Must be /26 or larger).

5. Save.

Phase 2: Deploy Firewall

1. Search: "Firewalls" -> + Create.

2. Resource Group: rg-hub-prod.

3. Name: fw-hub.

4. Region: East US.

5. Firewall SKU: Standard.

6. Firewall management: Use a Firewall Policy.

7. Firewall policy: Click Create new.

* Name: pol-global-corp.

* Region: East US.

* OK.

8. Virtual network: Select vnet-hub.

9. Public IP address: Create new pip-fw.

10. Create.

Phase 3: Create Route Table (The Glue)

1. Search: "Route tables" -> + Create.

2. Name: rt-spoke-to-hub.

3. Region: East US.

4. Propagate gateway routes: Yes.

5. Create.

6. Go to resource -> Routes -> + Add.

* Route name: To-Internet-via-FW.

* Address prefix: 0.0.0.0/0 (Default Route).

* Next hop type: Virtual appliance.

* Next hop address: 10.0.1.4 (Check Firewall Private IP).

* Add.

Phase 4: Associate Route Table

1. Go to Route Table rt-spoke-to-hub -> Subnets -> + Associate.

2. Virtual network: vnet-spoke (or vnet-ntier-spoke).

3. Subnet: Select the workload subnet (e.g., snet-workload).

4. OK.

Phase 5: Verify Blocking

1. Login to a VM in the Spoke.

2. Try curl google.com.

3. It should Time out or fail (Default Deny).

Phase 6: Allow Traffic

1. Go to Firewall Policy pol-global-corp.

2. Application Rules -> Add a rule collection.

* Name: Allow-Google.

* Priority: 200.

* Action: Allow.

* Rule:

* Name: Google.

* Source type: IP Address. Source: *.

* Protocol: http, https.

* Target FQDNs: *.google.com.

* Add.

3. Try curl google.com on the VM again. It should Succeed.