기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
# 아키텍처 3: AWS Transit Gateway
[AWS Transit Gateway](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html)는 VPC와 온프레미스 네트워크를 연결하는 관리형 라우팅 서비스입니다. Transit Gateway를 사용하면 네트워크 토폴로지를 간소화하고 수많은 VPC 간의 복잡한 피어링 관계를 피할 수 있습니다.
Transit Gateway는 클라우드 라우터 역할을 합니다. 각 새 연결은 VPC와 전송 게이트웨이 간에 한 번만 이루어집니다. 전이적 라우팅을 지원하는 허브로 전송 게이트웨이를 사용하면 메시 토폴로지의 모든 단일 VPC 간에 피어 관계를 추가할 필요가 없습니다. Transit Gateway와 해당 할당량에 대한 자세한 내용은 [전송 게이트웨이에 대한 할당량](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-quotas.html)을 참조하세요.
Transit Gateway를 사용하여 타사 서비스를 통합하면 다음과 같은 이점이 있습니다.
+ VPC와 타사 네트워크 간의 양방향 트래픽 지원
+ 모든 유형의 IP 트래픽 지원(TCP 및 UDP 모두)
+ VPC와 타사 네트워크 사이에 중앙 집중식 트래픽 검사 지점 배포
+ 통합과 관련된 VPC의 수 변경에 따라 쉽게 규모를 조정할 수 있습니다.
Transit Gateway 솔루션 사용의 단점은 다음과 같습니다.
+ 이 옵션은 일반적으로 직접 피어링 옵션보다 비용이 많이 듭니다.
+ 겹치는 CIDR 블록은 지원되지 않습니다.
+ 완전한 제어를 유지하고 고객과의 구성 요소 공유를 최소화하기 위해 많은 타사 제공업체가 이 솔루션을 지원하지 않습니다.
다음 아키텍처 다이어그램은 Transit Gateway를 사용하여 VPC를 타사 제공업체의 VPC에 연결하는 과정을 단순하게 보여줍니다. 각 VPC는 전송 게이트웨이에 연결되며, 게이트웨이는 연결된 모든 VPC 간 전이 라우팅을 지원합니다.
그러나 실제 구성은 좀 더 미묘하며 이 아키텍처는 다양한 배포 고려 사항과 옵션으로 구분됩니다.
## 네트워크 검사 중앙 집중화
Transit Gateway를 사용하는 경우 중앙 집중식 네트워크 트래픽 검사 지점인 전용 검사 VPC를 배포할 수 있습니다. 리전 내 피어링 연결과 관련된 라우팅 테이블의 정적 경로를 사용하여 타사 네트워크에서 들어오는 트래픽을 검사 VPC로 보낼 수 있습니다. 트래픽을 검사하기 위해 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스에 배포된 가상 보안 어플라이언스와 페어링된 AWS Network Firewall 또는 AWS Gateway Load Balancer를 사용할 수 있습니다. 자세한 내용은 용 *배포 모델의 중앙 집중식* [배포 모델 AWS Network Firewall](https://aws.amazon.com/blogs/networking-and-content-delivery/deployment-models-for-aws-network-firewall/)(AWS 블로그 게시물)을 참조하세요.
검사 VPC 연결이 양방향 트래픽을 대칭적으로 라우팅하려면 전송 게이트웨이가 [어플라이언스 모드](https://docs.aws.amazon.com/vpc/latest/tgw/transit-gateway-appliance-scenario.html#transit-gateway-appliance-support)에 있어야 합니다. 다음 아키텍처 다이어그램에서 볼 수 있듯이 전송 게이트웨이는 연결된 VPC의 트래픽을 검사 VPC의 탄력적 네트워크 인터페이스로 전달합니다.
## 배포 옵션 선택
가장 먼저 고려할 사항은 네트워크의 기존 전송 게이트웨이를 사용할 것인지 아니면 새로운 전용 전송 게이트웨이를 생성할 것인지입니다. 타사 네트워크와 더 잘 제어하고 분리할 수 있다는 것이 입증되었으므로 새 전용 전송 게이트웨이를 배포하는 것이 좋습니다. 이 가이드의 샘플 아키텍처는 새 전송 게이트웨이를 생성하고 기존 게이트웨이와 새 게이트웨이 간에 피어링 연결을 생성할 수 있습니다.
두 번째로 고려할 사항은 사용 사례에 가장 적합한 아키텍처를 찾는 것입니다.
1. **[아키텍처 3.1: Transit Gateway with AWS RAM](architecture-3-1.md)**- 이 배포 옵션에서는 단일 전송 게이트웨이를 타사 계정과 공유합니다. AWS Resource Access Manager (AWS RAM)를 사용하여 공유 관계를 구성합니다.
1. **[아키텍처 3.2: Transit Gateway 피어링](architecture-3-2.md)** - 이 배포 옵션에서는 2개의 전송 게이트웨이(사용자 계정과 타사 계정에 각각 하나) 간에 피어링 연결을 생성합니다.
이러한 옵션 중에서 선택할 때는 각 옵션의 다음과 같은 이점과 단점을 고려하세요.
****
- ****장점****
- **[아키텍처 3.1: Transit Gateway with AWS RAM](architecture-3-1.md):** 타사 계정에는 전송 게이트웨이가 필요하지 않으므로 아키텍처가 더욱 간소화됩니다. / **[아키텍처 3.2: Transit Gateway 피어링](architecture-3-2.md):** 네트워킹 구성을 더 잘 제어할 수 있으므로 타사에서 이 솔루션을 더 적합하다고 생각할 수 있습니다.
- **[아키텍처 3.1: Transit Gateway with AWS RAM](architecture-3-1.md):** 공유 전송 게이트웨이의 소유자로서 제어 및 가시성이 향상되었습니다. / **[아키텍처 3.2: Transit Gateway 피어링](architecture-3-2.md):** 타사가 자체 VPC 연결을 유지 관리하므로 운영 노력이 줄어듭니다.
- ****단점****
- **[아키텍처 3.1: Transit Gateway with AWS RAM](architecture-3-1.md):** 네트워킹 구성에 대한 통제력이 줄어들기 때문에 타사에서 꺼릴 수 있습니다. / **[아키텍처 3.2: Transit Gateway 피어링](architecture-3-2.md):** 네트워킹 아키텍처가 더 복잡합니다.
- **[아키텍처 3.1: Transit Gateway with AWS RAM](architecture-3-1.md):** 타사 계정의 VPC에 대한 Transit Gateway Attachment를 구성하는 것은 사용자의 책임입니다. / **[아키텍처 3.2: Transit Gateway 피어링](architecture-3-2.md):** 이 아키텍처는 트래픽 경로에 추가 홉을 생성합니다.
### 비용 고려 사항
또한 이러한 옵션 중에서 결정할 때 다음과 같은 비용 영향을 고려하세요.
+ Transit Gateway Attachment에 대한 시간당 요금은 연결 또는 **VPC)의 계정 소유자에게 청구됩니다. 일부 비용은 사용자가 부담하고 다른 비용은 타사가 부담합니다.
+ 전송 게이트웨이를 통해 트래픽을 보내는 VPC의 소유자에게 데이터 처리 요금이 부과됩니다. 전송 게이트웨이에서 데이터를 수신하는 데는 요금이 부과되지 않습니다.
+ 피어링된 두 전송 게이트웨이 간에 전송된 데이터에는 데이터 처리 요금이 부과되지 않습니다.
자세한 내용은 [ Transit Gateway 요금](https://aws.amazon.com/transit-gateway/pricing/)을 참조하세요.