Amazon VPC Transit Gateways의 작동 원리

포커스 모드

Amazon VPC Transit Gateways의 작동 원리 - Amazon VPC

아키텍처 다이어그램 예제 리소스 연결 Equal Cost Multipath 라우팅 가용 영역 라우팅 전송 게이트웨이 시나리오 예

AWS Transit Gateway에서 전송 게이트웨이는 Virtual Private Cloud(VPCs)와 온프레미스 네트워크 간에 흐르는 트래픽을 위한 리전 가상 라우터 역할을 합니다. Transit Gateway는 네트워크 트래픽의 볼륨에 따라 탄력적으로 조정됩니다. Transit Gateway를 통한 라우팅은 패킷이 대상 IP 주소를 기반으로 특정 다음 홉 연결로 전송되는 계층 3에서 작동합니다.

아키텍처 다이어그램 예제

다음 다이어그램에서는 3개의 VPC 연결이 있는 Transit Gateway를 보여 줍니다. 이러한 각 VPC의 라우팅 테이블에는 다른 두 VPC를 대상으로 하는 트래픽을 Transit Gateway로 보내는 로컬 경로가 포함됩니다.

다음은 이전 다이어그램에 표시된 연결에 대한 기본 Transit Gateway 라우팅 테이블의 예입니다. 각 VPC의 CIDR 블록이 라우팅 테이블에 전파됩니다. 따라서 각 연결은 패킷을 다른 두 가지 연결로 경로 지정할 수 있습니다.

대상 주소	대상	경로 유형
`VPC A CIDR`	`VPC A 연결`	전파
`VPC B CIDR`	`VPC B 연결`	전파
`VPC C CIDR`	`VPC C 연결`	전파

리소스 연결

Transit Gateway Attachment는 패킷의 소스이자 대상입니다. 다음 리소스를 Transit Gateway에 연결할 수 있습니다.

하나 이상의 VPCs. AWS Transit Gateway는 VPC 서브넷 내에 탄력적 네트워크 인터페이스를 배포합니다. 그러면 전송 게이트웨이가 선택한 서브넷으로 트래픽을 라우팅하는 데 사용됩니다. 각 가용 영역에 하나 이상의 서브넷이 있어야 합니다. 그러면 트래픽이 해당 영역의 모든 서브넷에 있는 리소스에 도달할 수 있습니다. 연결을 생성하는 동안 특정 가용 영역 내의 리소스는 동일한 영역 내에 서브넷이 활성화된 경우에만 Transit Gateway에 도달할 수 있습니다. 서브넷 라우팅 테이블은 Transit Gateway에 대한 경로를 포함합니다. 트래픽은 동일한 가용 영역의 서브넷에 연결이 있는 경우에만 Transit Gateway에 전달됩니다.
하나 이상의 VPN 연결
하나 이상의 AWS Direct Connect 게이트웨이
하나 이상의 Transit Gateway Connect 연결
하나 이상의 Transit Gateway 피어링 연결

Equal Cost Multipath 라우팅

AWS Transit Gateway는 대부분의 첨부 파일에 대해 ECMP(Equal Cost Multipath) 라우팅을 지원합니다. VPN 연결의 경우, Transit Gateway를 생성하거나 수정할 때 콘솔을 사용해 ECMP 지원을 활성화하거나 비활성화할 수 있습니다. 다른 모든 연결 유형의 경우, 다음과 같은 ECMP 제한 사항이 적용됩니다.

VPC - VPC는 CIDR 블록이 중첩될 수 없기 때문에 ECMP를 지원하지 않습니다. 예를 들어, CIDR 10.1.0.0/16을 포함한 VPC를 Transit Gateway에 대하여 같은 CIDR을 사용하는 두 번째 VPC와 연결하여 둘 사이의 트래픽을 로드 밸런싱할 라우팅을 설정할 수는 없습니다.
VPN - VPN ECMP support(VPN ECMP 지원) 옵션이 비활성화된 경우, Transit Gateway는 여러 경로에 걸쳐 같은 접두사가 발생하는 경우 내부 지표를 사용해 기본 설정 경로를 판단합니다. VPN 연결에 대한 ECMP 활성화 또는 비활성화에 대한 자세한 내용은 Amazon VPC Transit Gateways의 전송 게이트웨이를 참조하세요.
AWS Transit Gateway Connect - AWS Transit Gateway Connect 연결은 ECMP를 자동으로 지원합니다.
AWS Direct Connect Gateway - AWS Direct Connect Gateway 연결은 네트워크 접두사, 접두사 길이 및 AS_PATH가 정확히 동일한 경우 여러 Direct Connect Gateway 연결에서 ECMP를 자동으로 지원합니다.
Transit Gateway 피어링 - Transit Gateway 피어링은 동적 라우팅을 지원하지도 않고, 서로 다른 두 대상에 대하여 같은 정적 경로를 구성할 수도 없기 때문에 ECMP를 지원하지 않습니다.

참고

BGP Multipath AS-Path Relax가 지원되지 않으므로 Autonomous System Number(ASN)가 서로 다른 경우 ECMP를 사용할 수 없습니다.
서로 다른 연결 유형 간에는 ECMP가 지원되지 않습니다. 예를 들어 VPN과 VPC 연결 사이에서 ECMP를 활성화할 수는 없습니다. 대신, Transit Gateway 경로가 평가되며 트래픽은 그에 따라 평가된 경로로 라우팅됩니다. 자세한 내용은 경로 평가 순서 단원을 참조하십시오.
단일 Direct Connect 게이트웨이는 여러 전송 가상 인터페이스에서 ECMP를 지원합니다. 따라서 Direct Connect 게이트웨이는 하나만 설정하여 사용하는 것이 좋습니다. ECMP를 유리하게 활용하기 위해 게이트웨이를 여러 개 설정하여 사용하지 마세요. Direct Connect 게이트웨이 및 퍼블릭 가상 인터페이스에 대한 자세한 내용은 퍼블릭 가상 인터페이스 AWS 에서에 대한 Active/Active 또는 Active/Passive Direct Connect 연결을 설정하려면 어떻게 해야 하나요?를 참조하세요.

가용 영역

Transit Gateway에 VPC를 연결할 때는 Transit Gateway에서 하나 이상의 가용 영역을 사용하여 트래픽을 VPC 서브넷의 리소스로 라우팅해야 합니다. 각 가용 영역을 활성화하려면 정확히 하나의 서브넷을 지정해야 합니다. Transit Gateway는 서브넷의 IP 주소 하나를 사용하여 해당 서브넷에 네트워크 인터페이스를 배치합니다. 가용 영역을 활성화하면 지정된 서브넷이나 가용 영역이 아닌 VPC의 모든 서브넷으로 트래픽을 라우팅할 수 있습니다. 그러나 Transit Gateway Attachment가 있는 가용 영역에 상주하는 리소스만 Transit Gateway에 도달할 수 있습니다.

트래픽이 대상 연결이 없는 가용 영역에서 소싱되는 경우 AWS Transit Gateway는 해당 트래픽을 연결이 있는 무작위 가용 영역으로 내부적으로 라우팅합니다. 이러한 유형의 가용 영역 간 트래픽에는 추가 전송 게이트웨이 요금이 부과되지 않습니다.

