멀티클라우드 리버스 프록시 아키텍처 검토

1. 검토 배경

한 클라우드(Azure)의 VPN을 통해 접속한 사용자만 다른 클라우드(AWS)에 배포된 서비스에 접근하도록 제약해야 하는 상황. Site-to-Site VPN은 비용 부담으로 배제. 대안으로 "내부망 리버스 프록시 → 타 클라우드 Public ALB → Private 워크로드" 구조가 제시됨.

제안된 구조

[사용자 PC] ──(Azure VPN Client)──► [Azure VPN Gateway]
                                          │
                                          ▼
                                    [VNet 내부]
                                          │
                                          ▼
                              [Azure VM - nginx 리버스프록시]
                                  Private IP: 10.x.x.x
                                  Public IP: y.y.y.y (고정)
                                          │
                                          ▼ (공용 인터넷)
                              [AWS Public ALB + WAF]
                                  WAF 규칙: Source IP = y.y.y.y/32
                                          │
                                          ▼
                              [EKS Pod - Private Subnet]

검토자 의문

"보통 프록시를 public하게 설정하고 서비스를 private으로 설정하는데 반대로 되어 있다. 이게 맞는 구조인가?"

→ 날카로운 아키텍처적 지적. 본 문서는 이 질문에 대한 답을 정리함.

2. 전통적 3-tier 구조 vs 제안 구조

전통적 구조 (DMZ 모델)

[Internet] → [Public Proxy / DMZ] → [Private Backend]
              ↑ 공격 흡수            ↑ 네트워크 격리

Public Proxy: 인터넷에 노출, 공격 표면 흡수, WAF/IDS 집중 배치
Private Backend: 네트워크 레벨 격리, 프록시를 통해서만 도달 가능
방어 원칙: 외곽은 단단하게, 내부는 부드럽게 (Defense in Depth의 고전형)

제안 구조

[VPN Users] → [Private Proxy] → [Public ALB + WAF] → [Private Backend]
              ↑ VPN만 접근      ↑ IP 화이트리스트로
                                  "논리적 private"

Proxy: VNet 내부, VPN 사용자만 도달 가능 (Private)
ALB: 공식적으로는 Public이지만 WAF로 프록시 IP 1개만 허용 (논리적 Private)
Backend: VPC 내부, ALB 통해서만 도달

차이점

항목	전통 구조	제안 구조
프록시 위치	Public	Private
서비스 진입점	Private Backend	Public ALB (WAF 제한)
방어 메커니즘	네트워크 레벨 격리	IP 기반 논리 격리
Fail-safe	기본 차단 (NSG/SG)	규칙 의존 (WAF 설정 실수 시 전면 공개)
Mental model	직관적	반전되어 어색함

→ 순서가 뒤집힌 게 맞음. 이 구조적 기형은 제약 조건에서 비롯됨.

3. 왜 이런 기형이 발생하는가

근본 원인: Shared Public ALB 재사용 제약

기업 환경에서 EKS/K8s 클러스터에 일반적으로 다음과 같은 ALB 구성이 존재:

ALB 유형	scheme	접근 방식
Private Shared ALB	internal	VPC 내부에서만 도달
Public Shared ALB	internet-facing	인터넷에서 도달

특정 서비스만 VPN 사용자에게 제한하고 싶을 때:

Private shared ALB 사용하려면: 두 클라우드의 네트워크 연결 필요 → S2S VPN 비용 부담
Public ALB 사용하려면: 인터넷에서 누구나 접근 가능 → VPN 요구사항 위반
Public shared ALB에 inbound-cidrs 걸면: 다른 서비스의 Security Group과 union되어 효과 없음
- AWS Load Balancer Controller는 group.name이 같은 ingress들의 CIDR을 ALB의 SG에 합쳐서(union) 적용
- 한 서비스만 제한하려 해도 다른 서비스의 0.0.0.0/0 허용이 동시에 적용되어 whitelist 무력화

우회책의 결과

"Public ALB + WAF로 IP 제한"이라는 논리적 Private 구성 → 프록시는 Private, 진입점은 Public이라는 역전된 구조 등장.

4. 보안상 평가

실제 방어 효과

