Azure 프라이빗 서브넷(Private Subnets)을 위한 아웃바운드 연결 설계

프라이빗 서브넷이 모든 것을 바꾸는 이유

과거에 Azure 가상 머신(VM)은 플랫폼이 공유 풀에서 동적 SNAT IP를 자동으로 할당하는 기본 아웃바운드 인터넷 액세스에 의존했습니다. 이는 편리했지만 다음과 같은 문제점이 있었습니다.

• ❌ 예측 가능한 아웃바운드 IP 주소 부재
• ❌ 트래픽 검사 및 필터링 불가
• ❌ FQDN 또는 URL 거버넌스 부재
• ❌ 규정 준수를 위한 감사(Audit)의 어려움
• ❌ 인접 이웃(Noisy neighbor)으로 인한 SNAT 포트 고갈 위험

프라이빗 서브넷을 사용하면 아웃바운드 액세스가 기본적으로 비활성화됩니다. 이는 아웃바운드 설계의 책임을 아키텍트에게 의도적으로 부여하는 것입니다. 그 결과 다음과 같은 환경이 조성됩니다.

• ✅ 모든 아웃바운드 흐름이 의도적임
• ✅ 모든 아웃바운드 IP를 파악하고 문서화할 수 있음
• ✅ 모든 송신(Egress) 경로를 관리하고 로그를 기록할 수 있음
• ✅ 규정 준수 증거를 쉽게 생성할 수 있음

이제 질문은 **"내 VM이 인터넷에 연결되는가?"**가 아니라, **"내 VM이 정확히 어떻게 인터넷에 도달하며, 그 경로가 이 워크로드에 적절한가?"**가 되어야 합니다.

세 가지 아웃바운드 패턴 요약

시나리오 1: NAT Gateway

NAT Gateway란 무엇인가?

Azure NAT Gateway는 완전 관리형의 영역 회복성(Zone-resilient)을 갖춘 아웃바운드 전용 SNAT 서비스입니다. 서브넷 수준에서 연결되며, 하나 이상의 고정 공용 IP 주소 또는 접두사를 사용하여 해당 서브넷의 모든 아웃바운드 흐름을 자동으로 처리합니다.

이 서비스는 라우팅 복잡성이나 인라인 장치 없이 예측 가능하고 확장 가능한 아웃바운드 인터넷 액세스를 제공하는 한 가지 목적으로 제작되었습니다.

주요 흐름:

• VM → NAT Gateway: 자동 SNAT (UDR 불필요)
• NAT Gateway → 인터넷: 고정적이고 예측 가능한 공용 IP
• 인바운드: 지원되지 않음 (아웃바운드 전용)

작동 방식 (단계별)

1. VM이 아웃바운드 연결을 시작합니다 (예: API에 대한 HTTPS 호출).
2. NAT Gateway가 서브넷 경계에서 해당 흐름을 가로챕니다.
3. 원본 IP가 NAT Gateway의 고정 공용 IP로 변환(NAT)됩니다.
4. 패킷이 인터넷으로 전달됩니다.
5. 응답 트래픽은 자동으로 추적되어 VM으로 다시 전달됩니다.

UDR도, 라우팅 테이블도, 인라인 장치도 필요 없습니다. 그냥 작동합니다.

장점

• 대규모 SNAT 확장성 — 일반적인 기업 규모에서 포트 고갈 걱정이 없습니다.
• 예측 가능한 아웃바운드 IP — 외부 서비스의 허용 목록(Allowlist)에 추가하기 쉽습니다.
• 영역 회복성 — 가용성 영역(AZ) 장애에도 생존합니다.
• 서브넷 범위 적용 — 서브넷 내의 모든 VM에 자동으로 적용됩니다.
• 라우팅 설정 불필요

제한 사항

• ❌ 트래픽 검사 또는 필터링 기능 없음
• ❌ FQDN 또는 URL 정책 강제 불가
• ❌ 위협 인텔리전스 통합 없음
• ❌ 허용되는 인터넷 대상을 제한할 수 없음