가용성을 위해 여러 개의 가용 영역을 활성화하는 것이 좋습니다.

어플라이언스 모드 지원 사용

VPC에서 상태 저장 네트워크 어플라이언스를 구성하려는 경우 어플라이언스가 위치한 해당 VPC 연결에 대해 어플라이언스 모드 지원을 활성화할 수 있습니다. 이렇게 하면 Transit Gateway가 소스와 대상 간의 트래픽 흐름이 끝날 때까지 해당 VPC 연결에 동일한 가용 영역을 사용할 수 있습니다. 또한 해당 영역에 서브넷 연결이 있는 경우 Transit Gateway는 VPC의 모든 가용 영역으로 트래픽을 전송할 수 있습니다. 자세한 내용은 예: 공유 서비스 VPC의 어플라이언스 단원을 참조하십시오.

라우팅

Transit Gateway는 Transit Gateway 라우팅 테이블을 사용하여 연결 간에 IPv4 및 IPv6 패킷을 라우팅합니다. 연결된 VPC, VPN 연결 및 Direct Connect 게이트웨이에 대한 라우팅 테이블의 경로를 전파하도록 이러한 라우팅 테이블을 구성할 수 있습니다. Transit Gateway 라우팅 테이블에 정적 경로를 추가할 수도 있습니다. 패킷이 한 연결에서 오는 경우 이 패킷은 대상 IP 주소와 일치하는 경로를 사용하여 다른 연결로 라우팅됩니다.

Transit Gateway 피어링 연결의 경우 정적 경로만 지원됩니다.

라우팅 주제

라우팅 테이블
라우팅 테이블 연결
경로 전파
피어링 연결에 대한 라우팅
경로 평가 순서

라우팅 테이블

Transit Gateway는 자동으로 기본 라우팅 테이블과 함께 제공됩니다. 기본적으로 이 라우팅 테이블은 기본 연결 라우팅 테이블과 기본 전파 라우팅 테이블입니다. 경로 전파 및 라우팅 테이블 연결을 비활성화한 경우 AWS 는 Transit Gateway에 대한 기본 라우팅 테이블을 생성하지 않습니다.

Transit Gateway에 사용할 추가 라우팅 테이블을 만들 수 있습니다. 이렇게 하면 연결의 서브넷을 격리할 수 있습니다. 각 연결은 라우팅 테이블 하나와 연결할 수 있습니다. 한 연결은 하나 이상의 라우팅 테이블에 해당 경로를 전파할 수 있습니다.

Transit Gateway 라우팅 테이블에 경로와 일치하는 트래픽을 삭제하는 블랙홀 경로를 만들 수 있습니다.

Transit Gateway에 VPC를 연결할 때 트래픽이 Transit Gateway를 통해 라우팅되도록 경로를 서브넷 라우팅 테이블에 추가해야 합니다. 자세한 내용은 Amazon VPC 사용 설명서의 Transit Gateway에 대한 라우팅을 참조하세요.

라우팅 테이블 연결

Transit Gateway Attachment를 단일 라우팅 테이블과 연결할 수 있습니다. 각 라우팅 테이블은 0개 이상의 연결과 연결할 수 있으며 패킷을 다른 연결에 전달할 수 있습니다.

경로 전파

각 연결에는 하나 이상의 Transit Gateway 라우팅 테이블에 설치할 수 있는 경로가 있습니다. 연결이 Transit Gateway 라우팅 테이블에 전파되면 이러한 경로가 라우팅 테이블에 설치됩니다. 알려진 경로는 필터링할 수 없습니다.

VPC 연결의 경우 VPC의 CIDR 블록이 Transit Gateway 라우팅 테이블로 전파됩니다.

VPN 연결이나 Direct Connect 게이트웨이 연결과 함께 동적 라우팅이 사용되는 경우 BGP를 통해 온프레미스 라우터에서 학습한 경로를 Transit Gateway 라우팅 테이블로 전파할 수 있습니다.

VPN 연결과 함께 동적 라우팅을 사용하는 경우 VPN 연결과 연결된 라우팅 테이블의 경로가 BGP를 통해 고객 게이트웨이에 전달됩니다.

Connect 연결 파일의 경우 Connect 연결 파일과 연결된 라우팅 테이블의 경로가 BGP를 통해 VPC에서 실행되는 SD-WAN 어플라이언스와 같은 서드 파티 가상 어플라이언스에 전달됩니다.

Direct Connect 게이트웨이 연결의 경우 허용된 접두사 상호 작용은 고객 네트워크에 어떤 경로가 광고되는지 제어합니다 AWS.

정적 경로와 전파 경로의 대상이 동일한 경우 정적 경로의 우선순위가 높으므로 전파 경로는 라우팅 테이블에 포함되지 않습니다. 정적 경로를 제거하면 중복 전파 경로가 라우팅 테이블에 포함됩니다.

피어링 연결에 대한 라우팅

두 개의 Transit Gateway를 피어링하고 두 게이트웨이 간에 트래픽을 라우팅할 수 있습니다. 이렇게 하려면 Transit Gateway에서 피어링 연결을 생성하고 함께 피어링 연결을 생성할 피어 Transit Gateway를 지정해야 합니다. 그런 다음 Transit Gateway 라우팅 테이블에서 정적 경로를 생성하여 트래픽을 Transit Gateway 피어링 연결로 라우팅합니다. 피어 Transit Gateway로 라우팅된 트래픽은 피어 Transit Gateway에 대한 VPC 및 VPN 연결로 라우팅될 수 있습니다.

자세한 내용은 예: 피어링된 Transit Gateway 단원을 참조하세요.

경로 평가 순서

Transit Gateway 경로는 다음과 같은 순서로 평가됩니다.

대상 주소의 가장 구체적인 경로입니다.
CIDR은 동일하지만 연결 유형이 다른 경로의 경우 라우팅 우선 순위는 다음과 같습니다.
- 정적 경로(예: Site-to-Site VPN 정적 경로)
- 참조된 경로 접두사 목록
- VPC 전파 경로
- Direct Connect 게이트웨이 전파 경로
- 전송 게이트웨이 Connect 전파 경로
- 프라이빗 Direct Connect 전파 경로를 통한 Site-to-Site VPN
- Site-to-Site VPN 전파 경로
- 전송 게이트웨이 피어링 전파 경로(클라우드 WAN)

일부 첨부 파일은 BGP를 통한 라우팅 광고를 지원합니다. CIDR이 동일하고 연결 유형이 동일한 라우팅의 경우 라우팅 우선 순위는 BGP 속성으로 제어됩니다.

