[network] Site-to-Site VPN
전용선은 부담스럽고, 온프레미스와는 지금 당장 이어야 한다. 인터넷 위에 암호화 터널을 뚫는 가장 빠른 선택지.
One-Line Summary
Site-to-Site VPN은 온프레미스 네트워크와 VPC를 공용 인터넷 위에서 IPsec으로 암호화한 터널로 이어주는 하이브리드 연결 방식이다. 전용선을 깔지 않고 몇 분 만에 구성할 수 있고 암호화가 기본이지만, 공용 인터넷을 타므로 지연·대역폭이 들쭉날쭉하다. AWS 측 종단은 Virtual Private Gateway(VGW) 또는 Transit Gateway, 온프레미스 측 종단은 Customer Gateway(CGW)이며, 하나의 VPN 연결은 두 개의 터널로 이중화된다. 반면 Client VPN은 개별 사용자(노트북) 가 VPC에 안전하게 접속하는 관리형 OpenVPN 엔드포인트다.
Why It Exists
온프레미스 데이터센터와 AWS VPC를 이어야 할 때, 전용선(Direct Connect)은 안정적이지만 회선을 실제로 끌어오는 데 수 주가 걸리고 비싸다. "지금 당장, 안전하게, 싸게" 온프레미스와 VPC를 붙이고 싶은데 공용 인터넷밖에 없다면, 그 인터넷 구간을 암호화한 터널로 감싸면 된다.
Site-to-Site VPN이 그 역할을 한다.
온프레미스 ↔ VPC를 그냥 인터넷으로 연결하려면
-> 트래픽이 평문으로 공용망을 지나 노출 위험
-> 전용선(DX)은 안전하지만 개통에 수 주 + 고비용
Site-to-Site VPN 경유
-> 온프레미스(CGW) ↔ AWS(VGW/TGW) 사이 IPsec 터널 생성
-> 공용 인터넷 위를 지나도 구간이 암호화되어 안전
-> 몇 분~몇 시간이면 구성 완료, 회선 공사 불필요
시험 감각: "온프레미스와 VPC를 빠르게·암호화해서 연결" = Site-to-Site VPN. "전용·일관된 대역폭이 필요" = Direct Connect.
Abbreviations
| 약어 | 풀네임 | 의미 |
|---|---|---|
S2S VPN | Site-to-Site VPN | 온프레미스 ↔ VPC IPsec 터널(네트워크 대 네트워크) |
VGW | Virtual Private Gateway | AWS 측 VPN 종단, VPC에 부착 |
CGW | Customer Gateway | 온프레미스 측 물리/논리 VPN 장비를 나타내는 AWS 리소스 |
TGW | Transit Gateway | 다수 VPC/온프렘 허브, VPN 종단으로도 사용 |
IPsec | Internet Protocol Security | VPN 터널 암호화 프로토콜(전송 중 암호화) |
BGP | Border Gateway Protocol | 동적 라우팅으로 경로를 주고받는 프로토콜 |
DX | Direct Connect | AWS로 향하는 전용 사설 회선 |
Client VPN | AWS Client VPN | 개별 사용자용 관리형 OpenVPN 엔드포인트(사용자 대 네트워크) |
Site-to-Site VPN의 구성 요소 (빈출)
VPN 연결은 AWS 측 종단 + 온프레미스 측 종단 + 둘을 잇는 VPN Connection으로 이루어진다.
[온프레미스 DC] [AWS VPC]
라우터/방화벽 Virtual Private Gateway (VGW)
(실제 VPN 장비) 또는 Transit Gateway (TGW)
│ │
▼ ▼
Customer Gateway ══ Tunnel 1 (IPsec) ═══════► VGW/TGW
(CGW: 온프렘 장비를 ══ Tunnel 2 (IPsec) ═══════►
나타내는 AWS 리소스) └ 두 터널로 자동 이중화 ┘
| 구성 요소 | 위치 | 설명 |
|---|---|---|
| Virtual Private Gateway (VGW) | AWS 측 | VPC에 부착하는 VPN 종단. 하나의 VPC 전용 |
| Customer Gateway (CGW) | 온프레미스 측 | 온프렘 VPN 장비의 공인 IP·BGP ASN 등 정보를 담은 AWS 리소스(장비 자체가 아니라 그 표현) |
| VPN Connection | 둘 사이 | CGW ↔ VGW(또는 TGW)를 잇는 실제 연결. 터널 2개 포함 |
| Transit Gateway (TGW) | AWS 측(대안) | VGW 대신 종단으로 두면 여러 VPC를 한 VPN으로 공유 |
시험 감각: "온프레미스 장비를 AWS에 등록하는 리소스" = Customer Gateway. "VPC 쪽 VPN 종단" = Virtual Private Gateway. 헷갈리면 안 된다.
VGW로 종단 vs Transit Gateway로 종단
VPC가 하나면 VGW로 충분하지만, VPC가 여러 개거나 온프레미스와 다수 네트워크를 허브-스포크로 묶고 싶으면 Transit Gateway에 VPN을 종단한다.
| 구분 | VGW 종단 | Transit Gateway 종단 |
|---|---|---|
| 연결 대상 | VPC 1개 | 여러 VPC를 한 허브로 |
| 확장성 | VPC마다 VGW·VPN 필요(관리 폭증) | 허브 하나로 다수 VPC 공유 |
| 동적 라우팅 | BGP 지원 | BGP 지원(경로 자동 전파) |
| 권장 | 단일 VPC 하이브리드 | 다수 VPC/멀티 계정 하이브리드 |
시험 감각: "온프레미스를 여러 VPC와 VPN으로 연결" = VGW 여러 개가 아니라 Transit Gateway에 VPN 종단.
라우팅 — 정적 vs 동적(BGP)과 Route Propagation (빈출)
VPN을 뚫었다고 통신이 되는 게 아니다. VPC의 라우트 테이블이 온프레미스 대역을 VGW로 보내도록 경로가 있어야 한다. 자세한 라우팅 개념은 Route Table 참고.
| 방식 | 내용 |
|---|---|
| 정적(static) 라우팅 | 온프레미스 대역을 라우트 테이블에 수동으로 추가. 온프렘 장비가 BGP 미지원일 때 |
| 동적(dynamic, BGP) 라우팅 | 온프렘이 BGP로 자기 대역을 알려주면 자동 학습. 경로 변경에 유연 |
| Route Propagation | VGW가 VPN으로 학습한 온프레미스 경로를 라우트 테이블에 자동 반영(수동 추가 불필요) |
[VPC Route Table]
10.0.0.0/16 -> local (VPC 내부)
192.168.0.0/16 -> vgw-xxxx (온프레미스 대역 → VGW로) ← 이게 있어야 통신
└ BGP면 Route Propagation으로 자동 삽입
시험 감각: "VPN은 붙었는데 온프레미스와 통신이 안 된다" = 라우트 테이블에 온프렘 대역 → VGW 경로 / Route Propagation 활성화 확인.
이중화·고가용성 (빈출)
Site-to-Site VPN은 하나의 VPN 연결에 터널이 2개 자동 제공된다. 각 터널은 서로 다른 AWS 엔드포인트에서 종단되어, 하나가 죽어도 다른 터널로 트래픽이 넘어간다.
[기본 - 터널 이중화]
CGW ══ Tunnel 1 ══► VGW (한쪽 죽어도)
══ Tunnel 2 ══► VGW (다른 쪽으로 계속)
└ 단, 온프레미스 장비(CGW)가 1개면 그 장비 자체가 SPOF
[더 높은 가용성 - CGW 이중화]
CGW-A ══ 터널 2개 ══► VGW
CGW-B ══ 터널 2개 ══► VGW ← 온프렘 장비도 2대로 이중화
| 수준 | 구성 | 남는 단일 장애점 |
|---|---|---|
| 기본 | VPN 연결 1개(터널 2개) | 온프레미스 장비(CGW) 1대 |
| 권장 | Customer Gateway 2개(각각 터널 2개) | 온프렘 장비까지 이중화 |
시험 감각: 터널 2개는 AWS가 기본 제공. 더 높은 가용성을 원하면 온프레미스 쪽에 CGW(장비) 2개를 둔다.
VPN을 Direct Connect의 백업으로 (빈출)
가장 자주 나오는 하이브리드 패턴. Direct Connect를 주(primary) 경로로 쓰고, DX 회선 장애 시 Site-to-Site VPN을 페일오버(backup) 로 둔다. DX의 일관된 성능과 VPN의 빠른 구성·저비용을 조합한다.
[정상] 온프레미스 ══ Direct Connect (전용선, 주 경로) ══► VPC
└ VPN 터널은 대기(BGP 우선순위 낮게)
[DX 장애] 온프레미스 ┈┈X┈┈ Direct Connect (끊김)
└── Site-to-Site VPN (백업) ══► VPC 로 자동 우회
| 항목 | 내용 |
|---|---|
| 목적 | DX 단독 구성의 단일 장애점 제거(회선 장애 대비) |
| 동작 | BGP 라우팅으로 DX 우선, 끊기면 VPN 경로로 페일오버 |
| 주의 | DX만 쓰고 백업이 없으면 회선 장애 시 하이브리드 통신 전면 중단 |
시험 감각: "Direct Connect의 저비용 백업/이중화" = Site-to-Site VPN. "DX만으로는 부족한 복원력" 키워드면 확정.
Direct Connect vs Site-to-Site VPN 비교 (빈출)
| 구분 | Site-to-Site VPN | Direct Connect (DX) |
|---|---|---|
| 경로 | 공용 인터넷 위 IPsec 터널 | AWS로 향하는 전용 사설 회선 |
| 암호화 | IPsec 기본 암호화 | 기본은 암호화 아님(필요 시 위에 VPN/MACsec) |
| 지연·대역폭 | 인터넷에 종속 → 가변적 | 일관·예측 가능한 성능 |
| 구성 시간 | 몇 분~몇 시간 | 수 주(물리 회선 개통) |
| 비용 | 저렴 | 상대적으로 고가 |
| 대표 용도 | 빠른 연결, 암호화, DX 백업 | 대용량·저지연·안정 성능 필요 |
시험 감각: 빠름·암호화·인터넷·저비용 → VPN. 전용·일관성·저지연·고대역 → DX. 둘 다 원하면 DX 위에 VPN(암호화된 전용선) 또는 DX + VPN 백업.
AWS Client VPN — 사용자 대 네트워크
Site-to-Site VPN이 네트워크 대 네트워크(온프렘 전체 ↔ VPC)라면, AWS Client VPN은 개별 사용자 대 네트워크다. 재택근무자·개발자가 노트북에서 OpenVPN 클라이언트로 VPC(및 연결된 온프레미스)에 안전하게 접속한다. AWS가 관리하는 엔드포인트라 서버를 직접 운영할 필요가 없다.
[Site-to-Site VPN] 온프레미스 네트워크 전체 ══ IPsec ══► VPC
(사이트 ↔ 사이트, 상시 연결)
[Client VPN] 개별 노트북/사용자 ── OpenVPN(TLS) ──► Client VPN Endpoint ─► VPC
(원격 사용자 ↔ 네트워크, 사용자별 접속)
| 구분 | Site-to-Site VPN | AWS Client VPN |
|---|---|---|
| 연결 단위 | 네트워크 ↔ 네트워크 | 개별 사용자 ↔ 네트워크 |
| 프로토콜 | IPsec | OpenVPN 기반(TLS) |
| 종단 | VGW/TGW + CGW | Client VPN Endpoint + 사용자 소프트웨어 |
| 대표 상황 | 데이터센터-VPC 상시 연동 | 원격 근무자가 개인 기기로 접속 |
| 관리 | 온프렘 장비 필요 | AWS 관리형 엔드포인트 |
시험 감각: "개별 원격 사용자/재택근무자가 노트북으로 VPC에 접속" = Client VPN. "온프레미스 사이트 전체를 VPC에 연결" = Site-to-Site VPN.
Common Wrong Directions
| 오답 방향 | 왜 부족한가 |
|---|---|
| 빠르게 붙여야 하는데 Direct Connect 제안 | DX는 개통에 수 주 → 즉시 필요하면 Site-to-Site VPN |
| "일관된 저지연 대역폭"에 VPN 제안 | VPN은 공용 인터넷 종속 → 성능 가변. 그럴 땐 Direct Connect |
| VGW 하나로 여러 VPC를 VPN 연결하려 함 | VGW는 VPC 1개 전용 → 다수 VPC는 Transit Gateway 종단 |
| VPN만 뚫으면 통신 된다고 생각 | 라우트 테이블에 온프렘 대역 → VGW 경로/Route Propagation 필요 |
| 터널 2개면 완전 무장애라고 생각 | 온프레미스 장비(CGW) 1대면 그 장비가 SPOF → CGW 2개 |
| DX만 깔고 백업 없이 운영 | 회선 장애 시 전면 중단 → VPN을 DX 백업으로 |
| 원격 개별 사용자 접속에 Site-to-Site VPN | 그건 Client VPN(사용자 대 네트워크) |
| Customer Gateway를 AWS 측 종단으로 착각 | CGW는 온프레미스 측, AWS 측은 VGW/TGW |
Exam Triggers
| 문제에서 이런 표현이 나오면 | 떠올릴 것 |
|---|---|
| "connect on-premises to VPC quickly and encrypted" | Site-to-Site VPN |
| "encrypted tunnel over the public internet" | Site-to-Site VPN (IPsec) |
| "consistent/dedicated low-latency bandwidth" | Direct Connect |
| "low-cost backup/failover for Direct Connect" | Site-to-Site VPN (DX 백업) |
| "connect on-prem to multiple VPCs over VPN" | VPN + Transit Gateway 종단 |
| "on-prem routes not reaching VPC over VPN" | 라우트 테이블 온프렘 대역 → vgw / Route Propagation |
| "higher VPN availability / remove single device failure" | Customer Gateway 2개 |
| "remote workers/laptops securely access the VPC" | AWS Client VPN |
| "AWS side of VPN termination" | Virtual Private Gateway (또는 TGW) |
| "represents the on-premises VPN device" | Customer Gateway |
Memory Sentence
Site-to-Site VPN = 온프레미스(CGW) ↔ VPC(VGW, 또는 다수면 TGW)를 공용 인터넷 위 IPsec 터널로 잇는 빠르고 저렴한 암호화 연결. 하나의 연결에 터널 2개가 기본 이중화이고, 더 높은 가용성은 CGW 2개로. VPC 라우트 테이블에 온프렘 대역 → VGW 경로(Route Propagation)가 있어야 실제로 통한다. 성능이 일관돼야 하면 Direct Connect, 둘을 합치면 DX 주 경로 + VPN 백업. 개별 원격 사용자가 노트북으로 붙는 건 OpenVPN 기반 Client VPN(사용자 대 네트워크).
References
댓글
아직 댓글이 없습니다.