WAF IP 규칙이 정상 동작하면 실질 공격 표면은 전통 구조와 거의 동일
클라우드 관리형 ALB/WAF는 자체 운영 nginx보다 보안 패치 관리가 우수
결론: 기능적으로는 안전함

그러나 3가지 이유로 전통 구조가 여전히 우월

이유	설명
Mental model 일치	운영팀 누구나 직관적 이해, 인수인계 용이
Fail-closed 기본	전통 구조는 네트워크 기본 차단 → 설정 실수해도 안전. WAF 기반은 규칙 오설정 시 전면 공개
복잡도 대비 이득	레이어 증가 = 디버깅 포인트 증가, TLS 인증서 2곳, 모니터링 대상 다수

치명적인가?

❌ 기능상 치명적이지 않음
⚠️ 하지만 "찝찝함"은 실재하는 위험 신호 — 가볍게 넘기면 안 됨

5. 보안 규칙 미적용 시 리스크 분석

시나리오: WAF/whitelist 없이 Public ALB 공개 운영

앱 자체 인증(bcrypt, JWT, rate limit)이 있다면 즉시 뚫리는 수준은 아님. 그러나 "VPN으로만"이라는 원래 요구사항 자체를 포기하는 결정이며, 공격 표면이 크게 증가함.

규칙 없을 때 증가하는 리스크

리스크	규칙 있음	규칙 없음
로그인 폭격	VPN 통과 후만 가능	인터넷 누구나 시도 (rate limit만 의존)
의존성 CVE 노출	내부자만 접근 가능	zero-day 즉시 공격 대상
업로드 엔드포인트	차단됨	인증 전 경로 있으면 위험
피싱/크리덴셜 스터핑	낮음	로그인 UI 공개 → 직원 타게팅 용이
서비스 존재 노출	CT 로그만	스캐너 상시 탐지
컴플라이언스	"내부용" 주장 성립	"인터넷 노출" 기록

실제 발생 가능 시나리오

인증 프레임워크 CVE로 인증 전 RCE (JWT 라이브러리, multer 등 이력 존재)
파일 파싱 라이브러리(폰트/이미지/PDF)는 out-of-bounds read/write 취약점 빈번
유출된 비밀번호 재사용 공격은 rate limit으로 완전 차단 불가

규칙 없이 갈 때 최소 안전장치

강력한 비밀번호 정책 + MFA 추가
User-Agent/Referer 기반 basic 필터 (봇 90% 차단)
robots.txt disallow + X-Robots-Tag: noindex

6. 대안 아키텍처 비교

A. 동일 클라우드 내 VPN + Private ALB ⭐

[User] ──► [AWS OpenVPN / Client VPN] ──► [Private ALB] ──► [Backend]

Azure VPN 포기, AWS OpenVPN 또는 Client VPN 사용
전통 구조 완전 성립
비용: AWS OpenVPN(EC2 자체 호스트 시) 거의 $0, Client VPN은 ~$72/월
기존 Private ALB 패턴 그대로 활용

B. 타 클라우드 VPN 유지 + 전용 Public ALB

[Azure VPN] → [Private Proxy VM] → [전용 Public ALB (inbound-cidrs)] → [Backend]

Shared ALB 사용하지 않고 서비스 전용 ALB 신설
inbound-cidrs가 독립 SG에 적용 → whitelist 효과 보장
프록시 위치는 여전히 Private이지만, dedicated ALB가 "내 서비스만의 공개 진입점" 역할 명확
비용: ALB ~$22/월 추가

C. 현재 검토 중 (Private Proxy + Shared Public ALB + WAF)

Shared ALB 재활용, 기존 VM 재활용으로 추가 비용 최소
구조 역전 (위 2장 참조)
비용: WAF ~$10/월

D. Site-to-Site VPN + Private Shared ALB

전통 구조, 네트워크 레벨 격리
비용 부담으로 배제되는 경우 많음 ($50+/월)

비교표

대안 구조	직관성	월 비용	기존 VPN 유지	레이어 수
A. 동일 클라우드 VPN	✅ 완전 전통형	$0~$72	❌	2
B. 전용 Public ALB	🟡 유사 전통형	~$22	✅	4
C. 현재 검토	❌ 역전됨	~$10	✅	5
D. S2S VPN	✅ 전통형	$50+	✅	3

