In Azure, a DMZ (Demilitarized Zone) can be implemented using both a public subnet and a private subnet within a virtual network (VNet). This design allows segmentation of public-facing resources from internal components that require tighter security.

DMZ Subnet Responsibilities

• Public Subnet: Application Gateway, Azure Firewall DNAT targets, or public web servers accessible via public IP.
• Private Subnet: Backend services such as API servers or inspection appliances that should not be internet-facing.

Traffic Flow

1. User sends a request to the public IP (e.g., Application Gateway) in the Public Subnet.
2. Application Gateway routes traffic to VMs or services in the Private Subnet.
3. Backend services in the Private Subnet may query internal services (e.g., databases) in a separate internal subnet or VNet.

NSG Rules (Azure Network Security Groups)

1. DMZ Public Subnet → DMZ Private Subnet

2. DMZ Private Subnet → Internal Subnet (Separate VNet or Subnet)

Azure Firewall Rules (if using Azure Firewall)

If using Azure Firewall between DMZ and internal networks, rules would be configured in the Firewall Policy:

• Allow DNAT or Application rules from public IP to internal web service
• Allow network rules from Private Subnet IPs to DB or APIs in Internal Subnet
• Deny all other traffic not explicitly allowed

Best Practices

• Use NSGs to restrict traffic at the subnet or NIC level
• Inspect east-west traffic using Azure Firewall or NVA appliances
• Enable logging with NSG Flow Logs and Azure Monitor
• Use Azure Private Link to access PaaS services securely from Private Subnet

The post Azure DMZ Architecture appeared first on Azure Security Architect.