Azure Load Balancer와 Application Gateway 차이: L4와 L7, 무엇을 언제 선택할까

Azure Load Balancer와 Application Gateway 차이: L4와 L7, 무엇을 언제 선택할까

2026. 5. 30. 09:00ㆍCloud/Azure

Azure Load Balancer는 TCP/UDP를 다루는 L4 분산기이고, Application Gateway는 HTTP/HTTPS를 이해하는 L7 분산기입니다. 둘 중 하나를 고르는 것이 아니라, 트래픽 종류에 따라 역할을 나누는 것이 핵심입니다.

요약

기준	Load Balancer	Application Gateway
동작 계층	L4 (TCP/UDP)	L7 (HTTP/HTTPS)
라우팅 기준	5-tuple 해시 (IP/포트/프로토콜)	URL 경로, 호스트 헤더
SSL 종료	미지원	지원 (SSL Offload)
WAF	미지원	WAF_v2 SKU에서 지원
추천 상황	비-HTTP 트래픽, 고성능 L4 분산	웹 트래픽, 경로 기반 라우팅, 웹 방화벽 필요 시

1. 왜 이 비교가 필요한가

Azure에 웹 서비스를 올리고 "부하 분산기를 붙여야지"라고 생각하는 순간, 선택지가 두 개로 갈립니다. Load Balancer와 Application Gateway입니다. 이름만 보면 둘 다 트래픽을 나눠주는 도구라 비슷해 보입니다.

하지만 두 서비스는 동작하는 네트워크 계층이 다릅니다. 이 차이를 모르고 선택하면 다음과 같은 문제가 생깁니다.

HTTP 경로별로 트래픽을 나누고 싶은데 Load Balancer를 골라서 결국 불가능한 경우
단순 TCP 게임 서버에 Application Gateway를 붙였다가 불필요한 비용과 제약이 생기는 경우
WAF(웹 방화벽)가 필요한데 Load Balancer만 두고 별도 보안 계층을 빠뜨리는 경우

결론부터 말하면, 트래픽이 HTTP/HTTPS인지 아닌지가 1차 판단 기준입니다. 이 글에서는 그 기준을 계층·라우팅·보안·비용·운영 관점으로 나눠 설명합니다.

2. 비교 대상 개요

2.1 Azure Load Balancer란

Azure Load Balancer는 OSI 4계층(전송 계층)에서 동작하는 부하 분산기입니다. TCP와 UDP 트래픽을 처리하며, 패킷의 내용(HTTP 헤더, URL 등)은 들여다보지 않습니다.

핵심 특성:

특성	설명
동작 계층	L4 (TCP/UDP)
분산 방식	5-tuple(출발지 IP·포트, 목적지 IP·포트, 프로토콜) 해시
범위	리전 단위. Standard SKU는 가용 영역(AZ) 지원
유형	Public(인터넷 대면) / Internal(VNet 내부)
연결 처리	패스스루(pass-through). 연결을 종료하지 않음

Load Balancer는 들어온 연결을 백엔드 풀의 인스턴스로 그대로 전달합니다. 트래픽을 가로채 해석하지 않으므로 지연이 적고 처리량이 높습니다.

2.2 Application Gateway란

Application Gateway는 OSI 7계층(애플리케이션 계층)에서 동작하는 웹 트래픽 전용 부하 분산기입니다. HTTP/HTTPS 요청의 내용을 해석할 수 있어, URL 경로나 호스트 이름을 기준으로 트래픽을 라우팅할 수 있습니다.

핵심 특성:

특성	설명
동작 계층	L7 (HTTP, HTTPS, HTTP/2, WebSocket)
분산 방식	URL 경로 기반, 다중 사이트 호스팅(호스트 헤더)
동작 모델	리버스 프록시. 클라이언트 연결을 종료하고 새 연결을 백엔드로 생성
부가 기능	SSL 종료, WAF, 쿠키 기반 세션 고정, URL 재작성, 리디렉션
범위	리전 단위. v2 SKU는 AZ 및 오토스케일 지원

Application Gateway는 요청을 직접 받아 해석한 뒤, 규칙에 따라 적절한 백엔드 풀로 전달합니다. 이 과정에서 SSL 복호화, 헤더 검사, 경로 매칭 등이 일어납니다.

3. 핵심 차이 표