가장 적합한 사용 사례

• ✅ 외부 SaaS API를 호출하는 애플리케이션 계층
• ✅ OS 업데이트 및 패치 다운로드가 필요한 VM
• ✅ CI/CD 빌드 에이전트 및 파이프라인 러너
• ✅ 동서(East-West) 트래픽은 방화벽을 거치되, 단순 인터넷 송신은 허용되는 허브-앤-스포크의 스포크 VNet
• ✅ 개발/테스트 환경

시나리오 2: Azure Firewall

Azure Firewall이란 무엇인가?

Azure Firewall은 클라우드 네이티브 방식의 상태 유지형(Stateful) L3–L7 네트워크 보안 서비스입니다. 아웃바운드 송신에 사용될 경우, 송신 경로를 단순한 '연결 기능'에서 **'보안 강제 경계'**로 변환합니다.

NAT Gateway와 달리 Azure Firewall은 모든 패킷을 검사하고, 네트워크 규칙, 애플리케이션 규칙 및 위협 인텔리전스 피드를 기반으로 정책에 따라 허용 또는 거부 여부를 결정합니다.

주요 흐름:

• VM → UDR: 모든 아웃바운드 트래픽을 방화벽으로 강제 전송
• Firewall: 허용 전 정책에 따라 평가
• Firewall → 인터넷: 명시적으로 허용된 흐름만 통과
• 모든 거부된 흐름: 로그 기록 및 경고 가능

작동 방식 (단계별)

1. VM이 아웃바운드 연결을 시작합니다.
2. 사용자 정의 경로(UDR)가 흐름을 가로채서 Azure Firewall의 프라이빗 IP로 리디렉션합니다.
3. Azure Firewall이 트래픽을 평가합니다:
   • 네트워크 규칙 (IP/포트 일치)
   • 애플리케이션 규칙 (FQDN/URL 일치)
   • 위협 인텔리전스 (알려진 악성 IP/도메인)
4. 허용된 경우: 방화벽의 공용 IP를 통해 트래픽이 전달됩니다.
5. 거부된 경우: 트래픽이 차단되고 로그에 기록됩니다.
6. 모든 흐름(허용 및 거부)은 Log Analytics / Sentinel에 기록됩니다.

장점

• ✅ Full L3–L7 검사
• ✅ FQDN 및 URL 기반 필터링 (애플리케이션 규칙)
• ✅ 위협 인텔리전스 통합 (Microsoft TI 피드)
• ✅ TLS 검사 (Premium SKU)
• ✅ 중앙 집중식 거버넌스 (Firewall Manager를 통해 여러 VNet 관리)
• ✅ 풍부한 로깅 — 모든 허용/거부 흐름 기록
• ✅ IDPS (침입 탐지 및 방지 시스템) 제공 (Premium SKU)

제한 사항

• ❌ 높은 비용 (시간당 비용 + 데이터 처리 요금)
• ❌ 각 스포크 서브넷에 UDR 설정 필요
• ❌ 미세한 지연 시간(Latency) 추가
• ❌ 대규모 환경에서 세심한 SNAT 설정 필요

가장 적합한 사용 사례

• ✅ 규제 준수가 필요한 산업 (금융, 의료, 정부)
• ✅ 아웃바운드 인터넷이 보안 경계여야 하는 모든 워크로드
• ✅ 규정 준수를 위해 송신 허용 목록(Allowlisting)이 필요한 환경
• ✅ 중앙 집중식 제어 평면을 갖춘 허브-앤-스포크 아키텍처
• ✅ 아웃바운드 흐름 텔레메트리가 필요한 SOC 환경

시나리오 3: Load Balancer 아웃바운드

Load Balancer 아웃바운드란 무엇인가?

Azure Load Balancer 아웃바운드 규칙은 과거에 표준 부하 분산 장치 뒤에 있는 VM에 SNAT를 제공하는 주요 메커니즘이었습니다. NAT Gateway나 Azure Firewall과 같은 최신 패턴이 이를 대체하고 있지만, 특정 시나리오에서는 여전히 유효합니다.

