Front Door와 Traffic Manager는 무엇이 다른가요?

Front Door는 엣지에서 트래픽을 직접 처리하는 L7 리버스 프록시로, 글로벌 부하 분산과 함께 캐싱·WAF·SSL 종료를 제공합니다. Traffic Manager는 DNS 기반이라 실제 트래픽이 통과하지 않고 어느 엔드포인트로 갈지 DNS 응답만 돌려줍니다. 빠른 장애 조치와 HTTP 최적화가 필요하면 Front Door, 비-HTTP를 포함한 단순 DNS 라우팅이면 Traffic Manager가 맞습니다.

Load Balancer와 Application Gateway는 함께 쓸 수 있나요?

함께 쓸 수 있습니다. 둘은 계층이 달라 역할이 나뉩니다. Application Gateway는 HTTP/HTTPS(L7) 웹 트래픽을 경로·호스트 기준으로 라우팅하고, Load Balancer는 TCP/UDP(L4) 비-HTTP 트래픽을 저지연으로 분산합니다. 실무에서는 두 서비스를 용도에 맞게 나눠 배치합니다.

WAF가 필요하면 어떤 서비스를 골라야 하나요?

WAF(웹 방화벽)는 Application Gateway의 WAF SKU(지역 단위)나 Front Door의 WAF(글로벌 엣지 단위)에 붙일 수 있습니다. Load Balancer와 Traffic Manager에는 WAF 기능이 없으므로, 웹 공격 방어가 필요하면 Application Gateway 또는 Front Door를 선택해야 합니다.

여러 지역에 배포한 웹앱이면 무엇을 써야 하나요?

글로벌 진입점으로 Front Door를 두고, 각 지역 내부에서는 Application Gateway(L7)나 Load Balancer(L4)로 다시 분산하는 계층 구성이 일반적입니다. Front Door가 엣지 가속·글로벌 부하 분산·WAF를 담당하고, 지역 부하 분산기가 실제 백엔드로 트래픽을 전달합니다.

Azure 부하 분산 선택: Load Balancer·Application Gateway·Front Door·Traffic Manager 비교

Azure에는 이름이 비슷한 부하 분산 서비스가 네 개나 있어 처음 고를 때 누구나 헷갈립니다. 결국 두 가지 축 — L4냐 L7이냐, 그리고 지역이냐 글로벌이냐 — 만 잡으면 선택은 단순해집니다. 각 서비스의 성격과 상황별 선택 기준을 정리했습니다.

한눈에 보기

Load Balancer : TCP/UDP(L4)를 한 지역 안에서 초저지연으로 분산. VM·VMSS 앞단.
Application Gateway : HTTP/HTTPS(L7)를 한 지역 안에서 경로·호스트 기준으로 라우팅. WAF 선택 가능.
Front Door : HTTP/HTTPS(L7)를 글로벌 엣지에서 분산·가속. 캐싱·WAF 포함.
Traffic Manager : DNS 기반 글로벌 라우팅. 트래픽은 통과하지 않고 어느 엔드포인트로 갈지만 알려줌.

“부하 분산기 하나 붙이면 되는 줄 알았는데 Azure에는 Load Balancer, Application Gateway, Front Door, Traffic Manager가 다 있다”—처음 아키텍처를 짜는 팀이 거의 예외 없이 멈칫하는 지점입니다. 이름만 보면 경쟁 제품 같지만, 실제로는 동작 계층(L4/L7)과 적용 범위(지역/글로벌)가 다른 서로 다른 도구입니다. 하나를 고르는 문제가 아니라, 대개는 계층으로 함께 씁니다.

네 서비스 한눈에 비교

기준	Load Balancer	Application Gateway	Front Door	Traffic Manager
동작 계층	L4 (TCP/UDP)	L7 (HTTP/S)	L7 (HTTP/S)	DNS 기반
적용 범위	지역(Regional)	지역(Regional)	글로벌	글로벌
트래픽 경유	통과(프록시)	통과(프록시)	통과(엣지 프록시)	미경유(DNS만 응답)
라우팅 기준	5튜플·포트	URL 경로·호스트	URL 경로·호스트·엣지	우선순위·가중치·성능·지리
WAF	없음	있음(WAF SKU)	있음	없음
캐싱/CDN	없음	없음	있음	없음
SSL 종료	없음(패스스루)	있음	있음	해당 없음
대표 용도	VM·VMSS L4 분산, 비-HTTP	단일 지역 웹앱 L7	다중 지역 웹앱·엣지 가속	다중 지역 장애 조치(비-HTTP 포함)

표를 세로로 읽으면 성격이 드러납니다. Load Balancer와 Application Gateway는 한 지역 안에서 실제 트래픽을 처리하고, Front Door와 Traffic Manager는 여러 지역에 걸친 진입을 조율합니다. 다만 Front Door는 트래픽을 엣지에서 직접 받는 반면, Traffic Manager는 DNS 응답만 돌려준다는 점이 결정적으로 다릅니다.