기준	Load Balancer	Application Gateway
OSI 계층	L4 (전송)	L7 (애플리케이션)
지원 프로토콜	TCP, UDP	HTTP, HTTPS, HTTP/2, WebSocket
라우팅 기준	5-tuple 해시	URL 경로, 호스트 헤더
패킷 해석	안 함 (패스스루)	함 (리버스 프록시)
SSL/TLS 종료	미지원	지원 (SSL Offload, E2E TLS)
세션 고정	소스 IP 기반(2/3-tuple)만 가능	쿠키 기반 가능
WAF	미지원	WAF_v2에서 지원
URL 재작성/리디렉션	미지원	지원
전용 Subnet	불필요	필요 (Application Gateway 전용)
일반적 지연/처리량	낮은 지연, 높은 처리량	L7 처리로 상대적 오버헤드
대표 용도	DB, 게임, 커스텀 TCP/UDP	웹 애플리케이션, API, 마이크로서비스

4. 구조 차이

4.1 Load Balancer: 패킷을 해석하지 않는다

Load Balancer는 들어온 연결의 5-tuple을 해시해서 백엔드 인스턴스 하나를 고릅니다. 같은 5-tuple은 같은 인스턴스로 가지만, 요청 내용이 무엇인지는 보지 않습니다.

클라이언트 → Load Balancer(5-tuple 해시) → VM A 또는 VM B

/images로 가든 /api로 가든 Load Balancer 입장에서는 동일한 TCP 연결일 뿐입니다.
경로별로 다른 백엔드로 보내는 것은 불가능합니다.
대신 패킷을 그대로 흘려보내므로 처리 오버헤드가 작습니다.

4.2 Application Gateway: 요청을 읽고 라우팅한다

Application Gateway는 HTTP 요청을 받아 URL 경로나 호스트 헤더를 검사한 뒤, 규칙에 맞는 백엔드 풀로 전달합니다.

