[AWS] VPN on AWS
VPN on AWS
신뢰할 수 없는 인터넷 위에 신뢰할 수 있는 통로를 뚫는 기술. VPN 자체의 원리부터 AWS Site-to-Site VPN, Client VPN의 구성요소·동작방식·사용 이유까지.
| Category | Level | Reads | Status |
|---|---|---|---|
| Cloud Computing · Networking | 중급 ~ 고급 | 약 17분 | VERIFIED |
VPN(Virtual Private Network)이란?
VPN은 신뢰할 수 없는 공용 네트워크(인터넷) 위에, 암호화된 가상의 전용 통로(터널)를 만들어 마치 같은 사설망에 있는 것처럼 통신하게 해주는 기술이다.
핵심은 두 가지다. 첫째는 캡슐화(Encapsulation) — 원래 패킷을 통째로 새로운 패킷 안에 감싸서 보낸다. 둘째는 암호화 — 그 안에 감싼 내용을 제3자가 볼 수 없게 만든다. 이 두 가지가 결합해서, 물리적으로는 인터넷을 지나가지만 논리적으로는 사설망을 지나가는 것과 동일한 효과를 낸다.
핵심 기술 — IPsec과 IKE
AWS를 포함한 대부분의 엔터프라이즈 VPN은 IPsec(IP Security) 프로토콜 스위트 위에서 동작한다.
Internet Key Exchange. 양쪽이 서로를 인증하고, 이후 통신에 쓸 임시 세션 키를 안전하게 협상하는 단계. 앞서 다룬 TLS 핸드셰이크와 목적이 유사하다 — "안전하게 키를 교환하는 절차".
Phase 1에서 합의한 키로 실제 데이터를 암호화·캡슐화해서 주고받는 단계. ESP(Encapsulating Security Payload) 프로토콜이 암호화와 무결성 검증을 함께 처리한다.
즉 VPN도 결국 "먼저 안전하게 키를 교환하고(IKE), 그 키로 실제 데이터를 암호화해서 주고받는다(IPsec)"는, TLS와 본질적으로 같은 패턴을 네트워크 계층에서 구현한 것이다.
터널 반대편이 살아있는지 주기적으로 확인하는 기능. 상대가 응답하지 않으면 터널을 죽은 것으로 판단하고 페일오버나 재협상을 트리거한다.
VPN의 두 유형
네트워크와 네트워크를 연결한다. 사무실·데이터센터의 라우터/방화벽과 AWS VPC 사이에 상시 터널을 뚫어, 양쪽 네트워크 전체가 서로 통신 가능해진다.
개별 사용자(단말)를 네트워크에 연결한다. 재택근무자의 노트북이 VPN 클라이언트로 접속해서, 사내망에 있는 것처럼 리소스에 접근한다.
AWS Site-to-Site VPN
사내 데이터센터·사무실 네트워크를 VPC와 상시 연결하는 서비스다. 구성요소 4가지 관계를 정확히 잡는 게 이해의 핵심이다.
고객 쪽(온프레미스) 라우터/방화벽을 AWS에 등록한 논리적 표현. 실제 장비의 퍼블릭 IP와 라우팅 방식(정적/BGP)을 정의한다.
VPC 쪽의 VPN 종단점. 하나의 VPC에 붙여서 그 VPC로 들어오는 VPN 트래픽을 받는다. (최근에는 여러 VPC를 한 번에 묶을 수 있는 Transit Gateway를 종단점으로 쓰는 구성이 늘고 있다.)
Customer Gateway와 Virtual Private Gateway(또는 Transit Gateway)를 잇는 논리적 연결. 이 안에 실제 터널이 만들어진다.
하나의 VPN Connection은 항상 2개의 IPsec 터널로 구성된다. 서로 다른 AWS 종단 IP를 가져서, 한쪽 터널·AZ·장비에 장애가 나도 다른 터널로 자동 페일오버된다.
라우팅은 정적(Static) 또는 BGP(동적) 방식을 고를 수 있다. 온프레미스 대역이 자주 바뀌지 않는 소규모 환경이면 정적으로 충분하지만, 규모가 크거나 향후 대역 변경이 잦다면 BGP로 경로를 자동 교환하는 편이 운영 부담을 크게 줄인다.
여러 VPC와 온프레미스 연결을 중앙에서 허브처럼 묶어주는 라우터. VPN Connection을 Transit Gateway에 붙이면, VPN 하나로 여러 VPC 전체와 온프레미스를 연결할 수 있어 VPC마다 개별 VPN을 만들 필요가 없다.
AWS Client VPN
재택근무자·출장자 개개인의 노트북을 VPC(나아가 온프레미스까지)에 연결하는 완전관리형 원격 접속 VPN이다. OpenVPN 기반 클라이언트로 접속한다.
클라이언트가 접속하는 관리형 종단점. 여기서 클라이언트 IP 대역(CIDR), 인증 방식, DNS 설정을 정의한다.
이 엔드포인트를 실제 어느 VPC의 어느 서브넷에 연결할지 지정. 여러 서브넷을 연결해 AZ 이중화를 구성한다.
"어떤 사용자/그룹이 어떤 네트워크 대역에 접근 가능한지"를 정의하는 규칙. 인증만으로는 부족하고, 이 인가 규칙이 있어야 실제 트래픽이 허용된다.
연결된 클라이언트가 어디까지 도달할 수 있는지 결정하는 라우팅 규칙. VPC 내부뿐 아니라 Site-to-Site VPN을 통해 온프레미스까지 경로를 확장할 수 있다.
인증 방식
| 방식 | 특징 |
|---|---|
| Active Directory 인증 | 기존 사내 AD 계정으로 로그인, 조직 계정 체계를 그대로 재사용 |
| SAML 기반 페더레이션 | SSO 제공자(Okta 등)와 연동, MFA를 자연스럽게 통합 가능 |
| 상호 인증서(mTLS) 인증 | 클라이언트마다 발급된 인증서로 인증, 사용자 계정 체계 없이도 강력한 신원 증명 |
VPN 연결 시 "회사 리소스로 가는 트래픽만" VPN 터널을 태우고, 나머지 일반 인터넷 트래픽은 로컬 네트워크로 바로 내보내는 설정. 꺼두면(Full-tunnel) 모든 트래픽이 VPN을 거쳐, 보안은 강해지지만 대역폭 부담과 지연이 늘어난다.
Site-to-Site VPN vs Client VPN
| 구분 | Site-to-Site VPN | Client VPN |
|---|---|---|
| 연결 대상 | 네트워크 ↔ 네트워크 | 개별 단말 ↔ 네트워크 |
| 연결 방식 | 상시 자동 연결(장비 간) | 사용자가 클라이언트로 수동 접속 |
| 인증 단위 | 사전 공유 키(PSK) 또는 인증서(장비 단위) | 사용자 단위(AD/SAML/인증서) |
| 대표 용도 | 지사·데이터센터 상시 연결 | 재택근무·출장자 원격 접속 |
| 이중화 단위 | 터널 2개(자동) | 서브넷·AZ 다중 연결 |
다른 연결 방식과 비교
VPN은 AWS와 온프레미스·다른 네트워크를 잇는 여러 방법 중 하나일 뿐이다. 어디에 쓰이는지 구분해두면 설계 시 헷갈리지 않는다.
| 방식 | 연결 매체 | 속도·지연 | 구축 기간 |
|---|---|---|---|
| Site-to-Site VPN | 공용 인터넷(암호화) | 인터넷 상태에 따라 변동 | 즉시(수분~수시간) |
| Direct Connect | 물리 전용회선 | 예측 가능, 저지연·고대역폭 | 수 주 |
| VPC Peering | AWS 백본(VPC ↔ VPC) | 매우 낮음(같은 AWS 내부) | 즉시 |
장단점
- 전용회선 대비 구축이 빠르고 저렴함(수 분 안에 연결 가능)
- 기존 인터넷 회선을 그대로 활용, 별도 물리 배선 불필요
- Client VPN은 사용자 단위로 세밀한 접근 제어 가능
- 암호화 기본 적용으로 별도 보안 계층 설계 부담이 적음
- 인터넷 경유라 대역폭·지연이 예측하기 어려움
- 암호화·캡슐화 오버헤드로 순수 처리량은 전용회선보다 낮음
- 대규모 안정적 트래픽에는 Direct Connect 대비 비효율적
- Client VPN은 동시 접속자 수 증가 시 확장 설계가 필요함
언제 쓰는지
Direct Connect 구축 전 임시 연결, 전용회선의 백업 경로, 트래픽이 크지 않은 지사·소규모 사무실 연결.
재택·원격 근무자의 사내 리소스 접근, 계약직·외부 인력에게 제한된 네트워크만 열어줘야 할 때, VPN 클라이언트 배포·관리를 직접 하고 싶지 않을 때(완전관리형).
비용 구조
| 서비스 | 과금 방식 |
|---|---|
| Site-to-Site VPN | VPN Connection 시간당 요금 + 데이터 전송 요금 |
| Client VPN | Endpoint 연결 시간당 요금 + 동시 접속 클라이언트 수 기준 요금 |
둘 다 초기 고정비가 거의 없어 소규모로 시작하기 좋지만, 상시 대용량 트래픽이라면 장기적으로는 Direct Connect의 총소유비용(TCO)이 더 유리해지는 지점이 온다 — 트래픽 규모가 커질수록 정기적으로 재계산해볼 가치가 있다.