VPN은 공용 네트워크 위에 암호화된 터널을 만들어 서로 다른 네트워크가 사설망처럼 통신할 수 있게 해준다. AWS 환경에서는 온프레미스 네트워크와 VPC를 연결할 때 Site-to-Site VPN을 자주 사용한다.
이번 글에서는 Site-to-Site VPN의 기본 개념을 먼저 살펴보고, AWS에서 온프레미스 환경과 사설 통신을 구성할 때 사용할 수 있는 주요 네트워크 옵션들을 함께 정리해보려고 한다.
1. VPN이란?
VPN은 Virtual Private Network의 약자다.
말 그대로 공용 네트워크 위에 가상의 사설 네트워크를 만드는 기술이다.
일반적으로 인터넷은 공용망이기 때문에 그대로 사용하면 보안상 위험할 수 있다. VPN은 이 공용망 위에 암호화된 터널을 만들고, 그 터널을 통해 데이터를 주고받는다. 그래서 외부에서 보기에는 인터넷을 사용하는 것처럼 보이지만, 실제 통신은 암호화된 사설 통신처럼 동작한다.
VPN은 크게 두 가지 방식으로 자주 나뉜다.
| 구분 | 설명 |
|---|---|
| Client VPN | 개인 사용자가 노트북이나 PC에서 회사 내부망에 접속할 때 사용하는 방식 |
| Site-to-Site VPN | 회사의 온프레미스 네트워크와 AWS VPC 같은 클라우드 네트워크를 연결하는 방식 |
이번 내용에서 다루는 것은 Client VPN이 아니라 Site-to-Site VPN이다.
2. Site-to-Site VPN이란?
Site-to-Site VPN은 두 개의 네트워크를 VPN 터널로 연결하는 방식이다.
예를 들어 회사 내부망이 있고, AWS 안에 VPC가 있다고 해보자.
이 둘은 기본적으로 서로 다른 네트워크다. 회사 내부 서버가 AWS의 EC2나 RDS에 접근해야 하거나, 반대로 AWS 리소스가 회사 내부 시스템과 통신해야 한다면 두 네트워크를 연결해야 한다.
이때 사용할 수 있는 대표적인 방식이 Site-to-Site VPN이다.
구조를 단순하게 표현하면 다음과 같다.
온프레미스 네트워크
|
Customer Gateway Device
|
IPsec VPN Tunnel
|
AWS VPN Gateway
|
VPC여기서 중요한 점은 Site-to-Site VPN이 인터넷을 아예 사용하지 않는 기술은 아니라는 것이다.
인터넷을 지나가긴 하지만, 그 위에 IPsec 기반의 암호화 터널을 만들어 안전하게 통신한다.
3. AWS Site-to-Site VPN의 구성 요소
AWS Site-to-Site VPN을 이해하려면 몇 가지 구성 요소를 알아야 한다.
Customer Gateway Device
온프레미스 쪽에 있는 실제 VPN 장비다.
예를 들면 방화벽, 라우터, VPN 장비, 또는 소프트웨어 VPN 장비가 될 수 있다.
이 장비가 AWS와 IPsec 터널을 맺는다.
Customer Gateway
AWS 안에서 온프레미스 VPN 장비를 표현하는 리소스다.
실제 장비는 아니고, AWS가 “상대편 VPN 장비는 이런 IP와 설정을 가진 장비다”라고 알 수 있도록 등록하는 정보라고 보면 된다.
보통 Customer Gateway를 만들 때는 다음 정보가 필요하다.
| 항목 | 설명 |
|---|---|
| Public IP | 온프레미스 VPN 장비의 공인 IP |
| Routing 방식 | Static Routing 또는 Dynamic Routing |
| BGP ASN | Dynamic Routing을 사용할 때 필요한 ASN 값 |
Virtual Private Gateway
AWS VPC에 붙이는 VPN 게이트웨이다.
온프레미스 네트워크와 특정 VPC를 연결할 때 사용할 수 있다.
규모가 크지 않고 단일 VPC 중심이라면 Virtual Private Gateway를 사용할 수 있다.
Transit Gateway
여러 VPC와 온프레미스 네트워크를 중앙에서 연결하는 허브 역할을 한다.
여러 VPC, 여러 계정, 여러 온프레미스 네트워크가 얽히는 구조라면 Transit Gateway를 사용하는 편이 더 적합하다.
쉽게 말하면 Virtual Private Gateway는 특정 VPC에 붙는 방식이고, Transit Gateway는 여러 네트워크를 중앙에서 모아주는 방식이다.
VPN Tunnel
AWS Site-to-Site VPN은 하나의 VPN 연결에 기본적으로 두 개의 터널을 제공한다.
이는 고가용성을 위한 구조다.
터널 하나에 문제가 생겨도 다른 터널로 통신을 유지할 수 있도록 설계되어 있다.
따라서 운영 환경에서는 두 터널을 모두 구성하고, 라우팅도 장애 상황에 대응할 수 있게 잡는 것이 중요하다.
4. VPN 터널이 끊겼다는 것은 무엇을 봐야 할까?
단순히 AWS 쪽 문제라고 단정하면 안 되고, AWS 설정, 온프레미스 장비, 라우팅, 방화벽, 회선 상태를 함께 봐야 한다.
대표적으로 확인할 내용은 다음과 같다.
| 점검 항목 | 설명 |
|---|---|
| Tunnel Status | AWS 콘솔에서 터널이 UP인지 DOWN인지 확인 |
| IKE/IPsec 설정 | 암호화 알고리즘, 인증 방식, 수명 값 등이 양쪽에서 맞는지 확인 |
| BGP 상태 | Dynamic Routing을 쓴다면 BGP 세션이 정상인지 확인 |
| Route Table | VPC 라우팅 테이블에 온프레미스 대역으로 가는 경로가 있는지 확인 |
| Security Group | EC2 등 대상 리소스에서 온프레미스 대역을 허용하는지 확인 |
| NACL | 서브넷 네트워크 ACL이 트래픽을 막고 있지 않은지 확인 |
| 온프레미스 방화벽 | UDP 500, UDP 4500, ESP 등 VPN 관련 트래픽이 허용되는지 확인 |
| 공인 IP 변경 여부 | Customer Gateway에 등록된 온프레미스 공인 IP가 바뀌지 않았는지 확인 |
| ISP 회선 상태 | 인터넷 회선 장애나 품질 저하가 있었는지 확인 |
여기서 특히 중요한 것은 “터널이 끊겼다”는 말이 정확히 어떤 상태를 의미하는지 구분하는 것이다.
예를 들어 IPsec 터널 자체가 내려간 것인지, 터널은 살아 있는데 BGP만 끊긴 것인지, 라우팅이 잘못되어 통신만 안 되는 것인지에 따라 원인과 해결 방법이 달라진다.
5. AWS에서 제공하는 프라이빗 통신 옵션
AWS에서는 온프레미스와 AWS, 또는 AWS 내부 네트워크끼리 사설 통신을 하기 위해 여러 옵션을 제공한다.
5-1. AWS Site-to-Site VPN
가장 기본적인 하이브리드 네트워크 연결 방식이다.
온프레미스 네트워크와 AWS VPC를 IPsec VPN 터널로 연결한다.
장점은 비교적 빠르게 구축할 수 있고 비용 부담이 Direct Connect보다 낮다는 점이다.
단점은 인터넷 기반이기 때문에 네트워크 품질이 인터넷 회선 상태에 영향을 받을 수 있다는 점이다.
사용하기 좋은 상황은 다음과 같다.
| 상황 | 이유 |
|---|---|
| 빠르게 온프레미스와 AWS를 연결해야 할 때 | 전용 회선 없이 구성 가능 |
| 초기 구축 또는 테스트 환경 | 비용과 구축 난이도가 낮음 |
| 대역폭 요구가 아주 크지 않을 때 | 일반적인 업무 트래픽에 적합 |
5-2. AWS Direct Connect
Direct Connect는 온프레미스와 AWS를 전용 네트워크 회선으로 연결하는 서비스다.
인터넷을 거치지 않고 전용 연결을 사용하기 때문에 더 안정적이고 일관된 네트워크 품질을 기대할 수 있다.
다만 Site-to-Site VPN보다 구축 과정이 복잡하고, 회선 준비에도 시간이 걸릴 수 있다.
사용하기 좋은 상황은 다음과 같다.
| 상황 | 이유 |
|---|---|
| 안정적인 네트워크 품질이 중요할 때 | 인터넷 품질 영향을 줄일 수 있음 |
| 대용량 데이터 전송이 많을 때 | 높은 대역폭 구성에 적합 |
| 운영 환경에서 장기적으로 사용할 때 | 예측 가능한 네트워크 구성이 가능 |
5-3. Direct Connect + VPN
Direct Connect는 전용 회선을 제공하지만, 기본적으로 모든 구간을 자동으로 암호화해주는 개념은 아니다.
그래서 보안 요구사항에 따라 Direct Connect 위에 VPN을 함께 구성하기도 한다.
이 방식은 Direct Connect의 안정성과 VPN의 암호화를 함께 가져가고 싶을 때 사용할 수 있다.
5-4. Transit Gateway
Transit Gateway는 여러 VPC와 온프레미스 네트워크를 중앙에서 연결하는 허브 역할을 한다.
VPC가 하나일 때는 구조가 단순하지만, VPC가 여러 개로 늘어나면 각각을 개별적으로 연결하기 어렵다.
이때 Transit Gateway를 사용하면 네트워크 연결을 중앙에서 관리할 수 있다.
예를 들어 다음과 같은 구조를 만들 수 있다.
온프레미스
|
Site-to-Site VPN
|
Transit Gateway
| | |
VPC A VPC B VPC C사용하기 좋은 상황은 다음과 같다.
| 상황 | 이유 |
|---|---|
| 여러 VPC를 연결해야 할 때 | 중앙 허브 구조로 관리 가능 |
| 여러 계정의 VPC를 연결해야 할 때 | AWS RAM과 함께 사용 가능 |
| 온프레미스와 여러 VPC가 통신해야 할 때 | VPN 또는 Direct Connect와 연계 가능 |
5-5. VPC Peering
VPC Peering은 VPC와 VPC를 사설 IP로 직접 연결하는 방식이다.
두 VPC 간 통신이 필요할 때 사용할 수 있다.
다만 VPC Peering은 전이 라우팅을 지원하지 않는다.
예를 들어 VPC A와 VPC B가 Peering 되어 있고, VPC B와 VPC C가 Peering 되어 있다고 해서 VPC A가 VPC C와 자동으로 통신할 수 있는 것은 아니다.
사용하기 좋은 상황은 다음과 같다.
| 상황 | 이유 |
|---|---|
| VPC 두 개를 단순히 연결할 때 | 구성이 비교적 간단함 |
| 낮은 지연 시간이 필요할 때 | AWS 내부 사설망을 통해 통신 |
| 소규모 VPC 간 연결 | 복잡한 허브 구조가 필요 없을 때 적합 |
5-6. AWS PrivateLink
PrivateLink는 네트워크 전체를 연결하는 방식이라기보다, 특정 서비스에 사설로 접근하게 해주는 방식이다.
예를 들어 어떤 VPC 안에 서비스가 있고, 다른 VPC나 온프레미스에서 그 서비스에 접근해야 한다고 해보자.
이때 전체 네트워크를 열지 않고도 PrivateLink를 통해 특정 서비스만 안전하게 노출할 수 있다.
AWS 서비스에 접근할 때도 VPC Endpoint를 사용하면 인터넷 게이트웨이나 NAT 없이 사설로 접근할 수 있다.
사용하기 좋은 상황은 다음과 같다.
| 상황 | 이유 |
|---|---|
| 특정 서비스만 사설로 제공하고 싶을 때 | 전체 네트워크 연결이 필요 없음 |
| AWS 서비스에 사설로 접근하고 싶을 때 | VPC Endpoint 사용 가능 |
| 보안상 네트워크 노출 범위를 줄이고 싶을 때 | 필요한 서비스만 열 수 있음 |
6. 옵션 비교 정리
| 옵션 | 연결 대상 | 인터넷 사용 여부 | 주요 특징 | 적합한 상황 |
|---|---|---|---|---|
| Site-to-Site VPN | 온프레미스 ↔ AWS | 사용함 | IPsec 암호화 터널 | 빠른 구축, 초기 연결 |
| Direct Connect | 온프레미스 ↔ AWS | 사용하지 않음 | 전용 회선 | 안정적인 운영 환경 |
| Direct Connect + VPN | 온프레미스 ↔ AWS | 전용 회선 기반 | 전용 회선 + 암호화 | 보안과 안정성 모두 필요할 때 |
| Transit Gateway | 여러 VPC, 온프레미스 | 구성에 따라 다름 | 중앙 허브 | 대규모 네트워크 연결 |
| VPC Peering | VPC ↔ VPC | 사용하지 않음 | VPC 간 직접 연결 | 단순한 VPC 간 통신 |
| PrivateLink | VPC ↔ 특정 서비스 | 사용하지 않음 | 서비스 단위 사설 접근 | 특정 서비스만 안전하게 노출 |
7. 정리
이번 과제의 핵심은 VPN 장애 하나를 외우는 것이 아니라, AWS에서 네트워크가 어떤 방식으로 연결되는지 이해하는 데 있다.
Site-to-Site VPN은 온프레미스와 AWS를 연결할 때 가장 기본적으로 떠올릴 수 있는 방식이다.
하지만 모든 상황에서 Site-to-Site VPN만 정답은 아니다.
빠르게 연결해야 한다면 Site-to-Site VPN이 적합할 수 있고, 안정적인 전용 회선이 필요하다면 Direct Connect를 고려해야 한다.
VPC가 많아지고 네트워크 구조가 복잡해지면 Transit Gateway가 필요해질 수 있다.
VPC 간 단순 연결은 VPC Peering으로 해결할 수 있고, 특정 서비스만 사설로 노출하고 싶다면 PrivateLink가 더 적합하다.
결국 중요한 것은 “무엇을 어디와 연결할 것인가”, “얼마나 안정적이어야 하는가”, “보안 요구사항은 어느 정도인가”, “운영 규모가 얼마나 큰가”를 기준으로 연결 방식을 선택하는 것이다.
이번 VPN 터널 끊김 문제도 같은 관점에서 봐야 한다.
터널 상태만 보는 것이 아니라, 라우팅, BGP, 보안 그룹, NACL, 온프레미스 장비, 인터넷 회선 상태까지 함께 확인해야 원인을 제대로 좁힐 수 있다.
