ALZ Network Detailed Design
Here is a detailed level design for an Azure Network Landing Zone, structured from high-level concepts down to specific configurations.
This design follows the Microsoft Cloud Adoption Framework (CAF) and Well-Architected Framework principles, focusing on a **Hub-and-Spoke** topology, which is the most common and recommended pattern for enterprise-scale landing zones.
—
### **1. Design Principles & Objectives**
* **Security First:** Zero-Trust model. All traffic is denied by default; explicitly allowed by rules. Segmentation at the network and application layer.
* **Scalability & Modularity:** The hub-spoke design allows for easy addition of new workloads (spokes) without impacting existing ones.
* **High Availability & Resilience:** Deploy critical services (like VPN/ExpressRoute Gateways) across Availability Zones (where supported) for maximum uptime.
* **Operational Efficiency:** Centralized management of shared network services (e.g., firewalls, DNS) in the hub. Use of Infrastructure as Code (IaC) like Bicep or Terraform for repeatable, consistent deployments.
* **Governance & Compliance:** Use Azure Policy to enforce network standards (e.g., mandatory flow logs, prohibiting public IPs on certain subnets).
—
### **2. High-Level Topology: Hub-and-Spoke**
This design centralizes shared services in a **Hub Virtual Network (VNet)** and connects to isolated **Spoke VNets** for different workloads (e.g., production, non-production, shared services).
“`
|–> Spoke VNet (Production)
| |- Subnet: WebTier
| |- Subnet: AppTier
| |- Subnet: DataTier
|
Internet –> [Azure FW] –> |–> Spoke VNet (Non-Prod/Dev)
| |- Subnet: WebTier
| |- …
|
|–> Spoke VNet (Shared-Svcs)
| |- Subnet: Management
|
On-Prem — [ER/VPN GW] — |
(Datacenter)
“`
—
### **3. Core Component Detailed Design**
#### **3.1. Hub Virtual Network (`vnet-hub-weu-001`)**
The central point for connectivity and security.
* **Address Space:** `10.100.0.0/16`
* **Subnets:**
* **`AzureFirewallSubnet`** (delegated): `10.100.0.0/26`
* *Purpose:* Dedicated subnet for the Azure Firewall.
* **`GatewaySubnet`** (delegated): `10.100.1.0/27`
* *Purpose:* Dedicated subnet for VPN/ExpressRoute Gateways.
* **`ManagementSubnet`** (optional in hub): `10.100.2.0/24`
* *Purpose:* Hosts jump boxes/bastion hosts for managing other VMs. Often placed in a dedicated management spoke.
* **`SharedServicesSubnet`** (optional in hub): `10.100.3.0/24`
* *Purpose:* For shared utility VMs (e.g., domain controllers, file servers). Often placed in a dedicated shared services spoke.
* **`DnsForwarderSubnet`** (optional): `10.100.4.0/24`
* *Purpose:* Hosts VMs that forward DNS queries to on-premises resolvers or Azure Private DNS Resolver endpoints.
#### **3.2. Spoke Virtual Networks (e.g., `vnet-prod-weu-001`)**
Hosts application workloads. Isolated by environment and purpose.
* **Address Space:** `10.10.0.0/16` (Production), `10.20.0.0/16` (Non-Prod)
* **Subnets (per spoke):**
* **`WebTier`**: `10.10.1.0/24`
* *NSG:* Restrictive inbound from Internet/ALB, outbound to AppTier only.
* **`AppTier`**: `10.10.2.0/24`
* *NSG:* Inbound *only* from WebTier, outbound to DataTier and approved external APIs.
* **`DataTier`**: `10.10.3.0/24`
* *NSG:* Most restrictive. Inbound *only* from AppTier. No direct Internet access.
* **`PrivateEndpointSubnet`**: `10.10.10.0/24`
* *Purpose:* Dedicated subnet for Azure PaaS Private Endpoints (e.g., Azure SQL, Storage, Key Vault). This is a best practice for simplified management and NSG rules.
#### **3.3. Connectivity**
* **VNet Peering:**
* Hub-to-Spoke: Peering with **`Allow forwarded traffic`** enabled and **`Use remote gateways`** *disabled* on the spoke.
* Spoke-to-Hub: Peering with **`Use remote gateways`** enabled and **`Allow forwarded traffic`** *disabled* on the spoke.
* **NO** direct Spoke-to-Spoke peering. All traffic between spokes must flow through the hub firewall for inspection.
* **On-Premises Connectivity:**
* **ExpressRoute:** Preferred for private, reliable, high-bandwidth connection. Use ExpressRoute Gateway in the hub.
* **Site-to-Site VPN:** For backup or smaller branch offices. Use VPN Gateway in the hub.
* **Internet Connectivity:**
* **For Outbound:** All spoke VNets use the Azure Firewall in the hub as their default gateway via User-Defined Routes (UDRs). This is known as “forced tunneling.”
* **For Inbound:** Public Load Balancers or Application Gateways (WAF) are placed in the hub or their own DMZ spoke, which then route traffic to the application tiers in the spokes.
#### **3.4. Security**
* **Azure Firewall (Premium Tier):**
* **Centralized Egress/Ingress Point:** All traffic to/from Internet and between spokes is inspected here.
* **Rules:**
* **Network Rules:** For non-HTTP/S traffic (e.g., RDP, SSH, specific APIs).
* **Application Rules:** For FQDN-based filtering (e.g., `*.core.windows.net`).
* **Threat Intelligence:** Enable to alert/deny traffic from known malicious IPs/FQDNs.
* **TLS Inspection:** (Premium Tier) Decrypt and inspect outbound HTTPS traffic for deeper security analysis.
* **Network Security Groups (NSGs):**
* Applied at the **subnet level** (mandatory) and optionally at the NIC level.
* Follow the principle of least privilege. Example rule for `AppTier` NSG:
* **Inbound:** Allow TCP 443 from `10.10.1.0/24` (WebTier), Deny all else.
* **Outbound:** Allow TCP 1433 to `10.10.3.0/24` (DataTier), Allow TCP 443 to `10.100.0.4` (Azure Firewall IP for Internet egress).
* **Azure DDoS Protection Standard:** Enabled on the Hub VNet and all critical Spoke VNets to protect from volumetric attacks.
#### **3.5. Naming & Routing**
* **Naming Convention:** `resource-type-purpose-env-region-001` (e.g., `vnet-prod-weu-001`, `rt-shared-internet-prod-weu`).
* **Route Tables (UDRs):**
* **Hub Route Table:** Associated with Gateway and Firewall subnets. Usually has system routes only.
* **Spoke Route Table (e.g., `rt-shared-internet-prod-weu`):**
* **Default Route (`0.0.0.0/0`):** Next Hop = **Azure Firewall Private IP**.
* **On-Premises Routes (e.g., `192.168.0.0/16`):** Next Hop = **Azure Firewall Private IP** (so on-prem traffic can be inspected).
* This route table is associated with every subnet in the spoke.
#### **3.6. Monitoring & Management**
* **Azure Monitor Network Watcher:**
* **Connection Monitor:** To test connectivity between critical endpoints (e.g., spoke VM to on-prem SQL server).
* **Network Performance Monitor (NPM):** For monitoring network performance and latency.
* **Flow Logs:** Enable NSG Flow Logs for all subnets. Send logs to a **Log Analytics Workspace** for analysis and to Azure Storage for archive.
* **Traffic Analytics:** Process flow logs to provide visual maps of traffic patterns, identify security threats, and optimize performance.
—
### **4. DNS Strategy**
A critical and often overlooked component.
* **Azure Private DNS Zones:** For internal name resolution of Azure PaaS services.
* Create zones for `privatelink.database.windows.net`, `privatelink.blob.core.windows.net`, etc.
* Link these zones to the Hub and all Spoke VNets that require resolution.
* **DNS Forwarding:**
* **Spokes to Hub:** Configure Spoke VNets to use the Azure Firewall’s IP (or a dedicated DNS forwarder VM in the hub) as their DNS server.
* **Hub to On-Prem/Internet:** The Azure Firewall (or DNS forwarder VM) is configured to forward queries:
* For `corp.local` -> to on-premises DNS servers (via the private IP of the ExpressRoute/VPN link).
* For all other queries -> to Azure’s recursive resolvers (`168.63.129.16`) or to a public DNS like `1.1.1.1`.
—
### **5. Implementation & Governance**
* **Infrastructure as Code (IaC):** Define the entire landing zone (Hub VNet, Firewall, Peering, UDRs) using Bicep or Terraform modules. This ensures consistency and allows for version control.
* **Azure Policy:** Apply policies at the Management Group level to enforce rules such as:
* **`Allowed VNet/Subnet ranges`:** Prevent deployment of resources in non-approved networks.
* **`Deny public IP on NICs`** on data tier subnets.
* **`Enforce NSG flow logs`** on all subnets.
* **`Deny creation of VNets that are not peered to the hub`.**
This detailed design provides a robust, secure, and scalable foundation for any enterprise workload in Azure. It should be adapted to specific organizational requirements, compliance needs, and cost considerations.
Xx
Of course. This is an excellent scenario that combines modern corporate networking with Azure’s cloud backbone. Here is a detailed design for terminating a corporate SD-WAN at Azure Virtual WAN (vWAN).
### **Design Philosophy & Objectives**
* **Hybrid Hub:** Treat Azure vWAN as the primary cloud hub in your global network, integrating seamlessly with your SD-WAN.
* **Simplified Operations:** Leverage vWAN to reduce the complexity of managing multiple point-to-site, site-to-site, and ExpressRoute connections individually.
* **Dynamic Path Selection:** Enable intelligent, application-aware routing where traffic can take the optimal path (Internet via SD-WAN, private SD-WAN link, or Microsoft Global Network) based on policies.
* **Centralized Security:** Route all traffic through a central security stack (Azure Firewall) for consistent inspection and policy enforcement.
* **High Availability:** Design for resilient connectivity from the SD-WAN appliances to the Azure vWAN hubs.
—
### **High-Level Architecture**
The following diagram illustrates the final target architecture, which will be broken down in the detailed design below:
flowchart TD
Internet[“Public Internet”]
Corp[“Corporate HQ & Branches<br/>SD-WAN Network”]
subgraph AzureCloud[Azure Virtual WAN]
direction TB
vWAN[Virtual WAN Hub]
subgraph vWANSec[Secured Virtual Hub]
AFW[Azure Firewall<br/>Premium SKU]
end
vWAN –“Hub-to-VNet”–> Spoke1[Spoke VNet 1]
vWAN –“Hub-to-VNet”–> Spoke2[Spoke VNet 2]
end
Corp –“SD-WAN Over Internet<br/>(IPSec VPN)”–> vWAN
Corp –“Private SD-WAN Connection<br/>(e.g., MPLS)”–> ER[“ExpressRoute Circuit”] –“ExpressRoute Gateway”–> vWAN
Internet –“Internet Breakout”–> AFW
AFW –“Inspects all traffic”–> vWAN
style AzureCloud fill:#007cff2b
style vWANSec fill:#ff00001f
“`
### **1. Core Component: Azure Virtual WAN Hub**
The Azure vWAN hub is the central termination point in Azure. It contains all the necessary gateways.
* **vWAN Hub Region:** `West Europe` (Choose the region closest to the majority of your branches or your primary datacenter).
* **Hub Components:**
* **Site-to-Site VPN Gateway:** Automatically deployed when you create a VPN connection. This will terminate the IPsec tunnels from your SD-WAN appliances.
* **Scale Unit:** Choose based on aggregate throughput needs (e.g., `1 Gbps`).
* **ExpressRoute Gateway:** Deployed if you are using a private connection from your SD-WAN provider. This will terminate the ExpressRoute circuit.
* **Azure Firewall (Premium):** **This is critical.** Deploy Azure Firewall inside the vWAN hub, creating a **Secured Virtual Hub**.
* **SKU:** **Premium** is highly recommended for advanced threat prevention (IDS/IPS), TLS inspection, and URL filtering.
* **Policies:** Centralized firewall rules for all traffic traversing the hub (branch-to-branch, branch-to-Azure, branch-to-internet).
### **2. SD-WAN Connectivity Options (Dual-Path Recommended)**
A robust design incorporates multiple connection paths for redundancy and performance.
#### **Option A: Primary – Internet-Based IPSec VPN (Most Common)**
* **Method:** Your SD-WAN appliances establish standard **IPSec/IKEv2** tunnels directly to the Azure vWAN’s VPN gateway.
* **Configuration:**
* On Azure side: Create a **Virtual WAN Site** in the Azure portal. This generates a configuration file you can provide to your SD-WAN vendor.
* On SD-WAN side: Use the Azure-provided pre-shared keys (PSKs), public IPs of the VPN gateway, and BGP settings to configure the tunnels.
* **Advantage:** Leverages the public Internet. Simple to set up, low cost, and benefits from the SD-WAN’s ability to optimize traffic over unreliable links.
#### **Option B: Secondary/High-Performance – ExpressRoute**
* **Method:** Many SD-WAN providers (e.g., VMware Velocloud, Cisco Viptela) can integrate with an **ExpressRoute Circuit** instead of the public internet.
* **Configuration:**
* Procure an ExpressRoute circuit from a provider that partners with your SD-WAN vendor.
* The SD-WAN provider establishes a private connection between their network and the Microsoft Enterprise Edge (MSEE) routers.
* Link the ExpressRoute circuit to the **ExpressRoute Gateway** inside your Azure vWAN hub.
* **Advantage:** Traffic travels over a private, reliable, high-throughput connection with predictable latency. It does not traverse the public internet.
#### **Recommended Design: Dual-Path Termination**
Configure your SD-WAN appliances to establish **both** connection types to Azure vWAN:
- A primary path via **ExpressRoute** (for performance-sensitive traffic like VoIP, databases).
- A secondary/backup path via **Internet-based IPSec VPN**.
Your SD-WAN orchestrator can then dynamically steer application traffic down the best path based on real-time performance metrics and policies.
### **3. Routing & Security: The Brain of the Design**
This is where the true power of the integration lies.
* **Dynamic Routing via BGP:**
* Ensure your SD-WAN appliances **peer with BGP** to the Azure vWAN gateways.
* This automatically propagates all your corporate network routes (e.g., `192.168.0.0/16`) to the vWAN hub.
* The vWAN hub, in turn, propagates its learned routes (Azure VNet addresses, other branch routes) back to the SD-WAN.
* **Azure Firewall as the Next Hop:**
* This is the key to the “Secured Virtual Hub” model.
* In the vWAN hub configuration, you enable routing and specify that **all traffic** (including branch-to-branch, branch-to-internet) should have its **next hop be the Azure Firewall**.
* **Result:** All traffic from your SD-WAN branches is automatically funneled through the centralized Azure Firewall for policy enforcement, inspection, and logging before it reaches Azure workloads, the internet, or other branches.
### **4. Branch & Corporate HQ Configuration**
* **SD-WAN Appliances:** Each branch and HQ location has an SD-WAN appliance configured with:
* Two IPSec tunnels (active/active) to the Azure vWAN VPN gateway’s public IPs.
* BGP peering enabled over the tunnels to exchange routes.
* Policies to steer specific application traffic to the “Azure Cloud” path.
* **Traffic Flow Example:**
- A user at a branch requests access to an application in an Azure Spoke VNet (`10.10.1.4`).
- The SD-WAN appliance, based on its policy, sends the traffic over the IPSec tunnel to Azure vWAN.
- The vWAN hub’s route table directs the traffic to the Azure Firewall.
- Azure Firewall checks its application/network rules. If allowed, it forwards the traffic to the correct Spoke VNet.
- Return traffic follows the same path in reverse.
### **5. Monitoring and Management**
* **Azure Monitor:** Use Azure Monitor to track the health and performance of the vWAN hub, VPN/ER gateways, and Azure Firewall.
* **Azure Network Watcher:** Use Connection Monitor to proactively test latency and reachability from Azure to key on-premises resources.
* **SD-WAN Orchestrator:** Use your vendor’s portal (e.g., Cisco vManage, Velocloud Orchestrator) for end-to-end visibility of the underlay and overlay network, including application performance over the Azure connections.
—
### **Why This Design is Effective:**
* **Unified Policy:** Security policy is defined once in Azure Firewall and applied consistently to all branches and cloud workloads.
* **Optimal Performance:** The SD-WAN selects the best transport (Internet vs. Private), while Azure provides a high-speed backbone within the cloud.
* **Automated & Scalable:** Adding a new branch is as simple as connecting a new SD-WAN appliance. The Azure side automatically learns the new routes via BGP without any manual configuration on Azure UDRs.
* **Resilient:** Multiple active paths from each location ensure business continuity.
This design represents a modern, secure, and highly scalable approach to integrating your global corporate network with Microsoft Azure.
Xxx
No UDR design
show me a Azure network landing zone design without using UDR
Of course. Designing an Azure landing zone without User-Defined Routes (UDRs) is a fascinating challenge that forces you to leverage Azure’s native, managed services to their fullest. It’s a valid architecture that prioritizes simplicity and reduced operational overhead.
The key principle is: Without UDRs, you cannot force traffic through a Network Virtual Appliance (NVA) like a firewall. Therefore, you must use Azure’s native services for security and routing.
Here is a detailed design for a secure Azure network landing zone that does not use any UDRs.
- Core Design Principle: Native Services & Simplified Routing
- No Custom Routing: Accept and utilize Azure’s system routes. Rely on native Azure services for security and advanced features.
- Security at the Edge: Implement security as close to the resource as possible since you can’t centralize it with a forced-tunnel firewall.
- Managed Identities: Heavily rely on managed identities for PaaS service authentication to eliminate the need for traffic to access key vaults over private links for secrets (though private links are still recommended).
- High-Level Architecture
This design uses a flat network architecture rather than a hub-and-spoke, as hub-and-spoke almost always requires UDRs to direct traffic to a central hub.
Xx
show me a azure network landing zone design with vwan and no UDR routing
Of course. This is an excellent scenario that leverages the full power of Azure Virtual WAN (vWAN) to create a simple, scalable, and secure landing zone without the manual overhead of User-Defined Routes (UDRs).
Here is a detailed design for an Azure network landing zone using Virtual WAN and no custom UDRs.
- Design Philosophy & How It Works Without UDRs
The core principle is that Azure vWAN automates routing propagation and next-hop assignment. You define intent through configuration in the vWAN hub, and Azure automatically programs the effective routes on all connected networks (VNets, branches), eliminating the need for manual UDR management.
- No UDRs Required: The vWAN hub’s integrated router automatically propagates the correct routes to all connected spokes (VNets) and branches (VPN/ER).
- Centralized Security: All traffic is automatically routed through the central Azure Firewall based on policies you set in the vWAN hub, not based on routes you define in each VNet.
- Simplified Operations: Adding a new VNet (spoke) is as simple as peering it to the vWAN hub. Security and routing are automatically applied.
- High-Level Architecture
Diagram
Code
- Core Component Detailed Design
3.1. Azure Virtual WAN Hub (vwan-global-001)
The central nervous system. All connectivity and security radiate from here.
- Region: West Europe (Choose a primary region close to your resources)
- Hub Components:
- Azure Firewall (Standard or Premium): Deployed directly into the hub, making it a Secured Virtual Hub. This is your central chokepoint.
- ExpressRoute Gateway: For connecting your on-premises datacenter via a private ExpressRoute circuit.
- VPN Gateway (Optional): For connecting branch offices or SD-WAN appliances via IPSec VPN.
3.2. Spoke Virtual Networks (e.g., vnet-prod-weu-001)
Workload VNets are connected directly to the vWAN hub.
- Address Space: 10.1.0.0/16 (Production), 10.2.0.0/16 (Non-Prod)
- Subnets: Standard tiers (e.g., web, app, data). No UDRs are associated with any of these subnets.
- Connection to Hub: Connected via vNet Peering to the vWAN hub. This is not standard VNet peering; it’s a special “vNet Connection” that automatically handles routing propagation.
3.3. Connectivity & Routing (The Magic Without UDRs)
This is the critical section. Routing is managed by vWAN policies, not manual UDRs.
- Branch-to-VNet & VNet-to-VNet:
- How: The vWAN hub automatically learns and propagates all connected networks.
- Traffic Flow: Traffic between a branch and a spoke VNet, or between two spoke VNets, will automatically route through the vWAN hub.
- No UDR Needed: The “Remote Hub” and “Remote VNet” routes are automatically populated in the effective route tables of every connected VNet.
- Internet-Bound Traffic (Forced Internet Breakout):
- How: You create a Firewall Policy in Azure Firewall Manager.
- Configuration: In the policy, you enable “Internet traffic via Azure Firewall” for the secured hub.
- Traffic Flow: Any packet from a spoke VNet destined for a public IP address is automatically sent to the vWAN hub. The hub’s built-in router, based on the policy, directs this traffic to the Azure Firewall for inspection and egress.
- No UDR Needed: You never create a 0.0.0.0/0 route. The vWAN hub injects the necessary routes to make this happen automatically.
- Private Traffic Inspection (East-West & North-South):
- How: You create a Firewall Policy and enable “Private traffic via Azure Firewall”.
- Traffic Flow: Traffic between spokes (e.g., 10.1.0.0/16 -> 10.2.0.0/16) or from on-prem to a spoke is automatically directed to the Azure Firewall inside the hub for inspection before being allowed to proceed.
- No UDR Needed: Again, this is all handled by the vWAN hub’s routing fabric.
3.4. Security
- Azure Firewall Policy: Centralized policy managing NAT, Network, and Application rules. All traffic (internet and private) is inspected based on these rules.
- Network Security Groups (NSGs): Applied at the subnet level within each spoke VNet for micro-segmentation and as a second layer of defense. (e.g., deny all traffic from the web subnet to the data subnet except for specific ports). This is still crucial.
- Azure Private DNS Zones: Used for private resolution of Azure PaaS services (e.g., privatelink.database.windows.net). These zones are linked directly to the spoke VNets.
3.5. On-Premises Connectivity
- ExpressRoute Circuit: Connects your on-premises datacenter to the vWAN hub’s ExpressRoute gateway.
- Automatic Route Propagation: The routes from your on-premises network (advertised via BGP) are automatically propagated by the vWAN hub to all connected spoke VNets, and vice-versa.
- Benefits of This Design (No UDRs)
- Dramatically Reduced Operational Overhead: No need to create, manage, or troubleshoot custom route tables across dozens of subnets.
- Elimination of Routing Errors: No risk of asymmetric routing issues or accidentally overriding critical Azure service routes.
- Inherent Scalability: Adding a new VNet automatically ensures it gets the correct routing and security policies. The system is self-healing and consistent.
- Centralized Policy Management: Security and routing intent are defined in one place (Firewall Manager & vWAN Hub).
- Important Considerations
- Cost: vWAN and Azure Firewall are premium services. The operational savings must be weighed against the increased resource cost.
- Feature Parity: While Azure Firewall is feature-rich, it may not have the depth of features found in a best-of-breed NVA like Palo Alto (e.g., advanced URL filtering, more granular App-ID). Evaluate your requirements.
- Lock-in: This is a deeply Azure-native architecture, which can increase vendor lock-in.
Conclusion
This Azure vWAN design without UDRs represents the “cloud-native” ideal for a landing zone: fully managed, scalable, and secure by default. It trades the granular, manual control of UDRs for massive gains in operational simplicity and consistency, making it an excellent choice for enterprises all-in on Azure.