두 개의 축으로 정리하기

네 서비스는 사실 두 질문으로 갈립니다.

① TCP 레벨(L4)이냐, HTTP 레벨(L7)이냐? — URL 경로나 호스트 헤더로 라우팅해야 하면 L7이 필요합니다. 단순히 포트로 서버에 분산만 하면 L4로 충분합니다.
② 한 지역이냐, 여러 지역이냐? — 백엔드가 한 지역에 있으면 지역 서비스, 여러 지역에 걸쳐 있으면 글로벌 서비스가 필요합니다.

이 두 축을 교차하면 자연스럽게 매칭됩니다.

	지역(Regional)	글로벌(Global)
L4 (TCP/UDP)	Load Balancer	Traffic Manager(DNS)
L7 (HTTP/S)	Application Gateway	Front Door

비-HTTP(예: 게임 서버, 데이터베이스, SMTP)를 여러 지역으로 나눠야 한다면 L7 프록시인 Front Door로는 감당이 안 되므로, DNS 라우팅인 Traffic Manager가 유일한 글로벌 선택지가 됩니다.

각 서비스가 빛나는 시나리오

Load Balancer — 한 지역의 VM 스케일 세트 앞단에서 TCP/UDP 트래픽을 나누거나, 데이터베이스·게임 서버처럼 HTTP가 아닌 워크로드를 분산할 때 씁니다. 지연이 극히 낮고 처리량이 높습니다.

Application Gateway — 단일 지역에 배포한 웹 애플리케이션에서 /api는 API 백엔드로, /img는 정적 백엔드로 보내는 식의 경로 기반 라우팅, SSL 종료, 쿠키 기반 세션 어피니티가 필요할 때 적합합니다. WAF SKU를 쓰면 웹 공격 방어까지 한 곳에서 처리합니다.

Front Door — 사용자가 여러 나라에 흩어져 있고 백엔드도 여러 지역에 있을 때, 가장 가까운 엣지로 받아 지연을 줄이고 정적 자원을 캐싱하며 글로벌 장애 조치를 하고 싶을 때 선택합니다. 엣지에서 WAF와 SSL을 함께 처리합니다.

Traffic Manager — HTTP가 아닌 트래픽을 포함해 여러 지역 엔드포인트 사이에서 우선순위·성능·지리 기반으로 DNS 라우팅을 하거나, 액티브-패시브 재해 복구를 단순하게 구성할 때 씁니다. 트래픽 자체는 통과하지 않으므로 오버헤드가 없습니다.

선택 기준 체크리스트

URL 경로·호스트로 라우팅해야 하나? → 예면 L7(Application Gateway 또는 Front Door), 아니면 L4로 충분합니다.
백엔드가 여러 지역에 걸쳐 있나? → 예면 글로벌(Front Door 또는 Traffic Manager), 아니면 지역 서비스.
정적 자원 캐싱·엣지 가속이 필요한가? → 그렇다면 CDN이 내장된 Front Door.
웹 방화벽(WAF)이 필요한가? → Application Gateway(WAF SKU) 또는 Front Door.
HTTP가 아닌 프로토콜을 여러 지역으로 보내야 하나? → DNS 기반 Traffic Manager.

빠른 결론
한 지역 비-HTTP는 Load Balancer, 한 지역 웹앱은 Application Gateway, 여러 지역 웹앱은 Front Door, 여러 지역·비-HTTP 라우팅은 Traffic Manager. 대규모 서비스는 넷 중 하나가 아니라 글로벌(Front Door) → 지역(App Gateway/Load Balancer) 계층으로 조합하는 경우가 많습니다.

만드는 명령은 얼마나 다른가 (CLI 비교)

네 서비스 모두 Azure CLI로 시작할 수 있지만, 요구하는 사전 리소스와 개념이 다릅니다.

# Load Balancer (L4, 지역) — 표준 SKU 공용 부하 분산
az network lb create \
  --resource-group rg-demo --name lb-demo --sku Standard \
  --public-ip-address pip-lb --frontend-ip-name fe --backend-pool-name bepool

# Application Gateway (L7, 지역) — 경로 기반 라우팅·SSL·WAF(선택)
az network application-gateway create \
  --resource-group rg-demo --name agw-demo \
  --sku WAF_v2 --capacity 2 --vnet-name vnet-demo --subnet snet-agw \
  --public-ip-address pip-agw --frontend-port 443

# Front Door (L7, 글로벌) — 엣지 가속·글로벌 LB·WAF
az afd profile create \
  --resource-group rg-demo --profile-name afd-demo --sku Premium_AzureFrontDoor
# 이후 endpoint · origin group · route 를 추가

# Traffic Manager (DNS, 글로벌) — 우선순위·가중치·성능 기반 라우팅
az network traffic-manager profile create \
  --resource-group rg-demo --name tm-demo \
  --routing-method Performance --unique-dns-name my-tm-demo

