시작하면서
지금까지 진행했던 TGW 실습은 대부분 여러 VPC를 TGW에 연결하고, 라우팅 테이블을 하나만 만든 뒤, 각 VPC의 경로 정보를 TGW에 자동으로 전파(Propagation)하도록 설정하는 방식이었다. 이렇게 구성하면 TGW는 모든 VPC의 경로를 알고 있기 때문에, 연결된 모든 VPC가 서로 자유롭게 통신할 수 있는 구조가 만들어진다. 이 방식은 내부 시스템끼리의 제한 없는 통신이 필요한 경우에는 효율적으로 작동한다.
하지만 실제 운영 환경에서는 모든 VPC 간 통신을 항상 허용할 수는 없다. 예를 들어 개발 환경과 운영 환경을 분리하거나, 고객별 데이터를 다루는 테넌트를 나누거나, 민감한 시스템에는 외부 접근을 막아야 하는 등, 특정 통신만 허용하고 나머지는 차단해야 하는 상황이 자주 발생한다. 이런 요구가 있을 때는 TGW의 기본 구조만으로는 부족하며, 라우팅 테이블을 나눠서 구성하고, 어떤 VPC의 경로를 TGW 내부에 전달할지를 선택적으로 설정할 수 있어야 한다.
이번 실습은 바로 이런 구조를 만드는 과정을 다룬다. 목표는 VPC20과 VPC21은 서로 통신하지 못하도록 막되, 각각은 VPC19와는 통신이 가능하도록 구성하는 것이다. 이렇게 서로 다른 통신 관계를 설정함으로써, 라우팅 테이블을 나눠서 네트워크 흐름을 분리하는 방식이 실제로 어떻게 동작하는지 확인하고, 이 결과가 TGW 내부 라우팅 구조에 어떤 영향을 주는지도 함께 살펴보았다.
⚙️ 실습 환경 및 초기 구성 상태
실습은 총 세 개의 VPC를 기반으로 구성되었으며, 각 VPC는 다음과 같은 CIDR 대역과 이름으로 식별되었다.
MyVPC19: 10.19.0.0/16MyVPC20: 10.20.0.0/16MyVPC21: 10.21.0.0/16
각 VPC에는 고정된 사설 IP를 부여받은 EC2 인스턴스가 각각 하나씩 배치되어 있었으며, 이 인스턴스들은 각각 MyWeb19, MyWeb20, MyWeb21이라는 이름으로 구성되어 있었다.
초기 상태에서 각 인스턴스 간의 통신 상태를 확인하기 위해 ping 테스트를 수행하였으며, 테스트 결과 모든 인스턴스 간의 통신이 양방향으로 이루어지고 있었음을 확인했다.
📐 실습 목표와 구조 설계 방향
실습을 통해 구현하고자 한 네트워크 구조는 다음과 같은 트래픽 흐름 조건을 만족해야 했다.
| 출발지 → 도착지 | 통신 허용 여부 |
|---|---|
| VPC19 ↔ VPC20 | 허용됨 ✅ |
| VPC19 ↔ VPC21 | 허용됨 ✅ |
| VPC20 ↔ VPC21 | 차단됨 ❌ |
이 구조를 실현하기 위해 TGW의 기본 Route Table 하나만을 사용하는 방식을 포기하고, VPC20과 VPC21을 서로 다른 TGW 라우팅 테이블에 연결한 뒤, 각 라우팅 테이블에 대해서는 VPC19의 경로만 Propagation하도록 제한하는 방식으로 설계한다.
🔨 실습 단계별 구성 및 작업 내용
1. TGW 라우팅 테이블 분리 및 Attachment 재구성
우선 기존에 하나만 존재하던 TGW 라우팅 테이블을 둘로 분리하였다. MyTGWBlue는 VPC20 전용, MyTGWGreen은 VPC21 전용으로 할당하였다.
📌 TGW의 Attachment는 동시에 둘 이상의 라우팅 테이블에 연결될 수 없으며, 하나의 Attachment는 하나의 TGW Route Table에만 Association될 수 있다. 때문에 기존의 라우팅 테이블에서 해당 Attachment를 먼저 분리한 뒤, 새로 만든 라우팅 테이블에 다시 연결해야 한다.
MyTGWBlue: VPC20 전용
MyTGWGreen: VPC21 전용
2. Propagation 설정을 통한 경로 전파 제어
Attachment 연결 이후 각 라우팅 테이블에는 Propagation 설정을 추가하였다. VPC20과 VPC21은 서로를 인식하지 못해야 했고, 각 라우팅 테이블에는 오직 VPC19의 경로 정보만이 존재해야 한다.
- MyTGWBlue에서는 VPC19의 경로만 Propagation
- MyTGWGreen도 마찬가지로 VPC19만 Propagation
이 설정의 결과로 VPC20과 VPC21은 각각 VPC19에 대한 경로 정보만 갖게 되고, 서로의 경로는 전파받지 못하므로 서로를 인식할 수 없는 상태가 된다.
3. ping 테스트를 통한 구성 검증
설정이 완료된 이후, 각 인스턴스에서 ping 테스트를 다시 수행하여 통신 상태를 검증하였다.
VPC19에서 VPC20과 VPC21 모두에 대해 ping 응답이 정상적으로 도달하였으며, VPC20과 VPC21 간의 ping 요청은 응답을 받지 못했다.
- WEB19 > WEB20 :연결성공
- WEB19 > WEB21 :연결성공
- WEB20 > WEB19 : 연결성공
- WEB20 > WEB21 : 연결실패
- WEB20 > WEB19 : 연결성공
- WEB21 > WEB20 : 연결실패
마무리하면서
TGW 라우팅 테이블은 각 VPC를 어느 라우팅 테이블에 연결하고, 어떤 경로를 전파시킬지를 설정하는 것만으로도, 물리적인 망 구성의 변경 없이 논리적 네트워크 구성을 재설계할 수 있다는 점은 매우 강력한 장점이다.
이번 실습에서 구성한 방식은 다양한 실무 상황에 유연하게 적용될 수 있다. 예를 들어 운영 환경과 개발 환경을 분리하거나, 멀티 테넌시 환경에서 테넌트 간의 직접 통신을 차단하고 중앙 서비스만 접근 가능하도록 설계하는 등의 경우에 적절한 전략이 될 수 있다.
또한 중앙 관제 시스템을 운영하는 경우, 모든 VPC가 하나의 VPC에만 트래픽을 전송하도록 제한하는 구조를 구현하는 데에도 매우 유용하게 활용될 수 있다.