클라이언트 → Application Gateway(L7 규칙 평가)
                 ├── /api/*   → API 백엔드 풀
                 └── 그 외     → 웹 백엔드 풀

/api/* 요청은 API 서버로, 나머지는 웹 서버로 나눌 수 있습니다.
shop.example.com과 blog.example.com을 하나의 게이트웨이에서 다른 백엔드로 호스팅할 수 있습니다(다중 사이트 호스팅).
클라이언트 연결을 종료하고 백엔드로 새 연결을 만들기 때문에, SSL 복호화나 헤더 조작이 가능합니다.

5. 비용 차이

검증 필요
아래 가격 체계는 변경될 수 있으며 리전별로 상이합니다. 실제 단가는 Azure 공식 Pricing 페이지에서 확인해야 합니다.

두 서비스는 과금 모델 자체가 다릅니다. (공식 Pricing 문서 기준으로 확인한 과금 구조입니다.)

항목	Load Balancer (Standard)	Application Gateway (v2)
과금 구조	규칙 수 + 처리 데이터량	고정 시간 요금 + 용량 단위(Capacity Unit) 소비량
유휴 시 비용	규칙 기준으로 비교적 낮음	게이트웨이가 떠 있으면 고정 요금 발생
트래픽 증가 시	데이터 처리량에 비례	CU 소비량(연결 수, 처리량, 컴퓨트)에 비례

핵심은 다음과 같습니다.

Load Balancer는 일반적으로 Application Gateway보다 저렴한 경우가 많습니다. L4 패스스루라 처리 비용이 낮기 때문입니다.
Application Gateway는 게이트웨이를 띄워두는 것만으로 고정 시간 요금이 발생합니다. WAF_v2는 Standard_v2보다 단가가 높습니다.
따라서 "단순히 트래픽을 나누기만 하면 되는데" Application Gateway를 선택하면 불필요한 고정 비용을 부담할 수 있습니다.

비용만 보면 Load Balancer가 유리하지만, WAF나 경로 기반 라우팅이 필요한 상황에서 Load Balancer를 고르면 그 기능을 별도 계층(예: NVA, 자체 프록시)으로 직접 구축해야 하므로 총비용과 운영 부담이 오히려 커질 수 있습니다.

6. 보안 차이

6.1 WAF: Application Gateway만의 핵심 차별점

가장 큰 보안 차이는 WAF(Web Application Firewall)입니다.

Application Gateway의 WAF_v2 SKU는 OWASP 코어 룰셋 기반으로 SQL Injection, XSS 등 일반적인 웹 공격을 필터링합니다.
Load Balancer는 L4에서 동작하므로 HTTP 페이로드를 검사할 수 없고, WAF 기능 자체가 없습니다.

웹 애플리케이션을 인터넷에 직접 노출하는 경우, WAF는 단순한 부가 기능이 아니라 기본 방어선에 가깝습니다.

Security Note
Standard SKU Load Balancer는 기본적으로 "닫힌" 상태입니다. NSG로 명시적으로 허용해야 트래픽이 통과합니다. 반면 인터넷에 노출되는 웹 서비스라면 L4 차원의 NSG만으로는 애플리케이션 계층 공격을 막을 수 없습니다. 이 경우 Application Gateway(WAF_v2) 또는 글로벌 계층의 Azure Front Door(WAF)를 함께 검토하는 것이 좋습니다.

6.2 SSL 종료와 인증서 관리

Application Gateway는 SSL 종료(SSL Offload)를 지원합니다. 인증서를 게이트웨이에서 관리하고, 백엔드와는 평문 또는 재암호화(end-to-end TLS)로 통신할 수 있습니다.
Load Balancer는 TLS를 종료하지 않습니다. 암호화/복호화는 백엔드 인스턴스가 직접 처리해야 합니다.

인증서를 한 곳에서 관리하고 싶거나, 백엔드 서버의 TLS 처리 부담을 줄이고 싶다면 Application Gateway가 유리합니다.

6.3 접근 제어 관점

기준	Load Balancer	Application Gateway
트래픽 필터링	NSG (L3/L4)	NSG + WAF (L7 페이로드 검사)
공격 차단 범위	포트/IP 수준	포트/IP + 애플리케이션 계층 공격
인증서 관리	백엔드에서 직접	게이트웨이에서 중앙 관리

7. 운영 복잡도 차이

기준	Load Balancer	Application Gateway
전용 Subnet	불필요	전용 Subnet 필요
초기 설정	단순 (풀, 프로브, 규칙)	상대적으로 복잡 (리스너, 규칙, HTTP 설정, 인증서)
헬스 프로브	TCP/HTTP/HTTPS	HTTP/HTTPS 커스텀 프로브
스케일링	자동 (규모에 따라 확장)	v2는 오토스케일 지원
기능 확장성	L4 범위로 제한	경로 라우팅, 재작성, 리디렉션 등 풍부

Load Balancer는 설정 요소가 적어 운영이 단순합니다. 백엔드 풀, 헬스 프로브, 분산 규칙 정도만 정의하면 됩니다.

Application Gateway는 리스너(Listener), 라우팅 규칙, HTTP 설정, 백엔드 풀, 인증서 등 구성 요소가 많습니다. 그만큼 세밀한 제어가 가능하지만 초기 설정과 트러블슈팅 난이도가 높습니다. 또한 배포할 때 전용 Subnet이 필요하므로 VNet 설계 단계에서 미리 IP 대역을 확보해야 합니다.

8. 선택 기준

8.1 의사결정 플로우

분산하려는 트래픽이 무엇인가?
│
├── HTTP / HTTPS 웹 트래픽
│   └── URL 경로 라우팅 / SSL 종료 / WAF가 필요한가?
│       ├── 필요함        → Application Gateway (WAF_v2)
│       └── 기본 L7만 필요 → Application Gateway (Standard_v2)
│
└── TCP / UDP 비-HTTP 트래픽 (DB, 게임, MQTT, 커스텀 프로토콜)
    └── Load Balancer

8.2 상황별 권장

상황	권장 선택	이유
데이터베이스 연결 분산	Load Balancer (Internal)	TCP 기반, L7 기능 불필요
실시간 게임/IoT(UDP)	Load Balancer	UDP 지원, 낮은 지연
단순 웹 트래픽(경로 분리 없음)	상황에 따라 둘 다 가능	WAF가 필요하면 App Gateway
경로별 마이크로서비스 라우팅	Application Gateway	URL 경로 기반 라우팅
인터넷 노출 웹 + 웹 방화벽	Application Gateway (WAF_v2)	OWASP 기반 공격 필터링
다중 도메인 호스팅	Application Gateway	다중 사이트 호스팅

8.3 글로벌 vs 리전 관점

Load Balancer와 Application Gateway는 모두 리전 단위 서비스입니다. 여러 리전에 걸친 트래픽 분산이 필요하면 글로벌 계층 서비스를 함께 고려해야 합니다.

서비스	계층	범위
Load Balancer	L4	리전
Application Gateway	L7	리전
Traffic Manager	DNS 기반	글로벌
Azure Front Door	L7	글로벌

예를 들어 글로벌 사용자를 대상으로 하는 웹 서비스라면, 글로벌 진입점은 Front Door(L7, WAF, CDN)로 두고, 각 리전 내부에서는 Application Gateway나 Load Balancer로 트래픽을 분산하는 다층 구조를 설계할 수 있습니다.

9. 실무 예시

사례 1: Application Gateway와 Internal Load Balancer를 함께 사용

3-Tier 웹 서비스에서 두 서비스를 역할에 따라 나눠 쓰는 구조입니다.

프런트엔드 계층: Application Gateway(WAF_v2)가 인터넷 트래픽을 받습니다. SSL 종료, 경로 기반 라우팅, 웹 공격 필터링을 담당합니다.
애플리케이션 계층: Internal Load Balancer가 내부 애플리케이션 VM 사이의 TCP 트래픽을 분산합니다. 외부에 노출되지 않습니다.

이 구조를 선택한 이유:

외부에 노출되는 진입점은 L7 보안(WAF)이 필요하므로 Application Gateway가 적합합니다.
내부 서비스 간 통신은 단순 TCP 분산이면 충분하므로, 더 저렴하고 단순한 Internal Load Balancer가 적합합니다.
역할을 분리하면 각 계층의 비용과 보안 수준을 독립적으로 조정할 수 있습니다.

"왜 둘 다 쓰느냐"는 질문에 대한 답은, 계층마다 요구사항이 다르기 때문입니다. 진입점은 보안이 중요하고, 내부는 성능과 단순함이 중요합니다.

사례 2: 비-HTTP 워크로드

MQTT 브로커나 게임 서버처럼 HTTP가 아닌 프로토콜을 사용하는 경우입니다.

Application Gateway는 HTTP/HTTPS/WebSocket 중심이라 임의의 TCP/UDP 프로토콜을 그대로 분산하기 어렵습니다.
이 경우 Load Balancer가 사실상 유일한 선택지입니다. UDP를 지원하고, 패킷을 해석하지 않으므로 지연이 낮습니다.

이 시나리오에서는 "L7 기능이 있는 Application Gateway가 더 좋다"는 일반론이 적용되지 않습니다. 프로토콜이 선택을 결정합니다.

10. 자주 하는 실수

웹 트래픽에 Load Balancer를 붙이고 경로 라우팅을 기대하는 것: Load Balancer는 L4라 URL을 보지 못합니다. 경로별 분산이 필요하면 Application Gateway여야 합니다.
단순 TCP 분산에 Application Gateway를 쓰는 것: 불필요한 고정 비용과 전용 Subnet, 복잡한 설정을 떠안게 됩니다. L7 기능이 필요 없으면 Load Balancer가 더 단순하고 저렴합니다.
Application Gateway 전용 Subnet을 미리 확보하지 않는 것: Application Gateway는 전용 Subnet에 배포됩니다. VNet 설계 시 빠뜨리면 나중에 IP 대역을 재조정해야 합니다.
WAF가 필요한데 L4 NSG만으로 막으려는 것: NSG는 포트/IP 수준 제어입니다. SQL Injection 같은 애플리케이션 계층 공격은 WAF가 필요합니다.
글로벌 분산을 리전 서비스로 해결하려는 것: Load Balancer와 Application Gateway는 리전 단위입니다. 여러 리전에 걸친 분산은 Traffic Manager나 Front Door를 함께 설계해야 합니다.

11. 정리

Load Balancer는 L4(TCP/UDP) 분산기, Application Gateway는 L7(HTTP/HTTPS) 분산기입니다.
1차 판단 기준은 트래픽이 HTTP/HTTPS인지 여부입니다. 비-HTTP라면 Load Balancer가 사실상 정답입니다.
URL 경로 라우팅, SSL 종료, WAF가 필요하면 Application Gateway를 선택합니다.
비용은 일반적으로 Load Balancer가 낮지만, 필요한 L7 기능을 직접 구축하면 총비용이 역전될 수 있습니다.
실무에서는 진입점에 Application Gateway(WAF), 내부에 Internal Load Balancer를 두는 조합을 자주 사용합니다.
글로벌 분산이 필요하면 Traffic Manager나 Front Door를 리전 서비스와 함께 설계합니다.

참고 문서

'Cloud > Azure' 카테고리의 다른 글

Azure App Service vs Azure Functions 차이: 언제 무엇을 선택할까 (0)	2026.06.06
Azure Storage Account 종류와 선택 기준: Blob, File, Queue, Table (0)	2026.06.05
Azure RBAC란 무엇인가: Role Assignment와 Scope 이해하기 (0)	2026.05.30
Azure NSG와 ASG 차이: 네트워크 트래픽 제어와 그룹 기반 보안 설계 (0)	2026.05.30
Azure VNet이란 무엇인가: Subnet, NSG, Route Table 개념 정리 (0)	2026.05.29

wero90