Traffic Manager만 공용 IP가 아니라 --unique-dns-name으로 DNS 이름을 잡는다는 점이 성격을 그대로 보여줍니다. 나머지 셋은 트래픽이 통과하는 프록시라 프런트엔드 IP·포트가 필요합니다.

흔한 실수

Traffic Manager가 트래픽을 프록시한다고 오해한다 — 실제 트래픽은 통과하지 않고 DNS 응답만 돌려줍니다. 그래서 장애 조치도 DNS TTL만큼 지연되며, 클라이언트가 캐싱한 DNS 때문에 즉시 전환되지 않을 수 있습니다.
단일 지역 앱에 Front Door를 붙인다 — 글로벌이 필요 없는데 비용과 구성 복잡도만 늘어납니다. 한 지역이면 Application Gateway로 충분합니다.
Load Balancer로 URL 경로 라우팅을 시도한다 — L4라 경로·호스트 헤더를 보지 못합니다. 경로 기반 라우팅이 필요하면 Application Gateway나 Front Door가 필요합니다.
WAF를 아무 데나 둘 수 있다고 생각한다 — WAF는 Application Gateway와 Front Door에만 붙습니다. Load Balancer·Traffic Manager 경로에는 웹 방화벽을 걸 수 없습니다.
넷을 경쟁 관계로 보고 하나만 고른다 — 실제 대규모 아키텍처는 Front Door(글로벌·WAF) 뒤에 지역별 Application Gateway 또는 Load Balancer를 두는 계층 구성이 표준입니다.

실무에서는 대개 계층으로 조합한다

단일 서비스로 끝나는 경우는 소규모일 때뿐입니다. 트래픽이 커지고 지역이 늘면 자연스럽게 계층이 생깁니다. 예를 들어 전 세계 사용자를 받는 웹 서비스는 Front Door가 엣지에서 트래픽을 받아 WAF·캐싱·글로벌 부하 분산을 처리하고, 각 지역 내부에서는 Application Gateway가 L7 라우팅을, 그 뒤 Load Balancer가 VM 스케일 세트로 L4 분산을 담당합니다. 이렇게 역할을 나누면 각 계층이 잘하는 일에만 집중하게 되어, “어느 하나만 골라야 한다”는 고민 자체가 사라집니다.

자주 묻는 질문

Q. Front Door와 Traffic Manager는 무엇이 다른가요?
Front Door는 엣지에서 트래픽을 직접 처리하는 L7 리버스 프록시로 글로벌 부하 분산과 함께 캐싱·WAF·SSL 종료를 제공합니다. Traffic Manager는 DNS 기반이라 트래픽이 통과하지 않고 어느 엔드포인트로 갈지 DNS 응답만 돌려줍니다. 빠른 장애 조치·HTTP 최적화면 Front Door, 비-HTTP를 포함한 단순 DNS 라우팅이면 Traffic Manager가 맞습니다.
Q. Load Balancer와 Application Gateway는 함께 쓸 수 있나요?
함께 쓸 수 있습니다. 둘은 계층이 달라, Application Gateway는 HTTP/HTTPS(L7) 웹 트래픽을 경로·호스트 기준으로 라우팅하고 Load Balancer는 TCP/UDP(L4) 비-HTTP 트래픽을 저지연으로 분산합니다. 실무에서는 용도에 맞게 나눠 배치합니다.
Q. WAF가 필요하면 어떤 서비스를 골라야 하나요?
WAF는 Application Gateway의 WAF SKU(지역 단위)나 Front Door의 WAF(글로벌 엣지 단위)에 붙일 수 있습니다. Load Balancer와 Traffic Manager에는 WAF가 없으므로 웹 공격 방어가 필요하면 이 둘 중 하나를 선택해야 합니다.
Q. 여러 지역에 배포한 웹앱이면 무엇을 써야 하나요?
글로벌 진입점으로 Front Door를 두고, 각 지역 내부에서는 Application Gateway(L7)나 Load Balancer(L4)로 다시 분산하는 계층 구성이 일반적입니다. Front Door가 엣지 가속·글로벌 부하 분산·WAF를, 지역 부하 분산기가 실제 백엔드 전달을 담당합니다.

정리하면, Azure 부하 분산 선택은 “무엇이 제일 좋은가”가 아니라 L4인가 L7인가, 지역인가 글로벌인가라는 두 질문의 답입니다. 두 축을 먼저 정하면 네 서비스는 서로 자리를 다투지 않고 각자의 위치를 찾습니다.

부하 분산 앞뒤로 이어지는 주제들도 함께 보시면 그림이 완성됩니다. 컨테이너 앱을 어디에 올릴지는 App Service·Container Apps·AKS 비교에, 트래픽이 도착한 뒤의 보안 계층은 NSG·Azure Firewall·WAF 비교에, 백엔드로 나가는 사설 경로는 Private Endpoint와 Service Endpoint에 정리했습니다.