목차
개요
•
VPC나 온프레미스 등의 네트워크를 단일 지점으로 연결할 수 있는 라우팅 서비스
•
다른 네트워크에 연결할 필요 없이 AWS 전송 게이트웨이만 연결하면 되므로 관리를 간소화하고 운영 비용을 줄여줌
•
복잡한 AWS 네트워크 아키텍처를 간소화하여 관리 및 운용 효율이 보장되며, 향상된 보안과 멀티캐스트를 활용하여 유용한 통신 가능
•
연결의 접점이 되는 중앙 집중형 단일 게이트웨이로 허브&스포크 환경에서 허브 역할
Transit Gateway 환경 비교
Transit Gateway 미사용시
•
VPN, VPC 연결 수가 많아지면 게이트웨이 연결이 매우 복잡
•
VPC 는 1:1 연결만 지원하므로 많은 VPC 끼리 연결되면 연결이 매우 복잡해짐
•
많은 연결을 개별적으로 관리해야함
Transit Gateway 사용 시
•
HUB 역할을 하는 Transit Gateway 를 구성
•
모든 게이트웨이는 Transit Gateway 에 연결
•
구성이 단순해지고 단일 위치에서 관리 및 모니터링 가능
Transit Gateway 주요 기능
라우팅
•
동적 라우팅, 정적 라우팅 지원
엣지 연결
•
VPN을 사용하여 AWS 전송 게이트웨이와 온프레미스 장비 간 VPN 연결 생성 가능
VPC 기능 상호 운용성
•
VPC에 있는 인스턴스가 전송 게이트웨이에 연결된 다른 AWS VPC에 있는 NAT 게이트웨이, NLB, AWS 엔드포인트 서비스 및 EFS 등에 액세스 가능
모니터링
•
CloudWatch, VPC 플로우 로그와 같은 서비스에서 사용하는 통계와 로그 제공
리전 간 VPC 피어링
•
AWS 글로벌 네트워크를 사용하여 AWS 리전을 통해 트래픽을 라우팅할 수 있도록 지원
멀티캐스트
•
고객이 클라우드에서 멀티캐스트 애플리케이션을 쉽게 구축하고 모니터링, 관리 및 확장할 수 있도록 지원
보안
•
IAM과 통합되므로 전송 게이트웨이에 대한 액세스를 안전하게 관리 가능
지표
•
성능과 송수신된 바이트, 패킷, 폐기된 패킷을 비롯한 트래픽 지표를 통해 글로벌 네트워크를 모니터링
Transit Gateway 관련 용어
Transit Gateway 연결
•
전송 게이트웨이에 연결되는 방식으로 3가지 방식 지원
1. VPC 연결
•
전송 게이트웨이와 동일 리전의 VPC를 직접적으로 연결
2. VPN 연결
•
전송 게이트웨이와 Site-to-Stie VPN 연결
3. Transit Gateway 피어링
•
전송 게이트웨이 다른 리전의 전송 게이트웨이를 연결
Transit Gateway 라우팅 테이블
•
전송 게이트웨이에서 관리하는 라우팅 테이블
Transit Gateway 공유
•
전송 게이트웨이를 공유하여 다른 AWS 계정에 전달하여 연결 가능
Transit Gateway 멀티캐스트
•
전송 게이트웨이를 통해 멀티캐스트 트래픽 전달
Transit Gateway 네트워크 매니저
•
논리적 다이어그램 또는 지리적 맵과 중앙 대시 보드에서 글로벌 네트워크를 시각화
[실습] Transit Gateway를 통한 연결
1. CloudFormation 적용
•
VPC0인스턴스는 VPC1, VPC2의 외부인터넷 웹 접속을 위한 웹 프록시 서버
2. 기본 환경 검증
1.
VPC0-Instance1 
VPC1-Instance1간 통신 과정
VPC1-Instance1간 통신 과정#VPC1과 VPC2의 인스턴스들과 ping 통신 확인
[ec2-user@VPC0Instance1 ~]$ ./pingall.sh
Sat Jan 22 04:36:55 UTC 2022
host 10.0.1.10 is up
host 10.10.1.10 is up
host 10.10.2.10 is up
host 10.20.1.10 is up
host 10.20.2.10 is up
Bash
복사
1) 서브넷라우팅 테이블 확인하여 전송 게이트웨이로 전달
2) 전송게이트웨이의 기본 라우팅 테이블을 확인하여 VPC1로 전달
2. VPC1-Instance1의 외부 인터넷 통신 과정
[root@VPC1Instance1 ~]# curl http://checkip.amazonaws.com/ --connect-timeout 3
10.10.1.10 # VPC0-Instance1 프라이빗 IP
[root@VPC1Instance1 ~]# curl https://checkip.amazonaws.com/ --connect-timeout 3
3.36.67.77 # VPC0-Instance1 퍼블릭 IP
Bash
복사
3. VPC 엔드포인트 환경 검증
•
일반적으로 VPC별로 VPC엔드포인트를 생성해야 하지만 전송 게이트웨이로 내부 간 통신이 되는 환경이므로 VPC0(공용자원배치)에만 VPC 엔드포인트를 생성
[root@VPC1Instance1 ~]# dig +short vpce-0a1accaefa2d5ea0b-lme0u6d4.cloudformation.ap-northeast-2.vpce.amazonaws.com
10.0.1.103
10.0.2.234
Bash
복사
3. 전송 게이트웨이 라우팅 테이블을 이용한 트래픽 제어
•
기본 라우팅 테이블 외 별도의 테이블을 설정하여 트래픽 제어
1. 기본 라우팅 테이블에서 VPC1과 VPC2의 Association을 삭제
2. Blue 라우팅 테이블 설정
1) VPC1을 Association 설정
2) VPC0, VPC1을 선택하여 Blue 라우팅 테이블에 Propagation(전파)
3) Blue 라우팅 테이블 확인
10.0.0.0/16 | VPC0 |
10.10.0.0/16 | VPC1 |
3. Red 라우팅 테이블 설정
1) VPC2을 Association 설정
2) VPC0, VPC2을 선택하여 Blue 라우팅 테이블에 Propagation(전파)
3) Red 라우팅 테이블 확인
10.0.0.0/16 | VPC0 |
10.20.0.0/16 | VPC2 |
4.
동작 확인
1) 기본 라우팅 테이블을 사용하는 VPC0-Instance1 확인
•
VPC0, VPC1, VPC2 모든 경로 정보가 있으므로 VPC1과 VPC2대역과 통신 가능
2) Blue 라우팅 테이블을 사용하는 VPC1-Instance1 확인
•
VPC0, VPC1 경로 정보가 있으므로 VPC0과 VPC1 대역과 통신이 가능하지만, VPC2대역과는 통신 불가능
3) Red 라우팅 테이블을 사용하는 VPC2-Instance1 확인
•
VPC0, VPC2 경로 정보가 있으므로 VPC0과 VPC2대역과 통신이 가능하지만, VPC1대역과는 통신 불가능
4. 블랙홀 라우팅을 이용한 통신 차단
•
VPC0-Instance1은 VPC1과 VPC2의 모든 대역으로 통신이 가능한 상태인데, 블랙홀 라우팅을 통해 VPC2 대역 중 10.20.2.0/24대역만 차단 설정 해보기
1) 블랙홀 라우팅 설정
•
VPC0이 속한 기본 라우팅 테이블에 블랙홀 라우팅 설정
2) 블랙홀 라우팅 동작 확인
# VPC0-Instance1에서 Ping 테스트
[ec2-user@VPC0Instance1 ~]$ ping 10.20.1.10
PING 10.20.1.10 (10.20.1.10) 56(84) bytes of data.
64 bytes from 10.20.1.10: icmp_seq=1 ttl=254 time=1.27 ms
64 bytes from 10.20.1.10: icmp_seq=2 ttl=254 time=0.823 ms
^C
--- 10.20.1.10 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.823/1.051/1.279/0.228 ms
[ec2-user@VPC0Instance1 ~]$ ping 10.20.2.10
PING 10.20.2.10 (10.20.2.10) 56(84) bytes of data.
^C
--- 10.20.2.10 ping statistics ---
9 packets transmitted, 0 received, 100% packet loss, time 8176ms
Bash
복사
[참고]
•
전송 게이트웨이의 블랙홀 라우팅에 의해 차단된 경우 CloudWatch의 ‘packetDropCountBlackhole’ 지표에서 확인 가능
