AWS VPC Peering과 Transit Gateway 비교 실습: 언제, 어떻게 사용할까?

kauze98·2025년 4월 29일

AWS 실습

목록 보기

6/16

1. 서론

AWS에서 여러 개의 VPC(Virtual Private Cloud)를 만들고 운영하다 보면, 서로 다른 VPC끼리 어떻게 안전하게 연결해서 데이터를 주고받을 수 있을지 궁금해질 때가 많습니다. 저 역시 AWS 네트워킹이 처음이라, VPC 간 연결 방식이 헷갈렸고, 실제로 어떻게 구성하는지 직접 해보고 싶었습니다.

이번 실습에서는 AWS에서 제공하는 대표적인 네트워크 연결 방법인 VPC 피어링과 Transit Gateway를 직접 따라 해보면서, 두 방식의 차이점과 설정 방법을 익혀보려고 합니다.
2개의 AWS 리전에 각각 3개의 VPC를 만들고, 각 VPC에 EC2 인스턴스를 배포한 뒤, 두 가지 방식으로 VPC를 연결해보며 네트워크가 어떻게 동작하는지 하나씩 확인해볼 예정입니다.

VPC 피어링

Full-Mesh 연결: 3개 VPC 간 양방향 통신을 위해 각 VPC 쌍마다 별도 피어링 연결 생성 필요 (n(n-1)/2 연결 수)
수동 라우팅 설정: 각 VPC의 라우팅 테이블에 대상 VPC CIDR 대역을 피어링 연결로 지정
리전 간 제한: 피어링 연결 생성 시 반드시 동일 리전/계정 여부 지정 필요

Transit Gateway

Hub-and-Spoke 모델: Transit Gateway를 중앙 허브로 사용, VPC당 1개 Attachment 생성으로 전체 연결 관리
자동 라우팅 전파: 연결된 VPC CIDR이 Transit Gateway 라우팅 테이블에 자동 등록
리전 간 통합: Transit Gateway 자체의 리전 간 피어링 지원

VPC 피어링 활동을 위한 실습 환경
이 실습은 2개의 AWS 리전인 US-WEST-2(오리건 리전) 및 US-EAST-1(버니지아 북부 리전)로 시작합니다.

VPC1 및 VPC2는 us-west-2 오리건 리전에 있습니다.
VPC3는 us-east-1 버지니아 북부 리전에 있습니다.
다음 다이어그램과 같이 각 리전에는 Amazon EC2 리소스가 포함된 퍼블릭 및 프라이빗 서브넷이 있습니다.

2. 리전 간 VPC 피어링 설정

Amazon VPC 피어링 연결을 통해 3개의 VPC(VPC1, VPC2, VPC3) 간에 풀 메시 네트워크 토폴로지를 직접 구성하였습니다.

✅ 구성한 피어링 연결

VPC1(오리건 리전)과 VPC2(오리건 리전) 간 VPC 피어링 연결 구성

VPC1(오리건 리전)과 VPC3(버지니아 북부 리전) 간 VPC 피어링 연결 구성 그리고 VPC2(오리건 리전)과 VPC3(버지니아 북부 리전) 간 VPC 피어링 연결 구성

모든 피어링 연결은 서로 다른 리전 간 통신이 가능하도록 수락(accept) 되었으며, 현재 상태는 전부 'Active' 상태로 완전히 연결된 상태입니다.

3. VPC 피어링 연결을 통한 네트워크 트래픽 라우팅 구성

구성한 VPC 피어링 연결을 실질적으로 활용하기 위한 라우팅 설정 작업을 수행하였습니다.
VPC 간 피어링 연결이 Active 상태라 하더라도, 서로 간의 네트워크 통신이 가능하려면 라우팅 테이블(Route Table)에 명시적인 경로 설정이 필요합니다.

질문 : vpc1-PUBLIC-RouteTable 얘는 왜 라우팅 편집 안함? )챗한테 물어보기)

vpc1에서 라우팅 구성

vpc2에서 라우팅 구성

us-east-1 (N Virginia) 리전에서 vpc3에서 라우팅 구성

