VPC là Global Resource, Subnet là Regional — Khác Biệt Cơ Bản

Tổng quan

GCP's VPC là global resource nhưng subnets là regional. Điều này có vẻ đơn giản nhưng tạo ra hàng loạt implications cho multi-region design:

Single VPC spanning 40+ regions: Một VPC có subnets ở us-west1, europe-west1, asia-northeast1 cùng lúc
Eventual consistency: Route propagation, firewall rule application không phải instantaneous across regions
CIDR overlap prevention: Subnets toàn cầu phải có non-overlapping CIDRs, tạo planning complexity
Blast radius: Một firewall rule ở level VPC áp dụng tất cả regions, một IP cần được reserved globally

Khác với AWS (VPC per region) hay Azure (Virtual Network per region), GCP's architecture cho phép fine-grained control nhưng require deeper planning.

VPC: Global Resource

Mỗi GCP project có thể có multiple VPC networks (tính theo quotas). Mỗi VPC:

Exists at organization/project level, không tied to any region
Can contain subnets in all 40+ regions GCP operates
Has single route table applied to subnets/VMs across all regions
Has single firewall policy applying organization-wide

Project "production"
├── VPC "prod-network" (GLOBAL)
│   ├── Subnet "us-west1-prod" (REGIONAL - us-west1)
│   │   └── 10.0.0.0/20 → 256-4096 IPs
│   │   └── VMs, Load Balancers
│   ├── Subnet "europe-west1-prod" (REGIONAL - europe-west1)
│   │   └── 10.1.0.0/20 → 256-4096 IPs
│   └── Subnet "asia-northeast1-prod" (REGIONAL - asia-northeast1)
│       └── 10.2.0.0/20 → 256-4096 IPs
│
└── VPC "staging-network" (GLOBAL)
    ├── Subnet "us-central1-staging"
    └── ...

Implication 1: CIDR Planning at Global Scale

Vì tất cả subnets thuộc cùng VPC phải có unique CIDR ranges:

❌ WRONG - Overlapping CIDRs:

Subnet "us-west1":   10.0.0.0/16  (65,536 IPs)
Subnet "europe-west1": 10.0.0.0/16  (65,536 IPs) ❌ CONFLICT!

✅ CORRECT - Global CIDR planning:

VPC: 10.0.0.0/8 (16M IPs)
├── Region us-west1:    10.0.0.0/12 (1M IPs)
├── Region europe-west1: 10.16.0.0/12 (1M IPs)
├── Region asia-northeast1: 10.32.0.0/12 (1M IPs)
└── Region ap-southeast1:  10.48.0.0/12 (1M IPs)

Impact: At 100+ regions + multi-AZ = requires prefix reservation system

Reserve space for future regions (GCP often adds new regions)
Secondary ranges for GKE pods
Backup ranges for migration scenarios

Implication 2: Route Table is Global

Một route trong VPC applies to all regions simultaneously:

yaml

Route: 10.100.0.0/24 → next-hop-instance (us-west1-a VM)
Applies to: VMs in ALL regions
  - us-west1-a VMs ✅ Direct access (same region)
  - europe-west1-b VMs ✅ Routed globally
  - asia-northeast1-a VMs ✅ Routed globally

Trap: Nếu next-hop-instance stopped → route becomes unusable everywhere, không chỉ local region.

Route: 10.200.0.0/16 → next-hop-instance "gateway-vm" (us-west1-a, STOPPED)
Status: INVALID (❌ không có effect ở bất cứ region nào)

Implication 3: Firewall Rules Global Scope

Firewall rule VPC-level = áp dụng tất cả regions:

yaml

# VPC-level firewall rule
Ingress Allow: 
  From: 0.0.0.0/0 (internet)
  To: tag:http-server
  Protocol/Port: tcp:80
  
Effect:
  - us-west1: VMs tagged "http-server" = exposed to internet ✅
  - europe-west1: VMs tagged "http-server" = exposed to internet ✅
  - asia-northeast1: VMs tagged "http-server" = exposed to internet ✅

Blast radius: Single misconfigured rule can expose all systems globally.

Subnet: Regional Resource

Mỗi subnet tethered to single region:

yaml

Subnet "prod-us-west1":
  Region: us-west1
  VPC: prod-network
  Primary CIDR: 10.0.0.0/20
  Availability: all AZs in us-west1 (us-west1-a, us-west1-b, us-west1-c)

Important: Subnets ≠ AZs

Misconception: Subnet = single AZ Reality: Subnet = entire region

Subnet "us-west1-subnet" (single regional subnet)
├── us-west1-a
├── us-west1-b
└── us-west1-c

All 3 AZs can use same subnet!

VMs can be created in any AZ within the subnet's region. GCP's Software-Defined Network handles intra-region routing automatically via Andromeda.

