NLB와 ALB의 차이

한 줄 답변#

NLB는 L4(TCP/UDP), ALB는 L7(HTTP/HTTPS) 로드밸런서입니다. NLB는 패킷을 그대로 전달하고, ALB는 HTTP 요청을 해석해서 라우팅합니다.

동작 계층#

NLB (L4):
  클라이언트 → [NLB: TCP 패킷 전달] → 서버
  - 패킷 내용을 보지 않음
  - IP + Port로만 분기

ALB (L7):
  클라이언트 → [ALB: HTTP 요청 해석] → 서버
  - Host 헤더, URL 경로, HTTP 메서드 확인
  - 요청 내용 기반으로 라우팅 결정

핵심 차이#

항목	NLB	ALB
OSI 계층	L4 (TCP/UDP)	L7 (HTTP/HTTPS)
라우팅 기준	IP + Port	Host, Path, Header, Method
지연	~100us (극저지연)	~1ms
고정 IP	제공 (AZ당 1개)	미제공 (DNS 기반)
처리량	초당 수백만 요청	초당 수만 요청
프로토콜	TCP, UDP, TLS	HTTP, HTTPS, gRPC, WebSocket

라우팅 기능#

NLB:
  - 포트 기반 분기만 가능
  - :443 → 타겟 그룹 A
  - :8080 → 타겟 그룹 B