✅ 수행한 주요 작업 요약

✅ 이 실습을 통해 확인한 사항

VPC 피어링 연결만으로는 통신 불가하며, 반드시 라우팅 테이블에 피어링 대상 CIDR을 명시적으로 추가해야 한다는 점을 실습을 통해 검증했습니다.
리전 간 VPC 피어링 연결에서도 라우팅 설정 방식은 동일하며,
수락자 VPC가 위치한 리전 콘솔에서 해당 피어링 연결을 직접 지정해야 합니다.

4. VPC 피어링 연결에서 네트워크 연결 테스트

AWS Systems Manager의 Session Manager 기능을 활용하여 VPC 피어링 연결이 설정된 EC2 인스턴스 간 네트워크 통신이 정상적으로 이루어지는지를 ping 테스트로 검증해보았습니다. 실습에서는 퍼블릭 및 프라이빗 서브넷 각각에 EC2 인스턴스가 배포된 3개의 VPC(vpc1, vpc2, vpc3)를 대상으로 진행되었습니다.

먼저 us-west-2 (Oregon) 리전에 있는 vpc1-public-ec2 인스턴스에 접속했습니다. SSH 포트를 열거나 키 페어 없이도 접근할 수 있도록 Session Manager를 통해 접속하였습니다. 해당 인스턴스는 퍼블릭 서브넷에 위치하고 있으며, 프라이빗 IP 외에도 퍼블릭 IP를 가지고 있음을 확인했습니다.

접속한 인스턴스에서 ping 명령어를 사용하여 다른 VPC 인스턴스들의 프라이빗 IP로 테스트를 수행했습니다.

vpc1-public-ec2에서 ping < vpc2publicInstanceIP >, ping < vpc2privateInstanceIP > 연결테스트

vpc2-public-ec2에서 < ping vpc3-public-ec2 IP>, < ping vpc3-private-ec2 IP> 연결 테스트

🧩 확인한 사항
각 EC2 인스턴스의 보안 그룹에 ICMP(ping) 허용 규칙이 제대로 설정되어 있어야 하며, VPC 간 라우팅 테이블 및 피어링 연결이 올바르게 구성되어 있어야 정상적인 통신이 가능합니다.

한 VPC의 퍼블릭 EC2에서 다른 VPC의 프라이빗 EC2로도 통신이 잘 되는지를 확인함으로써, 전체 메시형 네트워크 토폴로지가 문제 없이 구성되어 있음을 검증했습니다.

5. VPC 피어링 연결에서 네트워크 트래픽 제어

Amazon VPC의 라우팅 테이블(Route Table)을 활용하여 VPC 피어링 간 특정 트래픽만 허용하고 나머지는 차단하는 방법을 실습했습니다. 목표는 vpc1의 퍼블릭 EC2 인스턴스에서 vpc3의 프라이빗 EC2 인스턴스로의 통신을 의도적으로 제한하는 것입니다. 다른 모든 인스턴스 간 통신은 허용되도록 설정합니다.

vpc1-PUBLIC-RouteTable에서 10.30.0.0/16 경로 항목을 10.30.50.0/24변경하였습니다.

vpc1-public-ec2에서 -> ping vpc3-public-ec2, ping vpc3-private-ec2 각 IP를 넣어서 연결 테스트를 하면, 연결은 vpc3-public-ec2에서만 성공하고 vpc3-private-ec2에서는 실패가 되었습니다.

하지만 vpc1-public-ec2 -> vpc2-public-ec2, vpc2-private-ec2 각 IP를 넣어서 연결 테스트를 하면, 연결은 vpc2-public-ec2와 vpc2-private-ec2 모두에서 작동해야 합니다.

라우팅 제어만으로도 VPC 간 트래픽 제한이 가능하며, 보안 그룹이나 NACL 설정 없이도 세분화된 제어를 할 수 있음을 확인하였습니다.

6. VPC 피어링 연결 제거

향후 AWS Transit Gateway 구성을 준비하기 위해, 기존에 설정해 둔 모든 VPC 피어링 연결을 정리하고 그에 따른 라우팅 테이블 정리 작업까지 수행했습니다.

