아키텍처 3: AWS Transit Gateway - AWS 규범적 지침
네트워크 검사 중앙 집중화배포 옵션 선택

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

아키텍처 3: AWS Transit Gateway

AWS Transit Gateway는 VPC와 온프레미스 네트워크를 연결하는 관리형 라우팅 서비스입니다. Transit Gateway를 사용하면 네트워크 토폴로지를 간소화하고 수많은 VPC 간의 복잡한 피어링 관계를 피할 수 있습니다.

Transit Gateway는 클라우드 라우터 역할을 합니다. 각 새 연결은 VPC와 전송 게이트웨이 간에 한 번만 이루어집니다. 전이적 라우팅을 지원하는 허브로 전송 게이트웨이를 사용하면 메시 토폴로지의 모든 단일 VPC 간에 피어 관계를 추가할 필요가 없습니다. Transit Gateway와 해당 할당량에 대한 자세한 내용은 전송 게이트웨이에 대한 할당량을 참조하세요.

Transit Gateway를 사용하여 타사 서비스를 통합하면 다음과 같은 이점이 있습니다.

  • VPC와 타사 네트워크 간의 양방향 트래픽 지원

  • 모든 유형의 IP 트래픽 지원(TCP 및 UDP 모두)

  • VPC와 타사 네트워크 사이에 중앙 집중식 트래픽 검사 지점 배포

  • 통합과 관련된 VPC의 수 변경에 따라 쉽게 규모를 조정할 수 있습니다.

Transit Gateway 솔루션 사용의 단점은 다음과 같습니다.

  • 이 옵션은 일반적으로 직접 피어링 옵션보다 비용이 많이 듭니다.

  • 겹치는 CIDR 블록은 지원되지 않습니다.

  • 완전한 제어를 유지하고 고객과의 구성 요소 공유를 최소화하기 위해 많은 타사 제공업체가 이 솔루션을 지원하지 않습니다.

다음 아키텍처 다이어그램은 Transit Gateway를 사용하여 VPC를 타사 제공업체의 VPC에 연결하는 과정을 단순하게 보여줍니다. 각 VPC는 전송 게이트웨이에 연결되며, 게이트웨이는 연결된 모든 VPC 간 전이 라우팅을 지원합니다.

Transit Gateway를 사용하여 다른 AWS 계정의 VPC 연결

그러나 실제 구성은 좀 더 미묘하며 이 아키텍처는 다양한 배포 고려 사항과 옵션으로 구분됩니다.

네트워크 검사 중앙 집중화

Transit Gateway를 사용하는 경우 중앙 집중식 네트워크 트래픽 검사 지점인 전용 검사 VPC를 배포할 수 있습니다. 리전 내 피어링 연결과 관련된 라우팅 테이블의 정적 경로를 사용하여 타사 네트워크에서 들어오는 트래픽을 검사 VPC로 보낼 수 있습니다. 트래픽을 검사하려면 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 배포된 가상 보안 어플라이언스와 페어링된 AWS Network Firewall 또는 AWS Gateway Load Balancer를 사용할 수 있습니다. 자세한 내용은 Deployment models for AWS Network Firewall의 Centralized deployment model(AWS 블로그 게시물)을 참조하세요.

검사 VPC 연결이 양방향 트래픽을 대칭적으로 라우팅하려면 전송 게이트웨이가 어플라이언스 모드에 있어야 합니다. 다음 아키텍처 다이어그램에서 볼 수 있듯이 전송 게이트웨이는 연결된 VPC의 트래픽을 검사 VPC의 탄력적 네트워크 인터페이스로 전달합니다.

전용 VPC에 중앙 집중식 검사 지점 생성

배포 옵션 선택

가장 먼저 고려할 사항은 네트워크의 기존 전송 게이트웨이를 사용할 것인지 아니면 새로운 전용 전송 게이트웨이를 생성할 것인지입니다. 타사 네트워크와 더 잘 제어하고 분리할 수 있다는 것이 입증되었으므로 새 전용 전송 게이트웨이를 배포하는 것이 좋습니다. 이 가이드의 샘플 아키텍처는 새 전송 게이트웨이를 생성하고 기존 게이트웨이와 새 게이트웨이 간에 피어링 연결을 생성할 수 있습니다.

두 번째로 고려할 사항은 사용 사례에 가장 적합한 아키텍처를 찾는 것입니다.

  1. 아키텍처 3.1: AWS RAM을 갖춘 Transit Gateway- 이 배포 옵션에서는 단일 전송 게이트웨이를 타사 계정과 공유합니다. AWS Resource Access Manager(AWS RAM)를 사용하여 공유 관계를 구성합니다.

  2. 아키텍처 3.2: Transit Gateway 피어링 - 이 배포 옵션에서는 2개의 전송 게이트웨이(사용자 계정과 타사 계정에 각각 하나) 간에 피어링 연결을 생성합니다.

이러한 옵션 중에서 선택할 때는 각 옵션의 다음과 같은 이점과 단점을 고려하세요.

  아키텍처 3.1: AWS RAM을 갖춘 Transit Gateway 아키텍처 3.2: Transit Gateway 피어링
장점 타사 계정에는 전송 게이트웨이가 필요하지 않으므로 아키텍처가 더욱 간소화됩니다. 네트워킹 구성을 더 잘 제어할 수 있으므로 타사에서 이 솔루션을 더 적합하다고 생각할 수 있습니다.
공유 전송 게이트웨이의 소유자로서 제어 및 가시성이 향상되었습니다. 타사가 자체 VPC 연결을 유지 관리하므로 운영 노력이 줄어듭니다.
단점 네트워킹 구성에 대한 통제력이 줄어들기 때문에 타사에서 꺼릴 수 있습니다. 네트워킹 아키텍처가 더 복잡합니다.
타사 계정의 VPC에 대한 Transit Gateway Attachment를 구성하는 것은 사용자의 책임입니다. 이 아키텍처는 트래픽 경로에 추가 홉을 생성합니다.

비용 고려 사항

또한 이러한 옵션 중에서 결정할 때 다음과 같은 비용 영향을 고려하세요.

  • Transit Gateway Attachment에 대한 시간당 요금은 연결 또는 VPC)의 계정 소유자에게 청구됩니다. 일부 비용은 사용자가 부담하고 다른 비용은 타사가 부담합니다.

  • 전송 게이트웨이를 통해 트래픽을 보내는 VPC의 소유자에게 데이터 처리 요금이 부과됩니다. 전송 게이트웨이에서 데이터를 수신하는 데는 요금이 부과되지 않습니다.

  • 피어링된 두 전송 게이트웨이 간에 전송된 데이터에는 데이터 처리 요금이 부과되지 않습니다.

자세한 내용은 Transit Gateway 요금을 참조하세요.