AS 경로 길이 단축
낮은 MED 값
연결에서 iBGP 라우팅을 지원하는 경우 eBGP가 iBGP 라우팅보다 선호됩니다.
중요
- AWS 는 위에 나열된 것과 동일한 CIDR, 연결 유형 및 BGP 속성을 가진 BGP 경로에 대해 일관된 경로 우선 순위 지정 순서를 보장할 수 없습니다.
- MED가 없는 전송 게이트웨이에 광고된 경로의 경우 AWS Transit Gateway는 다음 기본값을 할당합니다.
  
  Direct Connect 연결에 광고된 인바운드 경로의 경우 0입니다.
  
  VPN 및 Connect 연결에 광고된 인바운드 경로의 경우 100입니다.

AWS Transit Gateway는 기본 경로만 표시합니다. 백업 경로는 해당 경로가 더 이상 광고되지 않는 경우에만 Transit Gateway 라우팅 테이블에 표시됩니다. 예를 들어 Direct Connect 게이트웨이 및 Site-to-Site VPN을 통해 동일한 경로를 광고하는 경우 AWS . Transit Gateway는 기본 경로인 Direct Connect 게이트웨이 경로에서 수신한 경로만 표시합니다. 백업 경로인 Site-to-Site VPN은 Direct Connect 게이트웨이가 더 이상 광고되지 않는 경우에만 표시됩니다.

VPC 및 전송 게이트웨이 라우팅 테이블 차이

라우팅 테이블 평가는 VPC 라우팅 테이블을 사용할 때와 전송 게이트웨이 라우팅 테이블을 사용할 때가 다릅니다.

다음은 VPC 라우팅 테이블의 예입니다. VPC 로컬 경로는 우선순위가 가장 높으며, 그 다음은 가장 구체적인 경로입니다. 정적 경로와 전파 경로의 대상이 같은 경우, 정적 경로 우선순위가 더 높습니다.

대상 주소	대상	우선순위
10.0.0.0/16	로컬	1
192.168.0.0/16	pcx-12345	2
172.31.0.0/16	vgw-12345(정적) 또는 tgw-12345(정적)	2
172.31.0.0/16	vgw-12345(전파)	3
0.0.0.0/0	igw-12345	4

다음은 전송 게이트웨이 라우팅 테이블의 예입니다. VPN 연결보다 AWS Direct Connect 게이트웨이 연결을 사용하고 싶은 경우, BGP VPN 연결을 사용하고 Transit Gateway 라우팅 테이블의 경로를 전파합니다.

대상 주소	연결(대상)	리소스 유형	경로 유형	우선순위
10.0.0.0/16	tgw-attach-123 \| vpc-1234	VPC	정적 또는 전파	1
192.168.0.0/16	tgw-attach-789 \| vpn-5678	VPN	정적	2
172.31.0.0/16	tgw-attach-456 \| dxgw_id	AWS Direct Connect 게이트웨이	전파 완료	3
172.31.0.0/16	tgw-attach-789 \| tgw-connect-peer-123	연결	전파	4
172.31.0.0/16	tgw-attach-789 \| vpn-5678	VPN	전파 완료	5

전송 게이트웨이 시나리오 예

다음은 전송 게이트웨이의 일반적인 사용 사례입니다. 전송 게이트웨이는 이러한 사용 사례에만 국한되지 않습니다.

예시

Transit Gateway를 모든 VPC, AWS Direct Connect및 Site-to-Site VPN 연결을 연결하는 중앙 집중식 라우터로 구성할 수 있습니다. 이 시나리오에서는 모든 연결이 Transit Gateway 기본 라우팅 테이블과 연결되어 Transit Gateway 기본 라우팅 테이블에 전파됩니다. 따라서 모든 연결은 패킷을 서로 라우팅할 수 있으며 Transit Gateway는 단순한 계층 3 IP 라우터 역할을 합니다.

내용

개요
리소스
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. 이 시나리오에서는 Transit Gateway에 대한 VPC 연결 3개와 Site-to-Site VPN 연결 1개가 있습니다. 다른 VPC의 서브넷 또는 VPN 연결로 향하는 VPC A, VPC B 및 VPC C에 있는 서브넷의 패킷은 먼저 Transit Gateway를 통해 라우팅됩니다.

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
Transit Gateway의 VPC 연결 3개. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 각 VPC의 CIDR 블록이 전송 게이트웨이 라우팅 테이블에 전파됩니다. VPN 연결이 가동되면 BGP 세션이 설정되고 Site-to-Site VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 섹션을 참조하세요.

AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 Transit Gateway용 라우팅 테이블도 있습니다.

VPC 라우팅 테이블

각 VPC에는 항목 2개가 포함된 라우팅 테이블이 있습니다. 첫 번째 항목은 VPC의 로컬 IPv4 라우팅에 대한 기본 항목으로서, 이 VPC의 인스턴스가 서로 통신할 수 있게 해줍니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다. 다음 표에 VPC A 경로가 나와 있습니다.

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

다음은 라우팅 전파가 활성화된 이전 다이어그램의 연결에 대한 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파
10.99.99.0/24	`VPN 연결을 위한 연결`	전파

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

예: 중앙 집중식 라우터

내용

개요
리소스
라우팅

개요

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
Transit Gateway의 VPC 연결 3개. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 각 VPC의 CIDR 블록이 전송 게이트웨이 라우팅 테이블에 전파됩니다. VPN 연결이 가동되면 BGP 세션이 설정되고 Site-to-Site VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 섹션을 참조하세요.

AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 Transit Gateway용 라우팅 테이블도 있습니다.

VPC 라우팅 테이블

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

다음은 라우팅 전파가 활성화된 이전 다이어그램의 연결에 대한 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파
10.99.99.0/24	`VPN 연결을 위한 연결`	전파

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

전송 게이트웨이를 여러 격리된 라우터로 구성할 수 있습니다. 이는 여러 개의 Transit Gateway를 사용하는 것과 유사하지만 라우팅 및 연결이 변경될 수 있는 경우 더 많은 유연성을 제공합니다. 이 시나리오에서는 격리된 각 라우터에 단일 라우팅 테이블이 있습니다. 격리된 라우터와 연결된 모든 연결이 전파되어 해당 라우팅 테이블과 연결됩니다. 하나의 격리된 라우터와 연결된 경우 패킷을 서로 라우팅할 수 있지만, 격리된 다른 라우터에 연결된 경우 패킷을 라우팅하거나 수신할 수 없습니다.

내용

개요
리소스
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. VPC A, VPC B, VPC C의 패킷은 Transit Gateway로 라우팅됩니다. 인터넷이 대상인 VPC A, VPC B, VPC C에 있는 서브넷의 패킷은 먼저 Transit Gateway를 통해 라우팅된 후 Site-to-Site VPN 연결로 라우팅됩니다(대상이 해당 네트워크 내에 있는 경우). 대상이 다른 VPC의 서브넷인 한 VPC의 패킷(예: 10.1.0.0~10.2.0.0)은 Transit Gateway를 통해 라우팅되고, Transit Gateway 라우팅 테이블에 해당 경로가 없으므로 차단됩니다.

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
VPC 3개에 대한 Transit Gateway의 연결 3개. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오. AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

VPN 연결이 가동되면 BGP 세션이 설정되고 VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

라우팅

각 VPC에는 라우팅 테이블 하나가 있으며 Transit Gateway에는 라우팅 테이블 두 개가 있습니다. 하나는 VPC용이며 다른 하나는 VPN 연결용입니다.

