Khi hệ thống của doanh nghiệp mở rộng ra nhiều VPC khác nhau, nhiều VPC khác nhau như môi trường Dev, Staging, Production hoặc các dự án độc lập, nhu cầu kết nối giữa các VPC này để chia sẻ dữ liệu là điều tất yếu. Đây chính là lúc VPC Peering phát huy vai trò. Bài viết này sẽ giải thích chi tiết VPC Peering là gì, cơ chế hoạt động, lợi ích, hạn chế kỹ thuật và quy trình triển khai thực tế.
VPC Peering là gì?
VPC Peering là một kết nối mạng giữa hai VPC (Virtual Private Cloud), cho phép các tài nguyên nằm bên trong chúng như Instances, Databases, Containers trao đổi dữ liệu trực tiếp với nhau bằng địa chỉ IP riêng (Private IP). Nói một cách dễ hiểu, hai VPC sau khi peering với nhau sẽ “nhìn thấy” tài nguyên của nhau giống như chúng đang nằm trong cùng một mạng nội bộ, mặc dù về bản chất chúng vẫn là hai mạng độc lập, có thể thuộc hai tài khoản hoặc hai khu vực địa lý khác nhau.
Về cơ chế hoạt động, lưu lượng truy cập đi qua kết nối Peering không đi qua Internet, không cần thông qua Gateway hay bất kỳ thiết bị phần cứng trung gian nào. Toàn bộ traffic được giữ hoàn toàn trong hạ tầng nội bộ của nhà cung cấp Cloud, cho dù đó là AWS, GCP hay Azure. Đây là yếu tố then chốt giúp VPC Peering trở thành giải pháp được ưa chuộng cho các bài toán kết nối liên VPC, vì nó loại bỏ hoàn toàn lớp rủi ro và độ trễ phát sinh từ việc đi qua mạng công khai.
Tại sao nên sử dụng VPC Peering?
VPC Peering mang lại giá trị rõ rệt cả về mặt kỹ thuật lẫn chi phí vận hành. Dưới đây là bốn lý do chính khiến giải pháp này được nhiều kỹ sư hạ tầng lựa chọn.
1. Bảo mật vượt trội
Vì dữ liệu không bao giờ rời khỏi hạ tầng của nhà cung cấp Cloud, rủi ro bị tấn công từ Internet như nghe trộm gói tin, tấn công Man-in-the-Middle hay DDoS gần như được loại bỏ hoàn toàn trên đường truyền. Traffic giữa hai VPC peering đi trên mạng backbone riêng của nhà cung cấp, không cần mở port ra ngoài hay đi qua các điểm trung gian công khai, giúp giảm đáng kể diện tích bị tấn công (Attack Surface) của hệ thống.
2. Hiệu năng cao, độ trễ thấp
Kết nối Peering là kết nối trực tiếp giữa hai VPC, không phải đi qua nhiều lớp định tuyến trung gian như khi sử dụng VPN hoặc Public Internet. Nhờ vậy tốc độ truyền tải dữ liệu nhanh hơn rõ rệt, đặc biệt quan trọng với các ứng dụng yêu cầu độ trễ thấp như truy vấn cơ sở dữ liệu thời gian thực hay đồng bộ dữ liệu giữa các Microservices.
3. Tối ưu chi phí
Khi hai VPC giao tiếp qua Internet công khai, doanh nghiệp thường phải trả phí Data Transfer Out, vốn là một trong những loại phí dễ bị đội lên không kiểm soát khi lưu lượng tăng. VPC Peering giúp tránh hoàn toàn loại phí băng thông Internet này, vì việc tạo kết nối Peering thường không mất phí, chi phí phát sinh chủ yếu chỉ nằm ở phần data transfer giữa các Availability Zone hoặc Region, vốn thấp hơn nhiều so với Data Transfer ra Internet.
4. Hỗ trợ Cross-account và Cross-region
VPC Peering không bị giới hạn trong một tài khoản hay một khu vực địa lý duy nhất. Doanh nghiệp có thể kết nối VPC giữa các tài khoản AWS, GCP hoặc Azure khác nhau, hoặc giữa các Region cách xa nhau về vị trí địa lý. Đây là tính năng quan trọng với các tổ chức có cấu trúc tài khoản phân tán theo phòng ban, dự án, hoặc cần triển khai hệ thống đa vùng để phục vụ người dùng toàn cầu.
Những hạn chế kỹ thuật cần lưu ý
Bên cạnh lợi ích, VPC Peering cũng có những giới hạn kỹ thuật mà bất kỳ kỹ sư hạ tầng nào cũng cần nắm rõ trước khi triển khai trên môi trường Production.
1. Định tuyến phi chuyển tiếp (Non-transitive routing)
Đây là điểm gây nhầm lẫn lớn nhất đối với người mới tiếp cận VPC Peering. Nếu VPC A kết nối Peering với VPC B, và VPC B kết nối Peering với VPC C, thì VPC A không thể tự động kết nối với VPC C thông qua VPC B. Mỗi kết nối Peering chỉ hoạt động theo mô hình điểm nối điểm (Point-to-Point), không có khái niệm “đi nhờ” qua một VPC trung gian. Muốn VPC A giao tiếp được với VPC C, bắt buộc phải tạo một kết nối Peering riêng và trực tiếp giữa A và C.
2. Xung đột dải IP (CIDR Overlapping)
Hai VPC có dải địa chỉ mạng (CIDR block) trùng nhau hoàn toàn hoặc trùng một phần sẽ không thể thực hiện Peering, vì hệ thống định tuyến không thể xác định chính xác gói tin cần được gửi đến đâu khi có sự chồng lấp về địa chỉ IP. Đây là lý do việc quy hoạch dải IP từ giai đoạn thiết kế hạ tầng ban đầu là vô cùng quan trọng. Một sai sót nhỏ trong việc cấp phát CIDR ở thời điểm khởi tạo có thể khiến việc mở rộng kết nối liên VPC về sau gặp rất nhiều khó khăn, thậm chí phải tái cấu trúc lại toàn bộ dải địa chỉ.
3. Giới hạn số lượng kết nối
Mặc dù số lượng kết nối Peering được phép trên mỗi VPC khá lớn, ví dụ AWS mặc định cho phép 50 kết nối Peering đang hoạt động trên mỗi VPC và có thể tăng lên tối đa 125 kết nối, nhưng số lượng lớn không đồng nghĩa với việc nên lạm dụng.
Khi số VPC cần kết nối với nhau tăng lên, số lượng kết nối Peering theo mô hình Full Mesh sẽ tăng theo cấp số nhân. Với 100 VPC muốn kết nối đầy đủ theo mô hình full mesh, số lượng kết nối Peering cần thiết lên tới 4.950, tính theo công thức n(n-1)/2. Đây chính là hiện tượng thường được gọi là “Spaghetti Network”, một mạng lưới kết nối chằng chịt, khó theo dõi và gần như không thể quản trị hiệu quả khi quy mô hệ thống lớn dần.
So sánh: VPC Peering vs. VPN vs. Transit Gateway
Khi cân nhắc giải pháp kết nối liên VPC, nhiều người thường đặt VPC Peering lên bàn cân với Site-to-Site VPN và Transit Gateway. Bảng so sánh dưới đây giúp hình dung rõ hơn sự khác biệt giữa ba lựa chọn này.
| Tiêu chí | VPC Peering | Site-to-Site VPN | Transit Gateway |
| Độ phức tạp | Thấp, dễ thiết lập | Trung bình | Cao |
| Băng thông | Cao, tốc độ mạng nội bộ | Thấp, phụ thuộc ISP | Rất cao |
| Kiến trúc | Point-to-Point, một-một | Point-to-Point | Hub-and-Spoke, một-nhiều |
| Phí | Thấp hoặc miễn phí, chủ yếu phí data | Phí theo giờ cộng phí data | Phí theo giờ cộng phí xử lý data |
| Trường hợp dùng | Kết nối đơn lẻ, trực tiếp | Kết nối với hệ thống On-premise | Hệ thống phức tạp, nhiều VPC |
Nhìn chung, nếu nhu cầu chỉ là kết nối một vài VPC với nhau, VPC Peering vẫn là lựa chọn tối ưu nhất về cả chi phí và hiệu năng. Nhưng khi số lượng VPC tăng lên đáng kể, việc chuyển sang Transit Gateway để quản lý tập trung theo mô hình Hub-and-Spoke sẽ hợp lý hơn về lâu dài.
Các kịch bản sử dụng thực tế
VPC Peering được ứng dụng rộng rãi trong nhiều bài toán hạ tầng thực tế, dưới đây là ba kịch bản phổ biến nhất.
1. Chia sẻ dịch vụ tập trung
Một mô hình thường gặp là đặt một Database Cluster dùng chung tại một VPC riêng biệt, đóng vai trò trung tâm dữ liệu, rồi cho các VPC ứng dụng khác truy cập vào cụm cơ sở dữ liệu này thông qua kết nối Peering. Cách làm này giúp tránh việc nhân bản dữ liệu ra nhiều nơi, đồng thời tập trung công tác bảo trì, Backup và giám sát vào một điểm duy nhất.
2. Truy cập tài nguyên giữa các môi trường
Trong quá trình phát triển phần mềm, việc kết nối VPC Dev với VPC Staging để kiểm thử các dịch vụ chia sẻ là một nhu cầu rất thường gặp. Thay vì sao chép toàn bộ dữ liệu hoặc dịch vụ sang môi trường Dev, team kỹ thuật có thể Peering hai VPC này lại để Dev có thể gọi trực tiếp đến các API hoặc service đang chạy ở Staging, giúp việc kiểm thử sát với thực tế hơn.
3. Phân tán hệ thống theo khu vực
Với các doanh nghiệp có người dùng ở nhiều khu vực địa lý, việc kết nối VPC ở Region Singapore với VPC ở Region Tokyo để đồng bộ dữ liệu là giải pháp phổ biến nhằm đảm bảo dữ liệu luôn nhất quán giữa các vùng, đồng thời giảm độ trễ cho người dùng cuối tại từng khu vực do được phục vụ bởi hạ tầng gần nhất.
Quy trình triển khai VPC Peering cơ bản
Việc triển khai một kết nối VPC Peering về cơ bản gồm bốn bước, trong đó bước cập nhật bảng định tuyến là bước quan trọng nhất nhưng cũng thường bị bỏ quên nhất.
Bước 1: Gửi yêu cầu Peering
VPC chủ động khởi tạo kết nối, gọi là VPC chủ (Requester), sẽ gửi một yêu cầu Peering đến VPC còn lại, gọi là VPC nhận (Accepter). Yêu cầu này có thể được gửi trong cùng một tài khoản, giữa hai tài khoản khác nhau, hoặc giữa hai Region khác nhau.
Bước 2: Chấp nhận kết nối
Phía VPC nhận cần xác nhận đồng ý (Accept) yêu cầu Peering vừa được gửi đến. Nếu không có hành động chấp nhận trong một khoảng thời gian quy định, yêu cầu sẽ tự động hết hạn và kết nối không được thiết lập.
Bước 3: Cập nhật bảng định tuyến
Đây là bước quan trọng nhất mà nhiều người thường quên. Sau khi kết nối Peering được chấp nhận, cả hai VPC vẫn chưa thể giao tiếp với nhau nếu bảng định tuyến (Route Table) ở mỗi đầu chưa được cập nhật để chỉ đường lưu lượng đến dải CIDR của VPC đối diện thông qua kết nối Peering vừa tạo. Thiếu bước này là nguyên nhân phổ biến nhất khiến kết nối Peering “đã tạo nhưng không hoạt động”.
Bước 4: Cấu hình Security Group và Network ACL
Cuối cùng, cần điều chỉnh các quy tắc bảo mật như Security Group hoặc Network ACL ở cả hai VPC để cho phép traffic đi qua giữa các địa chỉ IP cụ thể. Nếu bỏ qua bước này, dù bảng định tuyến đã đúng, các gói tin vẫn có thể bị chặn lại bởi tường lửa ở cấp Instance hoặc Subnet.
Kết luận
VPC Peering là giải pháp đơn giản, hiệu quả và tiết kiệm chi phí cho việc kết nối trực tiếp giữa hai VPC, đặc biệt phù hợp khi số lượng VPC cần kết nối còn ở quy mô nhỏ. Tuy nhiên, để vận hành ổn định, người triển khai cần nắm rõ các giới hạn kỹ thuật quan trọng như tính phi chuyển tiếp, nguy cơ xung đột CIDR, và rủi ro tạo ra mạng lưới chằng chịt khi mở rộng quy mô. Khi hệ thống phát triển vượt quá khả năng quản lý của mô hình Peering truyền thống, chuyển sang Transit Gateway sẽ là bước đi hợp lý để đảm bảo khả năng mở rộng và dễ quản trị trong dài hạn.