Implication: You Can Have Multiple Subnets Per Region

Region: us-west1
├── Subnet "prod-tier1" (10.0.0.0/24)
├── Subnet "prod-tier2" (10.0.1.0/24) 
└── Subnet "prod-private" (10.0.2.0/24)

All 3 subnets co-exist in us-west1
VMs in different subnets can communicate (if firewall allows)

Global Architecture Example: Production System

VPC: "prod" (GLOBAL)

Routing (GLOBAL scope):
  10.0.0.0/8 → subnet-routes (internal)
  0.0.0.0/0 → default-internet-gateway

Firewall Rules (GLOBAL scope):
  rule-01: allow ingress tcp:443 from 0.0.0.0/0 to tag:lb (priority 1000)
  rule-02: allow ingress tcp:3306 from tag:app to tag:db (priority 1100)
  rule-03: deny egress to 0.0.0.0/0 except tag:gateway (priority 900)

Subnets (REGIONAL):

  Region: us-west1
  ├── Subnet "tier1" (10.0.0.0/20)
  │   └── VMs: lb-1a, lb-1b, lb-1c (load balancers)
  │   └── Network tag: lb
  └── Subnet "tier2" (10.0.16.0/20)
      └── VMs: app-1a, app-1b, app-1c (application servers)
      └── Network tag: app

  Region: europe-west1
  ├── Subnet "tier1" (10.16.0.0/20)
  │   └── VMs: lb-2a, lb-2b, lb-2c
  │   └── Network tag: lb
  └── Subnet "tier2" (10.16.16.0/20)
      └── VMs: app-2a, app-2b, app-2c
      └── Network tag: app

  Region: asia-northeast1
  ├── Subnet "tier1" (10.32.0.0/20)
  │   └── VMs: lb-3a, lb-3b, lb-3c
  │   └── Network tag: lb
  └── Subnet "tier2" (10.32.16.0/20)
      └── VMs: app-3a, app-3b, app-3c
      └── Network tag: app

Connectivity Flow

User → us-west1 LB (10.0.1.5)
  [Routed by Google Cloud CDN edge]
  
LB (us-west1) → App Server (us-west1 10.0.16.5)
  Firewall rule: allow tcp:3306 from tag:app ✓
  Routing: subnet-route (10.0.16.0/20)
  → Delivered via Andromeda (intra-region, ~0.1ms)

Later, User → asia-northeast1 LB (10.32.1.5)
  [Routed by geographical proximity]
  
LB (asia-northeast1) → App Server (asia-northeast1 10.32.16.5)
  Same firewall rules apply ✓ (globally scoped)
  Routing: subnet-route (10.32.16.0/20)
  → Delivered via Andromeda (intra-region, ~0.1ms)

Eventual Consistency: The Hidden Complexity

GCP VPC không phải "real-time" update. Route + firewall rule changes propagate globally nhưng không instantaneous:

Scenario: Dangerous Gap

Time 0:00 → Admin deletes firewall rule blocking egress to 1.2.3.4
  Action: Applied to VPC

Time 0:00-0:01 → Propagation happening
  us-west1: UPDATED ✓
  europe-west1: UPDATING... 
  asia-northeast1: WAITING...

Time 0:00:30 → Asymmetric traffic
  App in us-west1 → can reach 1.2.3.4 ✓
  App in europe-west1 → STILL BLOCKED ❌ (rule not yet propagated)
  
Result: Intermittent connection failures visible only in some regions

Duration: Typically <1 second cho simple rule changes, nhưng:

Large organizations (100+ subnets) = slower propagation
Route updates with BGP = can take 10-60 seconds
Hierarchical firewall policy changes = multi-level propagation

Mitigation:

Changes during low-traffic windows
Staged rollouts per region
Verification tests after each change

Comparison: AWS vs GCP vs Azure

Aspect	GCP	AWS	Azure
VPC Scope	Global	Regional	Regional
Subnets	Regional	Availability Zone	Regional
Route Table	Global (VPC-level)	Regional	Regional
Firewall	Global (VPC-level)	Regional (Security Group level)	Regional (NSG)
Multi-region	Single VPC spans regions	Requires VPC Peering	Requires Virtual Network Peering
IP Conflict	Global CIDR must be unique	Per-region CIDR isolation	Per-region CIDR isolation
Default Route	0.0.0.0/0 → default-internet-gateway	Requires explicit IGW	Requires public IP + NSG

AWS's Approach (per-region VPC)

Region: us-west-1
  VPC: 10.0.0.0/16
  ├── Subnet: 10.0.0.0/24 (us-west-1a)
  └── Subnet: 10.0.1.0/24 (us-west-1b)

