Transit Gateway로 전용선 위에 암호화 터널을 구성하는 방법
Direct Connect 기반 Private IP VPN은 전용선 경로 위에 IPsec 암호화 터널을 구성하는 방식입니다. 이 글은 실제 콘솔 캡처가 아니라 AWS 공식 구조를 기준으로 DX, DXGW, Transit VIF, TGW, VPN, VPC가 어떻게 연결되는지 설명합니다.
AWS Direct Connect 기반 Private IP VPN 구조를 DXGW, Transit VIF, Transit Gateway, IPsec 터널과 라우팅 흐름 중심으로 설명합니다.
Direct Connect 위에 VPN을 구성한다는 의미
Direct Connect 위에 VPN을 구성한다는 말은 인터넷을 통해 Site-to-Site VPN을 연결한다는 뜻이 아닙니다. 전용선인 Direct Connect 경로를 사용하면서, 그 위에 IPsec 암호화 터널을 추가하는 구조를 뜻합니다.
AWS에서는 이 구조를 Private IP VPN 관점으로 이해하는 것이 좋습니다. VPN 터널의 외부 IP가 공인 인터넷 경로가 아니라 Direct Connect를 통해 도달 가능한 사설 경로를 사용하기 때문입니다.
이 글은 실제 테스트 로그나 콘솔 캡처가 아니라 개념과 구성 흐름을 설명하는 설계 가이드입니다. 목표는 어떤 리소스가 왜 필요하고, 트래픽이 어떤 순서로 이동하는지 이해하는 것입니다.
일반 Site-to-Site VPN과 Private IP VPN의 차이
일반 Site-to-Site VPN은 온프레미스 VPN 장비의 공인 IP와 AWS VPN 엔드포인트의 공인 IP 사이에 IPsec 터널을 구성합니다. 전송 경로는 인터넷입니다.
Private IP VPN은 IPsec 터널 자체는 동일하게 사용하지만, 터널 엔드포인트에 도달하는 경로가 Direct Connect 기반 사설 연결입니다. 즉 전송 경로는 DX이고, 암호화는 VPN이 담당합니다.
이 차이 때문에 Private IP VPN은 전용선의 안정성과 IPsec 암호화를 함께 요구하는 환경에서 검토됩니다. 금융, 공공, 규제 산업처럼 전용 회선과 암호화 요구가 동시에 있는 경우에 적합합니다.
왜 DX만으로 부족하고 VPN을 함께 쓰는가
Direct Connect는 전용 네트워크 연결을 제공합니다. 하지만 DX 자체가 애플리케이션 데이터 전체를 IPsec으로 암호화하는 것은 아닙니다. 전송 경로를 전용선으로 만들 뿐, 암호화 요구는 별도로 판단해야 합니다.
기업 보안 정책에서 전용 회선만으로 부족하다고 판단하면 VPN을 함께 사용합니다. 이때 DX는 안정적인 사설 전송 경로가 되고, VPN은 터널 암호화와 인증을 담당합니다.
다만 DX와 VPN을 함께 쓰면 구조가 복잡해집니다. DXGW, Transit VIF, TGW, VPN Attachment, BGP, Route Table이 모두 연결되므로 각 리소스의 역할을 분리해서 이해해야 합니다.
전체 아키텍처: On-prem, DX, DXGW, Transit VIF, TGW, VPN, VPC
전체 구조는 온프레미스 라우터에서 시작해 Direct Connect 회선을 지나 AWS Direct Connect location으로 들어옵니다. 이후 Transit VIF가 Direct Connect Gateway에 연결되고, Direct Connect Gateway는 Transit Gateway와 연결됩니다.
Transit Gateway는 여러 VPC와 VPN Attachment를 연결하는 중앙 허브 역할을 합니다. Private IP VPN은 이 TGW를 기준으로 생성되고, VPC Attachment와 VPN 경로가 TGW Route Table에서 제어됩니다.
개념적으로 보면 DX는 물리·전송 경로, DXGW는 DX와 TGW를 이어주는 글로벌 라우팅 구성요소, TGW는 AWS 내부 네트워크 허브, VPN은 암호화 터널입니다.
| 구성요소 | 역할 | 설계 포인트 |
|---|---|---|
| Direct Connect | 온프레미스와 AWS 사이 전용 연결 | 회선, Location, 대역폭, 이중화 |
| Transit VIF | DX에서 DXGW로 연결되는 가상 인터페이스 | VLAN, BGP ASN, 피어 IP |
| Direct Connect Gateway | DX와 TGW를 연결하는 중간 게이트웨이 | TGW association, 허용 prefix |
| Transit Gateway | VPC와 VPN을 연결하는 중앙 라우팅 허브 | Attachment, Route Table, Propagation |
트래픽 흐름: 온프레미스에서 VPC까지 패킷이 이동하는 방식
온프레미스에서 VPC로 가는 트래픽은 먼저 온프레미스 라우터의 라우팅 테이블을 따라 DX 회선으로 전달됩니다. 이때 BGP를 통해 AWS 측 prefix와 온프레미스 prefix가 교환되어 있어야 합니다.
DX 경로를 통해 AWS에 도달한 트래픽은 Direct Connect Gateway와 Transit Gateway 연결을 거쳐 VPN 터널 경로로 들어갑니다. VPN 터널은 IPsec으로 암호화된 논리 경로를 제공하고, 최종적으로 TGW Route Table을 통해 대상 VPC Attachment로 전달됩니다.
반대 방향도 중요합니다. VPC에서 온프레미스로 돌아가는 경로가 TGW와 VPC Route Table에 없으면 통신은 실패합니다. 그래서 이 구조에서는 왕복 경로와 라우팅 전파를 함께 검증해야 합니다.
구성에 필요한 값: ASN, CIDR, BGP, 터널 내부 IP, 공인/사설 IP
이 구조를 설계하려면 먼저 CIDR이 겹치지 않아야 합니다. 온프레미스 CIDR, VPC CIDR, 터널 내부 CIDR이 충돌하면 라우팅이 불안정해지고 문제 원인을 찾기 어려워집니다.
BGP ASN도 사전에 정해야 합니다. AWS 측 ASN, 고객 라우터 ASN, Transit VIF BGP 설정, VPN 터널 BGP 설정이 서로 맞아야 경로가 정상적으로 교환됩니다.
일반 인터넷 VPN에서는 공인 IP가 중요하지만, Private IP VPN에서는 DX 경로에서 도달 가능한 사설 IP와 터널 내부 IP 설계가 더 중요합니다. 장비별로 요구하는 값이 다르므로 AWS에서 제공하는 설정 파일의 의미를 이해해야 합니다.
라우팅 관점에서 봐야 할 핵심
DX 기반 Private IP VPN에서 가장 중요한 것은 라우팅입니다. 터널이 올라와도 TGW Route Table, VPC Route Table, 온프레미스 라우터 경로 중 하나라도 빠지면 통신은 되지 않습니다.
TGW Route Table에서는 VPC Attachment와 VPN Attachment의 경로 전파 여부를 확인해야 합니다. 어떤 Attachment가 어떤 Route Table에 연결되어 있고, 어떤 prefix가 전파되는지 설계해야 합니다.
VPC Route Table에는 온프레미스 CIDR을 대상으로 TGW를 향하는 라우트가 필요합니다. 온프레미스 라우터에도 VPC CIDR이 AWS 방향으로 광고되거나 정적으로 설정되어야 합니다.
이 구조가 적합한 경우와 적합하지 않은 경우
이 구조는 전용 회선과 암호화를 동시에 요구하는 환경에 적합합니다. 예를 들어 규제 산업, 민감 데이터 전송, 내부망 연동, 장기간 안정적인 대역폭이 필요한 워크로드에서 검토할 수 있습니다.
반대로 단순 테스트, 소규모 연결, 낮은 트래픽, 빠른 구축이 목적이라면 일반 Site-to-Site VPN이 더 단순할 수 있습니다. DX 회선과 DXGW, TGW, Private IP VPN을 모두 구성하는 것은 운영 복잡도가 높습니다.
따라서 설계 전에는 보안 요구사항, 회선 비용, 이중화 수준, 운영 인력, 장애 대응 능력을 함께 봐야 합니다. 기술적으로 가능하다는 이유만으로 선택하면 운영 부담이 커질 수 있습니다.
다음 편에서 다룰 구성 순서
다음 편에서는 실제 구성을 시작하기 전에 정해야 할 설계값을 다룹니다. 온프레미스 CIDR, VPC CIDR, ASN, BGP Peer IP, 터널 내부 CIDR, 라우팅 광고 범위를 먼저 정리해야 합니다.
이 값들이 정리되지 않은 상태에서 DX, TGW, VPN을 만들면 나중에 라우팅 충돌이나 BGP Down 원인을 찾기 어려워집니다. 특히 운영 환경에서는 네트워크팀, 보안팀, 클라우드팀이 같은 설계표를 공유해야 합니다.
1편은 전체 구조를 이해하는 글이고, 2편부터는 사전 준비, Direct Connect, Transit Gateway, Private IP VPN, 온프레미스 라우터, 라우팅 검증, 장애 대응 순서로 세부 내용을 이어갑니다.
이 글은 AWS Direct Connect Gateway 문서, AWS Site-to-Site VPN 문서, Transit Gateway와 Direct Connect Gateway association, Transit VIF 구성 개념을 기준으로 작성한 설계 가이드입니다.
SUMMARY
FAQ
Direct Connect만 쓰면 암호화가 되나요?
Direct Connect는 전용 연결을 제공하지만 IPsec 암호화를 자동으로 제공하는 것은 아닙니다. 암호화 요구가 있으면 VPN 같은 별도 암호화 계층을 함께 설계해야 합니다.
DX 위에 VPN을 올리면 일반 Site-to-Site VPN과 무엇이 다른가요?
일반 VPN은 인터넷 공인 IP 경로를 사용하고, DX 기반 Private IP VPN은 Direct Connect 사설 경로를 통해 터널을 구성한다는 점이 다릅니다.
이 구조에서 가장 자주 문제가 되는 부분은 무엇인가요?
대부분 라우팅입니다. BGP 세션, TGW Route Table, VPC Route Table, 온프레미스 라우터 경로 중 하나만 누락되어도 통신이 실패할 수 있습니다.
AWS Direct Connect 기반 Private IP VPN은 전용선의 안정성과 IPsec 암호화를 함께 요구하는 환경에서 고려할 수 있는 구조입니다. 하지만 DX, DXGW, Transit VIF, TGW, VPN, VPC Route Table이 모두 연결되기 때문에 단순 VPN보다 설계 난이도가 높습니다. 1편에서는 전체 구조와 트래픽 흐름을 이해하고, 다음 편부터는 ASN, CIDR, BGP, 터널 내부 IP 같은 사전 준비 항목을 하나씩 정리하는 방식으로 접근하는 것이 좋습니다.