ALB와 NLB 차이: 언제 어떤 Load Balancer를 선택할까

ALB와 NLB 차이: 언제 어떤 Load Balancer를 선택할까

2026. 6. 1. 07:16ㆍCloud/AWS

새 서비스를 배포하면서 Load Balancer를 생성하려는데, ALB와 NLB 중 무엇을 선택해야 할지 고민됩니다. "HTTP면 ALB, TCP면 NLB"라는 단순한 기준만으로는 실무에서 마주치는 다양한 상황을 커버하기 어렵습니다. gRPC 서비스는? WebSocket은? 고정 IP가 필요한 경우는? 선택 기준을 명확히 정리합니다.

요약

기준	ALB (Application Load Balancer)	NLB (Network Load Balancer)
OSI 계층	Layer 7 (HTTP/HTTPS)	Layer 4 (TCP/UDP/TLS)
라우팅 방식	URL 경로, 호스트 헤더, HTTP 헤더, 쿼리 스트링 기반	포트 기반 (콘텐츠 무관)
성능	수백만 RPS 처리 가능, 약간의 지연 추가	수억 RPS, 초저지연 (마이크로초 단위)
고정 IP	불가 (DNS 이름만 제공)	가능 (AZ당 Elastic IP 할당)
프로토콜	HTTP, HTTPS, gRPC, WebSocket	TCP, UDP, TLS
클라이언트 IP 보존	X-Forwarded-For 헤더	기본 보존 (Target type에 따라 다름)
비용	LCU 기반 (규칙 수, 연결 수, 대역폭, 요청 수)	NLCU 기반 (연결 수, 대역폭, 흐름 수)
대표 사용 사례	웹 애플리케이션, API Gateway, 마이크로서비스	게임 서버, IoT, 금융 거래, VPN 터널

1. AWS Load Balancer 종류와 위치

AWS Elastic Load Balancing(ELB) 서비스는 현재 세 가지 유형의 Load Balancer를 제공합니다.

유형	계층	출시	상태
Classic Load Balancer (CLB)	L4/L7	2009	레거시 (신규 사용 비권장)
Application Load Balancer (ALB)	L7	2016	현재 권장 (HTTP/HTTPS)
Network Load Balancer (NLB)	L4	2017	현재 권장 (TCP/UDP)

CLB는 레거시로 분류되며, 신규 아키텍처에서는 ALB 또는 NLB를 선택합니다. 이 글에서는 ALB와 NLB의 차이에 집중합니다.

2. 동작 계층의 차이: L7 vs L4

ALB와 NLB의 가장 근본적인 차이는 동작하는 OSI 계층입니다.

ALB — Layer 7 (Application Layer)

ALB는 HTTP/HTTPS 프로토콜을 이해합니다. 요청의 내용(URL 경로, 호스트 헤더, HTTP 메서드, 쿼리 파라미터)을 파싱하여 라우팅 결정을 내립니다.

클라이언트 → ALB → HTTP 요청 파싱 → 라우팅 규칙 평가 → Target Group 선택 → 백엔드

ALB는 HTTP 요청을 종료(terminate)하고 새로운 연결을 백엔드로 생성합니다. 이 과정에서 요청 내용을 검사하고 수정할 수 있습니다.

NLB — Layer 4 (Transport Layer)

NLB는 TCP/UDP 수준에서 동작합니다. 패킷의 내용을 검사하지 않고, IP 주소와 포트 번호만으로 라우팅합니다.

클라이언트 → NLB → IP/포트 기반 라우팅 → Target Group → 백엔드

NLB는 연결을 종료하지 않고 패킷을 그대로 전달(pass-through)합니다. 이 때문에 지연이 극히 적고, 클라이언트 IP가 백엔드에 그대로 보존됩니다.

계층 차이가 만드는 실무적 영향