VPC A, VPC B 및 VPC C 라우팅 테이블

각 VPC에는 항목 2개가 포함된 라우팅 테이블이 있습니다. 첫 번째 항목은 VPC의 로컬 IPv4 라우팅에 대한 기본 항목입니다. 이 항목을 사용하면 이 VPC의 인스턴스가 서로 통신할 수 있습니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다. 다음 표에 VPC A 경로가 나와 있습니다.

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

이 시나리오에서는 VPC에 대한 라우팅 테이블 하나와 VPN 연결에 대한 라우팅 테이블 하나를 사용합니다.

VPC 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 VPN 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`VPN 연결을 위한 연결`	전파

VPC 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 각 VPN 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파

전송 게이트웨이 라우팅 테이블에서 라우팅을 전파하는 방법에 대한 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 라우팅 테이블에 대한 라우팅 전파 활성화을 참조하십시오.

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

예: 격리된 VPC

내용

개요
리소스
라우팅

개요

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
VPC 3개에 대한 Transit Gateway의 연결 3개. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오. AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

VPN 연결이 가동되면 BGP 세션이 설정되고 VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

라우팅

각 VPC에는 라우팅 테이블 하나가 있으며 Transit Gateway에는 라우팅 테이블 두 개가 있습니다. 하나는 VPC용이며 다른 하나는 VPN 연결용입니다.

VPC A, VPC B 및 VPC C 라우팅 테이블

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

이 시나리오에서는 VPC에 대한 라우팅 테이블 하나와 VPN 연결에 대한 라우팅 테이블 하나를 사용합니다.

VPC 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 VPN 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`VPN 연결을 위한 연결`	전파

VPC 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 각 VPN 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

Transit Gateway를 공유 서비스를 사용하는 여러 격리된 라우터로 구성할 수 있습니다. 이는 여러 개의 Transit Gateway를 사용하는 것과 유사하지만 라우팅 및 연결이 변경될 수 있는 경우 더 많은 유연성을 제공합니다. 이 시나리오에서는 격리된 각 라우터에 단일 라우팅 테이블이 있습니다. 격리된 라우터와 연결된 모든 연결이 전파되어 해당 라우팅 테이블과 연결됩니다. 하나의 격리된 라우터와 연결된 경우 패킷을 서로 라우팅할 수 있지만, 격리된 다른 라우터에 연결된 경우 패킷을 라우팅하거나 수신할 수 없습니다. 연결은 공유 서비스로 패킷을 라우팅하거나 공유 서비스에서 패킷을 수신할 수 있습니다. 격리해야 하는 그룹이 있지만 공유 서비스(예: 프로덕션 시스템)를 사용하는 경우 이 시나리오를 사용할 수 있습니다.

내용

개요
리소스
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. 인터넷이 대상인 VPC A, VPC B 및 VPC C에 있는 서브넷의 패킷은 먼저 Transit Gateway를 통해 라우팅된 후 Site-to-Site VPN을 위한 고객 게이트웨이로 라우팅됩니다. 대상이 VPC A, VPC B 또는 VPC C의 서브넷인 VPC A, VPC B 또는 VPC C에 있는 서브넷의 패킷은 Transit Gateway를 통해 라우팅되지만, Transit Gateway 라우팅 테이블에 경로가 없어 차단됩니다. 대상이 VPC D인 VPC A, VPC B, VPC C의 패킷은 Transit Gateway를 통해 라우팅된 후 VPC D로 라우팅됩니다.

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 4개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
전송 게이트웨이. 자세한 내용은 Transit Gateway 생성을 참조하십시오.
Transit Gateway의 VPC 연결 3개(VPC당 1개). 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오.

AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

VPN 연결이 가동되면 BGP 세션이 설정되고 VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

각 격리된 VPC는 격리된 라우팅 테이블과 연결되고 공유된 라우팅 테이블로 전파됩니다.
각 공유된 서비스 VPC는 공유된 라우팅 테이블과 연결되고 두 라우팅 테이블로 전파됩니다.

라우팅

각 VPC에는 라우팅 테이블 하나가 있으며 Transit Gateway에는 라우팅 테이블 두 개가 있습니다. 하나는 VPC용이며 다른 하나는 VPN 연결 및 공유 서비스 VPC용입니다.

VPC A, VPC B, VPC C, VPC D 라우팅 테이블

각 VPC에는 항목 2개가 포함된 라우팅 테이블이 있습니다. 첫 번째 항목은 VPC의 로컬 라우팅에 대한 기본 항목으로서, 이 VPC의 인스턴스가 서로 통신할 수 있게 해줍니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다.

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	`Transit Gateway ID`

Transit Gateway 라우팅 테이블

이 시나리오에서는 VPC에 대한 라우팅 테이블 하나와 VPN 연결에 대한 라우팅 테이블 하나를 사용합니다.

VPC A, B 및 C 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 VPN 연결에 대한 전파된 라우팅과 VPC D의 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`VPN 연결을 위한 연결`	전파
10.4.0.0/16	`VPC D 연결`	전파

VPN 연결 및 공유 서비스 VPC(VPC D) 연결은 각 VPC 연결을 가리키는 항목이 있는 다음 라우팅 테이블과 연결됩니다. 이렇게 하면 VPN 연결 및 공유 서비스 VPC에서 VPC와 통신할 수 있습니다.

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파

자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 라우팅 테이블에 대한 라우팅 전파 활성화 단원을 참조하십시오.

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 4개의 VPC 모두에 대한 CIDR이 포함되어 있습니다.

예: 공유 서비스를 사용하는 격리된 VPC

내용

개요
리소스
라우팅

개요

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 4개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
전송 게이트웨이. 자세한 내용은 Transit Gateway 생성을 참조하십시오.
Transit Gateway의 VPC 연결 3개(VPC당 1개). 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오.

AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.

VPN 연결이 가동되면 BGP 세션이 설정되고 VPN CIDR이 Transit Gateway 라우팅 테이블로 전파되며 VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

각 격리된 VPC는 격리된 라우팅 테이블과 연결되고 공유된 라우팅 테이블로 전파됩니다.
각 공유된 서비스 VPC는 공유된 라우팅 테이블과 연결되고 두 라우팅 테이블로 전파됩니다.

라우팅

VPC A, VPC B, VPC C, VPC D 라우팅 테이블

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	`Transit Gateway ID`

Transit Gateway 라우팅 테이블

이 시나리오에서는 VPC에 대한 라우팅 테이블 하나와 VPN 연결에 대한 라우팅 테이블 하나를 사용합니다.

VPC A, B 및 C 연결은 다음 라우팅 테이블과 연결되며, 해당 테이블에는 VPN 연결에 대한 전파된 라우팅과 VPC D의 연결에 대한 전파된 라우팅이 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`VPN 연결을 위한 연결`	전파
10.4.0.0/16	`VPC D 연결`	전파

대상 주소	대상	경로 유형
10.1.0.0/16	`VPC A 연결`	전파
10.2.0.0/16	`VPC B 연결`	전파
10.3.0.0/16	`VPC C 연결`	전파

