VPC Peering — Kết Nối Trực Tiếp Giữa Hai VPC Không Qua Internet

VPC Peering Làm Gì Bên Trong

VPC Peering cho phép hai VPCs (có thể thuộc các projects hoặc organizations khác nhau) giao tiếp với nhau bằng internal IP addresses, không qua internet.

Khi thiết lập peering, GCP không tạo ra "đường hầm" hay "cầu nối" vật lý giữa hai VPCs. Thay vào đó:

1. Control plane thiết lập một peering relationship trong GCP's network management system
2. Subnet routes của VPC A được import vào routing table của VPC B (và ngược lại)
3. Andromeda agents trên cả hai VPCs được cập nhật để biết về routes mới
4. Traffic giữa hai VPCs đi qua Google private backbone — không bao giờ ra internet

Peering là bilateral — cả hai VPCs phải accept peering relationship. VPC A đề nghị peering không đủ — VPC B phải explicitly accept.

# VPC A (project-a) đề nghị peering với VPC B
gcloud compute networks peerings create a-to-b-peering \
  --network=vpc-a \
  --peer-project=project-b \
  --peer-network=vpc-b \
  --import-subnet-routes-with-public-ip \
  --export-subnet-routes-with-public-ip

# VPC B (project-b) phải accept bằng cách tạo peering ngược lại
gcloud compute networks peerings create b-to-a-peering \
  --network=vpc-b \
  --peer-project=project-a \
  --peer-network=vpc-a \
  --import-subnet-routes-with-public-ip \
  --export-subnet-routes-with-public-ip

Peering chỉ ACTIVE sau khi cả hai sides create peering request.

Non-Transitivity: Quy Tắc Cốt Lõi Và Lý Do Thiết Kế

VPC Peering không có transitivity (không bắc cầu). Đây là thiết kế cố ý, không phải limitation có thể bypass.

VPC A ←→ Peering ←→ VPC B ←→ Peering ←→ VPC C

Câu hỏi: VPC A có thể kết nối với VPC C không?
Câu trả lời: KHÔNG

Tài liệu GCP giải thích rõ: "VPC Network Peering does not provide transitive routing."

Tại Sao Google Chọn Non-Transitive Design?

Lý do 1: Administrative isolation. Khi VPC A peered với VPC B, owners của A và B đều đồng ý với relationship đó. Nếu peering là transitive, peering với VPC B có thể vô tình expose VPC A với tất cả VPCs mà B đã peered — mà owners của A không biết và không consent.

Lý do 2: Security boundaries. Trong enterprise với nhiều teams, mỗi team muốn explicit control về "ai có thể kết nối vào domain của tôi". Transitivity phá vỡ điều này.

Lý do 3: Route management simplicity. Với non-transitive peering, route table của mỗi VPC chỉ chứa routes từ directly peered VPCs. Transitivity sẽ tạo ra route explosion — tất cả routes từ tất cả indirectly connected VPCs.

Hệ Quả Cho N-VPC Topology

Nếu có N VPCs cần full-mesh connectivity:

N = 3 VPCs: Cần 3 peering connections (A↔B, B↔C, A↔C)
N = 5 VPCs: Cần 10 peering connections
N = 10 VPCs: Cần 45 peering connections
N = 25 VPCs: Cần 300 peering connections (maximum per-VPC limit là 25 peerings)

Với N > 25, full-mesh peering trở nên không khả thi. Đây là lý do Shared VPC hoặc Network Connectivity Center (NCC) tồn tại — chúng giải quyết large-scale connectivity mà peering không thể handle.

Route Exchange: Cái Gì Được Chia Sẻ, Cái Gì Không

Khi peering được thiết lập, không phải tất cả routes đều tự động được share.

Subnet Routes: Luôn Được Exchange

Private IPv4 subnet routes luôn được export/import tự động (không cần configuration đặc biệt):

• Primary CIDR ranges của subnets
• Secondary CIDR ranges (GKE pod/service ranges)

Custom Routes (Static và Dynamic): Opt-in

Custom routes — bao gồm static routes và dynamic routes từ Cloud Router — không được exchange theo default. Phải explicitly enable:

gcloud compute networks peerings update a-to-b-peering \
  --network=vpc-a \
  --export-custom-routes \
  --import-custom-routes

Export-custom-routes: VPC A quảng bá custom routes của nó sang VPC B Import-custom-routes: VPC A chấp nhận custom routes từ VPC B

Trường hợp cần custom route exchange:

• VPC A có kết nối on-premises qua Cloud VPN/Interconnect, VPC B cần route đến on-premises qua A
• Hub-and-spoke: Hub VPC có routes đến internet qua NVA, Spoke VPCs cần những routes đó

Trường hợp KHÔNG nên export custom routes:

• Routes với next-hop là internet gateway (GCP từ chối export)
• Routes với network tags (không được exchange qua peering)
• Policy-based routes (không được exchange qua peering)

Publicly-Routed Private IPs: Opt-in

Nếu VPC dùng IP ranges mà thực tế là publicly routable (ví dụ: bạn sở hữu block 203.0.113.0/24), export/import chúng cần explicit flag:

gcloud compute networks peerings create a-to-b-peering \
  --export-subnet-routes-with-public-ip \
  --import-subnet-routes-with-public-ip

CIDR Overlap: Hard Constraint

