Designing Cloud Landing Zones by Traffic Flow: A Defence‑in‑Depth, DMZ‑First Architecture

As enterprises adopt Microsoft Azure for large‑scale and regulated workloads, security architecture must be driven by traffic trust boundaries and inspection intent, not connectivity alone. Regulatory frameworks consistently require a clear separation between Internet‑untrusted and private enterprise traffic, enforced through defence‑in‑depth controls aligned to the OSI model.

This drives the adoption of a DMZ‑first landing zone architecture, where volumetric protection, application‑layer inspection, and perimeter controls are enforced at well‑defined trust boundaries. Security enforcement is prioritised before access, rather than being an afterthought of connectivity. A distributed hub architecture enables this model at scale, delivering consistent controls while improving resiliency, fault isolation, and operational clarity.

 

Traffic Classification in an Enterprise Landing Zone

Enterprise traffic flows are classified based on origin, destination, and trust level, which directly dictates inspection requirements:

• Internet Inbound (North–South): Traffic from the public Internet to Azure‑hosted applications
• Internet Outbound (South–North): Egress traffic from private workloads to the Internet
• East–West: Traffic between virtual networks within or across regions
• Hybrid Connectivity: Traffic between Azure, on‑premises, and multi‑cloud environments

Each flow presents a distinct risk profile, making a uniform connectivity and inspection model unsuitable for enterprise and regulated environments.

Hub‑and‑Spoke as the Foundation for Centralised Security

Enterprises commonly adopt a Hub‑and‑Spoke topology using VNET peering or Azure Virtual WAN, extending hybrid connectivity via Site‑to‑Site VPN or ExpressRoute.

The hub provides a centralised, datapath‑centric layer for shared networking and security services, while spoke VNETs host application workloads and remain private, typically without public IPs. Ingress and egress are handled through shared, centrally managed endpoints.

This model consolidates critical controls—Azure Firewall, Azure WAF, and DDoS protection—at controlled entry and exit points, significantly reducing the attack surface. Integration with Microsoft Sentinel enables cross‑layer visibility, threat hunting, and detection of risks such as unauthorised access and data exfiltration.

Why a Single Hub Is Not Sufficient

Using a single hub to process all traffic types introduces operational and security challenges at scale by forcing Internet‑untrusted and private traffic through the same inspection tier.

Key limitations include:

• Coupled Internet and private security policies
• Rapid firewall rule sprawl and management overhead
• A single blast radius across all traffic types
• Throughput and SNAT scalability constraints
• Increased difficulty meeting regulatory separation requirements
• These issues become more pronounced as environments scale across regions and workloads.

Multi‑Hub as an Enterprise‑Grade Evolution

A multi‑hub architecture resolves these challenges by separating inspection responsibilities across dedicated hubs:

• DMZ Hub VNET: Internet‑facing traffic and perimeter security enforcement
• Core Hub VNET: Outbound Internet access, East‑West, and hybrid traffic inspection

This separation aligns security controls with traffic intent, reduces policy complexity, limits blast radius, and simplifies operations.

In the next section, we explore multi‑hub architecture patterns and examine how each traffic flow is inspected and governed in practice.

Scenario 1 – Third‑Party Firewall–Centric Multi‑Hub Design

In this scenario, third‑party firewalls provide inspection for all traffic flows—Internet inbound, Internet outbound, East‑West, and hybrid connectivity—while Azure WAF and Azure DDoS Protection are used to defend against volumetric attacks, application‑layer threats, and malicious bot traffic.

Architecture Overview

The design uses two dedicated hub virtual networks, with spoke VNets peered to both hubs to maintain traffic separation based on trust and inspection requirements:

1. DMZ Hub VNET (Internet Ingress Hub)
2. Core Hub VNET (Egress, East‑West, and Hybrid Hub)

DMZ Hub VNET – Internet Inbound (North–South) Traffic

The DMZ hub establishes a dedicated perimeter for Internet‑facing applications.