주요 흐름:

• VMs → Load Balancer: 백엔드 풀 멤버가 SNAT를 할당받음
• LB 아웃바운드 규칙: VM당 포트 할당 정의
• ⚠️ 대규모 환경에서 포트 고갈 위험
• ⚠️ 검사 또는 정책 강제 기능 없음

작동 방식 (단계별)

1. 백엔드 풀의 VM이 아웃바운드 연결을 시작합니다.
2. Load Balancer가 프런트엔드 공용 IP를 사용하여 SNAT를 적용합니다.
3. 고정된 풀에서 VM당 임시(Ephemeral) 포트가 할당됩니다.
4. 응답 트래픽은 추적되어 올바른 VM으로 전달됩니다.
5. 포트 풀이 고갈되면 연결이 실패합니다 (SNAT 고갈).

장점

• NAT Gateway나 방화벽보다 낮은 비용
• 기존 부하 분산 워크로드와 긴밀하게 통합됨
• 기존 운영 팀에게 익숙한 모델

제한 사항

• ❌ SNAT 포트 풀이 고정되어 있으며 수동 관리가 필요함
• ❌ 대규모 환경에서 SNAT 고갈 위험
• ❌ 트래픽 검사 기능 없음
• ❌ NAT Gateway보다 유연성이 떨어짐
• ❌ 신규 설계에는 권장되지 않음

가장 적합한 사용 사례

• ✅ 이미 Azure Load Balancer를 중심으로 구축된 기존 아키텍처
• ✅ 아웃바운드 연결 볼륨이 낮은 워크로드
• ✅ NAT Gateway로 현대화하기 전의 과도기적 아키텍처

의사 결정 프레임워크: 올바른 아웃바운드 패턴 선택

피해야 할 일반적인 실수

⚠️ 실수 1: SNAT 확장 제한 망각 Load Balancer 아웃바운드 규칙은 VM당 고정된 수의 임시 포트를 할당합니다. 규모가 커지면 빠르게 고갈됩니다. 이럴 때는 NAT Gateway를 사용하세요.

⚠️ 실수 2: 저위험 워크로드에 대한 과도한 보안 설정 모든 워크로드에 아웃바운드용 Azure Firewall이 필요한 것은 아닙니다. 개발/테스트 및 패치 트래픽은 더 간단하고 저렴하며 빠른 NAT Gateway로 충분합니다.

⚠️ 실수 3: 동일한 서브넷에서 아웃바운드 모델 혼용 NAT Gateway와 Load Balancer 아웃바운드 규칙은 동일한 서브넷에 공존할 수 없습니다. NAT Gateway가 항상 우선순위를 갖습니다. 서브넷 경계를 신중하게 계획하세요.

⚠️ 실수 4: Azure 플랫폼 종속성 차단 많은 Azure 서비스가 여전히 공용 엔드포인트를 사용합니다 (Private Link를 사용할 수 있는 경우에도). 송신 제어를 강화하기 전에 아웃바운드 정책이 필요한 Azure 서비스 태그를 허용하는지 확인하세요.

⚠️ 실수 5: 플랫폼 기본값에 의존 기본 아웃바운드 액세스는 신규 VNet에서 더 이상 지원되지 않습니다. 명시적인 구성 없이는 VM이 인터넷에 도달할 수 있다고 가정하지 마십시오.

요약 및 주요 시사점

핵심 원칙 프라이빗 서브넷은 아웃바운드 액세스를 "의도적"으로 만듭니다. 가장 복잡한 옵션이 아니라, 워크로드의 위험 수준에 맞는 아웃바운드 패턴을 선택하십시오.

참고 자료

• Azure NAT Gateway 개요
• Azure Firewall 개요
• Load Balancer 아웃바운드 규칙
• Azure VM의 기본 아웃바운드 액세스 중단 예고