[cloud] VPN? IPsec VPN ? - 100-hours-a-week/5-yeosa-wiki GitHub Wiki
VPN 개념
VPN 도입 이유
1. 비용 측면
우리 서비스는 AI 모델 학습을 포함하고 있어, GPU 리소스를 요구하는 상황이 자주 발생한다.
AWS에서 제공하는 약 100만 원 수준의 비용 지원만으로는 3–4개의 AI 모델 학습을 감당하기에 부담이 있었다.
이에 따라, **GCP의 $300 무료 크레딧(약 40만 원 상당)**을 병행 활용하기로 결정하였다.
덕분에 비용 효율을 고려해 GPU 학습 환경을 GCP에 분산 배치하고,
운영 환경은 AWS를 유지하는 멀티 클라우드 구조를 구성하게 되었다.
이 구조가 실현되기 위해서는 클라우드 간 안정적인 내부 네트워크 연결이 필수였고,
여기서 VPN의 필요성이 제기되었다.
2. 보안 측면
-
Dev 환경
- 개발 및 테스트 서버는 외부 공격 대상이 되지 않도록 완전히 폐쇄된 상태로 운용
- 도메인·로드밸런서·공인 IP를 전혀 부여하지 않고, VPN을 통해서만 운영자가 내부망에 접속
- 테스트 중인 기능이나 민감한 로직의 외부 노출을 원천 차단
-
Prod 환경
- 실사용자 요청은 외부와 연결되어야 하나, 운영/배포 트래픽은 VPN 별도 경로로 분리
- 운영자는 VPN 전용 백도어를 통해 SSH·DB 관리 콘솔·내부 API 서버 등 민감 리소스에 접근
- 외부 노출 없이 내부 제어권 확보
VPN은 단순 보안 장비가 아니라, Dev/Prod를 나눠 관리할 수 있는
실질적 제어 수단이자 운영 안전망으로 작동한다.
3. VPN 역할 정리
- 서로 다른 클라우드 간 내부 트래픽을 안전하게 연결
- Private Subnet에 존재하는 인스턴스에 대한 제어권 확보
- 운영 환경에서는 외부 접근을 차단하고, VPN을 통해서만 제한적 접근 허용
NAT Gateway 방식 vs VPN 방식
멀티 클라우드 환경에서 API 통신을 안전하게 구성하는
두 가지 전략의 비교와 선택 이유
1. NAT Gateway 방식 (공인망 통신 + HTTPS + 보안그룹)
개요
- GCP와 AWS 각각의 인스턴스가 NAT Gateway를 통해 공인 IP로 나가며,
서로의 공인 IP를 보안그룹에서 허용해 통신 - 통신은 HTTPS 기반 암호화
장점
- 구현이 간단하고 빠르게 통신 가능
- TLS로 기본적인 트래픽 암호화 제공
- 클라우드 서비스 수준에서 지원이 잘 되어 있음
단점
- 공인망을 통하므로 외부 노출 → 공격면 존재
- NAT IP나 서비스 변경 시 보안그룹/ACL 수작업 수정 필요
- 패킷은 암호화되나 통신 경로 자체는 노출
- 대규모 API 호출 시 지연(latency), 불안정 가능성
2. VPN 방식 (Private IP 통신 + 암호화 터널)
개요
- AWS와 GCP 사이에 IPsec 기반 VPN 터널을 구성하고,
내부 VPC를 라우팅 테이블과 함께 연결하여
Private IP ↔ Private IP로 직접 통신
장점
- 외부에 노출되지 않음 → 공격면 최소화
- 고정된 내부 IP로 통신 → IP 변경 없음, 관리 용이
- TLS 없이도 트래픽 자체가 암호화 (IPsec)
- 운영자 접근도 VPN으로 통합 가능 → 접근 제어 일원화
단점
- 초기 구성 복잡 (VPN Gateway, 라우팅, 인증 등 필요)
- VPN 터널 상태 유지/모니터링 필요
정리
항목 | NAT Gateway 방식 | VPN 방식 |
---|---|---|
보안 수준 | 공인망 노출 + TLS | 사설망 통신 + IPsec 암호화 |
유지보수 | IP 변경 시 수동 관리 | 내부 IP 고정, 자동화 용이 |
공격면 | 있음 (공인 포트, URI 탐색) | 없음 (외부에서는 접근 자체 불가) |
실무 적합성 | 테스트/간단한 연동 | 운영 환경 기본 설계에 적합 |
결론
단순한 통신은 NAT Gateway 방식으로도 가능하지만,
보안성과 안정성이 핵심인 운영 환경에서는 VPN 방식이
구조적으로 더 강력하고 실무에 적합하다고 판단하여 채택했습니다.