🔥 Load Balancer: ALB·NLB·GWLB의 역할

콘솔의 Load Balancers > Create 화면에는 ALB·NLB·GWLB 세 카드가 한 줄로 나란히 떠 있다. 이름은 셋 다 "Load Balancer"로 끝나는데, 같은 한 GB 트래픽을 통과시켰을 때 청구서에 올라오는 줄도 다르고 애초에 받을 수 있는 트래픽 자체가 다르다. 콘솔의 카드 세 개를 그냥 "LB의 세 종류"로 묶어 두면, L7 라우팅이 필요 없는 단순 TCP echo 한 대 앞에 ALB를 붙여 LCU 청구가 부풀어 오르거나, 반대로 호스트별 path-based 라우팅이 필요한 백엔드 앞에 NLB를 골라 두고 한 시간을 헤매다가 다시 만드는 일이 생긴다.

세 카드는 OSI 모델의 다른 계층에서 일한다. ALB는 7층에서 HTTP 요청 라인부터 host 헤더, URL 경로까지 보고 라우팅한다. NLB는 4층에서 TCP·UDP·TLS 헤더까지만 보고 패킷을 그대로 흘려 보낸다. GWLB는 3층에서 모든 IP 패킷을 GENEVE라는 캡슐에 감아 third-party 보안 어플라이언스로 보내고 다시 받아 원래 목적지로 보낸다. 한 줄로 묶는 카테고리이지만 실제로는 세 가지 다른 도구다.

여기서는 셋이 각각 무엇을 받는지, 셋을 가르는 다섯 가지 결정 손잡이가 무엇인지, 서울 리전 기준 청구는 어떻게 만들어지는지, 그리고 어느 곳에서는 LB 자체가 답이 아닌지를 짚는다. ALB·NLB·GWLB 세 카드의 차이를 한 번 정리해 두면 콘솔 Create 화면에서 망설일 일이 줄어들고, 한 달 청구서의 ELB 줄이 어디서 자랐는지를 짐작할 수 있다.

ALB는 무엇을 받는가: HTTP 요청 라인부터 path까지

ALB(Application Load Balancer)는 7층에서 일한다. 클라이언트가 보낸 HTTP 요청을 받아 Host: api.example.com 헤더, GET /v2/users/42 같은 요청 라인, 쿼리 스트링과 쿠키까지 보고, 그 내용으로 어느 target group에 보낼지를 결정한다. 콘솔에서 차근차근 짚으면 한 ALB 안에 Listener가 있고, Listener 위에 Rule이 줄지어 있고, 각 Rule이 하나의 Target Group을 가리키는 구조다.

