
이 글은 AWS에서 Transit Gateway를 활용해 여러 VPC 간 네트워크 연결을 구성하고, 각 VPC의 EC2 인스턴스가 사설 IP를 통해 서로 통신할 수 있도록 구현한 실습 내용을 정리한 것이다.
AWS 환경에서는 여러 서비스나 팀별로 VPC를 나누어 사용하게 된다. 이때 VPC끼리는 기본적으로 격리된 환경이기 때문에 서로 직접 통신할 수 없다. 이 문제를 해결하는 방법으로 흔히 사용하는 것이 VPC Peering이지만, 피어링은 연결되는 VPC가 많아질수록 복잡도가 기하급수적으로 증가한다.
이러한 문제를 해결하기 위해 AWS가 제공하는 서비스가 바로 Transit Gateway(TGW)이다. TGW는 여러 VPC 및 VPN, Direct Connect 연결을 하나의 중앙 라우터로 관리하여 간편하게 네트워크를 연결하고 제어할 수 있게 도와준다.
이 실습에서는 TGW를 활용해 서로 다른 3개의 VPC를 연결하고, EC2 인스턴스 간의 ping 통신을 통해 연결 상태를 검증하는 과정을 다룬다.
10.19.0.0/16, 10.20.0.0/16, 10.21.0.0/16MyWeb19, MyWeb20, MyWeb21)EC2_list.txt, ping.sh)다음 다이어그램은 위 구성된 실습 환경과 네트워크 흐름을 시각적으로 보여준다:

AWS 콘솔에서 Transit Gateway를 생성한다. 이름은 MyTGW로 지정한다.

Transit Gateway를 각 VPC에 연결하려면 'Transit Gateway Attachment'를 만들어야 한다. 이 Attachment를 통해 각 VPC의 트래픽이 Transit Gateway로 전달된다.
MyTGW19 (MyVPC19)MyTGW20 (MyVPC20)MyVPC21 (MyVPC21)Attachment 상태는 생성 후 몇 분 안에 available로 바뀐다.
각 VPC에서 다른 VPC로 가는 트래픽을 TGW를 통해 보내도록 라우팅 테이블을 수정한다. 이때 중요한 점은 CIDR 블록이다.
0.0.0.0/8로 설정했으나 이 설정은 실제 트래픽과 매칭되지 않기 때문에 동작하지 않는다.10.0.0.0/8)를 사용하여 TGW로 연결하는 것이다.10.0.0.0/8 → MyTGW
실습 환경에서는 각 VPC CIDR이 10.x.x.x 형태이기 때문에 위 CIDR로 충분하다. 그러나 실제 환경에서는 더욱 세부적으로 CIDR을 지정하는 것이 트래픽 관리를 위해 권장된다.
Transit Gateway 자체에도 라우팅 테이블이 존재하며, 각 Attachment의 'Association'과 'Propagation'을 설정해야 한다.
이 두 설정을 놓치면 Transit Gateway가 트래픽을 전달하지 못한다.
MyWeb19 인스턴스에서 ping.sh 스크립트를 실행해 다른 두 VPC의 EC2 인스턴스로의 ping 테스트를 수행한다.
실행 결과 모든 EC2 인스턴스가 성공적으로 ping에 응답함으로써, Transit Gateway를 통한 VPC 간 연결이 성공적으로 이루어졌다는 것을 확인할 수 있다.

이 실습을 통해 AWS의 복잡한 네트워크 아키텍처를 단순하고 효율적으로 관리할 수 있는 Transit Gateway의 필요성과 그 구성을 확실히 이해할 수 있었다.