My Awesome Project

Appearance

PSC vs VPC Peering — Routing, Security & Use Cases ​

Tại Sao So Sánh Này Quan Trọng ​

PSC và VPC Peering thường bị xem là hai lựa chọn thay thế cho cùng một mục tiêu — "kết nối hai VPC private". Cách hiểu này dẫn tới quyết định kiến trúc tồi, vì hai mô hình giải hai bài toán khác nhau. Peering kết nối network với network; PSC publish service tới consumer. Chọn sai mô hình không chỉ làm hệ thống phức tạp hơn mức cần thiết — nó còn tạo ra rủi ro bảo mật (blast radius lớn) hoặc bế tắc về scale.

File này không liệt kê feature song song để bạn chọn. Mục tiêu là làm rõ cơ chế routing và security của từng mô hình khác nhau như thế nào ở tầng gốc, để từ đó bạn tự suy ra được khi nào cái nào đúng. Hiểu được sự khác biệt cơ chế quan trọng hơn nhiều so với thuộc lòng một decision matrix.

Trục 1: Routing Model — Đây Là Khác Biệt Gốc Rễ ​

VPC Peering: trao đổi toàn bộ subnet routes ​

Khi bạn peer hai VPC, Google Cloud trao đổi toàn bộ subnet routes giữa hai bên. VPC A học tất cả các subnet route của VPC B và ngược lại, một cách tự động. Sau khi peering active, một VM trong A có thể (nếu firewall cho phép) gửi packet tới bất kỳ internal IP nào trong B, vì route đã tồn tại trong route table.

Đây là một mô hình network-level: hai mạng nhìn thấy nhau gần như toàn diện ở tầng L3. Điều này mạnh nhưng cũng là gốc rễ của mọi giới hạn:

  • IP range hai bên bắt buộc không trùng — vì route phải duy nhất. Nếu A và B đều có 10.0.0.0/16, route bị xung đột và peering bị từ chối.
  • Connectivity là "tất cả hoặc không" ở mức subnet: bạn không thể peer chỉ để lộ một service mà giấu phần còn lại của mạng.

PSC: chỉ expose đúng một IP, qua NAT ​

PSC không trao đổi route nào cả. Consumer chỉ có một forwarding rule (endpoint) với một IP nội bộ, IP đó được NAT sang service attachment của producer (xem cơ chế trong file 01). Consumer không học bất kỳ route nào của producer VPC; producer không học route nào của consumer.

Hệ quả trực tiếp từ cơ chế này:

  • Vì có NAT, IP range hai bên được phép trùng nhau — đây là điều peering không bao giờ làm được.
  • Consumer chỉ tiếp cận được đúng IP của endpoint, không phải toàn bộ producer VPC. Bề mặt kết nối hẹp đến mức tối thiểu.

Đây là điểm cần khắc sâu: peering chia sẻ route; PSC chia sẻ một service qua NAT. Mọi khác biệt về bảo mật, IP, và scale bên dưới đều là hệ quả của khác biệt routing nền tảng này.

Trục 2: Transitivity — Cả Hai Đều Non-Transitive, Nhưng Vì Lý Do Khác Nhau ​

Peering non-transitivity ​

VPC Peering nổi tiếng là non-transitive: nếu A peer với B, và B peer với C, thì A không tự động nói chuyện được với C. Lý do cơ chế: route học qua peering không được re-advertise sang peering khác. B không quảng bá route của A cho C. Đây là một quyết định thiết kế có chủ đích để tránh route explosion và vòng lặp routing không kiểm soát.

Hệ quả thực tế: kiến trúc hub-and-spoke với peering bị giới hạn — spoke không nói chuyện được với nhau qua hub chỉ bằng peering. Phải thêm route tĩnh + next-hop appliance, hoặc dùng Network Connectivity Center.

PSC (endpoint) non-transitivity ​

Endpoint PSC cũng non-transitive, nhưng vì cơ chế hoàn toàn khác: endpoint chỉ đến được đúng producer VPC mà service attachment trỏ tới. Nó không truyền connectivity sang các network peered với consumer. Nếu network X peer với consumer VPC, X không dùng được endpoint của consumer để chạm tới producer (Private Service Connect Overview).

Điều thú vị là PSC cung cấp hai "lối thoát" transitivity có kiểm soát mà peering không có:

  • PSC interface cho phép producer khởi tạo connection ngược và có tính bắc cầu giới hạn tới các workload kết nối vào consumer VPC.
  • Network Connectivity Center hub: connection PSC có thể được propagate tới các consumer VPC spoke khác cùng hub, cho phép nhiều spoke chia sẻ quyền truy cập một service (About accessing published services through endpoints).

Khác biệt mental model: peering non-transitive là một giới hạn cứng bạn phải né tránh; PSC non-transitive là một thuộc tính bảo mật (cô lập service) với các cơ chế mở rộng có chủ đích.

Trục 3: Security & Blast Radius — Lý Do Multi-Tenant Bắt Buộc PSC ​

Đây là trục quan trọng nhất khi thiết kế multi-tenant.

Blast radius của peering ​

Khi A peer với B, toàn bộ internal IP space của B trở nên có thể tiếp cận từ A ở tầng route (việc có đi được hay không phụ thuộc firewall). Điều này nghĩa là:

  • Bảo mật giữa A và B hoàn toàn phụ thuộc vào firewall rule — một firewall rule lỏng lẻo hay sai sót sẽ phơi bày mạng B cho A.
  • Trong môi trường multi-tenant (nhiều khách hàng), peering là không thể chấp nhận: bạn không bao giờ muốn mạng của khách hàng A có route tới mạng của khách hàng B, hoặc tới phần còn lại của producer network.

Blast radius của PSC ​