자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 라우팅 테이블에 대한 라우팅 전파 활성화 단원을 참조하십시오.

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 4개의 VPC 모두에 대한 CIDR이 포함되어 있습니다.

Transit Gateway 간에 Transit Gateway 피어링 연결을 생성할 수 있습니다. 그런 다음 각 Transit Gateway 연결 간에 트래픽을 라우팅할 수 있습니다. 이 시나리오에서는 VPC 및 VPN 연결이 Transit Gateway 기본 라우팅 테이블과 연결되어 Transit Gateway 기본 라우팅 테이블에 전파됩니다. 각 Transit Gateway 라우팅 테이블에는 Transit Gateway 피어링 연결을 가리키는 정적 라우팅이 있습니다.

내용

개요
리소스
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. Transit Gateway 1에는 두 개의 VPC 연결이 있고, Transit Gateway 2에는 하나의 Site-to-Site VPN 연결이 있습니다. 인터넷이 대상인 VPC A 및 VPC B에 있는 서브넷의 패킷은 Transit Gateway 1, Transit Gateway 2, VPN 연결 순으로 라우팅됩니다.

두 개의 피어링된 트랜짓 게이트웨이(하나는 두 개의 VPC 연결이 있고 다른 하나는 VPN 연결이 있는 게이트웨이)

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 2개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
두 개의 전송 게이트웨이. 이들은 동일한 리전에 있거나 서로 다른 리전에 있을 수 있습니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
첫 번째 Transit Gateway에 두 개의 VPC 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
두 번째 Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오. AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.
두 Transit Gateway 간의 Transit Gateway 피어링 연결. 자세한 내용은 Amazon VPC Transit Gateways의 전송 게이트웨이 피어링 연결 단원을 참조하십시오.

VPC 연결을 생성할 때 각 VPC의 CIDR이 Transit Gateway 1의 라우팅 테이블에 전파됩니다. VPN 연결이 작동 중이면 다음 작업이 수행됩니다.

BGP 세션이 설정됩니다.
Site-to-Site VPN CIDR이 Transit Gateway 2의 라우팅 테이블로 전파됩니다.
VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 각 Transit Gateway에는 라우팅 테이블이 있습니다.

VPC A 및 VPC B 라우팅 테이블

각 VPC에는 항목 2개가 포함된 라우팅 테이블이 있습니다. 첫 번째 항목은 VPC의 로컬 IPv4 라우팅에 대한 기본 항목입니다. 이 기본 항목을 사용하면 이 VPC의 리소스가 서로 통신할 수 있습니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다. 다음 표에 VPC A 경로가 나와 있습니다.

대상 주소	대상
10.0.0.0/16	로컬
0.0.0.0/0	tgw-1-id

Transit Gateway 라우팅 테이블

다음은 라우팅 전파가 활성화된 Transit Gateway 1의 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
10.0.0.0/16	`VPC A의 연결 ID`	전파
10.2.0.0/16	`VPC B의 연결 ID`	전파
0.0.0.0/0	`피어링 연결용 연결 ID`	고정

다음은 라우팅 전파가 활성화된 Transit Gateway 2의 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
172.31.0.0/24	`VPN 연결을 위한 연결 ID`	전파
10.0.0.0/16	`피어링 연결용 연결 ID`	정적
10.2.0.0/16	`피어링 연결용 연결 ID`	정적

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.0.0.0/16
10.2.0.0/16

예: 피어링된 Transit Gateway

내용

개요
리소스
라우팅

개요

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 2개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
두 개의 전송 게이트웨이. 이들은 동일한 리전에 있거나 서로 다른 리전에 있을 수 있습니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하십시오.
첫 번째 Transit Gateway에 두 개의 VPC 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
두 번째 Transit Gateway의 Site-to-Site VPN 연결. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPN에 대한 Transit Gateway Attachment 생성 단원을 참조하십시오. AWS Site-to-Site VPN 사용 설명서의 고객 게이트웨이 디바이스 요구 사항을 검토해야 합니다.
두 Transit Gateway 간의 Transit Gateway 피어링 연결. 자세한 내용은 Amazon VPC Transit Gateways의 전송 게이트웨이 피어링 연결 단원을 참조하십시오.

VPC 연결을 생성할 때 각 VPC의 CIDR이 Transit Gateway 1의 라우팅 테이블에 전파됩니다. VPN 연결이 작동 중이면 다음 작업이 수행됩니다.

BGP 세션이 설정됩니다.
Site-to-Site VPN CIDR이 Transit Gateway 2의 라우팅 테이블로 전파됩니다.
VPC CIDR이 고객 게이트웨이 BGP 테이블에 추가됩니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 각 Transit Gateway에는 라우팅 테이블이 있습니다.

VPC A 및 VPC B 라우팅 테이블

대상 주소	대상
10.0.0.0/16	로컬
0.0.0.0/0	tgw-1-id

Transit Gateway 라우팅 테이블

다음은 라우팅 전파가 활성화된 Transit Gateway 1의 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
10.0.0.0/16	`VPC A의 연결 ID`	전파
10.2.0.0/16	`VPC B의 연결 ID`	전파
0.0.0.0/0	`피어링 연결용 연결 ID`	고정

다음은 라우팅 전파가 활성화된 Transit Gateway 2의 기본 라우팅 테이블의 예입니다.

대상 주소	대상	경로 유형
172.31.0.0/24	`VPN 연결을 위한 연결 ID`	전파
10.0.0.0/16	`피어링 연결용 연결 ID`	정적
10.2.0.0/16	`피어링 연결용 연결 ID`	정적

고객 게이트웨이 BGP 테이블

고객 게이트웨이 BGP 테이블에는 다음과 같은 VPC CIDR이 포함되어 있습니다.

10.0.0.0/16
10.2.0.0/16

인터넷 게이트웨이 없이 VPC에서 NAT 게이트웨이와 인터넷 게이트웨이가 포함된 VPC로 아웃바운드 인터넷 트래픽을 라우팅하도록 전송 게이트웨이를 구성할 수 있습니다.

내용

개요
리소스
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. 아웃바운드 전용 인터넷 액세스가 필요한 여러 VPC A 및 VPC B에 애플리케이션이 있습니다. VPC C는 퍼블릭 NAT 게이트웨이와 인터넷 게이트웨이 및 VPC 연결에 대한 프라이빗 서브넷으로 구성합니다. 전송 게이트웨이에 모든 VPC를 연결합니다. VPC A 및 VPC B에서 아웃바운드 인터넷 트래픽이 전송 게이트웨이를 VPC C로 통과하도록 라우팅을 구성합니다. VPC C의 NAT 게이트웨이는 트래픽을 인터넷 게이트웨이로 라우팅합니다.

한 개의 Transit Gateway에는 VPC 연결 세 개가 있습니다.

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

