[AKS] Outbound(Egress) 경로 설계: outboundType부터 UDR(Azure Firewall)까지 (운영 체크리스트 + Test Command)

AKS를 운영하다 보면 인바운드(들어오는 트래픽)보다 아웃바운드(나가는 트래픽) 때문에 더 자주 막힙니다.

 

외부 API allowlist(고정 출구 IP), 보안팀의 방화벽 강제 경유, 프록시/SSL inspection, Private Endpoint 중심의 격리 전략까지… 전부 “AKS에서 밖으로 어떻게 나가느냐” 문제로 수렴하거든요.

 

이 글은 그 출발점인 networkProfile.outboundType(= outboundType) 을 기준으로, 각 타입이 의미하는 바와 설계 순서, 그리고 우리가 선택한 UDR(userDefinedRouting) 기준의 구현/테스트 템플릿까지 블로그용으로 정리한 글입니다.

(공식 문서 기준: https://learn.microsoft.com/en-us/azure/aks/egress-outboundtype)

 

1. outboundType이 뭔가요?

AKS의 outboundType은 클러스터(노드/파드)에서 인터넷/외부로 나가는 트래픽이 어떤 방식으로 SNAT(출구 IP 변환)되고, 어떤 경로로 빠져나갈지를 정하는 스위치입니다. 

• Ingress(인바운드) 설정이 아니라 Egress(아웃바운드) 설정입니다.
• outboundType을 쓰려면 기본적으로 VMSS + Standard Load Balancer 조건이 필요합니다.
• AKS CLI에서도 outboundType 허용 값이 명확히 정의돼 있습니다.

 

2. outboundType

AKS에서 흔히 쓰는 outbound type은 아래 다섯 가지입니다.

outboundType	의미(한 줄 요약)	언제 쓰나
loadBalancer	AKS가 Standard LB 기반 egress를 자동 구성	단순한 인터넷 아웃바운드
managedNATGateway	AKS가 관리형 NAT Gateway로 egress 구성	고정 egress IP + SNAT 확장성
userAssignedNATGateway	사용자가 만든 NAT Gateway를 egress로 사용	네트워크 표준(BYO VNet) 결합
userDefinedRouting(UDR)	AKS가 egress를 자동 구성하지 않고, UDR로 강제 라우팅	방화벽/프록시 경유 필수, 통제/로깅
none	egress 기본 경로 자체를 만들지 않음(격리 지향)	인터넷 최소화/차단, 사설만

2.1 loadBalancer (기본값)

AKS가 Standard Load Balancer 기반으로 egress를 자동 구성합니다.
가장 단순하지만, 고정 출구 IP/대량 아웃바운드/보안 통제가 강한 조직에서는 한계가 빨리 옵니다.

2.2 managedNATGateway / userAssignedNATGateway

NAT Gateway로 egress를 처리하는 방식입니다.

• NAT Gateway는 IP당 최대 64,512 TCP/UDP 플로우(최대 16 IP)까지 확장 가능해서, 대량 트래픽에서 SNAT 포트 고갈을 크게 줄여줍니다.
• managedNATGateway는 AKS가 NAT GW를 “관리형”으로 만들고 붙이는 성격,
  userAssignedNATGateway는 “내가 만든 NAT GW를 AKS가 쓰는” 성격으로 이해하면 편합니다.

2.3 userDefinedRouting (UDR)

AKS가 egress를 자동 구성하지 않고, “라우팅을 네가 책임져” 모드입니다.
보통은 **노드 서브넷에 Route Table을 연결하고 0.0.0.0/0 → Azure Firewall/NVA**로 강제 경유시킵니다.

추가로 “UDR + Azure Firewall로 egress 제한”은 공식 문서에 가이드가 있고, Azure Firewall은 AKS용 AzureKubernetesService FQDN Tag로 필요한 도메인들을 관리하기 쉽게 제공합니다.

2.4 none

AKS가 egress를 자동 구성하지 않는 형태로, 격리(인터넷 최소화/차단) 전략에서 선택합니다. outbound 의존성을 전부 Private Endpoint/허용된 경로로만 설계하려는 경우에 맞습니다. (outboundType 옵션 자체는 CLI에 정의되어 있습니다.)

 

3. 설계는 이렇게 결정하면 빨라집니다 (현업 의사결정 질문 4개)

1. 고정 출구 IP가 필요한가? (외부 API allowlist, SaaS 접근)
2. 보안팀 요구로 방화벽/프록시 경유가 “강제”인가? (검사/로깅/차단)
3. 대량 아웃바운드가 발생하는가? (SNAT 포트/연결 수)
4. 인터넷을 거의 쓰지 않는(혹은 금지) 환경인가? (Private-only)

이 질문에 대한 결론이 사실상 outboundType 결론입니다.

• 단순 인터넷 egress → loadBalancer
• 대량 egress + 고정IP + 운영 단순화 → managedNATGateway / userAssignedNATGateway
• 방화벽 강제 경유(검사/차단/로깅) → userDefinedRouting(UDR)
• 인터넷 최소/차단(격리) → none

표준: UDR(userDefinedRouting) 기반 아웃바운드 설계

우리는 보안 요구사항(방화벽 경유/로깅/차단 정책)을 만족해야 하므로 UDR을 표준으로 선택했습니다.

AKS 노드 서브넷(UDR) → Azure Firewall(NVA) → Internet
(이때 “출구 IP”는 AKS가 아니라 Firewall 쪽 Public IP로 보게 됩니다.)

4. 우리 환경: “UDR로 방화벽 강제 경유(Forced tunneling)” 기반 아웃바운드

여기서 중요한 포인트가 하나 있습니다.

(핵심) outboundType은 loadBalancer인데, 실제 egress는 UDR로 방화벽을 타고 있음

네가 실제로 확인한 출력은 아래 두 가지가 동시에 성립합니다.

1. AKS 설정상 outboundType은 loadBalancer
2. 노드 서브넷에는 Route Table이 붙어 있고, 0.0.0.0/0가 VirtualAppliance(=NVA/Firewall) 로 라우팅됨
   → 즉, 실제 인터넷 트래픽은 방화벽을 강제 경유(Forced tunneling)하는 구조입니다.

Forced tunneling은 “인터넷 바운드 트래픽을 다른 방화벽/NVA로 보내 추가 처리(검사/통제)하는 방식”으로 Azure Firewall 문서에서도 설명합니다.

4.1 현재 클러스터 outboundType 확인 결과

az aks show -g [resource-group-name] -n [aks-name] --query "networkProfile.outboundType" -o tsv
The behavior of this command has been altered by the following extension: aks-preview
loadBalancer

 

outboundType 기본값이 loadBalancer라는 점/허용 값 목록은 CLI 문서에도 그대로 나옵니다.

 

4.2 노드 서브넷에 Route Table(UDR) 연결 확인 결과

az network vnet subnet show --ids \
/subscriptions/[subscriptionsid]/resourceGroups/[resourcegroupname]/providers/Microsoft.Network/virtualNetworks/pzi-g1tfv-dev001-u2-vnt-002/subnets/pzi-g1tfv-dev001-u2-snt-003 \
--query "{subnet:name,routeTable:routeTable.id,nsg:nsg.id,natGateway:natGateway.id}" -o yaml

# 출력
natGateway: null
nsg: null
routeTable: /subscriptions/.../routeTables/[udr]
subnet: [subnet결과]

• NAT Gateway는 없음(null)
• Route Table이 서브넷에 연결됨
  → egress는 NAT GW가 아니라 UDR 기반 라우팅으로 제어하는 구조입니다.

4.3 Route Table(UDR) 라우트 확인 결과

az network route-table route list -g [resourcegroupname] \
  --route-table-name [routetablename] \
  --query "[].{name:name,addressPrefix:addressPrefix,nextHopType:nextHopType,nextHopIp:nextHopIpAddress}" -o table

# 출력
Name                 AddressPrefix         NextHopType       NextHopIp
-------------------  --------------------  ----------------  ------------
To-Internal          10.0.0.0/8            VirtualAppliance  [nexthop]
To-Internal_172      172.16.0.0/12         VirtualAppliance  [nexthop]
To-Internet          0.0.0.0/0             VirtualAppliance  [nexthop]
MSDC_Service-Routes  AppServiceManagement  Internet

 

여기서 핵심은 딱 한 줄입니다.

• 0.0.0.0/0 → VirtualAppliance 10.215.0.158

즉 인터넷으로 나가는 모든 트래픽을 NVA(대개 Azure Firewall)로 강제 경유시키는 구성이고, 이게 전형적인 forced tunneling 패턴입니다.

 

5. “실제 출구 IP”는 어디로 찍힐까? (Pod에서 검증)

설계/리소스만 보면 “그럴 것 같다” 정도지만, 운영에서 중요한 건 파드가 실제로 어디 IP로 나가느냐입니다.

네가 실행한 검증은 아주 표준적인 방법이고, 결론도 명확합니다.

 

kubectl run -it --rm netshoot --image=nicolaka/netshoot -- /bin/bash
curl -s https://api.ipify.org; echo

# 출력
172.191.11.xx

이 결과가 의미하는 것:

• AKS가 만든 Load Balancer Public IP(예: MC_ 리소스 그룹의 Public IP)로 나가는 게 아니라,
• 다른 Public IP(= 방화벽/NVA SNAT IP)로 egress가 나가고 있다는 뜻입니다.

즉, outboundType이 loadBalancer로 보이더라도, UDR에서 0.0.0.0/0을 NVA로 강제 라우팅하면 실제 트래픽은 방화벽을 타는 구조가 됩니다(Forced tunneling).

 

정리하며

• outboundType은 AKS egress 동작 방식(자동 구성 여부/기본 경로 가정) 을 정의하는 설정입니다.
• 하지만 실제 트래픽은 서브넷 UDR(0.0.0.0/0)과 방화벽/NVA 구성에 의해 강제 경유(Forced tunneling) 될 수 있고, 이때 실제 출구 IP는 방화벽 SNAT IP로 관측됩니다.
• 우리 환경에서는 ipify 기준으로 172.191.11.xx로 egress가 나가는 것이 확인되었으며, 이는 UDR 기반 방화벽 경유 구조가 실제로 적용되고 있음을 강하게 시사합니다.