• Internet traffic lands on a public Application Gateway with Azure WAF, protected by an Azure DDoS Protection Plan applied to the public frontend IP.
• Third‑party firewalls are deployed behind the Application Gateway to perform deep packet inspection.
• Firewalls operate in active‑active mode as standalone appliances, using three dedicated network interfaces (Untrust, Trust, and Management), each placed in separate subnets.
• Application Gateway provides load balancing and health probing, ensuring firewall availability and resiliency.

Core Hub VNET – Egress, East‑West, and Hybrid Traffic

The core hub handles all non‑Internet‑inbound traffic flows, including private inter‑VNET communication and hybrid connectivity.

• Third‑party firewalls are deployed behind an internal Azure Load Balancer, which maintains high availability using health probes.
• Firewalls follow the same active‑active, three‑NIC design for consistent policy enforcement and operational symmetry.
• Azure NAT Gateway is associated with the firewall Untrust subnet to scale outbound SNAT and simplify Internet egress with deterministic public IP.
• Site‑to‑site VPN or ExpressRoute terminate in this hub for on‑premises and multi‑cloud connectivity, ensuring private and regulated traffic bypasses Internet‑facing controls.

 

Architecture Patterns - Traffic Flow 

1.1 North–South (Internet Inbound) Traffic Flow

This flow applies when applications hosted on Azure (VMs, VM Scale Sets, or services behind Internal Load Balancer / Internal Application Gateway) are published to the Internet.

As shown in the diagram, Internet-bound client requests enter Azure through a dedicated DMZ Hub, where perimeter security controls are enforced before traffic reaches private application spokes.

Inbound Request Flow (Blue Path)

1. Client → Application Gateway (WAF)
   A client request (for example, app1.example.com) is resolved via DNS and lands on the public endpoint of Azure Application Gateway.
   Azure WAF performs Layer‑7 inspection, bot protection, and rule evaluation.
2. Application Gateway → Firewall (DMZ Hub)
   Based on hostname and routing rules, Application Gateway forwards traffic to the firewalls while preserving the client’s real IP using the X‑Forwarded‑For (XFF) header.
3. Firewall → Application (Spoke VNET)
   The firewall performs DNAT to the internal destination (Internal Application Gateway or Internal Load Balancer) and SNAT to its trust‑interface IP to ensure symmetric return traffic.
   Traffic is then routed over VNET peering to the private application workload.

Response Flow (Green Path)

1. Application → Firewall
   The application responds using its private IP, with the firewall trust interface as the destination.
2. Firewall → Application Gateway
   The firewall forwards the response based on its session state.
3. Application Gateway → Client
   Application Gateway returns the response to the Internet client.

DDoS Protection

Azure DDoS Protection continuously monitors the Application Gateway public IP and mitigates volumetric attacks before they reach the application stack.

 

North–South (Internet Inbound) Traffic Flow

 

Key Design Considerations

• Application Gateway routing - Use a multi‑site listener with hostname‑based rules to steer traffic to the appropriate firewall backend.
• Firewall backend mapping - Register firewall VMs in a single backend pool and differentiate applications using distinct backend settings (same protocol, different ports).
• Application steering at firewall - Firewalls perform port‑based DNAT (or private FQDN‑based DNAT where supported) to forward traffic to the correct application private IP in spoke VNets.
• Traffic symmetry - Source NAT is applied on the firewall trust interface to maintain symmetric return paths.
• Protocol support - The same pattern applies to TCP/UDP workloads, using an External Azure Load Balancer instead of Application Gateway where WAF is not required.

Client IP visibility

• Application Gateway enables WAF inspection using the real client IP, preserved downstream via X‑Forwarded‑For.
• With Azure Load Balancer, client IP is retained up to the firewall for IP‑based enforcement, with Azure DDoS Protection safeguarding the public frontend.

1.2 Hybrid Connectivity Traffic Flow

Hybrid connectivity represents communication between Azure workloads and on‑premises environments using Site‑to‑Site VPN or ExpressRoute.

 Traffic Flow