IP 주소 범위가 겹치지 않는 VPC 3개입니다. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
VPC A와 VPC B에는 각각 EC2 인스턴스가 있는 프라이빗 서브넷이 있습니다.
VPC C에는 다음과 같은 기능이 있습니다.
- VPC에 인터넷 게이트웨이 연결 자세한 내용은 Amazon VPC 사용 설명서의 인터넷 게이트웨이 생성 및 연결을 참조하세요.
- NAT 게이트웨이를 포함한 퍼블릭 서브넷. 자세한 내용은 Amazon VPC 사용 설명서의 NAT 게이트웨이 생성을 참조하세요.
- Transit Gateway Attachment를 위한 프라이빗 서브넷. 프라이빗 서브넷은 퍼블릭 서브넷과 같은 가용 영역에 있어야 합니다.
하나의 전송 게이트웨이입니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 섹션을 참조하세요.
Transit Gateway의 VPC 연결 3개. 각 VPC의 CIDR 블록이 전송 게이트웨이 라우팅 테이블에 전파됩니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오. VPC C의 경우, 프라이빗 서브넷을 사용해 연결을 생성해야 합니다. 퍼블릭 서브넷을 사용해 연결을 생성하면 인스턴스 트래픽이 인터넷 게이트웨이로 라우팅되지만, 인스턴스에 퍼블릭 IP 주소가 없기 때문에 인터넷 게이트웨이가 트래픽을 삭제합니다. 연결을 프라이빗 서브넷에 배치해야 트래픽이 NAT 게이트웨이로 라우팅되고, NAT 게이트웨이가 자체 탄력적 IP 주소를 소스 IP 주소로 사용하여 해당 트래픽을 인터넷 게이트웨이로 보냅니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 전송 게이트웨이용 라우팅 테이블도 있습니다.

라우팅 테이블

VPC A
VPC B
VPC C
Transit Gateway

VPC A의 라우팅 테이블

다음은 라우팅 테이블의 예입니다. 첫 번째 항목을 사용하면 VPC의 인스턴스가 서로 통신할 수 있습니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다.

대상 주소	대상
`VPC A CIDR`	로컬
0.0.0.0/0	`transit-gateway-id`

VPC B의 라우팅 테이블

대상 주소	대상
`VPC B CIDR`	로컬
0.0.0.0/0	`transit-gateway-id`

VPC C의 라우팅 테이블

인터넷 게이트웨이에 경로를 추가하여 NAT 게이트웨이를 퍼블릭 서브넷으로 서브넷을 구성합니다. 다른 서브넷은 프라이빗 서브넷으로 둡니다.

다음은 퍼블릭 서브넷의 라우팅 테이블 예입니다. 첫 번째 항목을 사용하면 VPC의 인스턴스가 서로 통신할 수 있습니다. 두 번째 및 세 번째 항목은 VPC A 및 VPC B에 대한 트래픽을 전송 게이트웨이로 라우팅합니다. 남은 항목에서는 기타 IPv4 서브넷 트래픽을 모두 인터넷 게이트웨이로 라우팅합니다.

대상 주소	대상
`VPC C CIDR`	로컬
`VPC A CIDR`	`transit-gateway-id`
`VPC B CIDR`	`transit-gateway-id`
0.0.0.0/0	`internet-gateway-id`

다음은 프라이빗 서브넷의 라우팅 테이블 예입니다. 첫 번째 항목을 사용하면 VPC의 인스턴스가 서로 통신할 수 있습니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 NAT 게이트웨이로 라우팅합니다.

대상 주소	대상
`VPC C CIDR`	로컬
0.0.0.0/0	`nat-gateway-id`

Transit Gateway 라우팅 테이블

다음은 Transit Gateway 라우팅 테이블의 예입니다. 각 VPC의 CIDR 블록이 Transit Gateway 라우팅 테이블에 전파됩니다. 정적 라우팅은 아웃바운드 인터넷 트래픽을 VPC C로 보냅니다. 필요에 따라 각 VPC CIDR에 블랙홀 경로를 추가하여 VPC 간 통신을 방지할 수 있습니다.

CIDR	연결	경로 유형
`VPC A CIDR`	`VPC A 연결`	전파
`VPC B CIDR`	`VPC B 연결`	전파
`VPC C CIDR`	`VPC C 연결`	전파
0.0.0.0/0	`VPC C 연결`	정적

예: 인터넷으로의 중앙 집중식 아웃바운드 라우팅

내용

개요
리소스
라우팅

개요

리소스

이 시나리오에서는 다음 리소스를 생성합니다.

IP 주소 범위가 겹치지 않는 VPC 3개입니다. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
VPC A와 VPC B에는 각각 EC2 인스턴스가 있는 프라이빗 서브넷이 있습니다.
VPC C에는 다음과 같은 기능이 있습니다.
- VPC에 인터넷 게이트웨이 연결 자세한 내용은 Amazon VPC 사용 설명서의 인터넷 게이트웨이 생성 및 연결을 참조하세요.
- NAT 게이트웨이를 포함한 퍼블릭 서브넷. 자세한 내용은 Amazon VPC 사용 설명서의 NAT 게이트웨이 생성을 참조하세요.
- Transit Gateway Attachment를 위한 프라이빗 서브넷. 프라이빗 서브넷은 퍼블릭 서브넷과 같은 가용 영역에 있어야 합니다.
하나의 전송 게이트웨이입니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 섹션을 참조하세요.
Transit Gateway의 VPC 연결 3개. 각 VPC의 CIDR 블록이 전송 게이트웨이 라우팅 테이블에 전파됩니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오. VPC C의 경우, 프라이빗 서브넷을 사용해 연결을 생성해야 합니다. 퍼블릭 서브넷을 사용해 연결을 생성하면 인스턴스 트래픽이 인터넷 게이트웨이로 라우팅되지만, 인스턴스에 퍼블릭 IP 주소가 없기 때문에 인터넷 게이트웨이가 트래픽을 삭제합니다. 연결을 프라이빗 서브넷에 배치해야 트래픽이 NAT 게이트웨이로 라우팅되고, NAT 게이트웨이가 자체 탄력적 IP 주소를 소스 IP 주소로 사용하여 해당 트래픽을 인터넷 게이트웨이로 보냅니다.

라우팅

각 VPC에는 라우팅 테이블이 있고 전송 게이트웨이용 라우팅 테이블도 있습니다.

라우팅 테이블

VPC A
VPC B
VPC C
Transit Gateway

VPC A의 라우팅 테이블

대상 주소	대상
`VPC A CIDR`	로컬
0.0.0.0/0	`transit-gateway-id`

VPC B의 라우팅 테이블

대상 주소	대상
`VPC B CIDR`	로컬
0.0.0.0/0	`transit-gateway-id`

VPC C의 라우팅 테이블

인터넷 게이트웨이에 경로를 추가하여 NAT 게이트웨이를 퍼블릭 서브넷으로 서브넷을 구성합니다. 다른 서브넷은 프라이빗 서브넷으로 둡니다.

대상 주소	대상
`VPC C CIDR`	로컬
`VPC A CIDR`	`transit-gateway-id`
`VPC B CIDR`	`transit-gateway-id`
0.0.0.0/0	`internet-gateway-id`

대상 주소	대상
`VPC C CIDR`	로컬
0.0.0.0/0	`nat-gateway-id`