Đây là constraint kỹ thuật không thể bypass: hai VPCs có bất kỳ CIDR overlap nào không thể peer với nhau.

Tài liệu GCP: "No subnet IP range can exactly match, contain, or fit within another subnet IP range in a peered VPC network."

VPC A:
  subnet-1: 10.0.0.0/20
  gke-pods:  10.1.0.0/16 (secondary range)

VPC B:
  subnet-2: 10.0.16.0/20  ← không conflict với 10.0.0.0/20
  gke-pods:  10.1.0.0/16  ← CONFLICT với VPC A secondary range!

→ Peering FAIL vì 10.1.0.0/16 xuất hiện ở cả hai VPCs

GCP perform validation khi peering được tạo. Nhưng vấn đề phức tạp hơn: GCP cũng validate khi subnet được tạo hoặc modified sau khi peering tồn tại. Nếu bạn cố thêm subnet có CIDR conflict với peered VPC → subnet creation fail.

Điều này tạo ra một "coordination tax": teams quản lý các VPCs đang peered phải coordinate về CIDR allocation để tránh conflicts.

DNS Qua VPC Peering: Giới Hạn Quan Trọng

VPC Peering cho phép traffic đi qua private IPs, nhưng DNS resolution không tự động hoạt động cross-VPC.

Tài liệu GCP: "Resources in a peered VPC network can't use Compute Engine internal DNS names created by a local VPC network."

VPC A: vm-a.c.project-a.internal
VPC B: vm-b.c.project-b.internal

Từ vm-a (VPC A), DNS lookup:
  nslookup vm-a.c.project-a.internal → 10.0.0.5 ✓ (local DNS)
  nslookup vm-b.c.project-b.internal → NXDOMAIN ✗ (cannot resolve cross-VPC)

→ Kể cả khi peering cho phép traffic, DNS resolution fails

Giải Pháp: Cloud DNS Peering

Cloud DNS Peering (khác với VPC Peering) cho phép một VPC forward DNS queries đến private zones của VPC khác:

# Tạo DNS peering zone trong VPC A để resolve VPC B's domain
gcloud dns managed-zones create peering-to-b \
  --dns-name=c.project-b.internal. \
  --visibility=private \
  --networks=vpc-a \
  --peering-config=server-network=vpc-b

Với DNS peering zone, VMs trong VPC A có thể resolve vm-b.c.project-b.internal → IP address trong VPC B.

Giải Pháp Thay Thế: Identical Private Zones

Tạo private DNS zone với cùng name trong cả hai VPCs:

# Trong VPC A: tạo zone quản lý service.internal
gcloud dns managed-zones create shared-service-zone \
  --dns-name=service.internal. \
  --visibility=private \
  --networks=vpc-a

# Trong VPC B: tạo cùng zone
gcloud dns managed-zones create shared-service-zone \
  --dns-name=service.internal. \
  --visibility=private \
  --networks=vpc-b

# Cả hai zones có cùng records
# vm-a.service.internal → 10.0.0.5
# vm-b.service.internal → 10.50.0.5

Approach này đơn giản nhưng cần synchronization giữa hai zones — khi record thay đổi phải update ở cả hai nơi.

Quota System: Peering Group Concept

GCP giới hạn peering theo "peering group" — mỗi VPC network's peering group bao gồm chính nó và tất cả VPCs trực tiếp peered.

Default limits:

• 25 peering connections per VPC (soft limit, có thể tăng)
• Tổng số active và pending peerings trong peering group ảnh hưởng đến quota

Ngoài ra, resource limits apply cho toàn bộ peering group:

• Subnet routes, custom routes, firewall rules — tổng của toàn group phải trong quota
• Nếu peering group quá lớn → resource limit có thể bị hit dù individual VPCs còn trong quota

Peering vs Shared VPC: Quyết Định Kiến Trúc

Tiêu chí	VPC Peering	Shared VPC
Quản lý mạng	Mỗi VPC tự quản lý	Tập trung tại Host project
Ownership	Multiple teams own multiple VPCs	Network team owns host VPC
Scale	Giới hạn 25 peerings/VPC	Không giới hạn service projects
Route sharing	Opt-in, limited	Full sharing trong shared VPC
DNS	Cần setup thêm	Tự động (cùng VPC)
Billing	Phức tạp (phân bổ cross-VPC)	Clearer (attributed to service project)
Setup complexity	Thấp	Cao hơn ban đầu
Autonomy	Teams có autonomy	Phụ thuộc network team

Quy tắc thực tế:

• Dùng peering khi: hai teams cần kết nối có tính ephemeral, hay cần strict separation of network ownership
• Dùng Shared VPC khi: scale lớn, cần centralized networking, compliance yêu cầu centralized control

Latency Và Performance

Traffic qua VPC peering đi trên Google private network — không qua internet. Latency phụ thuộc vào:

• Khoảng cách địa lý giữa VMs (cùng zone vs cross-region)
• Workload đang chạy trên cùng zone giảm latency đáng kể

Không có thêm latency overhead từ peering mechanism itself — Andromeda forward packets với cùng efficiency như trong cùng VPC.

References

• VPC Network Peering Documentation — Tài liệu chính thức
• Peering Limitations — Danh sách đầy đủ các constraints
• Cloud DNS Peering Zones — DNS resolution across peered VPCs
• Peering vs Shared VPC — Comparison từ tài liệu GCP