영향	ALB (L7)	NLB (L4)
라우팅 유연성	URL, 헤더, 쿼리 기반 세밀한 라우팅	포트 기반 단순 라우팅
SSL 종료	ALB에서 종료 후 백엔드에 HTTP 전달 가능	TLS 종료 또는 pass-through 모두 가능
지연 시간	HTTP 파싱으로 인한 추가 지연 (밀리초 단위)	패킷 전달만 하므로 초저지연 (마이크로초 단위)
프로토콜 제한	HTTP/HTTPS/gRPC만 가능	TCP/UDP/TLS 모든 프로토콜 가능
클라이언트 IP	X-Forwarded-For 헤더로 전달	기본 보존 (인스턴스 타겟 시)

3. 라우팅 방식 비교

ALB의 콘텐츠 기반 라우팅

ALB는 리스너 규칙(Listener Rules)을 통해 요청 내용에 따라 서로 다른 Target Group으로 라우팅할 수 있습니다.

라우팅 조건:

조건 유형	예시	사용 사례
호스트 헤더	`api.example.com`	도메인별 서비스 분리
URL 경로	`/api/v1/`, `/static/`	마이크로서비스 라우팅
HTTP 메서드	`GET`, `POST`	읽기/쓰기 분리
HTTP 헤더	`X-Custom-Header: value`	A/B 테스트, 카나리 배포
쿼리 스트링	`?version=2`	버전별 라우팅
소스 IP	`10.0.0.0/8`	내부/외부 트래픽 분리

실무 시나리오 — 마이크로서비스 라우팅:

하나의 ALB로 여러 마이크로서비스를 서빙하는 구조를 설계한다고 가정합니다.