Transit Gateway 라우팅 테이블

CIDR	연결	경로 유형
`VPC A CIDR`	`VPC A 연결`	전파
`VPC B CIDR`	`VPC B 연결`	전파
`VPC C CIDR`	`VPC C 연결`	전파
0.0.0.0/0	`VPC C 연결`	정적

공유 서비스 VPC에 있는 어플라이언스(예: 보안 어플라이언스)를 구성할 수 있습니다. Transit Gateway Attachment 간에 라우팅되는 모든 트래픽은 먼저 공유 서비스 VPC의 어플라이언스에서 검사합니다. 어플라이언스 모드가 활성화되면 Transit Gateway는 흐름 해시 알고리즘을 사용하여 어플라이언스 VPC에서 단일 네트워크 인터페이스를 선택하여 흐름 수명 동안 트래픽을 전송합니다. Transit Gateway는 반환 트래픽에 대해 동일한 네트워크 인터페이스를 사용합니다. 이렇게 하면 양방향 트래픽이 대칭적으로 라우팅됩니다. 즉, 트래픽 흐름은 수명이 다할 때까지 VPC 연결의 동일한 가용 영역을 통해 라우팅됩니다. 아키텍처에 여러 Transit Gateway가 있는 경우 각 Transit Gateway는 자체 세션 선호도를 유지하며 각 Transit Gateway는 다른 네트워크 인터페이스를 선택할 수 있습니다.

흐름 안정성을 보장하려면 정확히 하나의 전송 게이트웨이를 어플라이언스 VPC에 연결해야 합니다. 여러 전송 게이트웨이를 단일 어플라이언스 VPC에 연결해도 전송 게이트웨이가 흐름 상태 정보를 서로 공유하지 않기 때문에 흐름 안정성이 보장되지 않습니다.

중요

소스 및 대상 트래픽이 동일한 Transit Gateway Attachment에서 중앙 VPC(검사 VPC)로 들어오는 한 어플라이언스 모드의 트래픽은 올바르게 라우팅됩니다. 소스와 대상이 서로 다른 두 Transit Gateway Attachment에 있으면 트래픽이 하락할 수도 있습니다. 중앙 집중식 VPC가 인터넷 게이트웨이와 같은 다른 게이트웨이에서 트래픽을 수신한 다음 검사 후 해당 트래픽을 Transit Gateway Attachment로 전송하는 경우 트래픽이 하락할 수도 있습니다.
기존 연결에서 어플라이언스 모드를 활성화하면 연결은 가용 영역을 통해 흐를 수 있으므로 해당 연결의 현재 경로에 영향을 미칠 수 있습니다. 어플라이언스 모드가 활성화되지 않은 경우 트래픽은 원래 가용 영역으로 유지됩니다.

내용

개요
상태 저장 어플라이언스 및 어플라이언스 모드
라우팅

개요

다음 다이어그램은 이 시나리오를 위한 구성의 주요 구성 요소를 보여줍니다. Transit Gateway에는 VPC 연결 3개가 있습니다. VPC C는 공유 서비스 VPC입니다. VPC A와 VPC B 간의 트래픽은 Transit Gateway로 라우팅되며, 검사를 위해 VPC C의 보안 어플라이언스로 라우팅된 다음 최종 대상으로 라우팅됩니다. 어플라이언스는 상태 저장 장치이므로 요청 트래픽과 응답 트래픽을 모두 검사합니다. 고가용성을 위해 VPC C의 각 가용 영역에 어플라이언스가 있습니다.

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하세요.
VPC 연결 3개 - 각 VPC에 하나씩 존재합니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하세요.

각 VPC 연결의 각 가용 영역에 서브넷을 지정합니다. 공유 서비스 VPC의 경우에는 트래픽이 Transit Gateway에서 VPC로 라우팅되는 서브넷을 지정해야 합니다. 앞의 예에서는 서브넷 A와 C가 여기에 해당합니다.

VPC C에 대한 VPC 연결의 경우에는 어플라이언스 모드 지원을 활성화하여 응답 트래픽이 소스 트래픽과 같은 VPC C의 가용 영역으로 라우팅되게 해야 합니다.

Amazon VPC 콘솔은 어플라이언스 모드를 지원합니다. Amazon VPC API, AWS SDK,를 사용하여 어플라이언스 모드를 AWS CLI 활성화할 수도 있습니다 AWS CloudFormation. 예를 들어 create-transit-gateway-vpc-attachment 또는 modify-transit-gateway-vpc-attachment 명령에 --options ApplianceModeSupport=enable를 추가합니다.

참고

어플라이언스 모드의 흐름 안정성은 검사 VPC를 향해 발생하는 소스 및 대상 트래픽에 대해서만 보장됩니다.

상태 저장 어플라이언스 및 어플라이언스 모드

VPC 연결이 여러 가용 영역에 걸쳐 있고 상태 저장 검사를 위해 소스 및 대상 호스트 간의 트래픽을 동일한 어플라이언스를 통해 라우팅해야하는 경우, 어플라이언스가 있는 VPC 연결에 대한 어플라이언스 모드 지원을 활성화합니다.

자세한 내용은 AWS 블로그의 중앙 집중식 검사 아키텍처를 참조하세요.

어플라이언스 모드가 활성화되지 않은 경우의 동작

어플라이언스 모드가 활성화되지 않은 경우, Transit Gateway는 대상에 도달할 때까지 트래픽이 원래 가용 영역의 VPC 연결 간에 라우팅을 유지하려고 합니다. 트래픽은 가용 영역 장애가 있거나 가용 영역에 VPC 연결과 연결된 서브넷이 없는 경우에만 연결 사이의 가용 영역을 지납니다.

다음 다이어그램은 어플라이언스 모드 지원이 활성화되지 않은 경우의 트래픽 흐름을 보여 줍니다. VPC B의 가용 영역 2에서 시작된 응답 트래픽은 Transit Gateway에 의해 VPC C의 동일한 가용 영역으로 라우팅됩니다. 따라서 가용 영역 2의 어플라이언스가 VPC A에 있는 소스의 원래 요청을 인식하지 못하기 때문에 트래픽이 삭제됩니다.

라우팅

각 VPC에는 하나 이상의 라우팅 테이블이 있고 Transit Gateway에는 라우팅 테이블 두 개가 있습니다.

VPC 라우팅 테이블

VPC A 및 VPC B

VPC A와 B에는 항목 두 개가 있는 라우팅 테이블이 있습니다. 첫 번째 항목은 VPC의 로컬 IPv4 라우팅에 대한 기본 항목입니다. 이 기본 항목을 사용하면 이 VPC의 리소스가 서로 통신할 수 있습니다. 두 번째 항목은 기타 IPv4 서브넷 트래픽을 모두 Transit Gateway로 라우팅합니다. 다음은 VPC A의 라우팅 테이블입니다.

대상 주소	대상
10.0.0.0/16	로컬
0.0.0.0/0	tgw-id

VPC C

