공유된 Transit Gateway: AWS RAM에서 경로를 소유하는 사람은 누구인가

Transit Gateway를 Resource Access Manager로 공유하면 소유하지 않은 리소스에 대해 정의된 연결 API 집합을 다른 계정이 호출할 수 있게 할 뿐입니다. 게이트웨이, 라우트 테이블, 트래픽 전달 방식을 결정할 권리를 이전하지는 않습니다. 연결이 수신자 콘솔에 나타나고 즉시 작동하기 때문에 사람들은 소유권을 얻었다고 느낍니다. 그 아래의 메커니즘은 공유 리소스에 대한 권한 부여이며, 모든 자식 객체는 소유자 계정 경계 안에 남습니다. 이 분리가 공유 트랜짓에 관한 대부분의 액세스 거부 티켓을 설명합니다.

공유가 실제로 위임하는 것

리소스 공유는 리소스, 주체, 관리형 권한을 지정합니다. 권한은 그 주체가 수행할 수 있는 작업을 나열하며, Transit Gateway의 경우 그 목록은 공유 리소스에 대한 연결 작업을 포함합니다.

목록 밖의 모든 것은 콘솔이 아니라 API에서 실패하므로, 스크립트를 처음 실행할 때 오류가 자주 나타납니다.

라우트 테이블, 연결, 전파는 소유자에게 남는다

전달은 세 개의 자식 객체, 즉 연결이 어느 라우트 테이블에 연결되어 있는지, 어느 테이블로 전파되는지, 그 테이블이 어떤 경로를 담고 있는지로 결정됩니다. AWS 공유 문서는 수신자가 공유를 통해 트랜짓 게이트웨이 라우트 테이블이나 그 연결 및 전파를 생성, 수정, 삭제할 수 없다고 명시합니다. 그 호출은 소유자 계정에 속합니다. 새 연결이 필요한 수신자는 활성화하는 것을 잊은 권한을 행사하는 것이 아니라 관리 변경을 요청하는 것입니다.

아래 표는 인사 이동에도 살아남기 때문에 제가 설계 문서에 넣는 분담입니다.

가운데 행에서 VPC 소유자는 자신의 서브넷 경로를 제어하고, 게이트웨이 소유자는 중앙 전달 결정을 제어하며, 작동하는 경로에는 둘 다 필요하다는 점을 주의 깊게 읽으십시오. 어느 계정도 혼자서 완료할 수 없습니다.

하나의 경로, 두 개의 계정

스포크 VPC에서 온프레미스 프리픽스까지 패킷을 추적하십시오. 스포크 서브넷 라우트 테이블은 그 프리픽스를 트랜짓 게이트웨이 연결로 보내야 하며, VPC 소유자가 이를 변경할 수 있습니다. 그다음 게이트웨이는 연결의 연관 테이블에 VPN 연결을 가리키는 경로가 있어야 하며, 소유자만 이를 변경할 수 있습니다. 반환 트래픽에는 둘 모두의 거울이 필요합니다. 어느 한쪽을 놓치면 절반만 설치되어 방화벽 문제처럼 보이는 경로가 됩니다.

두 변경을 두 담당자와 함께 하나의 티켓에 적지 않으면 서로 다른 주에 완료됩니다.

배치가 중요할 때 가용 영역 ID를 사용하라

영역 이름은 계정 로컬 별칭입니다. 한 계정의 us-east-1a가 다른 계정의 us-east-1a와 같은 물리적 영역이라고 보장되지 않습니다. 설계에 같은 영역의 연결과 워크로드가 필요하면 AZ ID를 비교하고 기록하십시오.

이름을 비교하면 올바르게 보이는 다이어그램과 그렇지 않은 지연 프로필이 나옵니다. 누군가 차이를 측정한 후가 아니라 다이어그램을 그리는 동안 확인하십시오.

공유 해제는 데이터 경로를 끊지 않는다

공유를 제거하는 것은 취소처럼 느껴지지만 즉각적인 트래픽 중단은 아닙니다. AWS는 게이트웨이가 공유에서 제외되어도 연결이 계속 작동한다고 문서화합니다. 리소스를 관리할 권한은 사라지지만 기존 연결은 누군가 삭제하거나 비활성화할 때까지 전달을 계속합니다. 공유를 제거한 다음 연결을 제거하되 두 번째는 소유자가 수행하는 두 단계로 취소를 계획하십시오.

공유가 유일한 통제라면 통제가 없는 것입니다.

공유 기록과 라우팅 기록을 함께 보관하라

두 산출물은 두 가지 다른 질문에 답합니다. 공유 기록은 누가 리소스로 작업할 수 있는지 말합니다. 라우트 테이블은 어떤 네트워크가 실제로 통신할 수 있는지 말합니다. 같은 소유자 목록과 함께 보관하지 않으면 다음 사고는 결코 문제가 아니었던 권한을 증명하는 사람으로 시작됩니다.

그다음 각 방향의 흐름 하나와 도달할 수 없어야 하는 프리픽스 하나를 테스트하십시오.