Direct Connect를 도입한 뒤에도 VPN을 함께 보는 이유는 분명합니다. 하나는 암호화이고, 다른 하나는 장애 대비입니다. 다만 VPN을 붙였다는 사실만으로 자동 백업이 완성되는 것은 아닙니다.
Direct Connect와 Site-to-Site VPN을 함께 쓰는 이유를 암호화, 백업 경로, 라우팅 설계 관점에서 설명합니다. DX 위에 VPN을 얹는 구성과 인터넷 VPN을 백업으로 두는 구성을 구분하고, BGP와 static routing 차이가 장애 전환에 어떤 영향을 주는지 정리합니다.
Direct Connect만으로 충분하지 않은 경우
Direct Connect는 더 예측 가능한 경로를 제공하지만, 기본적으로 전송 중 트래픽을 자동 암호화해 주지는 않습니다. 또한 회선 하나를 만들었다고 해서 장애 대비가 끝나는 것도 아닙니다. 그래서 실무에서는 Direct Connect를 도입한 뒤에도 “이 트래픽은 암호화가 필요한가”, “이 경로가 끊기면 어디로 우회할 것인가”를 별도로 묻습니다.
이 질문에 답하다 보면 Site-to-Site VPN이 다시 등장합니다. VPN은 Direct Connect의 대체재라기보다, 특정 요구를 보완하는 도구로 보는 편이 정확합니다. 암호화가 필요할 때는 DX 위에 VPN을 얹을 수 있고, 별도 인터넷 경로를 백업으로 둘 수도 있습니다.
Site-to-Site VPN을 함께 쓰는 이유
VPN을 함께 쓰는 이유는 크게 두 가지입니다. 첫째는 암호화입니다. AWS 공식 문서도 Direct Connect 자체는 기본적으로 암호화되지 않으며, 전송 중 데이터를 암호화하려면 별도 암호화 옵션을 써야 한다고 설명합니다. Site-to-Site VPN은 이 요구를 해결할 수 있는 대표적인 방법입니다.
둘째는 복원력입니다. 전용 연결이 장애를 겪을 때 인터넷 기반 VPN을 다른 경로로 두면 운영 선택지가 넓어집니다. 다만 여기서 중요한 것은 “VPN이 있다”는 사실보다, 실제 라우팅이 어떤 우선순위와 전환 조건으로 설계되어 있느냐입니다.
암호화가 필요한 경우와 아닌 경우
Direct Connect는 전용 연결이기 때문에 종종 “이미 안전한 것 아닌가”라는 인상을 줍니다. 하지만 전용 연결과 암호화는 같은 말이 아닙니다. 규제 요구사항, 내부 보안 정책, 민감 데이터 전송 기준이 있다면 별도의 전송 암호화가 필요한지 따로 판단해야 합니다.
AWS 문서는 Direct Connect와 Site-to-Site VPN을 결합해 IPsec 암호화된 private connection을 만들 수 있다고 안내합니다. 이 구조는 공용 인터넷 VPN보다 더 일관된 네트워크 경험을 기대하면서도 암호화 요구를 충족하고 싶은 경우에 잘 맞습니다. 반대로 트래픽 자체가 이미 애플리케이션 계층에서 충분히 암호화되고 있고 네트워크 계층 암호화 요구가 없다면, 굳이 VPN을 추가하지 않는 판단도 가능합니다.
DX 위에 VPN을 얹는다는 말의 의미
“DX 위에 VPN을 얹는다”는 말은 Direct Connect가 경로를 제공하고, 그 위에서 VPN이 암호화 터널을 만든다는 뜻입니다. 즉, 하나는 네트워크 경로를, 다른 하나는 전송 보호를 담당합니다. 둘의 역할이 다르기 때문에 함께 쓸 수 있습니다.
이 구성이 특히 유용한 이유는 인터넷 기반 VPN보다 더 안정적인 기반 위에서 IPsec 터널을 운영할 수 있기 때문입니다. 다만 운영 관점에서는 터널 상태, 라우팅, 키 교환, 장애 전환까지 관리 대상이 늘어납니다. 보안 수준은 높아질 수 있지만, 운영 복잡도도 함께 증가합니다.
전용회선과 인터넷 VPN을 함께 설계하는 방식
Direct Connect와 VPN을 함께 쓰는 방법은 하나만 있는 것이 아닙니다. 대표적으로는 두 가지 패턴이 있습니다. 하나는 DX 위의 암호화이고, 다른 하나는 인터넷 VPN을 별도 백업 경로로 두는 구조입니다. 전자는 보안 요구를 보완하고, 후자는 장애 시 우회 경로를 마련합니다.
| 구성 | 주된 목적 | 운영 포인트 |
|---|---|---|
| DX + VPN over DX | 전용 경로 위 암호화 | 보안 요구 충족, 터널 운영 복잡도 증가 |
| DX + 인터넷 VPN | 별도 백업 경로 | 라우팅 우선순위와 장애 전환 설계가 핵심 |
| DX만 사용 | 단순한 전용 연결 | 암호화·우회 경로는 별도 검토 필요 |
문제는 이 두 패턴을 섞어 생각할 때 생깁니다. 암호화를 위해 VPN을 추가한 것인지, 장애 대비를 위해 VPN을 추가한 것인지부터 분명히 하지 않으면 설계가 흐려집니다.
BGP를 함께 쓸 때 failover가 어떻게 달라지는가
Site-to-Site VPN에서 고객 장비가 BGP를 지원한다면 AWS는 dynamic routing 사용을 권장합니다. 공식 문서는 BGP가 더 강한 liveness detection을 제공해 첫 번째 터널이 내려갔을 때 두 번째 터널로 전환하는 데 도움이 된다고 설명합니다. 그래서 백업 경로를 설계할 때 BGP 지원 여부는 단순 기능 체크가 아니라 장애 대응 품질과 연결됩니다.
반대로 static routing은 장비가 BGP를 지원하지 않을 때 선택할 수 있지만, 경로 우선순위와 장애 감지 방식이 달라집니다. 동일한 경로가 존재할 때는 정적 경로가 BGP 경로보다 우선될 수 있으므로, “백업으로만 쓰고 싶다”는 의도와 실제 동작이 어긋나지 않도록 반드시 확인해야 합니다.
VPN을 추가했다고 failover가 자동 완성되는 것은 아닙니다. 어떤 경로를 우선으로 볼지, 장애를 무엇으로 감지할지, 같은 prefix가 들어왔을 때 어떤 경로를 고를지까지 설계해야 합니다.
Active / Standby 백업 경로로 볼 때의 장단점
운영팀이 흔히 원하는 그림은 Direct Connect를 주 경로로 두고, VPN을 보조 경로로 두는 Active / Standby 구조입니다. 이 방식은 평상시 품질을 유지하면서 장애 시 우회할 수 있다는 점에서 이해하기 쉽습니다. 다만 실제로는 라우팅 메트릭, 광고 prefix, 장비 정책이 맞아야 의도한 standby 동작이 나옵니다.
장점은 명확합니다. 평소에는 전용 경로를 쓰고, 장애 시 우회 수단을 확보할 수 있습니다. 단점도 분명합니다. 두 경로의 성능 특성이 다르고, 장애가 났을 때 애플리케이션이 체감하는 지연이나 처리량도 달라질 수 있습니다. 그래서 백업 경로는 “있다”보다 “테스트했다”가 훨씬 중요합니다.
DX + VPN 구성에서 자주 놓치는 제약사항
첫째, 모든 VPN 장비가 static과 dynamic routing을 둘 다 지원하는 것은 아닙니다. 고객 게이트웨이 장비가 BGP를 지원하면 dynamic routing을 쓰고, 지원하지 않으면 static routing을 선택합니다. Site-to-Site VPN Concentrator는 BGP만 지원합니다.
둘째, DX 위에 VPN을 붙였다고 운영이 단순해지는 것은 아닙니다. 터널 상태, 키 관리, BGP 상태, 경로 우선순위까지 관찰해야 할 대상이 늘어납니다. 셋째, 인터넷 VPN을 백업으로 둘 때도 실제 장애 전환이 기대대로 되는지는 별도 검증해야 합니다. 네트워크 설계에서 가장 위험한 가정은 “붙여 두었으니 알아서 되겠지”입니다.
어떤 상황에서 이 구성이 가장 실용적인가
핵심 요약
Direct Connect와 VPN을 함께 쓰는 이유는 분명합니다. DX는 더 안정적인 경로를 만들고, VPN은 암호화나 별도 우회 경로를 보완합니다. 역할이 다르기 때문에 함께 쓸 수 있고, 실제로 많은 하이브리드 네트워크 설계에서 같이 검토됩니다.
다만 설계 질문은 늘 분리해야 합니다. 지금 필요한 것이 암호화인지, 백업인지, 둘 다인지 먼저 나누고, 그다음 BGP와 static routing, 경로 우선순위, 실제 장애 전환 테스트를 봐야 합니다. 이 순서를 지키면 VPN은 장식이 아니라 설계의 일부가 됩니다.
핵심 요약
Direct Connect와 VPN의 관계는 경쟁이 아니라 조합에 가깝습니다. 전용 경로가 필요한 이유와 암호화가 필요한 이유는 다르고, 장애 대비가 필요한 이유는 또 다릅니다. 이 차이를 분리해서 볼수록 구조는 더 선명해집니다.
좋은 하이브리드 네트워크는 회선 이름이 화려한 구조가 아니라, 장애가 났을 때 왜 그렇게 움직이는지 설명할 수 있는 구조입니다. DX와 VPN을 함께 쓴다면, 그 설명 가능성까지 함께 설계해야 합니다.
'AWS Guides' 카테고리의 다른 글
| Direct Connect 이중화와 장애 점검: Active/Active, Active/Passive, 통신 장애를 보는 순서 (0) | 2026.05.16 |
|---|---|
| Direct Connect 확장 설계: Transit Gateway로 여러 VPC를 연결하는 방법 (0) | 2026.05.16 |
| Direct Connect를 VPC에 연결하는 방법: VGW와 DX Gateway를 언제 쓰는가 (0) | 2026.05.16 |
| Direct Connect 라우팅 이해하기: BGP와 Static, ASN, Prefix, VLAN까지 (0) | 2026.05.16 |
| AWS Direct Connect 전체 구조 이해하기: Connection, VIF, VGW, DX Gateway 한 번에 정리 (0) | 2026.05.16 |