AWS 계정 두 개, 온프레미스 네트워크 하나: 어떤 경로인가?

분명해 보이는 틀은 피어링 대 VPN이지만, 그것은 잘못된 틀입니다. 피어링된 VPC는 가장자리 간 라우팅을 위해 이웃의 VPN 연결을 빌릴 수 없으므로, 라우팅 테이블이 무엇을 암시하든 그 선택지는 애초에 없었습니다. 실제로 선택하는 것은 공유 네트워크 허브, 두 개의 독립 VPN 경로, 좁은 애플리케이션 진입점입니다. 각각은 라우팅을 누가 소유하는지에 대한 다른 질문에 답합니다.

세 가지 선택지와 선택지가 아닌 것

피어링이라는 발상을 지우고, 남은 것을 다이어그램의 단순함이 아니라 소유권으로 비교하십시오. 아래 표는 결정을 압축한 것입니다.

계정 A가 온프레미스 네트워크 전체에 대한 도달성을 필요로 한다면 프록시 행은 형태가 틀립니다. 계정 A가 API 하나를 필요로 한다면 처음 두 행은 요구 사항이 요청한 것보다 많은 네트워크입니다.

공유 Transit Gateway가 이기는 경우

Transit Gateway는 각 VPC와 VPN을 별도의 네트워크로 연결합니다. 계정 간 공유를 통해 VPC 소유자는 계정을 합치지 않고 허브를 사용할 수 있으며, 온프레미스 프리픽스가 AWS 네트워크를 만나는 한 곳이 되고, 어떤 연결이 어떤 경로를 학습하는지 생각할 한 곳이 됩니다.

모든 것을 연결하는 것이 모든 것을 허용하는 것은 아닙니다. 연결과 전파가 어떤 연결이 어떤 라우팅 테이블을 사용하는지 결정하므로, 두 VPC 프리픽스가 각각 온프레미스 서비스에 도달하면서 상호 접근은 허브 설계에 의해 제외된 채로 남을 수 있습니다. 온프레미스 측은 여전히 AWS 프리픽스에 대한 반환 경로가 필요하며, 그것은 다른 팀의 변경 티켓입니다.

비용은 재무적일 뿐 아니라 조직적입니다. 허브 소유자는 다른 팀이 의존하는 라우팅 관계를 통제하므로, 한 연결의 변경이 허브 소유자가 들어본 적 없는 서비스의 트래픽을 옮길 수 있습니다. 연결 시간과 데이터 처리는 연결하는 모든 네트워크마다 누적되며, 그래서 허브는 그것을 운영하는 팀보다 빠르게 성장하는 경향이 있습니다.

별도 VPN이나 좁은 프록시가 이기는 경우

독립적인 VPN 두 개는 실제 운영 경계가 있는 소규모 배포에 적합합니다. 각 계정이 자체 터널을 변경하고, 어느 쪽도 라우팅 테이블을 편집해 다른 쪽을 망가뜨릴 수 없습니다. 한계는 온프레미스 측에 있습니다. 피어 게이트웨이는 추가 터널을 위한 용량이 필요하고, 주소 계획은 겹치지 않아야 하며, 같은 프리픽스를 광고하는 두 구성에는 기대가 아니라 의도적인 우선순위가 필요합니다.

프록시는 가장 좁은 인터페이스입니다. 계정 A가 계정 B의 데이터베이스 하나나 API 하나를 필요로 한다면, 범위가 한정된 중개자는 자체 인증, 로깅, 가용성 이야기를 갖는 정의된 진입점을 제공합니다. 또한 가장 남용되기 쉬운 선택지입니다. 모든 프라이빗 대상으로 전달하는 중개자는 단계만 늘어난 무제한 릴레이가 되었고, 다른 무엇에도 VPC에서 온프레미스 네트워크로의 투명한 통과처럼 동작하지 않습니다.

이 모든 것 전에 VPC 피어링 제한을 읽을 가치가 있습니다. 네 번째 발상이 왜 계속 돌아오는지, 왜 작동할 수 없는지 설명하기 때문입니다.

요구 사항을 충족하는 가장 좁은 인터페이스 선택

질문을 정렬하십시오. A가 네트워크 하나, 네트워크 집합, 아니면 서비스 하나를 필요로 합니까? 온프레미스 팀은 경로 하나를 원합니까, 여러 개를 원합니까? 다른 팀의 트래픽 라우팅을 바꿀 수 있는 사람은 누구입니까? 가장 좁은 인터페이스를 만드는 첫 답이 아키텍처이고, 그 이후의 모든 것은 구현입니다.

프리픽스 계획, 경로 소유권, 터널 또는 연결 인벤토리, 양측이 예상하는 장애 모드와 함께 답을 기록하십시오. 나중에 누군가 계정 A가 계정 B의 VPN을 그냥 쓸 수 없는 이유를 묻는다면 그 기록이 답이며, 다음 프로젝트에서 같은 세 가지 선택지를 다시 논쟁하지 않게 해 줍니다.