공유 서비스 VPC(VPC C)에는 서브넷마다 다른 라우팅 테이블이 있습니다. 서브넷 A는 Transit Gateway서 사용합니다(VPC 연결을 만들 때 이 서브넷을 지정합니다). 서브넷 A의 라우팅 테이블은 모든 트래픽을 서브넷 B의 어플라이언스로 라우팅합니다.

대상 주소	대상
192.168.0.0/16	로컬
0.0.0.0/0	appliance-eni-id

(어플라이언스가 있는) 서브넷 B에 대한 라우팅 테이블은 트래픽을 Transit Gateway로 돌려보냅니다.

대상 주소	대상
192.168.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

이 Transit Gateway는 VPC A 및 VPC B에 하나의 라우팅 테이블을, 공유 서비스 VPC(VPC C)에 하나의 라우팅 테이블을 사용합니다.

VPC A 및 VPC B 연결은 다음 라우팅 테이블과 연결됩니다. 라우팅 테이블은 모든 트래픽을 VPC C로 라우팅합니다.

대상 주소	대상	경로 유형
0.0.0.0/0	`VPC C의 연결 ID`	고정

VPC C 연결은 다음 라우팅 테이블과 연결됩니다. 이 연결은 트래픽을 VPC A와 VPC B로 라우팅합니다.

대상 주소	대상	경로 유형
10.0.0.0/16	`VPC A의 연결 ID`	전파
10.1.0.0/16	`VPC B의 연결 ID`	전파

예: 공유 서비스 VPC의 어플라이언스

중요

소스 및 대상 트래픽이 동일한 Transit Gateway Attachment에서 중앙 VPC(검사 VPC)로 들어오는 한 어플라이언스 모드의 트래픽은 올바르게 라우팅됩니다. 소스와 대상이 서로 다른 두 Transit Gateway Attachment에 있으면 트래픽이 하락할 수도 있습니다. 중앙 집중식 VPC가 인터넷 게이트웨이와 같은 다른 게이트웨이에서 트래픽을 수신한 다음 검사 후 해당 트래픽을 Transit Gateway Attachment로 전송하는 경우 트래픽이 하락할 수도 있습니다.
기존 연결에서 어플라이언스 모드를 활성화하면 연결은 가용 영역을 통해 흐를 수 있으므로 해당 연결의 현재 경로에 영향을 미칠 수 있습니다. 어플라이언스 모드가 활성화되지 않은 경우 트래픽은 원래 가용 영역으로 유지됩니다.

내용

개요
상태 저장 어플라이언스 및 어플라이언스 모드
라우팅

개요

이 시나리오에서는 다음 리소스를 생성합니다.

VPC 3개. 자세한 내용은 Amazon VPC 사용 설명서의 VPC 생성을 참조하세요.
Transit Gateway. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 전송 게이트웨이 생성 단원을 참조하세요.
VPC 연결 3개 - 각 VPC에 하나씩 존재합니다. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하세요.

각 VPC 연결의 각 가용 영역에 서브넷을 지정합니다. 공유 서비스 VPC의 경우에는 트래픽이 Transit Gateway에서 VPC로 라우팅되는 서브넷을 지정해야 합니다. 앞의 예에서는 서브넷 A와 C가 여기에 해당합니다.

VPC C에 대한 VPC 연결의 경우에는 어플라이언스 모드 지원을 활성화하여 응답 트래픽이 소스 트래픽과 같은 VPC C의 가용 영역으로 라우팅되게 해야 합니다.

Amazon VPC 콘솔은 어플라이언스 모드를 지원합니다. Amazon VPC API, AWS SDK,를 사용하여 어플라이언스 모드를 AWS CLI 활성화할 수도 있습니다 AWS CloudFormation. 예를 들어 create-transit-gateway-vpc-attachment 또는 modify-transit-gateway-vpc-attachment 명령에 --options ApplianceModeSupport=enable를 추가합니다.

참고

어플라이언스 모드의 흐름 안정성은 검사 VPC를 향해 발생하는 소스 및 대상 트래픽에 대해서만 보장됩니다.

상태 저장 어플라이언스 및 어플라이언스 모드

자세한 내용은 AWS 블로그의 중앙 집중식 검사 아키텍처를 참조하세요.

어플라이언스 모드가 활성화되지 않은 경우의 동작

라우팅

각 VPC에는 하나 이상의 라우팅 테이블이 있고 Transit Gateway에는 라우팅 테이블 두 개가 있습니다.

VPC 라우팅 테이블

VPC A 및 VPC B

대상 주소	대상
10.0.0.0/16	로컬
0.0.0.0/0	tgw-id

VPC C

대상 주소	대상
192.168.0.0/16	로컬
0.0.0.0/0	appliance-eni-id

(어플라이언스가 있는) 서브넷 B에 대한 라우팅 테이블은 트래픽을 Transit Gateway로 돌려보냅니다.

대상 주소	대상
192.168.0.0/16	로컬
0.0.0.0/0	tgw-id

Transit Gateway 라우팅 테이블

이 Transit Gateway는 VPC A 및 VPC B에 하나의 라우팅 테이블을, 공유 서비스 VPC(VPC C)에 하나의 라우팅 테이블을 사용합니다.

VPC A 및 VPC B 연결은 다음 라우팅 테이블과 연결됩니다. 라우팅 테이블은 모든 트래픽을 VPC C로 라우팅합니다.

대상 주소	대상	경로 유형
0.0.0.0/0	`VPC C의 연결 ID`	고정

VPC C 연결은 다음 라우팅 테이블과 연결됩니다. 이 연결은 트래픽을 VPC A와 VPC B로 라우팅합니다.

대상 주소	대상	경로 유형
10.0.0.0/16	`VPC A의 연결 ID`	전파
10.1.0.0/16	`VPC B의 연결 ID`	전파

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

Amazon VPC Transit Gateways란?

전송 게이트웨이 시작하기

이 페이지에서

쿠키 기본 설정 선택

Amazon VPC Transit Gateways의 작동 원리

주제

아키텍처 다이어그램 예제

리소스 연결

Equal Cost Multipath 라우팅

참고

가용 영역

어플라이언스 모드 지원 사용

라우팅

라우팅 주제

라우팅 테이블

라우팅 테이블 연결

경로 전파

피어링 연결에 대한 라우팅

경로 평가 순서

중요

VPC 및 전송 게이트웨이 라우팅 테이블 차이

전송 게이트웨이 시나리오 예

예시

내용

개요

리소스

라우팅

VPC 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 중앙 집중식 라우터

내용

개요

리소스

라우팅

VPC 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

내용

개요

리소스

라우팅

VPC A, VPC B 및 VPC C 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 격리된 VPC

내용

개요

리소스

라우팅

VPC A, VPC B 및 VPC C 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

내용

개요

리소스

라우팅

VPC A, VPC B, VPC C, VPC D 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 공유 서비스를 사용하는 격리된 VPC

내용

개요

리소스

라우팅

VPC A, VPC B, VPC C, VPC D 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

내용

개요

리소스

라우팅

VPC A 및 VPC B 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 피어링된 Transit Gateway

내용

개요

리소스

라우팅

VPC A 및 VPC B 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블