Region: eu-west-1
  VPC: 10.0.0.0/16 (SAME CIDR, different region - allowed!)
  ├── Subnet: 10.0.0.0/24 (eu-west-1a)
  └── Subnet: 10.0.1.0/24 (eu-west-1b)

For multi-region: Requires VPC Peering between regions

GCP's Approach (single global VPC)

VPC: 10.0.0.0/8 (GLOBAL)
  
Region: us-west-1
  ├── Subnet: 10.0.0.0/20 (UNIQUE)
  └── Subnet: 10.0.16.0/20 (UNIQUE)

Region: eu-west-1  
  ├── Subnet: 10.1.0.0/20 (UNIQUE - cannot reuse 10.0.0.0/20!)
  └── Subnet: 10.1.16.0/20 (UNIQUE)

Multi-region: Automatic (same VPC)

Advantage GCP: Simpler multi-region setup (no peering required) Disadvantage GCP: Exhausts CIDR space faster, requires global planning

Production Considerations

1. Reserve CIDR Space for Growth

VPC: 10.0.0.0/8 (16M IPs)

Current allocation:
├── Americas: 10.0.0.0/9 (8M IPs)
│   ├── us-west1: 10.0.0.0/12
│   ├── us-central1: 10.16.0.0/12
│   └── us-east1: 10.32.0.0/12
│
├── Europe: 10.128.0.0/9 (8M IPs) - RESERVED FOR FUTURE
│   ├── TBD: 10.128.0.0/12
│   └── TBD: 10.144.0.0/12
│
└── Asia: 10.192.0.0/10 (future expansion)

Reality: 5 years later, need to migrate to larger VPC (10.0.0.0/7 = 32M)

2. Disaster Recovery: Secondary VPC

VPC-Primary: "prod" (10.0.0.0/8)
VPC-Secondary: "prod-dr" (172.16.0.0/12)

If primary corrupted → failover to secondary
Requires:
  - Dual-stack DNS
  - Both VPCs connected via Interconnect (low-latency)
  - Route learning from both
  
Implication: IP addresses must be globally unique across both VPCs!
(no 10.0.0.1 in primary + 10.0.0.1 in secondary)

3. Firewall Rule Blast Radius

❌ DANGEROUS:
rule-01: allow all ingress 0.0.0.0/0 (applies to ALL regions)

✅ SAFER:
rule-01: allow all ingress 0.0.0.0/0 to tag:public-api (controlled blast)
rule-02: allow all ingress 0.0.0.0/0 to tag:internal-only (DENY - prevents mistake)

Conclusion

GCP's global VPC + regional subnets architecture memungkinkan:

✅ Simplified multi-region networking (no peering for connectivity)
✅ Centralized control (single firewall policy set)
✅ Consistent routing everywhere

Tetapi require:

❌ Global CIDR planning (no per-region isolation)
❌ Careful blast radius management (rules apply globally)
❌ Understanding eventual consistency (propagation delays)

Untuk production systems, visualize VPC seperti global network fabric dengan regional connection points (subnets), bukan sebaliknya.

VPC là Global Resource, Subnet là Regional — Khác Biệt Cơ Bản ​

Tổng quan ​

VPC: Global Resource ​

Implication 1: CIDR Planning at Global Scale ​

Implication 2: Route Table is Global ​

Implication 3: Firewall Rules Global Scope ​

Subnet: Regional Resource ​

Important: Subnets ≠ AZs ​

Implication: You Can Have Multiple Subnets Per Region ​

Global Architecture Example: Production System ​

Connectivity Flow ​

Eventual Consistency: The Hidden Complexity ​

Scenario: Dangerous Gap ​

Comparison: AWS vs GCP vs Azure ​

AWS's Approach (per-region VPC) ​

GCP's Approach (single global VPC) ​

Production Considerations ​

1. Reserve CIDR Space for Growth ​

2. Disaster Recovery: Secondary VPC ​

3. Firewall Rule Blast Radius ​

Conclusion ​

VPC là Global Resource, Subnet là Regional — Khác Biệt Cơ Bản

Tổng quan

VPC: Global Resource

Implication 1: CIDR Planning at Global Scale

Implication 2: Route Table is Global

Implication 3: Firewall Rules Global Scope

Subnet: Regional Resource

Important: Subnets ≠ AZs

Implication: You Can Have Multiple Subnets Per Region

Global Architecture Example: Production System

Connectivity Flow

Eventual Consistency: The Hidden Complexity

Scenario: Dangerous Gap

Comparison: AWS vs GCP vs Azure

AWS's Approach (per-region VPC)

GCP's Approach (single global VPC)

Production Considerations

1. Reserve CIDR Space for Growth

2. Disaster Recovery: Secondary VPC

3. Firewall Rule Blast Radius

Conclusion