PSC mặc định cô lập ở mức cao nhất: consumer chỉ thấy một IP endpoint, được NAT sang một service attachment. Không có route nào tới phần còn lại của producer network. Theo tài liệu, PSC cấp "explicit authorization" với "granular access control — consumer chỉ chạm được tới service endpoint được chỉ định, không phải toàn bộ peered network" (Private Service Connect Overview).

Đây là lý do mọi managed service của Google Cloud chuyển sang PSC: một producer (Google) phục vụ hàng triệu consumer (khách hàng), và không bao giờ được để consumer này thấy network của consumer khác. Peering không thể đáp ứng mô hình này; PSC sinh ra chính cho nó.

Mental model bảo mật: với peering, bạn mở rộng một trust boundary để bao gồm cả hai network rồi dùng firewall để thu hẹp lại. Với PSC, trust boundary không bao giờ mở rộng — bạn chỉ khoét đúng một lỗ nhỏ (một service) qua NAT. PSC là "default deny + expose một service"; peering là "default reachable + firewall để chặn".

Trục 4: IP Coordination ​

ChiềuVPC PeeringPSC
IP range hai bênBắt buộc không trùngCho phép trùng (nhờ NAT)
Phối hợp tổ chứcCần quy hoạch IPAM chung giữa các bênKhông cần — mỗi bên tự quản IP của mình
Khi M&A / multi-orgĐau đầu: hai công ty thường trùng 10.0.0.0/8PSC giải quyết tự nhiên

Trong thực tế doanh nghiệp lớn, đây thường là yếu tố quyết định. Hai công ty sáp nhập, cả hai dùng 10.0.0.0/8 — peering là bất khả thi nếu không re-IP (một dự án nhiều tháng, rủi ro cao). PSC cho phép bên này consume service của bên kia ngay lập tức mà không đụng tới IP plan.

Trục 5: Scale Limits ​

Cơ chế khác nhau dẫn tới giới hạn scale khác nhau về bản chất:

  • Peering giới hạn bởi số peering connection per VPC và tổng số route học được (route table có quota). Mỗi peering thêm route vào table; ở scale lớn, route count trở thành ràng buộc cứng. Một topology mesh n-VPC cần n*(n-1)/2 peering — bùng nổ tổ hợp.
  • PSC giới hạn bởi NAT subnet size (số connection per service attachment) và quota endpoint/forwarding rule. Quan trọng: PSC không thêm route, nên nó không đụng tới route quota. Một producer phục vụ hàng nghìn consumer chỉ cần NAT subnet đủ lớn, không cần n peering.

Ví dụ minh họa rõ nhất là GKE control plane (xem file 04): với VPC peering, một VPC chỉ host được 75 cluster per zone/region (giới hạn peering); chuyển sang PSC, con số lên 1000 cluster (About Private Service Connect — GKE). Sự nhảy vọt này là hệ quả trực tiếp của việc PSC không tiêu tốn peering slot.

Khung Quyết Định: Khi Nào Dùng Cái Nào ​

Dựa trên cơ chế đã phân tích, không phải theo "feature checklist":

Dùng VPC Peering khi:

  • Bạn cần kết nối network-to-network toàn diện giữa hai mạng tin cậy lẫn nhau và do cùng một tổ chức kiểm soát (ví dụ: hai VPC của cùng một team, một cho prod một cho shared services, cần nói chuyện đa chiều ở nhiều port/service).
  • IP range đã được quy hoạch không trùng.
  • Số lượng network nhỏ, không bùng nổ mesh.

Dùng PSC khi:

  • Bạn publish một service cụ thể cho bên khác (consume model), đặc biệt khi bên kia không hoàn toàn tin cậy hoặc thuộc tổ chức khác (SaaS, multi-tenant).
  • IP range có thể trùng hoặc bạn không kiểm soát được IP plan của consumer.
  • Bạn cần cô lập tối đa — chỉ lộ đúng một service, không lộ network.
  • Bạn cần scale tới hàng trăm/nghìn consumer mà không bị giới hạn peering/route.
  • Bạn đang consume một managed service (Cloud SQL, Memorystore, AlloyDB, GKE control plane) — ở đây bạn gần như không có lựa chọn, PSC là mô hình mặc định.

Lưu ý quan trọng: hai mô hình không loại trừ nhau. Một kiến trúc thật thường dùng peering cho kết nối nội bộ giữa các VPC tin cậy của chính mình, và PSC để consume managed service hoặc expose service ra ngoài. Đừng cố ép mọi thứ vào một mô hình.

Anti-Pattern: Dùng Peering Để "Expose Một Service" Trong Multi-Tenant ​

Sai lầm điển hình: một team platform cần cho team khác (hoặc khách hàng) truy cập một internal API, và họ peer hai VPC "cho nhanh".

Vì sao sai về cơ chế: peering trao đổi toàn bộ route. Dù bạn chỉ muốn lộ một API trên một IP, peering đã làm cho toàn bộ subnet của bạn có route từ phía bên kia. Bảo mật giờ phụ thuộc hoàn toàn vào việc bạn cấu hình firewall đúng — và firewall rule là thứ dễ sai, dễ drift theo thời gian. Một thay đổi firewall vô tình mở ra cả mạng.

Hệ quả ở scale: khi có 10 team cần truy cập, bạn có 10 peering, mỗi cái lộ toàn bộ network của bạn cho một bên. Blast radius nhân lên theo số peering. Một sự cố ở một bên có thể lan sang network của bạn qua route đã trao đổi.

Cách đúng: publish API qua một service attachment PSC. Bên kia tạo endpoint, chỉ thấy đúng một IP. Network của bạn không bao giờ có route từ phía họ. Bảo mật không còn phụ thuộc vào firewall rule mong manh mà nằm ngay trong mô hình kết nối.

References ​