Transit Gateway dùng chung: ai sở hữu các tuyến trong AWS RAM

Chia sẻ một Transit Gateway bằng Resource Access Manager làm một việc cụ thể: cho phép tài khoản khác gọi một tập API gắn kết xác định đối với tài nguyên mà họ không sở hữu. Nó không chuyển giao gateway, các bảng tuyến của nó hay quyền quyết định cách lưu lượng được chuyển tiếp. Người ta giả định ngược lại vì gắn kết xuất hiện trong bảng điều khiển của người nhận và hoạt động ngay lập tức, điều này tạo cảm giác sở hữu. Cơ chế bên dưới là cấp quyền trên một tài nguyên dùng chung, và mọi đối tượng con vẫn nằm trong ranh giới tài khoản của chủ sở hữu. Sự tách biệt đó giải thích phần lớn các phiếu từ chối truy cập quanh vận chuyển dùng chung.

Chia sẻ thực sự ủy quyền điều gì

Một chia sẻ tài nguyên nêu tên tài nguyên, principal và quyền được quản lý. Quyền liệt kê các hành động mà principal đó có thể thực hiện, và với Transit Gateway danh sách đó bao gồm các thao tác gắn kết trên tài nguyên dùng chung.

Bất kỳ điều gì ngoài danh sách đều thất bại ở API chứ không phải trong bảng điều khiển, đó là lý do lỗi thường xuất hiện lần đầu khi một script chạy.

Bảng tuyến, liên kết và lan truyền vẫn thuộc chủ sở hữu

Việc chuyển tiếp do ba đối tượng con quyết định: gắn kết được liên kết với bảng tuyến nào, nó lan truyền vào những bảng nào và những bảng đó chứa tuyến nào. Tài liệu chia sẻ của AWS nêu rằng người nhận không thể tạo, sửa hoặc xóa bảng tuyến của gateway vận chuyển hay các liên kết và lan truyền của chúng thông qua chia sẻ. Những lệnh gọi đó thuộc tài khoản chủ sở hữu. Người nhận cần một liên kết mới đang yêu cầu thay đổi hành chính, không phải đang thực thi một quyền đã quên bật.

Bảng dưới đây là cách phân chia tôi đặt trong tài liệu thiết kế, vì nó tồn tại qua các lần thay đổi nhân sự.

Hãy đọc kỹ hàng giữa: chủ sở hữu VPC kiểm soát tuyến của subnet mình, chủ sở hữu gateway kiểm soát quyết định chuyển tiếp trung tâm, và một đường đi hoạt động cần cả hai. Không tài khoản nào có thể hoàn thành một mình.

Một đường đi, hai tài khoản

Theo dõi một gói tin từ VPC spoke đến tiền tố tại chỗ. Bảng tuyến của subnet spoke phải gửi tiền tố đó đến gắn kết gateway vận chuyển, điều mà chủ sở hữu VPC có thể thay đổi. Sau đó gateway phải có một tuyến trong bảng liên kết của gắn kết trỏ đến gắn kết VPN, và chỉ chủ sở hữu mới thay đổi được. Lưu lượng quay về cần hình ảnh phản chiếu của cả hai. Bỏ sót bất kỳ bên nào và bạn nhận được một đường đi cài đặt nửa vời trông như sự cố tường lửa.

Viết cả hai thay đổi vào một phiếu với hai người phụ trách, nếu không chúng sẽ xong vào các tuần khác nhau.

Dùng ID vùng khả dụng khi vị trí quan trọng

Tên vùng là bí danh cục bộ của tài khoản. us-east-1a trong một tài khoản không được bảo đảm là cùng vùng vật lý với us-east-1a trong tài khoản khác. Khi thiết kế cần một gắn kết và một khối lượng công việc trong cùng vùng, hãy so sánh ID AZ và ghi lại.

So sánh tên tạo ra một sơ đồ trông đúng và một hồ sơ độ trễ không đúng. Hãy kiểm tra điều đó khi sơ đồ còn đang được vẽ, không phải sau khi ai đó đo sự khác biệt.

Bỏ chia sẻ không cắt đường đi của dữ liệu

Xóa chia sẻ có cảm giác như thu hồi, và nó không phải là dừng lưu lượng ngay lập tức. AWS ghi nhận rằng gắn kết vẫn hoạt động khi gateway không còn được chia sẻ. Quyền quản lý tài nguyên biến mất, trong khi gắn kết hiện có tiếp tục chuyển tiếp cho đến khi ai đó xóa hoặc vô hiệu hóa nó. Lên kế hoạch thu hồi theo hai bước: xóa chia sẻ, rồi xóa gắn kết, với chủ sở hữu thực hiện bước thứ hai.

Nếu chia sẻ là kiểm soát duy nhất của bạn, bạn không có kiểm soát.

Giữ hồ sơ chia sẻ và hồ sơ định tuyến cùng nhau

Hai hiện vật trả lời hai câu hỏi khác nhau. Hồ sơ chia sẻ cho biết ai được làm việc với tài nguyên. Bảng tuyến cho biết mạng nào thực sự có thể nói chuyện. Hãy lưu chúng cùng với cùng danh sách chủ sở hữu, nếu không sự cố tiếp theo sẽ bắt đầu bằng việc ai đó chứng minh một quyền chưa bao giờ là vấn đề.

Sau đó kiểm tra một luồng theo mỗi hướng và một tiền tố phải tiếp tục không thể tiếp cận.