vpc1-vpc2-peering
vpc1-vpc3-peering
vpc2-vpc3-peering
각각 제거

vpc3-PRIVATE-RouteTable에서 블랙혹 확인

vpc3-PUBLIC-RouteTable, vpc3-PRIVATE-RouteTable 같은 방법으로 블랙홀 부분 삭제

모든 피어링 연결의 상태가 Deleted로 변경된 것을 확인
오리건 리전의 라우팅 테이블에서는 경로가 자동으로 삭제됨
버지니아 리전에서는 Blackhole 상태의 경로를 수동으로 정리 완료
두 리전 모두에 남아 있는 피어링 연결 없음, 라우팅 테이블 또한 정상화 완료

7. AWS Transit Gateway 연결 설정

AWS Transit Gateway를 사용하여 3개의 VPC를 보다 효율적으로 연결하는 네트워크 구조를 구성하였습니다. 이전 태스크에서는 각 VPC 간 직접 피어링을 통해 풀 메시 형태로 VPC를 1:1로 연결해야 했지만, Transit Gateway를 사용하면 하나의 중앙 허브를 통해 VPC를 간접적으로 연결할 수 있어 구조가 훨씬 단순해지고 관리가 용이해집니다.

🔍 Transit Gateway 개념 요약

Transit Gateway: 여러 VPC 및 온프레미스 네트워크를 중앙에서 연결하는 네트워크 허브
Attachment: Transit Gateway와 연결된 VPC 또는 다른 네트워크 리소스
Association: 각 Attachment는 하나의 TGW 라우팅 테이블과 연결됨
Routing Table: 정적 또는 동적으로 경로를 관리하며, 이 실습에서는 기본 테이블이 아닌 사용자 정의 테이블을 사용
경로 전파(Propagation): VPC에서 TGW로 직접 경로를 전파할 수는 없으며, 수동으로 정적 경로를 설정해야 함

오리건과 버지니아 리전 각각에 AWS Transit Gateway를 생성하고, 이후의 VPC 연결 및 피어링 구성을 위한 기초 작업을 마쳤습니다. 기본 라우팅 테이블 기능은 모두 비활성화하여 더 세분화된 경로 관리가 가능한 사용자 정의 설정 기반 아키텍처로 준비하였습니다.

이제 각 VPC를 이 Transit Gateway에 연결하고, 필요한 라우팅 테이블 및 피어링 설정을 통해 중앙집중형 네트워크 허브 구성을 완성할 준비가 되었습니다.

8. AWS Transit Gateway Attachment 구성

이전에 생성한 AWS Transit Gateway와 각 VPC를 실제 연결(Attachment) 하여 네트워크 통신이 가능하도록 구성했습니다.
또한 리전 간 트래픽 전달을 위해 Transit Gateway 간의 Peering Attachment도 설정했습니다.

Attachment의 두 가지 유형

VPC Attachment
- Transit Gateway와 각 VPC를 직접 연결
- 이를 통해 각 VPC가 Transit Gateway를 통해 통신 가능
Transit Gateway Peering Attachment
- 서로 다른 리전의 Transit Gateway 간 연결
- 리전 간 라우팅을 위해 필수적인 구성 요소

vpc1에서 Transit Gateway VPC Attachment, vpc2에서 Transit Gateway VPC Attachment 구성

vpc3에서 Transit Gateway VPC Attachment 구성

오리건 리전에서 Transit Gateway Peering Attachment 구성

버지니아 북부 리전에서 Transit Gateway Peering Attachment 구성

(AWS Transit Gateway를 사용하여 여러 리전으로 트래픽을 라우팅할 때 Transit Gateway Peering Attachment가 필요합니다)

9. AWS Transit Gateway 연결을 통한 네트워크 트래픽 라우팅 구성

vpc1, vpc2, vpc3테이블 구성 사진

동일한 방법으로 각 테이블들 구성하였습니다.

버지니아 북부 리전에서 Transit Gateway 라우팅 테이블 구성 사진

오리건 리전에서 Transit Gateway 라우팅 테이블 구성 사진

