Mở đầu — vì sao bài này quan trọng
Khi bạn mới bắt đầu với cloud, mọi thứ thường gọn gàng trong một VPC (Virtual Private Cloud) duy nhất: web server, database, cache, tất cả nằm chung một "khu đất ảo" và nói chuyện với nhau thoải mái. Nhưng cuộc sống thật không đơn giản như vậy. Chỉ vài tháng sau, bạn sẽ thấy mình có VPC cho môi trường production, VPC riêng cho staging, một VPC nữa cho team data, rồi công ty mua lại một startup khác đem theo cả một tài khoản AWS riêng với VPC của họ. Đến lúc đó, câu hỏi sống còn xuất hiện: làm sao để các VPC này nói chuyện được với nhau một cách an toàn?
Đây chính xác là nội dung của Bài 40. Chúng ta sẽ đi sâu vào hai công cụ nền tảng để kết nối nhiều VPC: VPC Peering (kết nối 1-1 giữa hai VPC) và Transit Gateway (bộ định tuyến trung tâm kết nối hàng chục, hàng trăm VPC). Hiểu rõ hai công cụ này, biết khi nào dùng cái nào, là ranh giới phân biệt giữa một kỹ sư cloud "biết tạo VPC" và một kỹ sư "thiết kế được hạ tầng mạng cho cả doanh nghiệp".
Nếu bạn từng nghe câu "network là phần khó debug nhất trong cloud", thì phần lớn nỗi đau đó đến từ việc kết nối nhiều VPC sai cách: route thiếu, CIDR trùng nhau, quên cập nhật security group. Bài này sẽ giúp bạn tránh những cái bẫy đó ngay từ đầu.
Khái niệm cốt lõi
VPC Peering — kết nối 1-1 trực tiếp
VPC Peering là cách đơn giản nhất để nối hai VPC lại với nhau. Bạn tạo một "peering connection" giữa VPC A và VPC B, cập nhật bảng định tuyến (route table) ở cả hai bên, và ngay lập tức các máy chủ trong hai VPC có thể gọi nhau qua địa chỉ IP nội bộ (private IP) như thể chúng nằm chung một mạng. Traffic đi qua backbone nội bộ của nhà cung cấp cloud, không ra ngoài Internet công cộng.
Có bốn đặc điểm bạn phải khắc cốt ghi tâm về VPC Peering:
- Là kết nối 1-1 (one-to-one): Một peering connection chỉ nối đúng hai VPC. Muốn nối VPC A với B, C và D, bạn phải tạo ba peering connection riêng biệt.
- Hỗ trợ cross-region và cross-account: Bạn có thể peer hai VPC ở hai region khác nhau (ví dụ Singapore và Tokyo), hoặc thuộc hai tài khoản AWS khác nhau (rất hữu ích khi công ty có nhiều đơn vị hoặc khi tích hợp với đối tác).
- Non-transitive (không bắc cầu): Đây là đặc điểm quan trọng nhất và dễ gây nhầm lẫn nhất. 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. Traffic không "đi nhờ" qua B. Muốn A nói với C, bạn phải tạo thêm một peering connection A↔C.
- Miễn phí phí kết nối: Bản thân peering connection không tính tiền. Bạn chỉ trả phí cho lượng dữ liệu truyền đi (data transfer), đặc biệt là khi traffic đi qua các availability zone hoặc region khác nhau.
Vấn đề bùng nổ kết nối (mesh explosion)
Tính non-transitive của peering dẫn thẳng đến một vấn đề khi số lượng VPC tăng lên. Nếu bạn muốn mọi VPC nói chuyện được với mọi VPC (full mesh), số lượng peering connection cần thiết tăng theo công thức n×(n-1)/2.
- 3 VPC → cần 3 kết nối.
- 5 VPC → cần 10 kết nối.
- 10 VPC → cần 45 kết nối.
- 20 VPC → cần 190 kết nối.
Transit Gateway — bộ định tuyến trung tâm (hub-and-spoke)
Transit Gateway (TGW) hoạt động như một router trung tâm trên cloud. Thay vì nối từng cặp VPC với nhau, bạn nối mỗi VPC vào một Transit Gateway duy nhất (gọi là "attachment"). TGW đóng vai trò trung tâm (hub), các VPC là các nhánh (spoke). Traffic giữa các VPC đi qua TGW.
Điểm khác biệt cốt lõi so với peering:
- Có tính transitive: Nếu VPC A, B, C đều attach vào cùng một TGW và route được cấu hình đúng, thì A nói chuyện được với cả B và C mà không cần thêm kết nối nào. TGW định tuyến giúp.
- Mở rộng cực tốt: Thay vì 190 kết nối cho 20 VPC, bạn chỉ có 20 attachment vào một TGW. Quản lý tập trung tại một chỗ.
- Không chỉ nối VPC: TGW còn kết nối được với on-premises qua VPN hoặc Direct Connect, với các TGW ở region khác (TGW peering), và cho phép chia mạng thành các "route table" riêng để cô lập lưu lượng.
- Có phí: Khác với peering, TGW tính phí theo giờ cho mỗi attachment, cộng với phí xử lý dữ liệu trên mỗi GB đi qua gateway. Đây là cái giá cho sự tiện lợi và khả năng mở rộng.
Điều kiện tiên quyết mà ai cũng quên: CIDR không được trùng
Dù dùng peering hay TGW, có một quy tắc bất di bất dịch: các dải địa chỉ IP (CIDR block) của các VPC không được chồng lấn nhau. Nếu VPC A dùng 10.0.0.0/16 và VPC B cũng dùng 10.0.0.0/16, router không biết một địa chỉ như 10.0.1.5 thuộc VPC nào, và kết nối sẽ thất bại hoặc định tuyến sai. Việc quy hoạch dải IP (IP address planning) cho toàn bộ tổ chức phải làm ngay từ đầu — đây là lỗi thiết kế đắt giá nhất và khó sửa nhất.
Tình huống thực tế
Ví dụ 1: Startup fintech Việt Nam — từ peering đơn giản đến điểm nghẽn
Một startup fintech tại TP.HCM, gọi là "PayViet", ban đầu có ba VPC trên AWS region Singapore (ap-southeast-1): vpc-prod (ứng dụng), vpc-data (database và data warehouse), và vpc-shared (dịch vụ dùng chung như CI/CD, bastion host). Team DevOps dùng VPC Peering nối cả ba: prod↔data, prod↔shared, data↔shared — đúng 3 kết nối, gọn gàng, và không tốn phí kết nối. Traffic nội bộ nhanh, độ trễ thấp vì đi qua backbone AWS.
Mọi thứ chạy tốt trong một năm. Rồi công ty mở rộng: thêm vpc-analytics, vpc-ml, vpc-partner-integration, và mua lại một team làm ví điện tử đem theo vpc-wallet và vpc-wallet-data. Giờ có 8 VPC. Để full mesh, họ cần 28 kết nối. Mỗi lần thêm VPC mới, team phải tạo peering tới tất cả VPC hiện có và cập nhật route table khắp nơi. Một lần, kỹ sư quên thêm route ở vpc-ml, khiến job training không kéo được dữ liệu từ vpc-data — mất nửa ngày debug mới ra.
Bài học: Peering tuyệt vời khi số VPC nhỏ (dưới 5-6) và mối quan hệ kết nối đơn giản. Nhưng khi vượt qua ngưỡng đó, chi phí vận hành thủ công tăng vọt và rủi ro lỗi cấu hình tăng theo. PayViet cuối cùng phải di chuyển sang Transit Gateway.
Ví dụ 2: Chuyển sang Transit Gateway — tập đoàn bán lẻ đa thương hiệu
Hãy hình dung một tập đoàn bán lẻ giả định "MegaRetail Group" ở Đông Nam Á, sở hữu nhiều thương hiệu, mỗi thương hiệu có team kỹ thuật riêng và nhiều tài khoản AWS. Tổng cộng họ có khoảng 35 VPC trải trên hai region: Singapore và Jakarta. Nếu dùng peering full mesh cho 35 VPC, họ sẽ cần 595 kết nối — điều này bất khả thi để quản lý.
Họ triển khai một Transit Gateway ở mỗi region, attach tất cả VPC của region đó vào TGW tương ứng, rồi peer hai TGW với nhau để nối Singapore và Jakarta. Kết quả:
- Chỉ 35 attachment thay vì 595 kết nối.
- Họ dùng nhiều TGW route table để cô lập: các VPC "sandbox" của developer chỉ được vào VPC
shared-services(để dùng CI/CD, DNS), nhưng không được đi vào VPCproduction— thực thi cô lập ngay ở tầng định tuyến, không phụ thuộc security group. - Kết nối tới trung tâm dữ liệu on-premises ở Singapore được gắn vào TGW một lần qua Direct Connect, và mọi VPC đều truy cập được on-prem qua đó — điều mà peering không làm được vì non-transitive.
Bài học: Transit Gateway là lựa chọn mặc định cho doanh nghiệp có nhiều VPC, nhiều tài khoản, cần kết nối on-premises, và cần cô lập lưu lượng theo chính sách. Bạn trả phí để đổi lấy khả năng mở rộng và quản trị tập trung.
Ví dụ 3: Khi peering vẫn là lựa chọn đúng — kết nối với đối tác
Một công ty SaaS Việt Nam cung cấp dịch vụ chấm công, gọi là "TimeKeeper", cần cho phép hệ thống của một khách hàng doanh nghiệp lớn (một ngân hàng) truy cập trực tiếp API nội bộ mà không đi qua Internet công cộng, vì lý do bảo mật và tuân thủ. Ngân hàng có tài khoản AWS riêng, VPC riêng, ở cùng region Singapore.
Ở đây, họ không dùng Transit Gateway. Họ tạo một VPC Peering cross-account giữa VPC của TimeKeeper và VPC của ngân hàng. Lý do:
- Chỉ có một kết nối duy nhất giữa hai tổ chức, không có nhu cầu mở rộng thành mesh.
- Peering miễn phí phí kết nối, trong khi TGW sẽ phát sinh phí attachment hàng tháng không cần thiết.
- Non-transitive lại là ưu điểm ở đây: ngân hàng chỉ tiếp cận được đúng VPC được peer, không có nguy cơ "đi nhờ" sang các VPC khác của TimeKeeper. Ranh giới an ninh rõ ràng.
- Họ giới hạn route thật hẹp: chỉ mở route tới đúng subnet chứa API server, không mở toàn bộ CIDR.
Hướng dẫn từng bước
Dưới đây là quy trình thiết lập một VPC Peering trên AWS (nguyên lý áp dụng tương tự cho GCP và Azure):
- Kiểm tra CIDR trước tiên. Xác nhận hai VPC không có dải IP chồng lấn. Nếu trùng, dừng lại — bạn phải quy hoạch lại IP trước, không có cách nào peer được.
- Tạo peering connection. Từ VPC A, tạo yêu cầu peering tới VPC B (chỉ định VPC ID, tài khoản, và region của B nếu khác). Ở giai đoạn này kết nối ở trạng thái "pending-acceptance".
- Chấp nhận yêu cầu. Người quản lý VPC B (có thể là tài khoản khác) vào và bấm "Accept". Nếu cross-account, đây là bước xác nhận hai bên đồng thuận.
- Cập nhật route table ở CẢ HAI VPC. Đây là bước bị quên nhiều nhất. Trong route table của subnet ở VPC A, thêm entry: đích là CIDR của VPC B → target là peering connection. Làm ngược lại ở VPC B. Peering không tự thêm route cho bạn.
- Cập nhật security group và network ACL. Mở port cần thiết trong security group của các instance, cho phép traffic đến từ CIDR (hoặc security group) của VPC bên kia.
- Kiểm tra bằng private IP. Từ một instance ở VPC A, dùng
pinghoặccurltới private IP của instance ở VPC B để xác nhận thông đường.
Lỗi thường gặp & mẹo
- Quên cập nhật route table. Đây là lỗi số một. Peering connection ở trạng thái "active" nhưng không ping được — 90% là do thiếu route. Luôn kiểm tra route ở cả hai đầu.
- CIDR chồng lấn. Nếu ngay từ đầu tất cả VPC đều dùng
10.0.0.0/16vì copy-paste, bạn sẽ không bao giờ nối chúng được. Mẹo: quy hoạch một sơ đồ IP cho cả tổ chức từ ngày đầu, ví dụ prod dùng10.0.0.0/16, staging10.1.0.0/16, data10.2.0.0/16.
- Kỳ vọng peering có tính bắc cầu. Nhiều người tưởng peer A-B và B-C là xong cho A-C. Không phải. Nhớ: peering là non-transitive. Nếu bạn cần transitive, đó là dấu hiệu nên chuyển sang TGW.
- Quên security group và NACL. Route đúng nhưng vẫn không thông vì security group chặn. Route quyết định traffic đi đâu, security group quyết định traffic có được phép hay không — cả hai phải đúng.
- Bỏ qua chi phí data transfer. Peering miễn phí phí kết nối, nhưng traffic cross-region hay cross-AZ vẫn tính tiền. Với hệ thống lưu lượng lớn, hóa đơn data transfer có thể gây bất ngờ. Đặt các dịch vụ nói chuyện nhiều với nhau ở cùng AZ khi có thể.
- Mẹo lựa chọn: Dưới 3-4 VPC với quan hệ đơn giản → dùng peering. Nhiều VPC, nhiều account, cần on-prem, cần cô lập theo chính sách → dùng Transit Gateway. Kết nối 1-1 với đối tác bên ngoài → peering (tận dụng tính cô lập non-transitive).
Bài tập thực hành
- Tính toán mesh: Công ty của bạn có 12 VPC và muốn tất cả nói chuyện được với nhau. Nếu dùng VPC Peering full mesh, cần bao nhiêu kết nối? Nếu dùng Transit Gateway thì cần bao nhiêu attachment? (Gợi ý: dùng công thức n×(n-1)/2.)
- Thực hành trên AWS (free tier): Tạo hai VPC với CIDR khác nhau (ví dụ
10.10.0.0/16và10.20.0.0/16), mỗi VPC một EC2 instance nhỏ (t2.micro). Thiết lập peering, cập nhật route và security group, rồi ping thành công giữa hai instance qua private IP. Ghi lại từng bước.
- Phân tích tình huống: Một công ty có
vpc-prod,vpc-dev, và một VPCshared-serviceschứa DNS và bastion. Yêu cầu: prod và dev đều truy cập được shared-services, nhưng prod và dev không được nói chuyện trực tiếp với nhau. Bạn sẽ dùng peering hay TGW? Vẽ sơ đồ route và giải thích tại sao lựa chọn của bạn thực thi được yêu cầu cô lập này.
Tóm tắt
- VPC Peering là kết nối 1-1 giữa hai VPC, hỗ trợ cross-region và cross-account, miễn phí phí kết nối, nhưng non-transitive (không bắc cầu) và không mở rộng tốt khi số VPC tăng.
- Số kết nối full mesh tăng theo n×(n-1)/2, nhanh chóng trở nên bất khả thi quản lý khi vượt quá 5-6 VPC.
- Transit Gateway là router trung tâm theo mô hình hub-and-spoke, có tính transitive, mở rộng tốt, kết nối được cả on-premises và các region khác, nhưng có phí attachment và data processing.
- Quy tắc bất biến: các VPC được kết nối không được trùng CIDR — hãy quy hoạch dải IP toàn tổ chức ngay từ đầu.
- Peering vẫn là lựa chọn đúng cho kết nối 1-1 đơn giản, đặc biệt cross-account với đối tác, nhờ chi phí thấp và tính cô lập tự nhiên. TGW là lựa chọn cho doanh nghiệp nhiều VPC cần quản trị tập trung.
- Ba thứ luôn phải đúng cùng lúc để thông đường: peering/attachment active, route table, và security group.