서론 : VPN은 왜 필요한가
회사 서버가 AWS 클라우드에 있고, 재택근무 중인 직원이 사내 시스템에 안전하게 접속해야 하는 상황을 가정하자.
인터넷은 누구나 접근 가능한 공개된 네트워크다.
이 상태로 회사 내부 시스템에 직접 연결한다면, 도청·위변조·세션 탈취 같은 보안 위협에 그대로 노출된다.
이때 필요한 기술이 바로 VPN(Virtual Private Network), 즉 가상 사설망이다.
VPN은 인터넷이라는 공개된 도로 위에
암호화된 터널을 만들어 마치 전용선을 쓰는 것처럼 안전하게 데이터를 주고받게 해준다.
AWS에서 제공하는 VPN의 두 가지 형태
AWS는 목적에 따라 두 가지 VPN 서비스를 제공한다.
- Site-to-Site VPN : 네트워크와 네트워크를 연결 (예: 본사 ↔ AWS)
- Client VPN : 개인 PC와 네트워크를 연결 (예: 재택 직원 ↔ AWS)
이 글에서는 먼저 Site-to-Site VPN을 다룬다.
핵심은 개인 PC가 아니라, On-premise 네트워크 전체가 AWS VPC 전체와 통신할 수 있게 된다.
이 구조를 이해하려면, AWS 이전에 먼저 IPsec VPN 프로토콜의 동작 원리를 이해해야 한다.
※ IPsec은 AWS만의 기술이 아니라, Cisco, Juniper, Palo Alto 등 모든 네트워크 장비에서 지원하는 범용 기술이다.
왜 IPsec을 먼저 알아야 하는가
IPsec은 AWS 만의 기술이 아니다.
Cisco Juniper, Palo Alto, FortiGate 등 대부분의 네트워크 장비에서 공통으로 사용하는 산업 표준이다.
AWS Site-to-Site VPN은 이 IPsec 표준을 AWS 인프라 환경에 맞게 관리형 서비스로 구현한 것이다.
따라서 IPsec의 구조를 이해하면:
- AWS 설정의 의미가 보이고
- 장애 발생 시 로그를 해석할 수 있으며
- 장비 간 연동 이슈를 스스로 판단할 수 있다.
Part 1: IPsec VPN 동작 원리 (표준 프로토콜)
IPsec VPN이 동작하려면 세 단계가 필요하다: 신원 확인 → 암호화 협상 → 경로 설정
1단계 : 서로 신원 확인 및 협상 (IKE Phase 1)
VPN으로 연결될 두 네트워크는 먼저 서로 신뢰할 수 있는 대상인지 확인해야 한다.
이 과정이 IKE Phase1 (ISAKMP) 이다.
이 단계에서 수행되는 작업은 다음과 같다.
- 사전 공유 키(PSK) 또는 인증서를 통해 상호 인증한다.
- 사용할 암호화 방식을 협상한다.
- IKE 버전 (IKEv1/IKEv2)
- 암호 알고리즘 (AES 등)
- 무결성(SHA)
- Diffie-Hellman(DH) 그룹을 사용해 암호화 키를 교환한다.
- IKE SA (Security Association)가 생성된다.
쉽게 말해, 실제 데이터를 주고 받기 전에 안전한 제어 채널(Control Plane)을 만든다.
2단계 : 데이터 암호화 규칙 협상 (IKE Phase 2)
Phase 1이 완료되면, 이제 실제 트래픽을 암호화해 전송하는 IKE Phase 2 (IPsec)가 진행된다.
구체적으로는:
- 실제 데이터를 암호화할 IPsec SA (Security Association)를 만든다.
- 어떤 트래픽이 VPN 터널을 사용할지 정의한다. (Traffic Selector)
- ESP (Encapsulating Security Payload) 프로토콜로 패킷을 암호화하고 캡슐화한다.
- PFS (Perfect Forward Secrecy) 사용 여부와 SA 수명을 설정한다.
IKE로 보안 협상을 하고(Control Plane), IPsec로 실제 트래픽을 암호화해 전송한다.(Data Plane)
3 단계 : 트래픽 경로 설정 (Routing)
여기서 많은 장애가 발생한다.
"터널이 연결되었다" ≠ "통신이 된다"
암호화 터널이 준비돼 있어도,
패킷이 어느 경로로 가야 하는지를 모르면 데이터는 흐르지 않는다.
이 역할을 하는 것이 라우팅 (Routing)이다.
방법 1: 정적 라우팅 (Static Routing)
- AWS 설정에서 "10.0.0.0/16 네트워크는 VPN으로 보낼 것"을 직접 입력
- On-premise에서도 반대 방향 경로를 설정
- 간단하지만, 네트워크가 바뀔 때마다 수동으로 수정해야 함.
방법 2: 동적 라우팅 (Dynamic Routing)
- VPN 터널 안에서 양쪽이 자동으로 경로 정보를 주고 받음 (BGP)
- 네트워크 변경 시 자동으로 반영되고, 장애 시 다른 경로로 우회
- 운영이 훨씬 편리하고 안정적임.
- Site-to-Site VPN : 로그에서 터널 활동 및 BGP routing 로그를 볼 수 있다.
운영 안정성과 확장성 측면에서 BGP를 사용하는 것이 권장된다.
Part 2: AWS Site-to-Site VPN 구현
AWS Site-to-Site VPN 구성 요소
AWS Site-to-Site VPN은 앞서 설명한 IPsec 표준 프로토콜을 AWS 인프라에 맞게 구현한 관리형 서비스다.
그 구성 요소는 다음과 같다:
- Customer Gateway (CGW): 고객 측(On-premise / 방화벽 / 라우터)의 VPN 종단 장비 / 논리 객체
- Virtual Private Gateway (VGW) 또는 Transit Gateway (TGW): AWS 측 VPN endpoint
- VPN Connection: CGW ↔ VGW/TGW 사이의 논리 연결
- Tunnel 2개: AWS Site-to-Site VPN은 기본적으로 이중 터널을 제공(가용성/유지보수 대비)
이러한 구성 요소들이 조합되어, 고객 네트워크와 AWS 클라우드 간 안전하고 안정적인 연결을 만들 수 있다.
특히 AWS의 터널 이중화 전략은 운영 안정성의 핵심이다.
터널 이중화 전략
AWS가 기본적으로 2개의 터널을 제공하는 이유는 고가용성(High Availability) 때문이다:
- 유지보수성 : AWS가 터널1의 endpoint 장비를 점검할 때, 터널 2로 자동 우회한다.
- 네트워크 장애 : 한쪽 경로에 문제가 생겨도 서비스 중단은 없다.
- 로드 밸런싱 : 일부 장비는 두 터널에 트래픽을 분산할 수 있다.
실무 점검 사항 :
- 반드시 양쪽 터널 모두 활성화 : 한쪽만 설정하면 평소엔 되다가 유지보수 / 장애 시 서비스가 중단될 수 있다.
- BGP 사용 시 경로 우선순위 설정 : AS Path Prepending, Local Preference 등으로 Primary / Secondary 터널을 지정한다.
- 터널 상태 모니터링 : CloudWatch Metrics로 TunnelState, TennelDataIn/OUt을 추적한다.
Site-to-Site VPN 운영 포인트
1. 로그 및 모니터링 체계 구축
Site-to-Site VPN은 아래 로그를 제공한다 :
- 터널 로그 : IKE 협상, IPsec SA 생성/갱신, 터널 UP/DOWN 이벤트
- BGP 로그 : 경로 알림/수신, 피어링 상태 변화
이 로그들을 CloudWatch Logs로 전송하고, 필터 및 알림으로 설정한다.
장애가 발생한다면 가장 먼저 확인할 지점이다.
2. MTU 문제 대응
MTU (Maximum Transmission Unit)는 네트워크에서 한 번에 보낼 수 있는 최대 패킷 크기다.
IPsec은 원본 패킷을 암호화하고 ESP 헤더를 추가하기 때문에 패킷 크기가 증가한다.
- 일반 이더넷 MTU : 1500 bytes
- IPsec overheads : 약 50~75 bytes
- 권장 MSS : 1379 bytes (TCP)
만약 패킷 크기가 MTU를 초과한다면, 대용량 전송이 실패할 수 있기 때문에 TCP MSS를 조정하는 것은 필수다.
※ MSS (Maximum Segment Size)는 TCP 데이터 페이로드의 최대 크기다.
3. IKE / IPsec 패러미터 매칭
양쪽 종단의 설정이 정확히 일치해야 한다:
- IKE 버전 (IKEv1 vs. IKEv2)
- 암호화 / 무결성 알고리즘
- DH 그룹
- SA lifetime
- PSK (Pre-Shared Key)
AWS는 다운로드 가능한 설정 파일을 제공하지만, 네트워크 장비마다 표현 방식이 다르기 때문에 로그를 직접 보면서 연결 / 암호화 협상 실패 원인을 파악해야 한다.
4. 동적 라우팅 (BGP) 설계 고려사항
- AS 번호 중복 방지 : On-premise와 AWS의 AS 번호가 겹치지 않아야 한다.
- 불필요한 경로 필터링 : 불필요한 경로가 개방되지 않도록 Route Map을 설정한다.
- Direct Connect 우선순위 조정 : Primary / Backup 터널 또는 Direct Connect와의 우선순위
5. 비용 최적화
- Site-to-Site VPN의 경우, VPN outbound 트래픽은 과금된다.
- 대용량 트래픽이라면 Direct Connect를 사용하는 것이 더 경제적일 수 있다.
- Transit Gateway 사용 시, attachment 별로 시간 당 요금이 발생한다.
※ AWS Transit Gateway (TGW)
여러 Amazon VPC와 On-premise 네트워크를 연결하는 중앙 허브 서비스.
복잡한 peering을 제거하고, 전체 AWS 네트워크에 걸친 트래픽을 효율적으로 관리한다.
마치며
AWS Site-to-Site VPN은 IPsec / IKE라는 산업 표준 프로토콜을 기반으로 하는 관리형 서비스다.
AWS의 강점은 자동 이중화와 관리 편의성이다.
하지만 터널을 만들었다는 것이 통신이 가능해진다는 것은 아니며, 라우팅과 보안 그룹까지 함께 확인해야 한다는 것을 항상 유념해야 한다.
다음 글에서는 개인 PC와 AWS VPC 환경을 연결하는 AWS Client VPN 구현 절차에 대한 글을 다룰 것이다.
참고 출처
- Simulating Site-to-Site VPN Customer Gateways Using strongSwan | Networking & Content Delivery
- AWS Site-to-Site VPN - Amazon Virtual Private Cloud Connectivity Options
- What Is IKE (Internet Key Exchange)? | IKE Meaning - Palo Alto Networks
- Understand IPsec IKEv1 Protocol - Cisco
Powered By. Claude
'클라우드 > AWS' 카테고리의 다른 글
| [AWS] AWS VPN : OpenVPN 프로토콜과 Client VPN (0) | 2026.01.14 |
|---|---|
| [AWS] IAM User/Role/Policy & Service Role (0) | 2025.11.11 |
| [AWS] App Runner, ECS/EKS Anywhere (0) | 2025.11.05 |
| [AWS] ECS, ECR, EKS (0) | 2025.11.05 |
| [SAP] Amazon API Gateway - REST API (0) | 2025.09.08 |