오리건 리전에서 Transit Gateway Association 및 경로 전파 구성

버지니아 북부 리전에서 Transit Gateway Association 및 경로 전파 구성

결과 요약:

모든 VPC는 각자의 Transit Gateway에 연결되었고,
라우팅 테이블 설정을 통해 VPC 간 통신이 Transit Gateway를 통해 라우팅됩니다.
리전 간 통신은 TGW Peering과 고정 경로를 통해 처리되며,
전체 네트워크는 효율적이고 확장 가능한 구조로 전환됩니다.

10. AWS Transit Gateway 연결에서 네트워크 연결 테스트

AWS Systems Manager Session Manager를 사용하여 EC2 인스턴스에 브라우저 기반으로 접속한 뒤, ICMP ping 명령어를 사용해 Transit Gateway 연결을 통한 EC2 간 통신이 정상 동작하는지 검증합니다. 모든 EC2 인스턴스의 보안 그룹은 ICMP(ping)를 허용하도록 사전에 설정되어 있어야 합니다.

vpc1-public-ec2에 액세스

-> ping < vpc2publicInstanceIP >
-> ping < vpc2privateInstanceIP >

vpc2-public-ec2에 액세스

-> ping < vpc3publicInstanceIP >
-> ping < vpc3privateInstanceIP >

11. AWS Transit Gateway 연결에서 네트워크 트래픽 제어

오리건 리전에서 TGW 라우팅 수정

vpc1-tgw-Route-Table 선택
Routes 탭 → 기존 경로 10.30.0.0/16(vpc3 전체 범위) 삭제
CIDR: 10.30.50.0/24 (vpc3 퍼블릭 서브넷 범위)

→ Static route was created successfully 메시지 확인

연결 테스트

소스: vpc1-public-ec2
Session Manager로 접속 후 다음 명령 실행:

ping <vpc3-public-ec2의 프라이빗 IP> 성공
ping <vpc3-private-ec2의 프라이빗 IP> 실패

소스: vpc1-public-ec2 → vpc2 인스턴스들
둘 다 성공

소스: vpc2-public-ec2 → vpc3 인스턴스들
둘 다 성공

Transit Gateway 라우팅 테이블을 이용해 특정 경로만 허용함으로써 TGW 환경에서도 세밀한 트래픽 제어가 가능하다는 것을 보여줌
VRF처럼 각 VPC 연결에 대해 독립된 TGW Route Table을 갖도록 구성하면 유연한 네트워크 보안 제어 가능

11.마무리

VPC 피어링 구성

리전 간/리전 내 VPC 간 직접 연결 설정
라우팅 테이블을 통해 전체 메시 토폴로지 완성

VPC 라우팅 제어

특정 서브넷 간 통신을 허용하거나 차단
VPC 라우팅 테이블을 통한 세밀한 경로 설정

AWS Transit Gateway 구성

피어링보다 더 유연하고 확장 가능한 허브-스포크 네트워크 구성
VPC Attachment, Peering Attachment 설정

TGW 라우팅 테이블 관리

다중 TGW 라우팅 테이블로 가상 라우팅 및 전달(VRF) 구현
정적/동적 라우팅을 혼합하여 트래픽 경로 세밀 제어

이번 실습을 통해 처음으로 VPC 피어링과 Transit Gateway를 직접 구성해보면서, VPC 간 연결 방식과 네트워크 라우팅의 기본 원리를 이해할 수 있었습니다.

처음에는 다소 복잡하게 느껴졌지만, 피어링과 Transit Gateway의 차이를 직접 비교해보니 Transit Gateway가 구조적으로 더 단순하고 확장에 유리하다는 점이 인상 깊었습니다.

또한 라우팅 테이블을 수정하면서 트래픽 흐름을 제어할 수 있다는 점이 새로웠고, 실제로 ping 테스트를 해보며 서브넷 간 통신이 어떻게 되는지 확인한 경험이 큰 도움이 되었습니다.

앞으로는 이런 기본기를 바탕으로 보안 제어, 접근 정책, 비용 최적화 같은 실무 개념도 더 잘 이해할 수 있을 것 같습니다!