Amazon VPC Transit Gateway의 작동 방식

포커스 모드

Amazon VPC Transit Gateway의 작동 방식 - Amazon VPC

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

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

아키텍처 다이어그램 예제

다음 다이어그램은 세 개의 VPC 첨부 파일이 있는 전송 게이트웨이를 보여줍니다. 각 경로 테이블에는 로컬 경로와 다른 두 경로로 향하는 트래픽을 전송 게이트웨이VPCs로 보내는 경로가 VPCs 포함됩니다.

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

대상 주소	대상	경로 유형
`VPC A CIDR`	`Attachment for VPC A`	전파
`VPC B CIDR`	`Attachment for VPC B`	전파
`VPC C CIDR`	`Attachment for 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는 대부분의 연결에 대해 Equal Cost Multipath(ECMP) 라우팅을 지원합니다. VPN 연결의 경우 전송 게이트웨이를 생성하거나 수정할 때 콘솔을 사용하여 ECMP 지원을 활성화하거나 비활성화할 수 있습니다. 다른 모든 연결 유형에는 다음 ECMP 제한이 적용됩니다.

VPC - CIDR 블록VPC이 겹칠 수 ECMP 없으므로는를 지원하지 않습니다. 예를 들어 CIDR10.1.0.0/16VPC을 VPC 사용하여를 초 단위로 전송 게이트웨이CIDR에 연결한 다음 라우팅을 설정하여 이들 간에 트래픽을 로드 밸런싱할 수 없습니다.
VPN - VPN ECMP 지원 옵션이 비활성화된 경우 전송 게이트웨이는 내부 지표를 사용하여 여러 경로에 동일한 접두사가 있는 경우 기본 경로를 결정합니다. VPN 연결 활성화 또는 비활성화에 ECMP 대한 자세한 내용은 섹션을 참조하세요Amazon Transit Gateway의 VPC Transit Gateway.
AWS Transit Gateway Connect - AWS Transit Gateway Connect 연결은를 자동으로 지원합니다ECMP.
AWS Direct Connect Gateway - AWS Direct Connect Gateway 연결은 네트워크 접두사, 접두사 길이 및 AS_PATH가 정확히 동일한 경우 ECMP 여러 Direct Connect Gateway 연결에서 자동으로 지원됩니다.
Transit Gateway 피어링 - Transit Gateway 피어링은 동적 라우팅을 지원하지 않으며 두 대상에 대해 동일한 정적 경로를 구성할 수 없기 ECMP 때문에를 지원하지 않습니다.

참고

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

가용 영역

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

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

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

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

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

라우팅

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

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

라우팅 주제

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

라우팅 테이블

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

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

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

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

라우팅 테이블 연결

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

경로 전파

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

VPC 연결의 경우의 CIDR 블록VPC이 전송 게이트웨이 라우팅 테이블에 전파됩니다.

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

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

Connect 연결의 경우 Connect 연결과 연결된 라우팅 테이블의 경로는에서 VPC 까지 실행되는 SD-WAN 어플라이언스와 같은 타사 가상 어플라이언스에 광고됩니다BGP.

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

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

피어링 연결에 대한 라우팅

두 개의 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 전파 경로
- Site-to-Site VPN 프라이빗 Direct Connect 전파 경로를 통해
- Site-to-Site VPN전파된 경로
- Transit Gateway 피어링 전파 경로(클라우드 WAN)

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

AS 경로 길이 단축
더 낮은 MED 값
연결에서 지원하는 경우 eBGP over iBGP 경로가 선호됩니다.

중요
AWS 는 위에 나열된 것과 동일한 CIDR, 연결 유형 및 BGP 속성을 가진 경로에 대해 일관된 BGP 경로 우선 순위 지정 순서를 보장할 수 없습니다.

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

VPC 및 Transit Gateway 라우팅 테이블 차이

라우팅 테이블 평가는 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

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

대상	연결(대상)	리소스 유형	경로 유형	우선순위
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를 모든 VPCs, AWS Direct Connect및 Site-to-Site VPN 연결을 연결하는 중앙 집중식 라우터로 구성할 수 있습니다. 이 시나리오에서는 모든 연결이 Transit Gateway 기본 라우팅 테이블과 연결되어 Transit Gateway 기본 라우팅 테이블에 전파됩니다. 따라서 모든 연결은 패킷을 서로 라우팅할 수 있으며 Transit Gateway는 단순한 계층 3 IP 라우터 역할을 합니다.

내용

개요
리소스
라우팅

개요

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

3개의 VPC 연결과 1개의 VPN 연결로 구성된 전송 게이트웨이입니다.

리소스

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

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

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

라우팅

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

VPC 라우팅 테이블

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

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

Transit Gateway 라우팅 테이블

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

대상 주소	대상	경로 유형
10.1.0.0/16	`Attachment for VPC A`	전파
10.2.0.0/16	`Attachment for VPC B`	전파
10.3.0.0/16	`Attachment for VPC C`	전파
10.99.99.0/24	`Attachment for VPN connection`	전파

고객 게이트웨이 BGP 테이블

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

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

예: 중앙 집중식 라우터

내용

개요
리소스
라우팅

개요

리소스

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

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

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

라우팅

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

VPC 라우팅 테이블

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

Transit Gateway 라우팅 테이블

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

대상 주소	대상	경로 유형
10.1.0.0/16	`Attachment for VPC A`	전파
10.2.0.0/16	`Attachment for VPC B`	전파
10.3.0.0/16	`Attachment for VPC C`	전파
10.99.99.0/24	`Attachment for VPN connection`	전파

고객 게이트웨이 BGP 테이블

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

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

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

내용

개요
리소스
라우팅

개요

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

리소스

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

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

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

라우팅

각 VPC 에는 라우팅 테이블이 있고, 전송 게이트웨이에는 두 개의 라우팅 테이블이 있습니다. 하나는 용VPCs이고 다른 하나는 VPN 연결용입니다.

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

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

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

Transit Gateway 라우팅 테이블

이 시나리오에서는에 대해 하나의 라우팅 테이블VPCs을 사용하고 VPN 연결에 대해 하나의 라우팅 테이블을 사용합니다.

VPC 첨부 파일은 다음 라우팅 테이블과 연결되어 있으며,이 테이블에는 VPN 첨부 파일에 대한 전파된 경로가 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`Attachment for VPN connection`	전파

VPN 연결은 각 VPC 연결에 대해 전파된 경로가 있는 다음 라우팅 테이블과 연결됩니다.

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

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

고객 게이트웨이 BGP 테이블

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

10.1.0.0/16
10.2.0.0/16
10.3.0.0/16

예: 격리됨 VPCs

내용

개요
리소스
라우팅

개요

리소스

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

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

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

라우팅

각 VPC 에는 라우팅 테이블이 있고, 전송 게이트웨이에는 두 개의 라우팅 테이블이 있습니다. 하나는 용VPCs이고 다른 하나는 VPN 연결용입니다.

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

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

Transit Gateway 라우팅 테이블

이 시나리오에서는에 대해 하나의 라우팅 테이블VPCs을 사용하고 VPN 연결에 대해 하나의 라우팅 테이블을 사용합니다.

VPC 첨부 파일은 다음 라우팅 테이블과 연결되어 있으며,이 테이블에는 VPN 첨부 파일에 대한 전파된 경로가 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`Attachment for VPN connection`	전파

VPN 연결은 각 VPC 연결에 대해 전파된 경로가 있는 다음 라우팅 테이블과 연결됩니다.

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

고객 게이트웨이 BGP 테이블

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

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의 서브넷에서 패킷은 먼저 전송 게이트웨이를 통해 라우팅한 다음의 고객 게이트웨이로 라우팅합니다Site-to-Site VPN. VPC A, VPC B 또는 VPC C에 서브넷의 대상이 있는 VPC A, VPC B 또는 VPC C의 서브넷 패킷은 전송 게이트웨이 라우팅 테이블에 경로가 없으므로 차단되는 전송 게이트웨이를 통해 라우팅됩니다. VPC D가 대상인 VPC A, VPC B 및 VPC C의 패킷은 전송 게이트웨이를 통해 VPC D로 라우팅됩니다.

4개의 VPC 연결과 1개의 VPN 연결로 구성된 전송 게이트웨이입니다.

리소스

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

4개VPCs. 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
전송 게이트웨이. 자세한 내용은 Transit Gateway 생성을 참조하십시오.
Transit Gateway에 있는 4개의 첨부 파일, 1개당 1개VPC. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
전송 게이트웨이의 VPN 연결입니다 Site-to-Site. 자세한 내용은 Amazon Transit Gateways를 VPN 사용하여에 VPC 대한 전송 게이트웨이 연결 생성 단원을 참조하십시오.

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

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

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

라우팅

각 VPC 에는 라우팅 테이블이 있고, 전송 게이트웨이에는 두 개의 라우팅 테이블이 있습니다. 하나는 용VPCs이고 다른 하나는 VPN 연결 및 공유 서비스용입니다VPC.

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

각 VPC 에는 두 개의 항목이 있는 라우팅 테이블이 있습니다. 첫 번째 항목은의 로컬 라우팅에 대한 기본 항목입니다. VPC이 항목을 사용하면이 항목의 인스턴스가 서로 통신VPC할 수 있습니다. 두 번째 항목은 다른 모든 IPv4 서브넷 트래픽을 전송 게이트웨이로 라우팅합니다.

대상 주소	대상
10.1.0.0/16	로컬
0.0.0.0/0	`transit gateway ID`

Transit Gateway 라우팅 테이블

이 시나리오에서는 하나의 라우팅 테이블을에 VPCs 사용하고 하나의 라우팅 테이블을 VPN 연결에 사용합니다.

VPC A, B 및 C 연결은 다음 라우팅 테이블과 연결되어 있으며,이 테이블에는 VPN 연결에 대한 전파된 경로와 VPC D에 대한 연결에 대한 전파된 경로가 있습니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`Attachment for VPN connection`	전파
10.4.0.0/16	`Attachment for VPC D`	전파

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

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

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

고객 게이트웨이 BGP 테이블

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

예: 공유 서비스와 VPCs 격리됨

내용

개요
리소스
라우팅

개요

리소스

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

4개VPCs. 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
전송 게이트웨이. 자세한 내용은 Transit Gateway 생성을 참조하십시오.
Transit Gateway에 있는 4개의 첨부 파일, 1개당 1개VPC. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.
전송 게이트웨이의 VPN 연결입니다 Site-to-Site. 자세한 내용은 Amazon Transit Gateways를 VPN 사용하여에 VPC 대한 전송 게이트웨이 연결 생성 단원을 참조하십시오.

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

VPN 연결이 완료되면 BGP 세션이 설정되고 VPN CIDR가 전송 게이트웨이 라우팅 테이블로 전파되고 VPC CIDRs이 고객 게이트웨이 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 라우팅 테이블

이 시나리오에서는 하나의 라우팅 테이블을에 VPCs 사용하고 하나의 라우팅 테이블을 VPN 연결에 사용합니다.

대상 주소	대상	경로 유형
10.99.99.0/24	`Attachment for VPN connection`	전파
10.4.0.0/16	`Attachment for VPC D`	전파

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

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

고객 게이트웨이 BGP 테이블

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

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

내용

개요
리소스
라우팅

개요

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

피어링된 전송 게이트웨이 2개, 하나는 VPC 연결 2개, 다른 하나는 VPN 연결 1개.

리소스

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

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

VPC 첨부 파일을 생성하면 CIDRs 각의가 전송 게이트웨이 1의 라우팅 테이블에 VPC 전파됩니다. VPN 연결이 시작되면 다음 작업이 발생합니다.

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

라우팅

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

VPC A 및 VPC B 라우팅 테이블

각 VPC 에는 2개의 항목이 있는 라우팅 테이블이 있습니다. 첫 번째 항목은에서 로컬 IPv4 라우팅의 기본 항목입니다VPC. 이 기본 항목을 사용하면이 항목의 리소스가 서로 통신VPC할 수 있습니다. 두 번째 항목은 다른 모든 IPv4 서브넷 트래픽을 전송 게이트웨이로 라우팅합니다. 다음 표에는 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	`Attachment ID for VPC A`	전파
10.2.0.0/16	`Attachment ID for VPC B`	전파
0.0.0.0/0	`Attachment ID for peering connection`	고정

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

대상 주소	대상	경로 유형
172.31.0.0/24	`Attachment ID for VPN connection`	전파
10.0.0.0/16	`Attachment ID for peering connection`	정적
10.2.0.0/16	`Attachment ID for peering connection`	정적

고객 게이트웨이 BGP 테이블

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

10.0.0.0/16
10.2.0.0/16

예: 피어링된 Transit Gateway

내용

개요
리소스
라우팅

개요

리소스

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

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

VPC 첨부 파일을 생성하면 CIDRs 각의가 전송 게이트웨이 1의 라우팅 테이블에 VPC 전파됩니다. VPN 연결이 시작되면 다음 작업이 발생합니다.

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

라우팅

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

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	`Attachment ID for VPC A`	전파
10.2.0.0/16	`Attachment ID for VPC B`	전파
0.0.0.0/0	`Attachment ID for peering connection`	고정

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

대상 주소	대상	경로 유형
172.31.0.0/24	`Attachment ID for VPN connection`	전파
10.0.0.0/16	`Attachment ID for peering connection`	정적
10.2.0.0/16	`Attachment ID for peering connection`	정적

고객 게이트웨이 BGP 테이블

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

10.0.0.0/16
10.2.0.0/16

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

내용

개요
리소스
라우팅

개요

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

리소스

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

IP 주소 범위가 VPCs 겹치지 않는 3개 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
VPC A와 VPC B에는 각각 EC2 인스턴스가 있는 프라이빗 서브넷이 있습니다.
VPC C는 다음과 같습니다.
- 에 연결된 인터넷 게이트웨이입니다VPC. 자세한 내용은 Amazon VPC 사용 설명서의 인터넷 게이트웨이 생성 및 연결을 참조하세요.
- NAT 게이트웨이가 있는 퍼블릭 서브넷입니다. 자세한 내용은 Amazon VPC 사용 설명서의 NAT 게이트웨이 생성을 참조하세요.
- Transit Gateway Attachment를 위한 프라이빗 서브넷. 프라이빗 서브넷은 퍼블릭 서브넷과 같은 가용 영역에 있어야 합니다.
하나의 전송 게이트웨이입니다. 자세한 내용은 Amazon Transit Gateways를 사용하여 VPC 전송 게이트웨이 생성 단원을 참조하십시오.
전송 게이트웨이에 있는 세 개의 VPC 첨부 파일입니다. 각의 CIDR 블록은 전송 게이트웨이 라우팅 테이블에 VPC 전파됩니다. 자세한 내용은 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 서브넷 트래픽을 전송 게이트웨이로 라우팅합니다.

대상 주소	대상
`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 라우팅 테이블의 예입니다. 각의 CIDR 블록은 전송 게이트웨이 라우팅 테이블에 VPC 전파됩니다. 정적 경로는 아웃바운드 인터넷 트래픽을 VPC C로 전송합니다. 필요에 따라 각 VPC에 블랙홀 경로를 추가하여 상호VPC 통신을 방지할 수 있습니다CIDR.

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

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