7. 멀티클라우드 프록시 패턴의 업계 현황

질문

"보통 S2S VPN으로 뚫고 진행하는데, 프록시 방식은 얼마나 흔한가?"

답: 드물지 않지만 주류는 아님

프로덕션 멀티클라우드 환경에서는 S2S VPN / ExpressRoute + Direct Connect가 압도적 주류. "프록시 VM으로 크로스 클라우드 접근"은 특정 상황의 우회책으로 사용됨.

실제 사용되는 5가지 컨텍스트

스타트업/중소기업 비용 절감형
- S2S VPN 비용 부담, 크로스 클라우드 서비스 1-2개만 필요
- 내부 툴 한정 접근 용도
클라우드 마이그레이션 브릿지
- 온프레 → 클라우드, A 클라우드 → B 클라우드 이전 중 임시 운영
- 완료 후 프록시 제거
ZTNA (Zero Trust Network Access) 초기형
- Cloudflare Access, Google Cloud IAP, Teleport, Pomerium
- 현재 논의 구조는 이를 저가 자체 구현한 셈
컴플라이언스/감사 요구
- 금융/의료에서 모든 크로스 클라우드 트래픽을 단일 지점에서 로깅
- 프록시가 TLS 종단하여 감사 로그 생성
SaaS 게이트웨이
- VPN 사용자만 특정 외부 SaaS 접근 허용
- Squid/nginx forward proxy 방식

주류가 아닌 이유

이유	설명
지연	2개 클라우드 경유로 latency 증가
SPOF	프록시 장애 = 서비스 접근 불가 (네이티브 네트워킹은 클라우드 자체가 HA)
대역폭 병목	프록시 VM 스펙 한계 (GB 단위 업로드 시 특히)
운영 복잡도	VM, 인증서, 모니터링 등 추가 관리 요소
확장성	서비스 수 증가 시 감당 불가 → 결국 S2S로 수렴

공개 사례

Cloudflare Tunnel: 본질적으로 같은 개념. Fortune 500 다수 사용
클라우드 마이그레이션 중 임시 브릿지: 다수 공개 사례 존재
중견기업의 Azure AD + AWS 워크로드 조합: 종종 사용
게임사의 빌드/CI 툴 크로스 클라우드 접근: 내부 관리 툴 용도

"처음 해본 느낌"의 진짜 원인

대기업/프로덕션은 이미 S2S VPN 보유 → 프록시 쓸 일 없음
소규모에서 쓰긴 하는데 임시/내부용이라 공론화 드묾
공식 문서·교과서에 잘 안 나옴 → 경험 없으면 낯설게 느껴짐

8. 아키텍처 결정 기준

의사결정 플로우

VPN 요구사항이 반드시 특정 클라우드 VPN이어야 하는가?
├─ NO → 대안 A (동일 클라우드 VPN) ⭐ 최적
└─ YES → 서비스 규모 / 사용자 수 평가
         ├─ 단일 서비스, 소수 사용자, 비용 민감
         │   ├─ 구조 직관성 중시 → 대안 B (전용 Public ALB)
         │   └─ 비용 최우선 → 대안 C (Shared + WAF) ⚠️
         └─ 다수 서비스, 다수 사용자 또는 장기 운영
             └─ 대안 D (S2S VPN) 또는 ZTNA 솔루션

주요 trade-off 포인트

관점	권장
구조 정합성	A > D > B > C
비용	A ≈ C < B < D
운영 단순성	A > D > B > C
Mental model 일관성	A > D > B > C
확장성	D > A > B > C

의사결정 시 유의점

"한 번도 못 해본 구조"라는 감각은 경고 신호
처음 하는 인프라는 최대한 정석에 가깝게 진행해야 인수인계/장애 대응 용이
아키텍처 선택은 기술 결정이 아니라 제품 결정 — VPN 요구사항의 본질부터 재확인
"찝찝함"은 미래의 운영 부담이 현재로 투영된 신호

9. 제안 구조(대안 C) 채택 시 운영 고려사항

비용 제약으로 구조 역전을 수용하는 경우, 다음 사항을 준수하면 실무적으로 수용 가능한 수준으로 운영 가능.

구축 단계별 검증 순서