ALB 리스너 규칙:
  규칙 1: 호스트 = api.example.com, 경로 = /users/*  → User Service TG
  규칙 2: 호스트 = api.example.com, 경로 = /orders/* → Order Service TG
  규칙 3: 호스트 = admin.example.com                  → Admin Service TG
  기본 규칙: → Default Service TG (404 페이지)

이 구조에서 ALB 하나로 여러 서비스를 라우팅할 수 있으므로, 서비스마다 별도의 Load Balancer를 생성할 필요가 없습니다. 비용과 관리 복잡도를 줄일 수 있습니다.

NLB의 포트 기반 라우팅

NLB는 요청 내용을 검사하지 않으므로, 포트 번호로만 라우팅합니다.

NLB 리스너:
  포트 443 (TLS) → Backend TG (포트 443)
  포트 8080 (TCP) → Admin TG (포트 8080)
  포트 27017 (TCP) → MongoDB TG (포트 27017)

URL 경로나 헤더 기반 라우팅이 필요 없고, 단순히 포트별로 트래픽을 분배하는 경우에 적합합니다.

4. 성능 특성 비교

지연 시간 (Latency)

구분	ALB	NLB
추가 지연	수 밀리초 (ms)	수십 마이크로초 (μs)
원인	HTTP 파싱, 규칙 평가, 연결 재생성	패킷 레벨 전달, 연결 pass-through
영향	일반 웹 서비스에서는 체감 어려움	초저지연 요구 서비스에서 유의미한 차이

대부분의 웹 애플리케이션에서 ALB의 추가 지연(수 ms)은 문제가 되지 않습니다. 그러나 금융 거래 시스템, 실시간 게임 서버, HFT(High-Frequency Trading) 환경에서는 마이크로초 단위의 차이가 중요할 수 있습니다.

처리 용량 (Throughput)

구분	ALB	NLB
초당 요청 수	수백만 RPS	수억 RPS
초당 새 연결 수	수만	수백만
동시 연결 수	수백만	수천만
자동 확장	트래픽 증가 시 자동 확장 (워밍업 시간 필요)	트래픽 급증에도 즉시 대응 (워밍업 불필요)

ALB는 트래픽이 급증하면 내부적으로 스케일링하는 데 시간이 필요합니다. 예측 가능한 대규모 트래픽(이벤트, 세일)이 있다면 AWS Support에 사전 워밍업(pre-warming)을 요청할 수 있습니다.

NLB는 설계 자체가 급격한 트래픽 변동에 대응하도록 되어 있어, 별도의 워밍업 없이 수백만 RPS를 즉시 처리할 수 있습니다.

실무 시나리오 — 트래픽 급증 대응

이커머스 서비스에서 타임세일 이벤트를 진행합니다. 평소 1,000 RPS에서 이벤트 시작 시 50,000 RPS로 급증합니다.

ALB 사용 시: 급증 직후 일부 요청에서 503 에러가 발생할 수 있습니다. AWS Support에 사전 워밍업을 요청하거나, 이벤트 전에 점진적으로 트래픽을 올려 ALB를 확장시키는 방법이 있습니다.
NLB 사용 시: 즉시 대응 가능하지만, HTTP 라우팅이 필요하다면 NLB 뒤에 별도의 리버스 프록시를 두어야 합니다.

일반적으로 웹 서비스라면 ALB를 사용하면서 사전 워밍업으로 대응하는 것이 운영 복잡도 측면에서 유리합니다.

5. 고정 IP와 네트워크 특성

고정 IP 지원

구분	ALB	NLB
IP 주소	동적 (DNS 이름만 제공)	고정 (AZ당 Elastic IP 할당 가능)
DNS 이름	제공됨	제공됨
IP 화이트리스트	DNS 기반으로만 가능	고정 IP로 방화벽 규칙 설정 가능

이 차이는 실무에서 중요한 선택 기준이 됩니다.

실무 시나리오 — 파트너사 방화벽 연동:

B2B 서비스를 운영하는데, 파트너사가 자사 방화벽에 우리 서비스의 IP를 화이트리스트로 등록해야 합니다. ALB는 IP가 동적으로 변경되므로 파트너사에 고정 IP를 제공할 수 없습니다.

이 경우 선택지는 두 가지입니다.

NLB 사용: Elastic IP를 할당하여 고정 IP를 파트너사에 제공
NLB + ALB 조합: NLB(고정 IP) → ALB(HTTP 라우팅) → 백엔드. 고정 IP와 L7 라우팅이 모두 필요한 경우

두 번째 방식은 비용이 증가하지만, 고정 IP와 콘텐츠 기반 라우팅을 모두 충족할 수 있습니다.

클라이언트 IP 보존

구분	ALB	NLB
클라이언트 IP 전달 방식	X-Forwarded-For 헤더	패킷 소스 IP 그대로 보존
백엔드에서 확인 방법	HTTP 헤더 파싱 필요	소켓의 원격 IP로 직접 확인
제한 사항	헤더 위조 가능성 (신뢰 체인 필요)	IP 타겟 사용 시 Proxy Protocol 필요

NLB는 인스턴스 타겟을 사용할 때 클라이언트 IP를 그대로 보존합니다. 백엔드 애플리케이션이 소켓에서 직접 클라이언트 IP를 읽을 수 있습니다. 다만 IP 타겟이나 ALB를 타겟으로 사용하는 경우에는 Proxy Protocol v2를 활성화해야 클라이언트 IP를 전달받을 수 있습니다.

AWS PrivateLink 지원

NLB만 AWS PrivateLink(VPC Endpoint Service)의 엔드포인트로 사용할 수 있습니다. 다른 AWS 계정이나 VPC에서 프라이빗하게 서비스에 접근해야 하는 경우, NLB가 필수입니다.

[소비자 VPC] → VPC Endpoint → PrivateLink → [제공자 VPC의 NLB] → 백엔드

이 구조는 SaaS 서비스를 프라이빗하게 제공하거나, 멀티 계정 환경에서 공유 서비스를 노출할 때 사용됩니다.

6. 헬스 체크 비교

구분	ALB	NLB
프로토콜	HTTP, HTTPS	TCP, HTTP, HTTPS
경로 지정	가능 (`/health`)	HTTP/HTTPS 사용 시 가능
응답 코드 확인	가능 (200-399 등)	HTTP/HTTPS 사용 시 가능
간격	5-300초 (기본 30초)	10-300초 (기본 30초)
세밀한 판단	HTTP 응답 본문까지 확인 가능	TCP 연결 성공 여부만 확인 (TCP 모드)

ALB는 HTTP 수준의 헬스 체크를 기본으로 제공하므로, 애플리케이션이 실제로 정상 응답을 반환하는지 확인할 수 있습니다. NLB의 TCP 헬스 체크는 포트가 열려 있는지만 확인하므로, 애플리케이션이 에러를 반환하더라도 "정상"으로 판단할 수 있습니다.

7. 비용 구조 비교

ALB와 NLB 모두 시간당 고정 요금 + 사용량 기반 요금으로 구성됩니다.

요금 구조 (US-East-1 기준)

구분	ALB	NLB
시간당 고정 요금	$0.0225/시간	$0.0225/시간
사용량 단위	LCU (Load Balancer Capacity Unit)	NLCU (Network Load Balancer Capacity Unit)
사용량 요금	$0.008/LCU-시간	$0.006/NLCU-시간

서울 리전(ap-northeast-2)은 US-East-1 대비 약 10~20% 높은 요금이 적용됩니다. 정확한 리전별 요금은 AWS ELB 요금 페이지에서 리전을 선택하여 확인할 수 있습니다.

LCU vs NLCU 계산 기준

ALB의 LCU (4가지 차원 중 가장 높은 값 적용):

차원	1 LCU 기준
새 연결 수	25개/초
활성 연결 수	3,000개
처리 바이트	1GB/시간
규칙 평가 수	1,000개/초

NLB의 NLCU (4가지 차원 중 가장 높은 값 적용):

차원	1 NLCU 기준 (TCP)	1 NLCU 기준 (UDP)
새 연결/흐름 수	800개/초	400개/초
활성 연결/흐름 수	100,000개	50,000개
처리 바이트	1GB/시간	1GB/시간

비용 시나리오 비교

시나리오: 일반 웹 서비스 (HTTP API) - 초당 1,000 요청, 평균 응답 크기 10KB, 활성 연결 5,000개

이 경우 ALB와 NLB의 월 비용은 비슷한 수준입니다. 다만 ALB는 라우팅 규칙이 많아지면 LCU가 증가하고, NLB는 연결 수가 많아지면 NLCU가 증가합니다.

비용 관점 선택 기준: - 라우팅 규칙이 단순하고 연결 수가 적다면 → 비용 차이 미미 - 라우팅 규칙이 복잡하고 많다면 → ALB의 LCU 증가 주의 - 장시간 유지되는 연결이 많다면 (WebSocket, gRPC 스트리밍) → NLB가 유리할 수 있음 - 대역폭이 매우 높다면 → 두 서비스 모두 처리 바이트 기준 동일

8. 프로토콜별 선택 가이드

프로토콜/사용 사례	권장 LB	이유
HTTP/HTTPS REST API	ALB	URL 기반 라우팅, 헤더 조작, 리다이렉트
gRPC	ALB	HTTP/2 기반, 경로 라우팅 지원
WebSocket	ALB	HTTP Upgrade 지원, Sticky Session
TCP (데이터베이스, 캐시)	NLB	L4 pass-through, 초저지연
UDP (DNS, 게임, VoIP)	NLB	UDP 프로토콜 지원 (ALB 불가)
TLS pass-through	NLB	백엔드에서 직접 TLS 종료
MQTT (IoT)	NLB	장시간 TCP 연결 유지
커스텀 TCP 프로토콜	NLB	비표준 프로토콜 지원

gRPC와 WebSocket — ALB를 선택하는 이유

gRPC는 HTTP/2 기반 프로토콜입니다. ALB는 HTTP/2를 네이티브로 지원하며, gRPC 요청의 서비스/메서드 경로를 기반으로 라우팅할 수 있습니다.

ALB 규칙:
  경로 = /com.example.UserService/* → User gRPC TG
  경로 = /com.example.OrderService/* → Order gRPC TG

WebSocket도 ALB가 HTTP Upgrade 메커니즘을 지원하므로, 초기 핸드셰이크 후 양방향 통신이 가능합니다. Sticky Session을 활성화하면 같은 클라이언트의 WebSocket 연결이 동일한 백엔드 인스턴스로 유지됩니다.

UDP 서비스 — NLB만 가능

ALB는 HTTP 기반이므로 UDP를 지원하지 않습니다. DNS 서버, 게임 서버(실시간 위치 동기화), VoIP, 미디어 스트리밍 등 UDP를 사용하는 서비스는 NLB를 선택해야 합니다.

9. 실무 아키텍처 패턴

패턴 1: ALB 단독 — 일반 웹 서비스

가장 흔한 패턴입니다. HTTP/HTTPS 기반 웹 애플리케이션이나 REST API를 서빙합니다.

인터넷 → ALB (HTTPS 종료) → Target Group → EC2/ECS/Lambda

적합한 경우: - 웹 애플리케이션, REST API, GraphQL - 마이크로서비스 라우팅이 필요한 경우 - WAF(Web Application Firewall) 연동이 필요한 경우 - 인증서 관리를 LB에서 처리하고 싶은 경우

패턴 2: NLB 단독 — 비HTTP 서비스

TCP/UDP 기반 서비스를 외부에 노출합니다.

인터넷 → NLB (고정 IP) → Target Group → EC2 (게임 서버, DB 프록시 등)

적합한 경우: - 게임 서버 (UDP/TCP) - IoT 디바이스 연결 (MQTT) - 데이터베이스 프록시 (TCP) - VPN 터널 종단점 - 고정 IP가 필수인 B2B 연동

패턴 3: NLB + ALB 조합 — 고정 IP + L7 라우팅

고정 IP와 HTTP 라우팅이 모두 필요한 경우의 하이브리드 패턴입니다.

인터넷 → NLB (Elastic IP) → ALB (Target으로 등록) → Target Group → 백엔드

적합한 경우: - 파트너사에 고정 IP를 제공하면서 L7 라우팅도 필요한 경우 - PrivateLink로 서비스를 노출하면서 HTTP 라우팅이 필요한 경우

주의점: - 비용이 두 배로 증가합니다 (NLB + ALB 각각 과금) - 홉이 추가되므로 지연이 약간 증가합니다 - 운영 복잡도가 높아집니다

이 패턴은 요구사항이 명확할 때만 사용하는 것이 좋습니다.

패턴 4: NLB + PrivateLink — 크로스 계정 서비스 노출

다른 AWS 계정에 서비스를 프라이빗하게 제공하는 패턴입니다.

[소비자 계정 VPC] → VPC Endpoint → PrivateLink → [제공자 계정 NLB] → 백엔드

적합한 경우: - SaaS 서비스를 고객에게 프라이빗하게 제공 - 멀티 계정 환경에서 공유 서비스 (인증, 로깅 등) 노출 - 인터넷을 경유하지 않는 B2B 연동

10. 선택 의사결정 플로우

다음 질문을 순서대로 확인하면 대부분의 경우 적절한 선택을 할 수 있습니다.

1단계: 프로토콜 확인 - UDP가 필요한가? → NLB - 비표준 TCP 프로토콜인가? → NLB - HTTP/HTTPS/gRPC인가? → 2단계로

2단계: 네트워크 요구사항 확인 - 고정 IP가 필수인가? → NLB (또는 NLB + ALB 조합) - PrivateLink가 필요한가? → NLB - 초저지연이 필수인가? (마이크로초 단위) → NLB

3단계: 라우팅 요구사항 확인 - URL 경로/호스트 기반 라우팅이 필요한가? → ALB - WAF 연동이 필요한가? → ALB - HTTP 헤더 조작/리다이렉트가 필요한가? → ALB - 위 모두 불필요하다면 → ALB (기본 선택, 운영 편의성)

11. 운영 시 주의사항

ALB 운영 주의점

항목	설명
워밍업	트래픽 급증 예상 시 AWS Support에 사전 워밍업 요청
규칙 수 제한	리스너당 최대 100개 규칙 (기본값, 증가 요청 가능)
타임아웃	유휴 연결 타임아웃 기본 60초 (WebSocket 사용 시 증가 필요)
보안 그룹	ALB에 Security Group 연결 필수 (인바운드 규칙 설정 필요)
느린 시작	새 타겟 등록 시 Slow Start 모드로 점진적 트래픽 증가 가능

NLB 운영 주의점

항목	설명
Security Group	2023년부터 NLB에도 Security Group 연결 가능 (선택사항)
헬스 체크	TCP 헬스 체크만 사용 시 애플리케이션 레벨 장애 감지 불가
Cross-Zone	기본 비활성화 — AZ 간 트래픽 불균형 발생 가능
클라이언트 IP	IP 타겟 사용 시 Proxy Protocol v2 활성화 필요
연결 유지	유휴 연결 타임아웃 350초 (변경 불가)

Cross-Zone Load Balancing 차이

구분	ALB	NLB
기본값	활성화	비활성화
비용	무료	Cross-Zone 트래픽에 데이터 전송 비용 발생
영향	AZ 간 균등 분배	비활성화 시 AZ별 타겟 수 불균형이면 트래픽 편중

NLB에서 Cross-Zone을 비활성화한 상태에서 AZ-a에 타겟 2개, AZ-b에 타겟 1개가 있다면, AZ-b의 타겟이 AZ-a 타겟보다 2배의 트래픽을 받게 됩니다. 이 점을 고려하여 AZ별 타겟 수를 균등하게 유지하거나, Cross-Zone을 활성화해야 합니다.

12. 자주 나오는 질문

질문	핵심 답변
ALB와 NLB의 가장 큰 차이는?	동작 계층. ALB는 L7(HTTP 내용 기반 라우팅), NLB는 L4(IP/포트 기반 라우팅)
고정 IP가 필요하면?	NLB. ALB는 동적 IP만 제공하므로 Elastic IP 할당 불가
gRPC 서비스에는?	ALB. HTTP/2 네이티브 지원, 서비스 경로 기반 라우팅 가능
PrivateLink를 사용하려면?	NLB 필수. ALB는 VPC Endpoint Service의 엔드포인트로 사용 불가
트래픽 급증 대응은?	NLB가 유리. ALB는 워밍업 시간 필요, NLB는 즉시 대응
둘 다 필요한 경우는?	NLB → ALB 조합. 고정 IP + L7 라우팅이 모두 필요할 때
WAF를 연동하려면?	ALB. NLB는 AWS WAF 연동 불가
Cross-Zone 기본값 차이는?	ALB는 기본 활성화(무료), NLB는 기본 비활성화(활성화 시 비용 발생)

13. 정리

ALB는 L7에서 HTTP 요청 내용을 파싱하여 세밀한 라우팅을 제공합니다. 웹 애플리케이션, REST API, 마이크로서비스 환경에서 기본 선택입니다.
NLB는 L4에서 패킷을 그대로 전달하여 초저지연과 높은 처리량을 제공합니다. 비HTTP 프로토콜, 고정 IP, PrivateLink가 필요한 경우에 선택합니다.
대부분의 웹 서비스는 ALB로 충분합니다. NLB를 선택해야 하는 명확한 이유(고정 IP, UDP, 초저지연, PrivateLink)가 없다면 ALB를 기본으로 사용하는 것이 운영 편의성 측면에서 유리합니다.
고정 IP와 L7 라우팅이 모두 필요한 경우 NLB + ALB 조합을 사용할 수 있지만, 비용과 복잡도 증가를 감수해야 합니다.
NLB의 Cross-Zone Load Balancing은 기본 비활성화이므로, AZ별 타겟 수를 균등하게 유지하거나 명시적으로 활성화해야 합니다.

참고 문서

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

AWS ECS vs EKS 차이: 컨테이너 오케스트레이션 선택 기준 (0)	2026.06.06
AWS S3 기본 개념: 버킷 정책, 버전 관리, 수명 주기 설계 (0)	2026.06.05
AWS 3-Tier 아키텍처 설계 예시: Web, App, DB 계층 분리와 운영 전략 (0)	2026.06.01
Security Group과 NACL 차이: Stateful vs Stateless, 적용 범위, 운영 전략 (0)	2026.05.31
Public Subnet과 Private Subnet 차이: Route Table, 보안, 비용 기준으로 정리 (0)	2026.05.29

wero90

태그

최근글

댓글

공지사항

아카이브

요약