내용

개요
리소스
라우팅

개요

리소스

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

IP 주소 범위가 VPCs 겹치지 않는 3개 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
VPC A와 VPC B에는 각각 EC2 인스턴스가 있는 프라이빗 서브넷이 있습니다.
VPC C는 다음과 같습니다.
- 에 연결된 인터넷 게이트웨이입니다VPC. 자세한 내용은 Amazon VPC 사용 설명서의 인터넷 게이트웨이 생성 및 연결을 참조하세요.
- NAT 게이트웨이가 있는 퍼블릭 서브넷입니다. 자세한 내용은 Amazon VPC 사용 설명서의 NAT 게이트웨이 생성을 참조하세요.
- Transit Gateway Attachment를 위한 프라이빗 서브넷. 프라이빗 서브넷은 퍼블릭 서브넷과 같은 가용 영역에 있어야 합니다.
하나의 전송 게이트웨이입니다. 자세한 내용은 Amazon Transit Gateways를 사용하여 VPC 전송 게이트웨이 생성 단원을 참조하십시오.
전송 게이트웨이에 있는 세 개의 VPC 첨부 파일입니다. 각의 CIDR 블록은 전송 게이트웨이 라우팅 테이블에 VPC 전파됩니다. 자세한 내용은 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에 대한 라우팅 테이블

