Hai tài khoản AWS, một mạng nội bộ: con đường nào?
Transit Gateway dùng chung, hai VPN độc lập hay một proxy hẹp: hãy chọn theo quyền sở hữu và phạm vi ảnh hưởng, không theo con đường dễ thêm nhất hôm nay.
Cách đặt vấn đề hiển nhiên là peering so với VPN, và đó là cách đặt vấn đề sai. Một VPC đã peering không thể mượn kết nối VPN của hàng xóm để định tuyến từ biên đến biên, nên lựa chọn đó chưa bao giờ có trên bàn, bất kể bảng tuyến nói gì. Điều bạn thực sự chọn là giữa một trung tâm mạng dùng chung, hai đường VPN độc lập và một cửa vào ứng dụng hẹp. Mỗi lựa chọn trả lời một câu hỏi khác về việc ai sở hữu định tuyến.
Ba lựa chọn và lựa chọn không tồn tại
Hãy bắt đầu bằng việc xóa bỏ ý tưởng peering, rồi so sánh phần còn lại theo quyền sở hữu chứ không theo độ đơn giản của sơ đồ. Bảng dưới đây là quyết định ở dạng nén.
| Option | Who owns the path | Main cost |
|---|---|---|
| Shared transit gateway | Hub owner, used by both VPC owners | Shared blast radius, attachment and data-processing charges |
| Separate VPNs per account | Each account independently | Peer capacity, duplicated tunnels, overlapping prefixes to coordinate |
| Application proxy | The account that hosts the intermediary | New auth, logging and availability surface, and only one service |
Nếu tài khoản A cần chạm tới toàn bộ mạng nội bộ, hàng proxy là sai hình dạng. Nếu tài khoản A chỉ cần một API, hai hàng đầu tiên là nhiều mạng hơn mức yêu cầu đòi hỏi.
Khi Transit Gateway dùng chung thắng thế
Transit Gateway gắn mỗi VPC và VPN như những mạng riêng biệt, và việc chia sẻ giữa các tài khoản cho phép chủ sở hữu VPC dùng trung tâm mà không phải hợp nhất tài khoản. Đó là sức hút: một nơi các tiền tố nội bộ gặp các mạng AWS, và một nơi để lý giải gắn kết nào học tuyến nào.
Gắn mọi thứ không có nghĩa là cho phép mọi thứ. Liên kết và lan truyền quyết định gắn kết nào dùng bảng tuyến nào, nên hai tiền tố VPC có thể mỗi bên chạm tới một dịch vụ nội bộ trong khi quyền truy cập lẫn nhau vẫn bị loại trừ bởi thiết kế của trung tâm. Phía nội bộ vẫn cần tuyến quay lại cho các tiền tố AWS, và đó là phiếu thay đổi của một nhóm khác.
Chi phí mang tính tổ chức nhiều như mang tính tài chính. Chủ sở hữu trung tâm kiểm soát các quan hệ định tuyến mà nhóm khác phụ thuộc, nên một thay đổi ở một gắn kết có thể làm dịch chuyển lưu lượng của một dịch vụ mà chủ sở hữu trung tâm chưa từng nghe tới. Giờ gắn kết và xử lý dữ liệu cộng dồn với mỗi mạng bạn gắn, đó là lý do các trung tâm thường lớn nhanh hơn nhóm vận hành chúng.
Khi VPN riêng hoặc proxy hẹp thắng thế
Hai VPN độc lập phù hợp với một triển khai nhỏ có ranh giới vận hành thật: mỗi tài khoản đổi đường hầm của mình, và không bên nào phá được bên kia bằng cách sửa bảng tuyến. Các giới hạn nằm ở phía nội bộ. Cổng ngang hàng cần dung lượng cho các đường hầm bổ sung, quy hoạch địa chỉ không được chồng lấn, và hai cấu hình quảng bá cùng tiền tố cần một ưu tiên có chủ đích thay vì hy vọng.
Proxy là giao diện hẹp nhất. Nếu tài khoản A cần một cơ sở dữ liệu hoặc một API trong tài khoản B, một trung gian có phạm vi cho bạn lối vào xác định với câu chuyện xác thực, ghi nhật ký và tính sẵn sàng riêng. Đây cũng là lựa chọn dễ bị lạm dụng nhất: một trung gian chuyển tiếp tới mọi đích riêng tư đã trở thành rơ-le không giới hạn với thêm các bước, và nó sẽ không hành xử như tuyến xuyên trong suốt từ VPC tới mạng nội bộ cho bất cứ thứ gì khác.
Nên đọc các hạn chế của peering VPC trước tất cả những điều này, vì chúng giải thích vì sao ý tưởng thứ tư cứ quay lại và vì sao nó không thể hoạt động.
Chọn giao diện hẹp nhất đáp ứng yêu cầu
Hãy sắp xếp các câu hỏi: A cần một mạng, một tập mạng hay một dịch vụ? Nhóm nội bộ muốn một đường hay nhiều đường? Ai được phép đổi định tuyến cho lưu lượng của nhóm kia? Câu trả lời đầu tiên tạo ra giao diện hẹp nhất chính là kiến trúc, và mọi thứ sau đó là triển khai.
Ghi lại câu trả lời cùng quy hoạch tiền tố, quyền sở hữu tuyến, danh mục đường hầm hoặc gắn kết, và chế độ hỏng hóc mà mỗi bên mong đợi. Khi về sau có người hỏi vì sao tài khoản A không thể chỉ dùng VPN của tài khoản B, bản ghi đó chính là câu trả lời, và nó giúp bạn khỏi tranh luận lại đúng ba lựa chọn ấy ở dự án sau.