DDE Network Topology

Purpose

This document describes the network architecture for the DDE environment. The DDE topology is simpler than the primary Azure and AWS environments, consisting of two VNets connected via peering. Notably, the Active Directory servers are colocated in the same VNet as the Palo Alto firewall rather than in a dedicated identity VNet.

Topology Overview

                    Internet
                       │
                       │ (north/south)
                       ▼
          ┌────────────────────────┐
          │     Firewall VNet      │
          │   Palo Alto VM-Series  │
          │   + Active Directory   │
          └────────────────────────┘
                       │
                  VNet Peering
                       │
                       ▼
          ┌────────────────────────┐
          │     Billings VNet      │
          │  Customer AVD Session  │
          │       Hosts            │
          └────────────────────────┘

VNet Summary

VNet	Purpose	Notable
Firewall VNet	North/south traffic inspection, Active Directory	AD colocated with firewall
Billings VNet	Customer AVD session hosts	Named "billings" — contains AVD workloads

Key Design Differences from Primary Environment

The DDE network differs from the primary Azure environment in two important ways:

1. Active Directory is in the Firewall VNet

In the primary Azure environment, identity services have their own dedicated VNet. In DDE, the AD servers share the firewall VNet. This means identity traffic does not need to traverse VNet peering to reach the firewall — it is local to the same VNet. However, it also means the firewall VNet contains both network infrastructure and identity workloads.

2. Only Two VNets

DDE is a simpler environment with just two VNets rather than the multi-spoke model used in Azure and AWS. There is no separate management, dev, or identity VNet — the firewall VNet serves as both the hub and the identity tier.

Traffic Flow

North/South Traffic (Internet ↔ AVD Sessions)

Customer AVD connections originate from the internet and are inspected by the Palo Alto firewall before reaching session hosts in the Billings VNet.

• Inbound: Internet → Firewall VNet (untrust zone) → policy check → VNet peering → Billings VNet (AVD session hosts)
• Outbound: Billings VNet → VNet peering → Firewall VNet → untrust zone → Internet

Identity Traffic

AVD session hosts in the Billings VNet reach Active Directory via the VNet peering to the Firewall VNet. AD traffic stays within the peered VNet pair and does not traverse the internet.

Customer AVD Sessions

Customers connect to AVD session hosts in the Billings VNet through the firewall. The firewall enforces zone-based policies controlling what resources AVD sessions can access, limiting the blast radius if a session is compromised.

VNet Peering Configuration

Peering	Direction	Purpose
Firewall VNet ↔ Billings VNet	Bidirectional	AVD traffic inspection, AD access for session hosts

Design Rationale

Why AD is in the Firewall VNet

The DDE environment was designed for simplicity given its focused purpose — delivering customer AVD sessions. Colocating AD with the firewall reduces the number of VNets to manage and eliminates the need for a dedicated identity peering relationship. The tradeoff is that the firewall VNet carries both infrastructure and identity workloads, which is a known design difference from the primary environment.

Why the Prod VNet is Named "Billings"

The Billings VNet name reflects the original business purpose of the workloads it hosts — billing-related applications delivered to customers via AVD. Despite the name, it functions as the production workload VNet for the DDE environment.

Tenant Isolation

The DDE environment runs in a completely separate Azure tenant from the primary environment. There is no network connectivity between the DDE tenant and the primary Azure tenant — the VNet peering described in this document is internal to the DDE tenant only.

See DDE Infrastructure Overview for full tenant isolation details.

Compliance Relevance

Requirement	How Network Topology Addresses It
HIPAA §164.312(a) — Access Control	Firewall zone policies control AVD session access
HIPAA §164.312(e) — Transmission Security	All customer traffic inspected by Palo Alto firewall
SOC2 CC6.6 — Logical Access	Customer sessions isolated to Billings VNet
SOC2 CC6.7 — Data Transmission	Centralized firewall inspects all inbound/outbound flows

Document History

Date	Change	Author
March 2026	Fixed DDE infrastructure and network topology links	Rory
February 2026	Initial draft	Rory

Related Documentation

• DDE Infrastructure Overview
• Palo Alto Firewall Overview
• Azure Network Topology
• AWS Network Topology