• Request (Blue: 1–4):
  Traffic originates from applications in spoke VNETs and is forwarded via UDRs to the Internal Load Balancer, through active‑active firewalls, and then to on‑premises via VPN or ExpressRoute.
• Response (Green: 5–8):
  Return traffic follows the same path in reverse.

Hybrid Connectivity Traffic Flow

 

Key Design Considerations

• Source and destination IP addresses remain unchanged end‑to‑end, despite firewalls operating behind an Internal Load Balancer.
• UDRs steer both outbound and inbound hybrid traffic to the Internal Load Balancer as the next hop.
• Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. 
• Azure Virtual Network Manager can be used to manage and scale UDR deployment centrally across Hub and spoke networks.

1.3 East-West Traffic flow

This traffic flow represents the connectivity between resources across VNETs through Firewall. Considerations remain same as “Hybrid Connectivity Traffic flow” mentioned above.

East-West Traffic Flow

1.4 Egress/Outbound Connectivity Traffic flow

This traffic flow represents the connectivity from the resources hosted inside VNETs to Internet through Firewalls deployed behind Internal Load Balancer in Core Hub VNET.

Egress/Outbound Connectivity Traffic flow

Key Considerations: 

• A default route (0.0.0.0/0) UDR directs Internet-bound traffic to the Internal Load Balancer for firewall inspection.
• Firewall performs SNAT to its untrusted interface, after which Azure NAT Gateway translates traffic to a fixed public IP.
• Alternatively, a public IP can be assigned to the firewall untrusted interface to perform SNAT directly, removing the need for NAT Gateway and reducing cost.
• Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. 

However, with horizontal firewall scaling, outbound public IPs become non-deterministic.

 

Scenario 2: Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows

In this scenario, third‑party firewalls secure Internet‑facing traffic, while Azure Firewall handles Egress, East–West, and Hybrid flows. This separation enables organisations to retain existing perimeter security investments while adopting a fully managed, cloud‑native control and data plane for internal traffic flows.

As private traffic patterns scale, particularly for chatty East–West communication, Azure Firewall helps simplify operations and improves scalability by offloading traffic inspection to a managed service. This approach reduces operational overhead and provides consistent policy enforcement across internal and hybrid flows.

Setup

• DMZ Hub design remains unchanged from Scenario 1.
• Core Hub VNET use Azure Firewall for better scalability, built‑in resilience, and simplified operations.
• Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic.
• It requires a single subnet (unless force tunnelling is enabled), optimising IP consumption.
• Outbound traffic is SNATed by Azure Firewall and further translated via Azure NAT Gateway.
• Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required.

Traffic Flow

North–South (Internet Inbound) Traffic Flow represented with Numbers.

• Request flow represented with Blue: 1–3
• Response flow represented with Brown: 4–6

Egress/Outbound Connectivity Traffic flow represented with alphabets.

• Request flow represented with Green: A–C
• Response flow represented with Blue: D–F

Hybrid flow represented with purple

Architecture Diagram:

Third‑Party Firewalls for Ingress, Azure Firewall for Private Flows

 

Further if you want to use Azure Firewall for the Internet Ingress flow, you can use it as well. Below is the architecture diagram explaining the same pattern.

 

Azure Firewalls for Ingress and Private Flows

Key Considerations: 

• Application Gateway behaviour remains the same as Scenario 1; however, backend pools use IP‑based targets.
• Internal applications should be exposed via internal Application Gateway or internal load balancer to provide stable backend IPs.

• To optimise traffic flow and avoid unnecessary network address translation, the private IP address of the Application Gateway or internal Load Balancer should be configured in the backend pool of External Load Balancer in DMZ Hub VNET. This design does not need Azure Firewall to perform both source NAT (SNAT) and destination NAT (DNAT) operations.

• Further, implementing User Defined Routes (UDRs) in the Application Gateway subnet—specifically for spoke VNet CIDR ranges steers traffic routing through the Firewall.