Backend Pod만 먼저 배포 + 임시 관리자 IP로 ALB 제한 → 정상 동작 확인
WAF 규칙 추가 + 프록시 VM의 고정 공인IP 허용 → VM에서 curl 테스트
프록시 nginx 구성 + 내부 DNS → VPN 붙은 PC에서 브라우저 접근
각 단계마다 다음 단계 진행 전 반드시 검증

운영 필수 설정

관리자 비상 접근 루트: WAF 규칙에 관리자 IP(/32) 추가 한 자리 확보
로그 수집 통합: 각 레이어에서 로그 수집 (VPN, nginx, WAF, ALB, Backend)
요청 추적: X-Request-ID 헤더로 전 레이어 추적
TLS 인증서 자동 갱신: Let's Encrypt 갱신 실패 알림
프록시 IP 변동 방지: 고정 EIP + IaC 관리

업로드가 큰 서비스 주의사항

nginx client_max_body_size 명시적 설정 (기본값 1M)
proxy_request_buffering off 설정 → VM 디스크/메모리 절약
proxy_read_timeout, ALB idle timeout 조정

장애 진단 체크리스트

증상	진단 순서
접근 불가 (타임아웃)	VPN 연결 → 프록시 상태 → WAF 로그 → ALB target health
업로드 실패 (413)	nginx client_max_body_size 확인
업로드 끊김 (504)	nginx proxy_read_timeout, ALB idle timeout 확인
전체 차단 (403)	WAF IP 규칙의 프록시 공인IP 매칭 여부 확인

10. 참고 자료

같은 개념의 상용/오픈소스 구현

Cloudflare Zero Trust - 상용 ZTNA
Google Cloud IAP (Identity-Aware Proxy) - GCP 네이티브
Teleport - 오픈소스, VPN+프록시+audit 통합
Pomerium - 오픈소스 identity-aware proxy

AWS 공식 가이드

AWS "Secure Hybrid Connectivity" 패턴 문서
AWS Client VPN 관리자 가이드
AWS WAF IP set 설정 가이드

검색 키워드

한국어: "VPN 리버스 프록시 크로스 클라우드", "멀티클라우드 프록시 패턴"
영어: "cross-cloud reverse proxy", "VPN gated proxy", "zero trust network access"

11. 핵심 교훈

Shared 리소스의 제약은 아키텍처 왜곡을 유발
- Shared ALB의 SG 공유 특성 때문에 서비스별 차별 제약이 어려움
- 이런 제약이 "Private proxy → Public ALB" 같은 역전된 구조의 원인
"찝찝함"은 가볍게 볼 신호가 아님
- 아키텍처적 위화감은 대개 실제 운영상 문제로 이어짐
- 숙련자의 직관이 경고하는 시점에 대안 검토 필수
VPN 요구사항의 출처 확인이 아키텍처 결정의 출발점
- "어떤 VPN이든 상관없다" → 훨씬 단순한 구조 가능
- "특정 클라우드 VPN 강제" → 제약 조건이 되어 복잡도 증가
- 기술 논의 전에 비즈니스/정책 요구 재확인 필요
"한 번도 못 해본 구조"라는 감각은 정보 신호
- 드물게 쓰이는 이유가 있음
- 공론화 안 된 패턴은 레퍼런스·커뮤니티 지원 부족
- 장기 운영 시 인수인계/문서화 부담 증가
저비용 우회책은 "이해한 상태로" 선택해야 함
- 비용 절감 자체는 정당한 결정
- 단, trade-off를 명확히 인지하고 선택한 것과 모르고 빠진 것은 다름
- 본 문서의 역할은 "알고 선택할 수 있도록" 맥락 제공

'DevOps' 카테고리의 다른 글

면접용 Vault 환경변수 주입 설명 (0)	2026.04.09
200ms latency- 실시간 개인화 시스템 아키텍처 Deep Dive (0)	2026.02.26
왜 여러 회사에서 AKS는 불안정하고 EKS는 안정적으로 느껴졌을까 (0)	2026.02.05
kubernetes에서 Pod requests / limits Tunning (1)	2025.12.30
오픈소스 검색엔진 비교: OpenSearch vs Meilisearch vs Typesense (0)	2025.11.06