Enterprise Cloud Network & Landing Zone Network Architecture
A unified blueprint for building secure, scalable, and governable cloud networks — from VPC 1.0 basic connectivity to VPC 3.0 Landing Zone governance, covering CCN, Direct Connect, public ingress/egress, defense-in-depth, and end-to-end traffic observability.
Evolution of Cloud Networking
Cloud networking has evolved through three distinct generations, each addressing the limitations of its predecessor. Understanding this evolution is critical when designing an enterprise-grade network that balances agility, scalability, and governance.
The jump from VPC 2.0 to VPC 3.0 is not merely technical — it is organizational. It introduces a Network Admin Account owned by IT/Network team, fully decoupling network ownership from business workload ownership. This is the foundation of Landing Zone governance.
Landing Zone Network Overview
2.1 · Five Core Capability Pillars
Unified Network Planning
Hierarchical IP allocation, CIDR reservation, VPC naming convention
Unified Connectivity
CCN-based hub-and-spoke, cross-account, cross-region, cross-cloud
Unified Traffic Governance
Centralized ingress/egress, route tables, traffic steering policies
Unified Security Boundary
Defense in depth, CFW, NACL, security groups, zero-trust
Unified Operability
Flow logs, network probes, traffic mirroring, one-click diagnostics
2.2 · Hub-and-Spoke Reference Architecture
Hub Components (Network Admin Account)
- CCN — central route exchange fabric; all VPCs, gateways attach here
- Ingress VPC — Public CLB, WAF, CDN entry point for north-south traffic
- Egress VPC — NAT Gateway (SNAT only) for outbound internet traffic
- CFW VPC — Cloud Firewall / NGFW / GWLB for east-west inspection
- Hybrid Cloud Gateway — Direct Connect Gateway & VPN Gateway to on-premise
Spoke Components (Workload Accounts)
- App VPCs — business workloads (compute, storage, databases)
- Spoke VPCs attach to CCN; no direct internet ingress/egress
- Network permissions are restricted — business team owns compute only
- Production / Non-production live in separate accounts and separate CCNs
- Shared Services Account (AD, DNS, Bastion) sits as a special spoke
2.3 · Six Challenges Solved by Landing Zone Network
01 Fragmented Architecture
Point-to-point VPC peering creates an unmaintainable mesh. Landing Zone consolidates into a single hub.
02 IP Conflicts
Without hierarchical IP planning, CIDR ranges overlap during interconnection. Centralized IP pool prevents collision.
03 Legacy Model Limitations
Single-account / single-VPC cannot scale beyond a few hundred resources. Multi-account strategy is mandatory for enterprise.
04 Inconsistent Connectivity
Ad-hoc peering + gateway placement causes asymmetric routing. CCN provides symmetric, deterministic routing.
05 Unclear Traffic Boundaries
Without centralized ingress/egress, audit and compliance are impossible. Hub VPC enforces clear traffic boundaries.
06 Lack of Unified Control & High Re-design Cost
Decentralized ownership means every new business line re-designs network. Landing Zone enables plug-and-play onboarding.
Multi-Account / Multi-VPC Partitioning
A multi-account strategy fully decouples network, shared services, and business. Each domain has its own owner, blast radius, and permission boundary. This is the cornerstone of Landing Zone governance.
| Account Type | Owner | Core Components | Network Permissions | Primary Responsibility |
|---|---|---|---|---|
| Network Account (Hub) Hub |
IT / Network Team | Hub VPC, DC Gateway, CCN, VPN Gateway, NAT Gateway, Public CLB, CFW | Full network ownership — routing, firewall, gateway management | Provide centralized connectivity, security inspection, and traffic governance for all spoke accounts |
| Shared Services Account Shared |
IT / Platform Team | AD (Active Directory), DNS, Bastion Host, Security Scanning appliances, central logging | Limited — consumes network services from Hub; cannot modify routing | Provide shared infrastructure services consumed by all workload accounts |
| Workload Accounts (Spokes) Spoke |
Business / Application Teams | App VPCs — compute (CVM, TKE), storage (COS, CBS), databases (CDB, Redis) | Restricted — can only operate compute/storage resources inside their own VPC; no route/firewall modification | Deliver business applications; consume network and shared services via CCN |
Why Decouple?
- Blast radius isolation — a misconfigured route in a workload account cannot impact other accounts
- Audit clarity — network actions are attributable to the Network team
- Permission minimization — business teams get least-privilege compute-only roles
Production / Non-Production Split
- Production and Non-production use separate CCN instances
- Separate route domains — no accidental cross-environment traffic
- Independent Direct Connect gateways where required
- Environments may share the Hub account but with isolated CCNs
Onboarding New Business
- New workload account → attach VPC to existing CCN
- No re-design of network — plug-and-play
- IP allocation from the hierarchical pool prevents conflicts
- Default security policies inherited from Hub
IP Planning & VPC Design
4.1 · Hierarchical IP Allocation
IP addresses must be planned top-down from a global pool to avoid conflicts during future interconnection, M&A, or hybrid cloud extensions. The hierarchy below is the recommended allocation model:
Private RFC1918 ranges are used for VPCs and subnets. Plan at least 2x headroom for future growth.
10.0.0.0/8— large enterprises; sufficient for thousands of VPCs172.16.0.0/12through172.31.0.0/16— mid-size; common for regional split192.168.0.0/16— small footprint; single-VPC deployments- Mask range:
/12(largest VPC) to/28(smallest subnet, 11 usable IPs)
4.2 · VPC Planning Rules
| Deployment Scenario | VPC Count | Subnet Requirement | Rationale |
|---|---|---|---|
| Single Region, Single AZ | 1 VPC per region | ≥1 subnet per tier (web/app/db) | Simplest topology; suitable for non-critical workloads |
| Single Region, Cross-AZ DR | 1 VPC per region | ≥2 subnets in different AZs per tier | Provides AZ-level fault tolerance; instances distribute across AZs |
| Multi-Region DR | ≥1 VPC per region | ≥2 subnets per tier per region | Region-level disaster recovery; active-active or active-standby across regions |
| Multi-Region Active-Active | ≥2 VPCs (one per region) | Full subnet stack per region | Geo-redundant; traffic routed via Global Service Accelerator or DNS |
4.3 · Subnet Capacity Reference
Usable IPs exclude network address, broadcast address, and 3 cloud-reserved addresses per subnet. Right-size subnets to avoid waste — a /28 is enough for a small admin tier.
4.4 · Three-Tier Subnet Model
Every VPC should implement a three-tier subnet classification that encodes internet accessibility. Security groups and NACLs enforce the boundary at each tier.
Public Subnet Internet In/Out
- Direct internet ingress and egress
- Hosts public-facing resources: Public CLB, NAT Gateway, Bastion
- Assigned a public IP / EIP
- Internal communication allowed within VPC
- Highest exposure — strictest security group
Protected Subnet No Internet
- No internet access — neither inbound nor outbound
- Internal communication restricted to defined peers only
- Hosts sensitive databases, internal APIs, compliance-bound systems
- Used for air-gapped or PCI-DSS / HIPAA workloads
- Egress, if any, requires explicit proxy
Private Subnet NAT Outbound
- No direct internet inbound
- Outbound via NAT Gateway (SNAT) in the Egress VPC
- Internal communication allowed within VPC
- Hosts application servers, microservices, internal APIs
- Most common tier — default for compute workloads
In Landing Zone topology, workload VPCs typically contain only Private and Protected subnets. Public subnets live in the Hub account's Ingress/Egress VPCs, centralizing internet exposure to a controlled boundary.
Cloud Connect Network (CCN)
5.1 · Three Core Values
01 Cross-Account Interconnection
VPCs from different accounts attach to a single CCN instance. Traffic flows through CCN without exposing VPC peering to each account — eliminating the N×(N-1)/2 peering explosion.
02 Route Isolation
Multiple route tables can be defined within one CCN. Different VPC groups (production / non-production / shared services) use isolated route tables, preventing unwanted cross-domain traffic.
03 Fine-Grained Route Control
Per-VPC route tables allow/deny specific CIDRs. Enables service insertion patterns — e.g., steering traffic through a firewall VPC before reaching its destination.
5.2 · CCN Service Stats
5.3 · CCN Route Table Design — Service Insertion Pattern
The most important pattern in Landing Zone networking is service insertion via CFW VPC. Traffic between two workload VPCs is steered through the firewall VPC for inspection, rather than flowing directly.
Step 1 — Route Tables Inside Each VPC
Step 2 — CCN Route Tables (Per-VPC, Applied at CCN Edge)
You cannot define route tables directly inside CCN. Define them inside the CFW VPC and publish to CCN. The CCN controller then enforces these routes at the edge of each VPC attachment, achieving per-VPC route isolation and service insertion.
5.4 · Six Route Tables per CCN
A well-governed CCN maintains six route tables to separate traffic domains:
| Route Table | Purpose | Applies To |
|---|---|---|
| Default | Catch-all for unmapped traffic | All attachments |
| Inbound | Public ingress traffic from CLB / WAF | Ingress VPC attachment |
| Outbound | Egress traffic toward NAT Gateway | Workload VPCs needing internet |
| App | East-west inter-VPC traffic | Workload VPCs (inspected by CFW) |
| VPN | Site-to-site / remote VPN traffic | VPN Gateway attachment |
| Operations | Bastion, monitoring, flow log traffic | Shared Services / Ops VPCs |
Direct Connect
Hub-Model Direct Connect (CCN-type DC Gateway)
The Landing Zone uses the CCN-type Direct Connect Gateway deployed in the Network Admin Account. On-premise traffic ingresses through the Hub, gets inspected by CFW, then distributes to spoke VPCs via CCN — providing a single, governed hybrid-cloud entry point.
- BGP enabled for dynamic route exchange — routes auto-converge on link failure
- Centralized in Network Account — full visibility, audit, and governance
- Production / Non-production use independent CCN and route domains
- Supports 1+1 redundant physical links for high availability
- BGP ECMP across redundant links maximizes bandwidth utilization
6.1 · Bandwidth vs. Migration Time
Approximate time to transfer 100 TB of data over a dedicated link at sustained utilization (~95% efficiency after protocol overhead).
| Bandwidth | Theoretical Throughput | Time for 100 TB | Recommended Use Case |
|---|---|---|---|
| 1 Gbps | ~115 MB/s | ≈ 9.5 days | Small workload migration, ongoing sync after initial bulk transfer |
| 2 Gbps | ~230 MB/s | ≈ 4.7 days | Mid-size workload, daily delta sync |
| 5 Gbps | ~575 MB/s | ≈ 1.9 days | Large enterprise initial migration, database cutover |
| 10 Gbps | ~1.15 GB/s | ≈ 1 day | Bulk data migration, time-critical cutover windows |
For large migrations, provision 10 Gbps for the initial bulk transfer, then downgrade to 1–2 Gbps for ongoing hybrid-cloud traffic. This optimizes cost while meeting the cutover deadline.
Public Ingress & Egress
7.1 · Public Ingress Architecture
Public CLB in Ingress VPC (Hub)
The Public CLB (Cloud Load Balancer) is deployed in the Ingress VPC of the Network Admin Account and is attached to CCN. Backend services from workload accounts register with this CLB, achieving centralized internet exposure.
Traffic Path — North-South Inbound
Services from multiple workload accounts can register as backends of a single CLB in the Network account. This is achieved via CCN — the CLB sees backend IPs across all spoke VPCs as if they were local. Benefits: single public IP, unified WAF policy, simplified DNS.
7.2 · Public Egress Architecture
NAT Gateway in Egress VPC (Hub)
Outbound internet traffic from workload VPCs is centralized through a NAT Gateway in the Egress VPC. SNAT-only mode ensures all outbound traffic appears from a single, auditable public IP.
- SNAT only — outbound source IP translation; no inbound DNAT
- ECMP for scalable bandwidth — multiple NAT Gateways can be ECMP-grouped to exceed single-instance bandwidth limits
- Centralized egress enables IP whitelisting with third-party APIs and unified egress logging
Multiple workload accounts can route their outbound traffic via the same NAT Gateway in the Network account. CCN routes the traffic to the Egress VPC; NAT Gateway performs SNAT; egress IP is consistent across all spoke accounts — simplifying partner API whitelisting and audit.
Firewall & Security Architecture
8.1 · Three-Layer Defense in Depth (East-West Traffic)
Macro-Segmentation — Network Segmentation
Strict production / test isolation via separate CCN instances, separate VPCs, and separate route tables. Production workloads cannot route to staging or dev environments by default. The blast radius of any compromise is limited to a single environment.
Service Insertion — Security Inspection
High-risk east-west traffic is steered through NGFW (Next-Generation Firewall) in the Hub VPC. Implemented via CCN per-VPC route tables that direct inter-VPC traffic to the FW VPC for inspection before reaching the destination. Supports IDS/IPS, threat intel, and deep packet inspection.
Micro-Segmentation — Instance-Level Zero-Trust
Security Groups + NACLs enforce least-privilege at the resource and subnet levels. Security groups are stateful, attached per ENI; NACLs are stateless, attached per subnet. Together they implement zero-trust: no implicit trust based on network location, only explicit allow rules.
8.2 · Firewall Products Matrix
| Product | Traffic Direction | Scope | Primary Capability |
|---|---|---|---|
| CLB WAF | North-South Inbound | L7 HTTP/HTTPS | Web attack protection (SQL injection, XSS) + CC attack defense |
| VPC Firewall | East-West | Attached to CCN | Inter-VPC traffic inspection; enables service insertion pattern |
| Internet Edge Firewall | In/Out Boundary | VPC egress to internet | Boundary inspection; outbound threat detection & DLP |
| NACL | Subnet-Level | Stateless, per subnet | Coarse-grained allow/deny; fast first-line filtering |
| Security Groups | Resource-Level | Stateful, per ENI | Fine-grained instance-level allow rules; zero-trust enforcement |
8.3 · GWLB (Gateway Load Balancer)
Transparent Security Service Insertion
GWLB provides transparent traffic steering to third-party security appliances (e.g., Palo Alto, Fortinet) without changing source or destination IPs — preserving audit trails and simplifying firewall rules.
- Transparent protection — source/dest IP unchanged; appliances see real client/server IPs
- IP-based load balancing — distributes flows across multiple appliance instances
- ECMP support — scales horizontally by adding appliance instances; no single-instance bottleneck
- Integrated ecosystem — pre-validated with Palo Alto VM-Series, Fortinet FortiGate, Check Point, F5
- Typically deployed in the CFW VPC of the Hub account, paired with CCN service insertion
Traffic Flow Paths
North-South Inbound (6 steps)
Public internet request reaching a backend service in a workload VPC.
North-South Outbound (5 steps)
Workload VPC accessing the public internet (e.g., calling a third-party API).
East-West Inter-VPC (4 steps)
Two workload VPCs communicating (e.g., web tier → database tier).
East-West Hybrid Cloud (5 steps)
Cloud workload reaching an on-premise data center.
Every traffic pattern traverses CCN + CFW. This is by design — the Hub account is the single chokepoint for all inter-VPC, internet, and hybrid-cloud traffic, enabling unified audit, policy enforcement, and threat detection.
VPN Comparison
SSL VPN Remote Access
Browser-based or thin-client VPN for individual users accessing cloud resources.
- Cost: Pay-per-user; lower fixed cost; suitable for occasional users
- Security: TLS-based; user-level authentication (password + MFA); certificate-based device trust supported
- Scalability: Hundreds to low thousands of concurrent users per instance; horizontally scalable
- Granularity: Per-user, per-application access control; can restrict to specific CIDRs or services
- Best for: Remote employees, contractors, mobile workforce, admin bastion access
IPSec VPN Site-to-Site
Tunnel-based VPN connecting entire networks (on-premise DC ↔ cloud VPC).
- Cost: Fixed per-tunnel cost; cost-effective for high-bandwidth, always-on links
- Security: IKEv1/IKEv2 negotiation; pre-shared key or certificate authentication; strong encryption (AES-256, SHA-256)
- Scalability: Scales by adding tunnels; supports BGP over IPSec for dynamic routing; multi-tunnel ECMP
- Granularity: Network-level — entire CIDR ranges routed over the tunnel; not user-aware
- Best for: Branch office connectivity, hybrid cloud backup, DC-to-cloud migration, DR replication
| Dimension | SSL VPN | IPSec VPN |
|---|---|---|
| Cost | Per-user; low fixed cost | Per-tunnel; cost-effective for high bandwidth |
| Security | TLS + MFA + device certificate | IKEv2 + PSK/cert + AES-256 |
| Scalability | Up to ~thousands of users per instance | Multi-tunnel + BGP + ECMP |
| Granularity | Per-user, per-app | Per-network CIDR |
| Typical Use | Remote workforce access | Site-to-site / hybrid cloud connectivity |
Network Observability
Build a 360° network observability system. Visibility is the prerequisite for governance — without it, security policies are blind and troubleshooting is reactive. Three complementary capabilities cover traffic analysis, troubleshooting, and deep inspection.
01 Traffic Analysis
VPC Flow Logs capture metadata of every network flow — source/dest IP, port, protocol, bytes, packets, accept/reject action.
- Aggregated to CLS (Cloud Log Service) for search & query
- Feeds into anomaly detection and threat analytics
- Supports compliance audit (e.g., "who accessed the database subnet?")
- Retained per regulatory requirements (typically 6–12 months)
02 Troubleshooting
Cloud-native network probes and one-click diagnostic tools validate connectivity before and after changes.
- Path analysis: trace route from any instance to any destination
- Security group / NACL simulation — predict accept/reject before applying
- Route table visualization — see effective routes per ENI
- One-click connectivity test between two ENIs
03 Traffic Mirroring
Lossless traffic mirroring to NDR (Network Detection & Response) appliances for deep packet inspection.
- Mirrors full packets — not just metadata
- Filters by 5-tuple, VPC, subnet, or ENI
- Targets: IDS/IPS, NDR, network recorders
- Used for forensic investigation and advanced threat hunting
Together these three capabilities deliver full visibility: "who talked to whom, what was inspected, what was the outcome" — at flow, packet, and policy levels. This is the foundation of evidence-based network governance.
Security Products Matrix
| Product | Category | Protection Scope | Key Capability | Typical Use Case |
|---|---|---|---|---|
| Dayu BGP Anti-DDoS | Network | L3/L4 DDoS | BGP-anycast scrubbing centers; Tbps-level mitigation | Protect public-facing IPs (CLB, EIP) from volumetric attacks |
| YunJing (CWP) | Host | Host intrusion detection | File integrity, ransomware detection, baseline check | Agent-based protection on every CVM / TKE node |
| WAF (Web Application Firewall) | Web | L7 HTTP/HTTPS | OWASP Top 10, CC attack, bot management | Protect public CLB frontends and APIs |
| Shu Dun (Data Security) | Data | Sensitive data discovery | Data classification, masking, DLP | Discover and protect PII / PCI data in COS, CDB, CBS |
| Bastion Host | Access | Admin access control | Session recording, command audit, MFA | Centralized admin jump server for SSH/RDP/VNC |
| AnTu (Security Operations Center) | SOC | Security operations | Threat aggregation, incident response, SOAR playbooks | Central SOC for correlating alerts across all products |
| Yu Jie (Cloud Security Center) | Posture | Cloud security posture | CSPM, compliance check, risk scoring | Continuous compliance monitoring (CIS, ISO27001, GDPR) |
These products feed alerts into AnTu SOC, providing a single pane of glass for security operations. Dayu + WAF form the perimeter defense; YunJing + Bastion protect the inside; Shu Dun secures data at rest; Yu Jie continuously validates posture. Together with the network defense-in-depth architecture in Section 8, this forms end-to-end cloud security.
Architecture Summary
- Adopt VPC 3.0 Landing Zone model — hub-and-spoke with Network Admin Account as the hub
- Centralize all internet exposure in Hub Ingress/Egress VPCs; workload VPCs remain private
- Use CCN as the single interconnection fabric — cross-account, cross-region, cross-cloud
- Implement service insertion via CFW VPC for east-west traffic inspection
- Apply hierarchical IP planning — global pool → region → AZ → business line → workload
- Separate production / non-production into independent CCNs and route domains
- Deploy defense in depth — macro segmentation → service insertion → micro segmentation
- Centralize Direct Connect in the Hub account with BGP for dynamic route exchange
- Build 360° observability — flow logs + troubleshooting probes + traffic mirroring
- Layer security products — Dayu (DDoS) + WAF (web) + YunJing (host) + AnTu (SOC) + Yu Jie (posture)