• For non-web (TCP/UDP) workloads, applications can be directly exposed through the firewall public IP, with Azure DDoS Protection applied to mitigate volumetric attacks.
• Spoke VNET subnets should be associated with custom route tables with Propagate Gateway Routes set to No, preventing gateway-learned routes from bypassing the intended security inspection path configured via UDR. However, VPN Gateway Subnet Route table should have route table with Propagate Gateway Routes set to Yes. 

Scenario 3 - Overcoming Peering Complexity at Scale with Azure Virtual WAN

In environments where each application is hosted in its own dedicated VNET for isolation and stronger security, a traditional hub‑and‑spoke model quickly becomes complex. With a single hub, "N" spoke VNETs require "N" peering's; introducing multiple hubs increases this to "2N", significantly amplifying operational overhead—especially across multiple regions.

Azure Virtual WAN addresses this challenge by eliminating the need for extensive VNET peering. As a global, managed service, it simplifies large‑scale and multi‑region architectures while providing built‑in scalability and operational consistency.

Setup

• DMZ Hub design and components remain unchanged from Scenario 1 keeping defense in depth principles intact for Internet Inbound or North-South traffic.
• Core Hub VNET is replaced with Azure Virtual WAN Secure Hub which has Azure Firewall inside the managed Secure Hub VNETs. This further eliminates the need for creating Azure Firewall Subnet, Azure NAT Gateway resources for East-West, Egress and Hybrid connectivity and provides same level of security protection as mentioned in Scenario 2.
• Secure Hub design using Virtual WAN removes the routing and inspection complexity which was unless required in Scenario 2 by removing UDR configurations in Spoke VNETs, Gateway Subnet and Azure Firewall Subnet. This provides simplified design and operations with built-in resiliency by leveraging the managed platform.
• Azure Firewall eliminates the need for load balancers and reduces complexity for chatty east‑west traffic.
• East-West, Egress, and Hybrid connectivity happens via VPN Gateway and Express Route Gateway present in Virtual Hub. All private and Internet Egress traffic is inspected by Azure Firewall present in secure Hub.   
• Outbound traffic is SNATed to Public IP by Azure Firewall thus avoiding the need of Azure NAT Gateway.
• Firewall‑based SNAT to public IP can be used to avoid NAT Gateway costs when deterministic egress IPs or higher SNAT scale are not required.

Traffic Flow

North–South (Internet Inbound) Traffic Flow represented with Numbers.

• Request flow represented with Blue: 1–5
• Response flow represented with Green: 6–10

Egress/Outbound Connectivity Traffic flow represented with Red

Hybrid flow represented with Green

East-West connectivity flow represented with black

 

Architecture Diagram:

 

Hub and Spoke with Azure Virtual WAN

 

Key Considerations

• Virtual WAN has additional cost
• Refer to architecture diagram above for different traffic flows. The DMZ VNET components consideration remains same as per scenario 1
• You can use your own managed public IP on Azure Firewall for applying standard IP/Network DDoS protection plan.

Benefits of multi-Hub approach over single Hub

You can use this table as decision matrix to choose the best option for your application requirements.

 

Key Takeaways

Security‑first landing zones should not be designed as one‑size‑fits‑all networks. By designing hubs based on traffic trust level and inspection intent, rather than convenience, organisations gain:

o   Stronger security boundaries and better fault isolation

o   Predictable operations at scale

o   Lower long‑term cost and complexity

o   Design for traffic flows, not just connectivity

o   Use DMZ hubs exclusively for Internet‑untrusted traffic

o   Use Core hubs for East‑West, outbound, and hybrid connectivity

o   Map security controls to OSI layers

o   Avoid single‑hub designs for large, regulated, or multi‑region environments

This distributed hub‑and‑DMZ landing zone provides a clean, scalable, and secure foundation for enterprise workloads in any Hyperscaler. For regulated, internet‑exposed, or multi‑region environments, a distributed hub with a dedicated DMZ is no longer optional — it is a foundational architecture decision.