Azure China Test Environment (TST) Network Architecture

1. Document Overview

This document details the underlying network architecture, traffic routing logic, and external connectivity boundaries of the Azure China Test Environment (TST).

• Environment Positioning: The TST environment serves as a full-featured replica of the Production (PROD) environment. Its core purpose is to provide a network topology and security control baseline that is highly consistent with production, facilitating comprehensive validation during pre-launch and integration testing phases.
• Isolation and Simulation Mechanism: To guarantee the absolute security of real production data, the TST environment strictly cuts off all connections to physical on-premises data centers. Instead, the TST environment connects to the MOCK environment via SD-WAN appliances (treating the MOCK environment as a "Virtual On-premises" data center). This establishes a fully closed-loop hybrid cloud testing sandbox.

2. Network Topology

The TST environment adopts the standard Hub and Spoke topology, consistent with the PROD environment design.

• TST Hub Node (Central Hub): Acts as the traffic distribution and security compliance center for the test network, hosting core network elements such as the test core firewalls and internal load balancers.
• TST Spoke Nodes (Business Test Subscriptions): Represent the independent business subscriptions participating in testing and their respective Virtual Networks (VNets). All TST Spoke subscriptions are connected to the TST Hub node via VNet Peering.
• SD-WAN Subscription (Simulated On-premises Interconnect Hub): The TST environment contains an independent subscription dedicated to SD-WAN nodes. These nodes do not connect to physical data centers; rather, they are used to establish directed connectivity to the MOCK environment.

3. Core Components and IP Address Management (IPAM)

To achieve absolute network isolation between the test environment and the production environment (10.47.x.x), the TST environment operates on a completely independent IP address space (10.46.x.x). However, it strictly retains the same subnet role mapping logic used in production.

(Note: Generally, the overarching IP address space for the Azure China TST environment—including infrastructure and business test subnets—is primarily allocated from the 10.46.x.x address block.)

3.1 Core Subnet Mapping Principles

The network utilizes specific IP suffixes/subnets to distinguish different service roles. The key mappings for the TST environment are as follows:

• 10.46.0.x subnet: TST Hub central network devices (encompassing the test core firewalls and internal load balancers).
• 10.46.1.x subnet: TST Core DNS server cluster.
• 10.46.2.x subnet: Big Data test business cluster.
• 10.46.3.x subnet: Agent service test cluster.
• 10.46.4.x subnet: Tier 0 test environment.
• 10.46.5.x and 10.46.6.x subnets: APIM (API Management) test business cluster.
• 10.46.7.x subnet: Dedicated to SD-WAN subscription underlay interconnection (connecting to the MOCK virtual on-premises environment).

3.2 Core Security and High Availability Components

• FortiGate Firewall Cluster: Deployed within the TST Hub (10.46.0.x), consisting of active and standby devices (the IP addresses of the primary and standby firewall nodes are 10.46.0.7 and 10.46.0.8, respectively). This cluster enforces unified access control and performs East-West and North-South traffic inspection for the TST environment.
• Internal Load Balancer (ILB): The IP address is 10.46.0.38. The front end receives outbound traffic from all TST Spoke subscriptions and distributes it to the backend TST firewall cluster using a Round Robin mechanism.

4. Traffic Routing Mechanisms

4.1 Internal Asymmetric Routing Prevention

Consistent with the production environment, the underlying network employs a directional bypass mechanism for lateral (Sub-to-Sub) traffic to ensure the accuracy of test validations:

• Outbound Traffic: Source TST Spoke business subscription -> TST Internal Load Balancer (10.46.0.38) -> TST Core Firewall Cluster (10.46.0.7 or 10.46.0.8) -> Destination TST Spoke.
• Return Traffic: After processing by the firewall, the return traffic is routed directly back to the source TST Spoke's IP address. This forces a bypass of the load balancer (10.46.0.38), ensuring the absolute integrity of the TCP handshake and session state.

4.2 Simulated Hybrid Cloud Communication (TST to MOCK)

This is a core design highlight of the TST environment's closed-loop testing architecture. The TST environment completely blocks connections to real physical data centers.

• Communication Path: TST Spoke business VNet -> TST Hub -> VNet Peering -> TST SD-WAN Node (10.46.7.x subnet) -> MOCK Environment.
• Routing Logic: In this architecture, the MOCK environment simulates a Virtual On-premises data center. The TST environment establishes connectivity with MOCK via SD-WAN and dynamically learns the MOCK environment's routes. This allows business teams to fully validate complex hybrid cloud logic (e.g., cloud systems invoking "on-premises" systems) without touching the actual production network.

4.3 Internet and Cross-Cloud Routing Strategy

• Mainland China Traffic: If the internal TST environment needs to access the domestic public internet, the traffic is inspected and permitted by the TST Firewall cluster (10.46.0.7 and 10.46.0.8) and then routed directly through the local Azure China internet gateway.
• International Traffic (Cross-Cloud Proxy): Based on data loss prevention and isolation principles, the TST environment generally does not have cross-border dedicated line privileges to the production-grade AWS Proxy. Customized routing paths from the test environment to the global internet (e.g., overseas resources like Google) are strictly restricted or physically blocked at the network layer.

5. Operations & Management Boundaries

• Responsibility Decoupling and Environment Independence: When network and security teams modify TST firewall policies (within the 10.46.0.x subnet) or UDR (User Defined Route) tables, the impact radius is strictly confined to the 10.46.x.x address space and the MOCK network boundaries. This provides high fault tolerance for development and testing teams and ensures absolutely no interference with the PROD environment (10.47.x.x).
• External Inbound Traffic: This document primarily focuses on the internal TST network architecture. For inbound traffic originating from the external public internet targeting internal TST services, traffic is uniformly managed and inspected at Layer 7 by the dedicated DMZ TST environment (which hosts an independent App Gateway and WAF). For detailed architectural information regarding inbound flows, please refer to the standalone DMZ Architecture Document.