대상 주소	대상
`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`	`Attachment for VPC A`	전파
`VPC B CIDR`	`Attachment for VPC B`	전파
`VPC C CIDR`	`Attachment for VPC C`	전파
0.0.0.0/0	`Attachment for VPC C`	정적

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

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

중요

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

내용

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

개요

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

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

3개VPCs. 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
Transit Gateway. 자세한 내용은 Amazon Transit Gateways를 사용하여 VPC 전송 게이트웨이 생성 단원을 참조하십시오.
각에 대해 하나씩 3개의 VPC 첨부 파일VPCs. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.

각 VPC 연결에 대해 각 가용 영역에 서브넷을 지정합니다. 공유 서비스의 경우 VPC트래픽이 전송 게이트웨이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 블로그의 중앙 집중식 검사 아키텍처를 참조하세요.

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

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

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

라우팅

각 VPC에는 하나 이상의 라우팅 테이블이 있고 전송 게이트웨이에는 두 개의 라우팅 테이블이 있습니다.

VPC 라우팅 테이블

VPC A 및 VPC B

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

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

VPC C

공유 서비스VPC(VPC C)에는 각 서브넷에 대해 서로 다른 라우팅 테이블이 있습니다. 서브넷 A는 전송 게이트웨이에서 사용됩니다(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 라우팅 테이블

이 전송 게이트웨이는 VPC A 및 VPC B에 대해 하나의 라우팅 테이블과 공유 서비스VPC(VPC C)에 대해 하나의 라우팅 테이블을 사용합니다.

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

대상 주소	대상	경로 유형
0.0.0.0/0	`Attachment ID for VPC C`	정적

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

대상 주소	대상	경로 유형
10.0.0.0/16	`Attachment ID for VPC A`	전파
10.1.0.0/16	`Attachment ID for VPC B`	전파

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

중요

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

내용

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

개요

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

3개VPCs. 자세한 내용은 Amazon VPC 사용 설명서의 생성을 VPC 참조하세요.
Transit Gateway. 자세한 내용은 Amazon Transit Gateways를 사용하여 VPC 전송 게이트웨이 생성 단원을 참조하십시오.
각에 대해 하나씩 3개의 VPC 첨부 파일VPCs. 자세한 내용은 Amazon VPC Transit Gateways를 사용하여 VPC 연결 생성 단원을 참조하십시오.

각 VPC 연결에 대해 각 가용 영역에 서브넷을 지정합니다. 공유 서비스의 경우 VPC트래픽이 전송 게이트웨이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에는 하나 이상의 라우팅 테이블이 있고 전송 게이트웨이에는 두 개의 라우팅 테이블이 있습니다.

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 라우팅 테이블

이 전송 게이트웨이는 VPC A 및 VPC B에 대해 하나의 라우팅 테이블과 공유 서비스VPC(VPC C)에 대해 하나의 라우팅 테이블을 사용합니다.

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

대상 주소	대상	경로 유형
0.0.0.0/0	`Attachment ID for VPC C`	정적

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

대상 주소	대상	경로 유형
10.0.0.0/16	`Attachment ID for VPC A`	전파
10.1.0.0/16	`Attachment ID for VPC B`	전파

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

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

문서 규칙

Amazon VPC Transit Gateways란 무엇입니까?

전송 게이트웨이 시작하기

이 페이지에서

쿠키 기본 설정 선택

Amazon VPC Transit Gateway의 작동 방식

주제

아키텍처 다이어그램 예제

리소스 연결

Equal Cost Multipath 라우팅

참고

가용 영역

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

라우팅

라우팅 주제

라우팅 테이블

라우팅 테이블 연결

경로 전파

피어링 연결에 대한 라우팅

경로 평가 순서

중요

VPC 및 Transit Gateway 라우팅 테이블 차이

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

예시

내용

개요

리소스

라우팅

VPC 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 중앙 집중식 라우터

내용

개요

리소스

라우팅

VPC 라우팅 테이블

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

내용

개요

리소스

라우팅

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

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 격리됨 VPCs

내용

개요

리소스

라우팅

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

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

내용

개요

리소스

라우팅

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

Transit Gateway 라우팅 테이블

고객 게이트웨이 BGP 테이블

예: 공유 서비스와 VPCs 격리됨

내용

개요

리소스

라우팅

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 테이블