ALB:
  - api.example.com/users → User 서비스
  - api.example.com/orders → Order 서비스
  - admin.example.com/* → Admin 서비스
  - Header X-Version: v2 → V2 서비스

ALB는 하나의 로드밸런서로 여러 서비스를 Host/Path 기반으로 분기할 수 있다. NLB는 포트를 나누거나 별도 NLB를 만들어야 한다.

성능#

NLB가 압도적으로 빠르다:

항목	NLB	ALB
지연	~100us	~1ms (10배 차이)
워밍업	불필요	트래픽 급증 시 필요할 수 있음
초당 연결	수백만	수만

NLB는 패킷을 해석하지 않고 전달만 하기 때문이다. ALB는 HTTP 파싱, 헤더 검사, 라우팅 규칙 평가를 하므로 오버헤드가 있다.

고정 IP#

NLB:
  AZ-a: 52.78.xxx.xxx (고정)
  AZ-c: 13.125.xxx.xxx (고정)
  → IP allowlist에 유리

ALB:
  k8s-staging-xxxx.ap-northeast-2.elb.amazonaws.com
  → IP가 변동됨 (DNS 기반)
  → IP allowlist 불가, 도메인으로 연동해야 함

파트너사가 “우리 방화벽에 IP를 등록해야 합니다” 하면 NLB여야 한다.

Security Group — ALB를 선택한 결정적 이유#

CloudFront → LB 구조에서 직접 접근을 막아야 한다#

CloudFront를 앞에 놓는 이유는 DDoS 방어 + WAF인데, 공격자가 ALB 주소를 알아내서 CloudFront를 우회하면 의미가 없다. 실제로 침투테스트에서 이걸 당했다(H-10).

정상 흐름: 사용자 → CloudFront (WAF 검사) → ALB → Pod     ✅
우회 공격: 공격자 → ALB 직접 접근 (WAF 우회)  → Pod     ❌ 막아야 함

이걸 막으려면 ALB가 CloudFront에서 오는 요청만 받도록 해야 한다.

ALB: Security Group + Prefix List로 해결#

CloudFront는 전 세계 Edge 서버에서 요청을 받아서 Origin(ALB)으로 전달한다. 이 Edge 서버들의 IP 주소를 AWS가 pl-22a6434b라는 Managed Prefix List로 관리한다 (약 45개 IP 대역, 자동 업데이트).

ALB Security Group:
  인바운드 규칙:
    443 ← pl-22a6434b          (CloudFront Edge IP 약 45개)
    443 ← 39.119.192.15/32     (팀원 A)
    443 ← 124.49.102.36/32     (팀원 B)
    443 ← 122.34.166.131/32    (팀원 C)

결과:
  CloudFront Edge에서 오는 요청    → 허용 ✅
  팀원 IP에서 직접 접근             → 허용 ✅
  공격자가 ALB 주소로 직접 접근     → 차단 ❌ (SG에 없는 IP)

ALB는 Security Group을 완전 지원하기 때문에 Prefix List를 바로 적용할 수 있다.

NLB: Security Group 적용이 제한적#

NLB는 원래 Security Group을 아예 지원하지 않았다. 2023년에 추가되긴 했지만 제약이 있다:

조건	NLB SG 지원
타겟 유형: IP	지원
타겟 유형: Instance	미지원
타겟 유형: ALB	미지원
기존 NLB에 SG 추가	불가 (생성 시에만)

EKS 환경에서 AWS Load Balancer Controller가 NLB를 생성할 때 타겟 유형이 Instance인 경우가 많아서, SG를 붙일 수 없는 상황이 발생한다.

NLB (Instance 타겟):
  SG 적용 불가
  → CloudFront Prefix List를 붙일 수 없음
  → 누구나 NLB에 직접 접근 가능
  → CloudFront + WAF 보안 체인이 무력화됨

비교 정리#

항목	NLB	ALB
SG 지원	2023년 추가, 타겟 유형 제약	완전 지원
Prefix List 적용	조건부 (IP 타겟만)	바로 적용
CloudFront 직접 접근 차단	어렵거나 불가능	`pl-22a6434b` 한 줄로 해결
결과	보안 체인에 구멍	보안 체인 완성

이 차이가 NLB 대신 ALB를 선택한 결정적 이유다. NLB의 성능(~100us)이 아무리 좋아도, CloudFront → WAF → SG 보안 체인을 구성할 수 없으면 티켓팅 플랫폼에서는 쓸 수 없었다.

AWS 서비스 연동#

서비스	NLB	ALB
CloudFront Origin	제약 있음	바로 연결
AWS WAF	X (L4라 HTTP 해석 불가)	O
ACM 인증서	수동 관리	자동 연동
Cognito 인증	X	O

보안 체인(CloudFront → WAF → LB → 백엔드)을 구성하려면 ALB가 필수다.

비용 (ap-northeast-2)#

항목	NLB	ALB
시간당 고정	$0.0225	$0.0225
처리 단위	NLCU $0.006	LCU $0.008
Public IP	고정 IP 포함	자동 할당 $0.005/h/IP
월 예상 (2AZ)	~$16	~$23 (IP 포함)

ALB가 약간 비싸지만 큰 차이는 아니다.

언제 뭘 쓰나#

NLB를 써야 하는 경우#

고정 IP가 필수 (파트너 allowlist)
TCP/UDP 직접 처리 (DB, 메시징, 게임 서버)
극저지연이 중요 (실시간 트레이딩)
PrivateLink로 서비스 노출
초대량 동시 연결 처리

ALB를 써야 하는 경우#

Host/Path 기반 라우팅 (MSA 여러 서비스)
CloudFront + WAF 보안 체인
HTTP 리다이렉트/고정 응답
gRPC 라우팅 (Istio 앞단)
Cognito 인증 연동

실무 경험#

PlayBall 프로젝트에서 처음에 NLB를 고려했다. 티켓 오픈 시점의 대량 트래픽에 NLB의 L4 성능이 유리하다고 판단했기 때문이다.

하지만 CloudFront를 앞단에 놓으면서 NLB → ALB로 전환했다:

CloudFront origin 연동: ALB는 DNS로 바로 연결, NLB는 제약
Security Group: ALB SG에 CloudFront Prefix List 적용하여 직접 접근 차단
AWS WAF 연동: ALB에만 WAF 직접 연결 가능
Host 기반 라우팅: 여러 서비스(API, Grafana, ArgoCD)를 하나의 ALB에서 분기

ALB의 ~1ms 지연은 CloudFront 캐싱과 Istio 내부 라우팅이 있기 때문에 체감 차이가 없었다.