TransitGateway Intra-Peering
Update: 2024-07-28
Last updated
Update: 2024-07-28
Last updated
TransitGateway는 서로 다른 리전 또는 동일 리전에서 TransitGateway를 Peering 할 수 있습니다.
리전 내 피어링 기능을 사용하면 더 이상 동일한 AWS 리전의 다른 Transit Gateway 간에 트래픽을 라우팅하기 위해 여러 Transit Gateway 간에 브리지 VPC를 생성하거나 단일 VPC를 여러 Transit Gateway에 연결할 필요가 없습니다. 리전 내 피어링은 별도의 Transit Gateway를 통해 서비스 및 관리되는 온프레미스 네트워크와 VPC 간의 라우팅 및 상호 연결을 간소화합니다. 이 기능을 통해 고객은 별도의 관리 도메인이 있는 여러 Transit Gateway를 유연하게 배포할 수 있으며 이러한 Transit Gateway를 보다 기본적으로 상호 연결하는 손쉬운 방법을 제공합니다. 리전 내 피어링을 사용하면 유연한 네트워크 토폴로지를 구축하고 네트워크를 동일한 AWS 리전의 타사 또는 파트너 관리형 네트워크와 쉽게 통합할 수 있습니다.
아래 구성도는 동일 리전에서 여러개의 TransitGateway를 수용하는 디자인입니다.
앞서 TransitGateway 멀티 어카운트 Chapter를 수행하였다면 사전 준비하기 는 생략해도 됩니다.
Lab 구성을 위해서, 새로운 Account에서 수행합니다.
새로운 계정에 접속 하고, Cloudformation을 통해 기본이 되는 VPC구성을 먼저 구성합니다.
Code-Server terminal 에서 aws cli 명령어로 Cloudformation 코드를 실행해서 , 서울리전의 PRD, STG, DEV VPC를 생성합니다.
Seoul-VPC-PART-PRD 생성
Seoul-VPC-PART-STG 생성
Seoul-VPC-PART-DEV 생성
정상적으로 구성되면 아래와 같이 AWS 서비스 Cloudformation 콘솔창에서 확인 할 수 있습니다. VPC는 각 3분 내외에 생성됩니다.
Code-Server terminal 에서 aws cli 명령어의 Cloudformation 코드를 실행해서 , PART1, PART2 TrasitGateway들을 생성합니다.
Seoul-TGW-PART1 생성 - PRD VPC와 연결되는 TGW 입니다.
Seoul-TGW-PART2 생성 - STG , DEV VPC와 연결되는 TGW 입니다.
정상적으로 구성되면 아래와 같이 Cloudformation에서 확인 할 수 있습니다. Transitgateway는 각 5분 내외에 생성됩니다.
Cloudformation 으로 생성된 자원들이 정상적으로 배포되었는지 확인합니다
AWS 관리콘솔 - VPC 를 선택합니다.
VPC가 정상적으로 생성되었는지 확인합니다.
AWS 관리콘솔 - EC2를 선택합니다.
EC2가 정상적으로 생성되었는지 확인합니다.
AWS 관리콘솔 - VPC - TransitGateway 를 선택해서, Transit Gateway 정상적으로 구성되었는지 확인합니다.
VPC-Transit Gateway-Transit Gateway 연결 을 선택해서, Transit Gateway attachment가 정상적으로 구성되었는지 확인합니다.
3개의 Attachment를 선택하면, 이미 "Seoul-PART-PRD, STG, DEV VPC"의 TGW-Subnet ID에 연결되어 있는 것을 확인할 수 있습니다. 또한 Routing Table에 Association 된 상태도 확인이 가능합니다.
Seoul-TGW-PART2-Attach-Seoul-VPC-PART-PRD - Seoul-PART-PRD VPC 에 연결
Seoul-TGW-PART2-Attach-Seoul-VPC-PART-DEV - Seoul-PART-STG VPC 에 연결
Seoul-TGW-PART2-Attach-Seoul-VPC-PART-DEV - Seoul-PART-DEV VPC 에 연결
TGW Routing Table과 Attachment가 연결된 상태를 확인
Attachment가 VPC의 어떤 Subnet과 연결되었는지 확인
VPC-Transit Gateway-Transit Gateway- Transit Gateway 라우팅 테이블 을 선택해서 라우팅 테이블 구성을 확인해 봅니다. Associations(연결) 와 Propagation(전파), Routes(경로 탭을 눌러서, Seoul-VPC-PART-PRD/STG/DEV 연결과 각 VPC의 CIDR가 정상적으로 업데이트 되었는지 확인합니다.
이제 Cloudformation을 통해서 TransitGateway Intra-Peering이 모두 정상적으로 구성되었습니다.
모든 랩의 구성 시험은 Private 인스턴스로 시험합니다. Cloudformation을 통해 System Manager와 Session Manager를 사용할 수 있도록 자동 배포 구성하였습니다.
Session Manager를 사용할 수 있도록 아래 같이 각 PC환경에 맞추어서 AWS Session Manager Plugin을 설치합니다. Code-Server Terminal을 사용하거나 웹콘솔에서 Session Manager를 사용하면 각 PC환경에서 설치할 필요가 없습니다.
Code-Server 터미널에서 아래 aws cli 명령을 실행하여 생성된 Seoul-의 EC2 인스턴스를 확인합니다.
아래와 같이 Code-Server에서 shell을 실행해 봅니다.
아래와 같은 결과를 확인할 수 있습니다.
ssm plugin을 통해서 인스턴스 ID 기반으로, 직접 Private Instance에 접속합니다.아래와 같은 명령을 통해서 직접 Private Instance에 접속합니다.
SSM을 통해서 Cloud9에서 터미널 창을 추가로 오픈하고, 아래와 같이 bash 콘솔로 접속하고, 시험할 호스트들을 host file에 등록합니다.
1.서밋 컴퍼니는 아래와 같은 VPC를 서울 리전에 소유하고 있습니다.
Production Workload : Seoul-VPC-PART-PRD
Staging Workload : Seoul-VPC-PART-STG
Dev Workload : Seoul-VPC-PART-Dev
2. Production VPC는 이미 TGW를 생성해서 사용하고 있습니다 Staging,Dev VPC도 이미 TGW를 생성해서 사용하고 있습니다
3. 동일 리전에서 TGW를 연결하고 Staging,DEV VPC의 워크로드의 Private Subnet의 워크로드들은 Production VPC를 통해서 외부와 연결하고 서로 통신을 하기를 원합니다
목표 구성과 필요작업은 아래와 같습니다.
Seoul-TGW-PART1 , Seoul-TGW-PART2를 동일 리전안에서 연결해 봅니다.
Seoul-TGW-PART1 , Seoul-TGW-PART2에는 이미 각 VPC의 CIDR가 Propagated(전파 가 구성되어 있기 때문에, TGW에서 작업은 불필요합니다.
Seoul-TGW-PART2 TGW ID를 복사해 둡니다. Peering을 위해서는 TGW ID를 알고 있어야 합니다.
AWS 관리콘솔 - VPC - Transit Gateway - Transit Gateway 연결 을 선택합니다.
Create Transit Gateway Attachment(Transit Gateway 연결 생성) 를 선택합니다.
Peering 이름을 생성합니다. Seoul-TGW-PART1-To-PART2
Trasit gateway ID를 선택합니다. Seoul-TGW-PART1
연결유형을 Peering Connection으로 선택합니다.
계정 - 내 계정을 선택
리전 - ap-northeast-2 를 선택
Transit gateway 수락자 - 앞서 복사해 둔 Seoul-TGW-PART2 Transit gateway ID를 입력합니다.
작업이 완료되면 아래와 같이 Seoul-TGW-PART2가 수락할때 까지 Pending 상태가 됩니다.
Seoul-TGW-PART2에서 수락하지 않으면 연결되지 않습니다.
비어있는 Name을 Seoul-TGW-PART2-To-PART1 으로 변경하고 ,상단메뉴 "작업" 을 선택하고 Transit Gateway 연결수락을 선택합니다.
Accept(수락를 선택하면, pending 으로 전환되고 3~4분 이후 available로 변경됩니다.
이제 Attachment가 Available(가용)으로 변경되면,Seoul-TGW-PART1-RT 라우팅 테이블의 Transit Gateway-Transit Gateway Route Table 탭에서 생성한 Peering Attachment를 Association(연결)을 시켜 줍니다.
연결 생성 이후 Trasit Gateway 라우팅테이블의 연결 탭에서 3~4분 이후 Associated (연결) 됩니다.
Seoul-TGW-PART2-RT 라우팅 테이블도 Transit Gateway-Transit Gateway Route Table 탭에서 생성한 Peering Attachment를 Association(연결)을 시켜 줍니다.
연결 생성 이후 Trasit Gateway 라우팅테이블의 연결 탭에서 3~4분 이후 Associated (연결) 됩니다.
Peering은 구성을 완료했지만, 상호간의 라우팅 구성이 되어 있지 않았습니다.
먼저 Seoul-TGW-PART1에서 Seoul-TGW-PART2로 라우팅을 구성해 줍니다.
Transit Gateway - Transit Gateway 라우팅 테이블 을 선택합니다.
Seoul-TGW-PART1-RT 를 선택하고, Route(경로) 탭을 선택하고, Create static Route(정적경로생성)를 선택합니다.
Static Route(정적 경로) 설정을 위한 CIDR, Attachment를 선택합니다
CIDR : 10.0.0.0/8 (STG, DEV VPC CIDR 대역 )
Attachment : Seoul-TGW-PART1-To-PART2 선택
Static Route(정적 경로) 설정을 위한 CIDR, Attachment를 선택합니다
CIDR : 0.0.0.0/0 (STG, DEV VPC가 인터넷 트래픽으로 가기 위한 CIDR )
Attachment : Seoul-TGW-PART1-Attach-Seoul-VPC-PART-PRD 선택
연결 생성 이후 Trasit Gateway 라우팅테이블의 연결 탭에서 경로가 생성됩니다.
Seoul-TGW-PART2에서도 Seoul-TGW-PART1 으로 라우팅을 구성해 줍니다.
Transit Gateway - Transit Gateway 라우팅 테이블 을 선택합니다.
Seoul-TGW-PART2-RT 를 선택하고, Route(경로) 탭을 선택하고, Create static Route(정적경로생성)를 선택합니다.
Static Route(정적 경로) 설정을 위한 CIDR, Attachment를 선택합니다
CIDR : 0.0.0.0/0 (STG, DEV VPC에서 인터넷 경로, PRD 경로를 위한 CIDR)
Attachment : Seoul-TGW-PART2-To-PART1 선택
연결 생성 이후 Trasit Gateway 라우팅테이블의 연결 탭에서 경로가 생성됩니다.
앞서 TGW Routing을 모두 구성하더라도, VPC에서 라우팅 구성이 되어 있지 않기 때문에 정상적으로 트래픽이 처리되지 않습니다. Seoul-VPC-PART-PRD 에서 Seoul-VPC-PART-STG,DEV를 위한 라우팅 테이블과 Seoul-VPC-PART-STG,DEV에서 Seoul-VPC-PRD, Internet 연결을 위한 라우팅 테이블을 구성해야 합니다
Seoul-VPC-PART-PRD VPC에서 다음과 같은 라우팅 테이블을 추가해 줍니다.
Seoul-VPC-PART-PRD-PublicRT - 10.0.0.0/8 경로가 TGW로 향하도록 구성
Seoul-VPC-PART-PRD-Private-Subnet-A-RT - 10.0.0.0/8 경로가 TGW로 향하도록 구성
VPC - 라우팅 테이블 에서 Seoul-VPC-PART-PRD-PublicRT 을 선택합니다.
라우팅 탭에서 라우팅 편집을 선택합니다.
10.0.0.0/8 목적지의 대상을 TGW로 선택하여 추가하고, 저장합니다.
저장 이후 정상적으로 라우팅이 추가되었는지 확인합니다.
Seoul-VPC-PART-PRD-Private-Subnet-A-RT 라우팅도 동일하게 추가해 줍니다.
Seoul-VPC-PART-STG,DEV VPC에서 다음과 같은 라우팅 테이블을 추가해 줍니다.
Seoul-VPC-PART-STG-Private-Subnet-A-RT - 0.0.0.0/0 경로가 TGW로 향하도록 구성
Seoul-VPC-PART-DEV-Private-Subnet-A-RT - 0.0.0.0/0 경로가 TGW로 향하도록 구성
VPC - 라우팅 테이블 에서 Seoul-VPC-PART-STG-Private-Subnet-A-RT 을 선택합니다.
라우팅 탭에서 라우팅 편집을 선택합니다.
0.0.0.0/0 목적지의 대상이 NAT Gateway로 되어 있습니다. 제거하고 0.0.0.0/0 목적지로 Transit Gateway로 신규 추가합니다.
저장 이후 정상적으로 라우팅이 추가되었는지 확인합니다.
Seoul-VPC-PART-DEV-Private-Subnet-A-RT 라우팅도 동일하게 추가해 줍니다.
Cloud9에서 PRD, STG, DEV VPC의 EC2로 접속해 봅니다. 연결은 SSM(Session Manager)를 통해서 접속합니다.
아래 처럼 정상적으로 통신이 되는지 확인합니다.
Seoul-VPC-PART-PRD-Private-10.11.21.101
Seoul-VPC-PART-STG-Private-10.12.21.101
Seoul-VPC-PART-DEV-Private-10.13.21.101