라우팅 규칙으로 쓸 수 있는 조건은 6가지다. host header, path pattern, HTTP header, HTTP request method, query string, source IP. 예를 들어 Host: api.example.com + Path: /v2/* → users-service-tg, 같은 ALB 위에서 Host: static.example.com → cloudfront-fallback-tg 같은 분기를 한 LB 안에서 처리한다. 백엔드를 하나의 도메인 뒤에서 마이크로서비스로 쪼개고 싶을 때 ALB가 첫 답이 되는 이유다.

Target type은 4가지다. instance(EC2 인스턴스 ID), ip(IP 주소, on-prem이나 컨테이너 IP), lambda(Lambda 함수 직접 호출), 그리고 alb 타입은 NLB target group에서만 쓰는 별도 형식이다. ALB target group의 health check 기본 성공 코드는 200이고, 200~399 범위로도 넓힐 수 있다. 이 부분은 ASG 편에서 ELB Health Check를 통해 ASG가 자동 교체 신호를 받는 흐름에서 한 번 본 그 health check다.

ALB만 받을 수 있는 트래픽이 몇 가지 더 있다. WebSocket(ws/wss), gRPC(HTTP/2 위), HTTP/2 자체, 그리고 내장 OIDC 인증(Cognito·Okta·Auth0 같은 IdP를 ALB가 직접 처리해 백엔드는 X-Amzn-Oidc-Data 헤더만 받는 패턴). AWS WAF도 ALB에만 직접 붙는다. 2024년 2월 6일 출시된 one-click integration으로 콘솔 한 번 클릭에 WebACL을 ALB에 연결할 수 있다. NLB나 GWLB 앞에 WAF를 두려면 CloudFront를 먼저 세워야 한다는 게 그래서다.

ALB가 과한 경우도 있다. 한 대 EC2 앞에 ALB를 두고 도메인만 붙이는 경우다. ALB 시간당 단가는 작아 보여도 한 달이면 16달러 가까이 자라고, 트래픽이 늘면 LCU가 그 위에 추가로 늘어난다. 단순 도메인 → 단일 인스턴스 매핑은 Route 53 alias 레코드로 끝나는 경우가 많고, ALB의 path-based routing이 정말로 필요해지는 시점에서야 띄우는 게 청구서에 정직하다.

NLB는 무엇을 받는가: TCP/UDP 패킷의 헤더만

NLB(Network Load Balancer)는 4층에서 일한다. 클라이언트가 보낸 TCP·UDP·TLS 패킷의 4-tuple(source IP, source port, dest IP, dest port)을 보고 어느 target에 보낼지를 결정한다. 7층 헤더는 들여다보지 않는다. payload는 그대로 흘려 보낸다. 그래서 millions of requests per second 급의 흐름을 ultra-low latency로 받을 수 있다 (NLB 공식 페이지).

NLB의 가장 큰 시그니처는 두 가지다. static IP per AZ와 source IP 보존이다. 각 AZ마다 NLB가 하나의 고정 IP를 갖고(원하면 Elastic IP를 직접 부착할 수도 있고), 외부 시스템이 IP allow-list로 NLB를 등록할 수 있다. ALB는 IP가 자주 바뀌어 hostname으로만 안전하게 가리킬 수 있는 것과 대비를 이룬다. 그리고 NLB는 TCP 흐름의 source IP를 그대로 백엔드에 전달한다. 백엔드 앱에서 클라이언트의 진짜 IP를 보고 싶을 때 ALB는 X-Forwarded-For 헤더를 봐야 하지만, NLB는 그냥 OS의 socket이 그 IP로 받는다.

받을 수 있는 트래픽은 ALB보다 훨씬 넓다. TCP, UDP, TCP_UDP(같은 포트), TLS. TLS termination도 NLB에서 가능하고, 인증서는 AWS Certificate Manager에서만 가져올 수 있다(NLB는 외부 업로드 인증서를 받지 못한다). 게임 서버처럼 UDP가 필요한 워크로드, MQTT/IoT 트래픽, 금융권의 직접 TCP 프로토콜 같은 곳은 ALB가 받지 못하므로 NLB가 거의 default다.

NLB가 한참 늦게 받은 기능 두 가지가 운영에서 자주 발목을 잡는다. 하나는 security group 부착으로 2023년 8월 10일에 출시했다 (AWS What's New 2023-08). 그 전까지는 NLB 자체에 SG가 없어서 인바운드 필터링은 target 인스턴스의 SG에 의존해야 했다. 그리고 NLB는 생성 시점에만 SG를 붙일 수 있다. 한 번 SG 없이 만든 NLB에는 나중에 부착할 수 없으니, NLB를 새로 띄울 때 SG를 같이 명시하는 습관이 필요하다.

다른 하나는 cross-zone load balancing 기본값이다. ALB는 cross-zone이 항상 켜져 있고 끄지도 못한다(인터-AZ 데이터 전송 비용도 ALB가 떠안는다). NLB는 기본 꺼짐 상태다. 한 AZ의 NLB 노드는 같은 AZ의 target에만 분산한다. 이걸 켜면 트래픽이 AZ를 넘기 시작하고, 인터-AZ 데이터 전송 비용(서울 기준 GB당 약 $0.01)을 별도로 부과한다. 한쪽 AZ에 target이 몰려 있을 때 cross-zone을 켜는 게 답이지만, 그 결정 한 줄이 청구서에 별도 줄로 올라온다.

NLB target group은 ALB와 같은 instance/ip target type을 받지만 한 가지 더 있다. alb target type이다. AWS가 2021년 9월에 출시한 기능으로, NLB target group에 ALB를 직접 등록할 수 있다 (AWS networking blog 2021). AWS PrivateLink는 NLB만 endpoint service의 backend로 받는데, L7 라우팅도 같이 쓰고 싶다면 NLB → ALB → 앱 두 단을 거는 패턴이 그래서 자연스럽다. 한 ALB는 최대 두 NLB의 target이 될 수 있고, TLS listener는 ALB-type target에 forward할 수 없다는 제약이 따라온다.

GWLB는 무엇을 받는가: 모든 IP 패킷이 GENEVE 안에

GWLB(Gateway Load Balancer)는 가장 낯선 카드다. 4 계층보다 더 아래에서 일한다. 3 계층에서 모든 IP 패킷을 받는다. 포트도 안 본다. 그냥 라우팅 테이블이 GWLB 엔드포인트를 next hop으로 가리키면 그 경로로 지나가는 모든 IP 패킷이 GWLB로 들어간다.

GWLB가 받은 패킷은 그대로 target에 보내지 않는다. GENEVE라는 캡슐화 프로토콜로 한 번 감싸서 UDP 6081 포트로 third-party 보안 어플라이언스에 보낸다 (GWLB 공식 docs). 어플라이언스는 패킷을 검사·조작·차단한 뒤 다시 GENEVE로 감아 GWLB에 돌려준다. GWLB는 캡슐을 벗기고 원래 목적지로 흘려 보낸다. 클라이언트도 백엔드 앱도 어플라이언스가 중간에 있다는 걸 모른다. 이런 구성을 bump-in-the-wire 패턴이라고 부른다.

쓰임새는 좁다. third-party 어플라이언스가 있어야 의미가 있다. Palo Alto VM-Series, Fortinet FortiGate, Check Point CloudGuard 같은 가상 방화벽·IPS·DPI 제품을 AWS에서 high-availability로 운용하고 싶을 때 등장한다. AWS-native 도구로 충분하면 GWLB 대신 AWS Network Firewall이 매니지드 답이다. 둘의 역할 구분은 section02 VPC 설계 패턴에서 한 번 정리했다.

운영에서 자주 걸리는 GWLB 함정은 security group이 GENEVE 캡슐화 패킷을 받을 수 있어야 한다는 점이다. data VPC에서 inbound UDP 6081을 GWLB의 ENI에서 허용하지 않으면, 모든 검사 트래픽이 조용히 멈춘다. 그리고 GWLB는 target group이 GENEVE 프로토콜에 6081 포트로만 등록되도록 강제한다. 일반 HTTP/TCP target group과 섞을 수 없다.

GWLB도 cross-zone이 기본 꺼짐이다. 어플라이언스가 한 AZ에만 있고 트래픽이 다른 AZ에서 들어오는 비대칭 상황이면 cross-zone을 켜야 하는데, 인터-AZ 트래픽 비용이 검사 트래픽 양만큼 그대로 곱해서 붙는다는 게 청구서에서 가장 빠르게 자라는 대목이다. 보안 검사 트래픽은 보통 production traffic의 100%를 통과하므로 cross-zone 한 줄의 결정이 데이터 전송 청구서의 한 줄을 좌우한다.

셋을 구분하는 다섯 가지 결정 손잡이

세 LB를 한 표로 옆에 놓고 보면 다섯 가지가 다르다.

손잡이	ALB	NLB	GWLB
OSI 층	7층 (HTTP)	4층 (TCP/UDP/TLS)	3층 (모든 IP)
라우팅 단위	host/path/header/method/query/source IP	4-tuple	라우팅 테이블 next hop
Cross-zone 기본값	always-on (끌 수 없음)	off	off
청구 모델 (Seoul)	$0.0225/hr + $0.008/LCU-hr	$0.0225/hr + $0.006/NLCU-hr	$0.0125/hr per AZ + $0.004/GLCU-hr
WAF 직접 부착	가능	불가 (CloudFront 우회)	불가

이 표 위에서 결정 한 줄이 거의 자동이다. 질문은 L7 라우팅이 필요한가다. 답이 "그렇다"이면 ALB가 거의 default. 답이 "아니다, 그냥 TCP/UDP 흐름을 분배하고 source IP를 보존하고 싶다"이면 NLB. 답이 "third-party 보안 어플라이언스 체인이 필요하다"이면 GWLB.

여기에 따라오는 두 번째 질문이 cross-zone을 켤 것인가다. ALB는 자동으로 켜진 채 인터-AZ 비용도 떠안으니 결정할 게 없다. NLB와 GWLB는 한 AZ에 target이 몰려 있을 때 켜야 하는데, 켜는 순간 GB당 $0.01 정도의 인터-AZ 데이터 전송이 따라온다. 한 달 1 TB 검사 트래픽이 cross-zone으로 AZ를 넘으면 그것만 약 $10이 별도 줄로 붙는다. 작아 보여도 트래픽이 두 자릿수 TB 단위면 무시할 액수가 아니다.

청구 모델: 시간당 + 용량 단위 한 시간 사례

LB 시간당 단가는 셋 다 작은 편이다. 하지만 청구서에서 LB 줄이 자라는 진짜 이유는 용량 단위 차원에 있다. ALB는 LCU, NLB는 NLCU, GWLB는 GLCU. 셋 다 해당 시간 가장 높았던 한 차원만 청구하지만, 어느 차원이 1 단위에 닿는 임계값이 다르다.

ALB의 LCU는 AWS가 4가지 차원으로 측정한다 (Elastic Load Balancing pricing).

• new connections per second: 25개 연결/초 = 1 LCU
• active connections per minute: 3,000개 연결/분 = 1 LCU
• processed bytes: HTTP는 시간당 2.22 GB = 1 LCU, HTTPS는 시간당 1 GB = 1 LCU
• rule evaluations per second: 처음 10개 규칙은 무료, 그 다음부터 1,000개 평가/초 = 1 LCU

한 시간 사례를 짚어 보자. 한 시간 동안 평균 초당 50개의 새 HTTPS 연결, 분당 6,000개의 활성 연결, 시간당 5 GB 처리, 규칙 8개(무료 한도 안)였다고 하자. new connections는 50/25 = 2 LCU, active connections는 6,000/3,000 = 2 LCU, processed bytes는 5/1 = 5 LCU, rule eval은 0이다. 한 시간 청구는 최대값인 5 LCU만이다. 5 × $0.008 = $0.04. 여기에 ALB hourly $0.0225를 더하면 한 시간 약 $0.0625. 한 달 720시간으로 곱하면 약 $45다.

NLB의 NLCU는 3차원이다. new flows/sec, active flows(분당 샘플링), processed bytes. 단가가 $0.006/NLCU-hr로 ALB보다 25% 싸고, 7층 처리 비용이 없으니 같은 트래픽 양에서 NLCU 자체도 ALB의 LCU보다 작은 값으로 측정한다. L7 라우팅이 필요 없는 곳에서 NLB가 거의 항상 더 싸다는 결론이 청구 모델에서 자연스럽게 나온다.

GWLB의 GLCU도 3차원이다. 각 GLCU가 초당 600개의 새 연결, 분당 60,000개의 활성 연결, 시간당 1 GB까지 처리한다. 시간당 단가가 AZ당 $0.0125로 따로 곱해지는 게 GWLB의 한 가지 함정이다. 3개 AZ에 GWLB endpoint를 두면 시간당 $0.0125 × 3 = $0.0375만 hourly로 자동 청구한다. 검사 트래픽이 100%를 통과하는 보안 흐름의 특성상 GLCU는 그 위에 빠르게 늘어난다.

"관리형이라는 말이 감추는 비용"이 LB에서 나타나는 곳은 cross-zone 켰을 때의 데이터 전송과 LCU 4차원의 최대값 청구 두 곳이다. 시간당 단가에 720을 곱한 숫자는 작지만, 실제 청구서에서 LB 줄이 부풀어 오르는 이유는 위 두 줄에서 자란다. 한 달 청구서를 처음 받았을 때 LB가 예상보다 비싸다면 거의 매번 LCU·NLCU·GLCU 줄이 따로 있고, 그 옆에 EC2-Other의 inter-AZ data transfer 줄이 같이 자라 있다.

언제 LB가 아닌 다른 걸 써야 하는가

LB 카드 셋이 받지 못하는 영역도 있다. L7 라우팅이 필요한가를 한 번 던지기 전에, 애초에 LB가 답인가를 한 번 더 묻는다.

도메인 → 단일 인스턴스 한 대. ALB를 띄우고 한 대를 target group에 등록하는 흔한 구성인데, Route 53의 A record 또는 alias 레코드 한 줄로 끝나는 곳이다. ALB hourly 만으로 한 달 약 $16, LCU까지 더하면 더 자라는데, 분기·헬스체크 없는 단일 인스턴스라면 Route 53 health check + DNS failover가 더 가볍다.

글로벌 트래픽 분산. ALB·NLB·GWLB는 모두 region 단위 도구다. 한국 사용자는 Seoul ALB로, 미국 사용자는 us-east-1 ALB로 보내고 싶다면 LB 두 개 + Route 53의 latency-based routing 또는 geolocation routing이 윗단에 있어야 한다. 이 영역은 LB가 아니라 Route 53이 답이다.

정적 자산 / edge cache. CloudFront가 자체로 origin failover, edge에서의 캐싱, edge에서의 Lambda@Edge 처리까지 한다. 정적 사이트나 이미지·비디오 위주의 트래픽은 CloudFront → S3가 ALB보다 훨씬 싸고 빠르다. ALB는 동적 backend 앞단에서만 의미가 있다.

API + Lambda 조합. ALB도 Lambda target을 받지만, API Gateway는 throttling, API key 관리, custom authorizer, request/response transformation, OpenAPI/Swagger 통합까지 묶어 준다. 단순한 API + Lambda면 ALB보다 API Gateway가 운영 손잡이가 적다.

third-party 어플라이언스 없는 inspection. GWLB는 third-party 어플라이언스가 있어야 의미가 있다. AWS-native 방화벽으로 충분하면 AWS Network Firewall이 더 가볍고, 추가 어플라이언스 라이선스 비용도 안 든다.

LB 카드 셋이 모든 트래픽 분산의 답은 아니다. region 안 / 동적 backend / L4·L7 트래픽 세 조건을 만족할 때만 LB가 default고, 한 조건이 빠지면 윗단의 다른 도구가 더 자연스럽다.

결정은 'L7 라우팅이 필요한가' 한 줄에서

ALB·NLB·GWLB는 같은 콘솔 카테고리에 있지만 셋이 받는 트래픽 자체가 다르다. ALB는 7층의 HTTP 요청 라인부터 host·path까지 보고 라우팅하는 도구, NLB는 4층의 TCP/UDP/TLS 흐름을 source IP 보존한 채로 분배하는 도구, GWLB는 3층의 모든 IP 패킷을 GENEVE에 감아 third-party 어플라이언스에 흘려 보내는 도구다. 한 카드의 역할에 다른 카드를 두면 청구서가 새거나 되어야 할 일이 안 된다.

운영에서 LB를 새로 띄우기 전에 한 줄을 자문한다. L7 라우팅이 필요한가. 답이 "그렇다"면 ALB. 답이 "아니다"인데 PrivateLink endpoint service 호환·source IP 보존·static IP 중 하나라도 필요하면 NLB. 답이 "third-party 보안 어플라이언스 체인이 필요하다"면 GWLB. 그리고 한 번 더 자문한다. region 안 / 동적 backend / L4·L7 세 조건이 다 만족하는가. 한 조건이 빠지면 LB가 아니라 Route 53·CloudFront·API Gateway 윗단의 도구가 답이다.

다음 단계로 언제 EC2가 아닌 다른 걸 써야 하는가로 넘어간다. EC2 위에 LB를 띄우는 패턴 자체를 한 단계 위에서 다시 보는 단원이다. Lambda·Fargate·App Runner가 LB까지 같이 자동으로 묶어 주는 흐름과 EC2+ASG+ALB의 직접 조립 흐름의 차이를 본다.

참고 자료

• Elastic Load Balancing User Guide overview: ALB·NLB·GWLB·CLB 4종 비교 공식 문서
• Application Load Balancer Listeners and rules: Listener·Rule 6 가지 조건과 ALB 라우팅 모델
• Network Load Balancer (What is a Network Load Balancer?): NLB 4 계층 동작과 source IP 보존
• Network Load Balancer now supports security groups (2023-08-10): NLB SG 출시 공지
• Application Load Balancer-type target group for NLB: NLB → ALB 체이닝 출시 (2021-09)
• Gateway Load Balancers User Guide: GWLB 동작과 GENEVE/UDP 6081
• AWS WAF One-Click Integration with ALB (2024-02-06): WAF + ALB 직접 연결 출시
• Application Load Balancer Health Check Logs (2025-11): ALB target health check 로그를 S3로 출시
• Elastic Load Balancing pricing: LCU·NLCU·GLCU 차원 정의, 시간당 단가 (리전 selector로 Seoul 선택)