AWS 로드 밸런서 ALB NLB GWLB 차이와 용도별 선택 기준 정리

서버 한 대로 시작한 서비스도 사용자가 늘면 두 대, 세 대로 늘어나고, 그 순간부터 요청을 어느 서버로 보낼지 정해 줄 장치가 필요해집니다. AWS에서 이 역할을 하는 것이 Elastic Load Balancing(ELB)입니다. 그런데 로드 밸런서를 만들려고 하면 Application Load Balancer, Network Load Balancer, Gateway Load Balancer 중에서 먼저 종류를 골라야 합니다.

 

세 종류는 이름이 비슷하지만 동작하는 계층과 트래픽을 나누는 기준이 다릅니다. 종류를 잘못 고르면 경로별 라우팅이 필요한데 설정할 수 없거나, 고정 IP가 필요한데 받을 수 없는 문제가 생깁니다. 로드 밸런서는 만든 뒤에 종류를 바꿀 수 없어서 처음 선택이 중요합니다.

 

이 글에서는 로드 밸런서의 기본 구성 요소, 세 종류의 차이와 대표 사용 사례, 교차 영역 로드 밸런싱이 트래픽 분배에 미치는 영향, 그리고 요금 구조까지 정리합니다.

 

결론부터 말씀드리면 HTTP와 HTTPS 기반 웹 서비스는 요청 내용을 보고 나눌 수 있는 ALB, TCP·UDP 트래픽이나 고정 IP가 필요한 경우는 NLB, 방화벽 같은 네트워크 보안 장비를 트래픽 경로에 끼워 넣을 때는 GWLB를 선택합니다. Classic Load Balancer는 이전 세대 제품이라 새로 만드는 서비스에서는 고려하지 않아도 됩니다.

 

 

로드 밸런서는 리스너, 대상 그룹, 상태 검사로 동작합니다

리스너는 로드 밸런서가 어떤 프로토콜과 포트로 연결을 받을지 정하는 설정입니다. 예를 들어 HTTPS 443 리스너를 만들면 443 포트로 들어오는 요청을 받습니다. 대상 그룹은 요청을 전달받을 서버 목록이고, EC2 인스턴스, IP 주소 등을 등록합니다.

 

로드 밸런서는 등록된 대상에 주기적으로 상태 검사 요청을 보내 정상인 대상에게만 트래픽을 보냅니다. 비정상으로 판단된 대상은 트래픽에서 빠지고, 다시 정상이 되면 자동으로 복귀합니다. 서버 한 대가 멈춰도 서비스 전체가 멈추지 않는 이유가 여기에 있습니다.

 

로드 밸런서를 만들 때는 사용할 가용 영역을 고르며, 선택한 가용 영역마다 로드 밸런서 노드가 만들어집니다. ALB는 최소 두 개 이상의 가용 영역을 선택해야 합니다. 인터넷에서 접근하는 인터넷 경계형과 VPC 내부에서만 쓰는 내부용 중 하나를 고르는데, 어느 쪽이든 대상 서버에는 사설 IP로 요청을 전달하므로 대상 서버에 공인 IP가 없어도 됩니다.

 

리스너가 요청을 받고, 상태 검사를 통과한 대상 그룹의 서버로만 전달하며, 대상 서버는 프라이빗 서브넷에 두어도 동작합니다.

 

ALB, NLB, GWLB 한눈에 비교

세 로드 밸런서의 차이는 네트워크 계층 모델로 보면 가장 쉽게 이해됩니다. ALB는 7계층인 애플리케이션 계층에서 HTTP 요청의 내용까지 읽고, NLB는 4계층인 전송 계층에서 연결 단위로 트래픽을 넘기며, GWLB는 3계층인 네트워크 계층에서 IP 패킷을 보안 장비로 보냅니다.

 

 

구분	ALB	NLB	GWLB
동작 계층	7계층(애플리케이션)	4계층(전송)	3계층(네트워크)
주요 프로토콜	HTTP, HTTPS, gRPC, WebSocket	TCP, UDP, TLS	IP 패킷(GENEVE 6081 포트)
분배 기준	리스너 규칙(경로, 호스트, 헤더) 후 기본 라운드 로빈	프로토콜과 출발지·목적지 정보 기반 흐름 해시	5-튜플 흐름 해시
고정 IP	없음(DNS 이름으로 접속)	가용 영역별 고정 IP, 탄력적 IP 연결 가능	해당 없음
교차 영역 분배 기본값	항상 켜짐(대상 그룹에서 끌 수 있음)	꺼짐	꺼짐
대표 용도	웹 서비스, API, 마이크로서비스	게임 서버, IoT, 고정 IP가 필요한 연동	방화벽, 침입 탐지 장비 연결

 

요청의 내용을 보고 나눠야 하면 ALB, 연결 자체를 빠르게 넘기거나 고정 IP가 필요하면 NLB, 보안 장비를 경로에 넣어야 하면 GWLB입니다.

 

ALB는 요청 내용을 보고 나눕니다

ALB의 가장 큰 장점은 리스너 규칙입니다. 규칙은 우선순위 순서로 평가되며, 요청 경로가 /api로 시작하면 API 서버 그룹으로, 호스트 이름이 admin으로 시작하면 관리자 서버 그룹으로 보내는 식의 분기가 가능합니다. 로드 밸런서 하나로 여러 서비스를 나눠 처리할 수 있어 비용과 관리 부담이 줄어듭니다.

 

HTTPS 처리도 로드 밸런서에서 맡길 수 있습니다. AWS Certificate Manager에서 발급한 인증서를 리스너에 연결하면 암호화 해제를 로드 밸런서가 처리하고, HTTP로 들어온 요청을 HTTPS로 넘기는 리디렉션 규칙도 설정만으로 만들 수 있습니다. HTTP/2는 HTTPS 리스너에서만 사용할 수 있습니다.

 

ALB를 거치면 서버에 찍히는 접속 IP가 로드 밸런서 노드의 IP로 바뀝니다. 실제 사용자 IP는 ALB가 자동으로 추가하는 X-Forwarded-For 헤더에 담기므로, 웹 서버 로그 설정에서 이 헤더를 기록하도록 바꿔야 합니다.

 

ALB는 경로·호스트 기반 규칙, HTTPS 처리, 리디렉션을 제공하며, 실제 사용자 IP는 X-Forwarded-For 헤더로 확인합니다.

 

NLB는 연결 단위로 빠르게 넘깁니다

NLB는 요청 내용을 해석하지 않고 연결 단위로 대상을 고릅니다. 프로토콜, 출발지와 목적지의 IP·포트 같은 정보로 흐름 해시를 계산해 대상을 정하고, 하나의 TCP 연결은 끝날 때까지 같은 대상으로 전달됩니다. HTTP가 아닌 프로토콜을 쓰는 게임 서버나 IoT 장비 연동에 잘 맞습니다.

 

NLB의 또 다른 특징은 고정 IP입니다. 활성화한 가용 영역마다 네트워크 인터페이스가 만들어지고 고정 IP가 할당되며, 원하면 탄력적 IP를 연결할 수도 있습니다. 거래처 방화벽에 접속 IP를 미리 등록해야 하는 경우처럼 IP가 바뀌면 안 되는 연동에서 NLB가 선택되는 이유입니다.

 

고정 IP와 ALB의 경로 기반 라우팅이 둘 다 필요하다면 NLB의 대상으로 ALB를 등록하는 구성을 쓸 수 있습니다. 외부에는 NLB의 고정 IP를 알려 주고, 안쪽에서는 ALB가 요청 내용을 보고 나누는 방식입니다.

 

NLB는 연결 단위 흐름 해시로 대상을 정하고 가용 영역별 고정 IP를 제공하므로, 비 HTTP 트래픽과 IP 허용 목록이 필요한 연동에 적합합니다.

 

GWLB는 보안 장비를 트래픽 경로에 끼워 넣습니다

GWLB는 웹 서버가 아니라 방화벽, 침입 탐지·방지 시스템 같은 가상 보안 장비 앞에 두는 로드 밸런서입니다. 들어오고 나가는 트래픽을 보안 장비로 보내 검사하게 하고, 검사를 통과한 트래픽을 원래 목적지로 돌려보냅니다. 로드 밸런서와 장비는 GENEVE 프로토콜로 6081 포트를 통해 트래픽을 주고받습니다.

 

하나의 흐름에 속한 패킷은 5-튜플 흐름 해시에 따라 항상 같은 장비로 전달됩니다. 그래서 장비가 연결 상태를 추적하며 검사할 수 있고, 장비를 여러 대로 늘려도 흐름이 섞이지 않습니다. 일반적인 웹 서비스 운영에서는 직접 만들 일이 드물지만, 보안 장비 제품을 도입할 때 자주 등장하는 구성입니다.

 

GWLB는 가상 보안 장비를 확장 가능하게 연결하기 위한 로드 밸런서이며, 일반 웹 트래픽 분산 용도로는 쓰지 않습니다.

 

교차 영역 로드 밸런싱과 요금 구조

교차 영역 로드 밸런싱은 각 로드 밸런서 노드가 다른 가용 영역의 대상에게도 트래픽을 보낼지 정하는 설정입니다. AWS 문서의 예시로 차이를 계산해 보면 이해가 쉽습니다. 가용 영역 A에 대상 2대, B에 대상 8대가 있고 두 노드가 트래픽을 절반씩 받는 상황입니다.

 

설정	A 영역 대상 1대당	B 영역 대상 1대당
교차 영역 켜짐	10%	10%
교차 영역 꺼짐	25%(50% ÷ 2대)	6.25%(50% ÷ 8대)

 

교차 영역을 끄면 대상 수가 적은 영역의 서버가 네 배 가까운 부하를 받게 됩니다. ALB는 기본으로 켜져 있지만 NLB와 GWLB는 기본값이 꺼짐이므로, NLB를 쓸 때는 가용 영역별 대상 수를 비슷하게 맞추거나 교차 영역 설정을 검토해야 합니다.

 

요금은 세 종류 모두 로드 밸런서가 실행된 시간과 사용량 단위(ALB는 LCU, NLB는 NLCU, GWLB는 GLCU)를 합산하는 구조입니다. 트래픽이 거의 없어도 로드 밸런서가 존재하는 시간만큼 시간당 요금이 발생하므로, 테스트용으로 만든 로드 밸런서는 끝나면 바로 삭제하는 것이 좋습니다. 여기에 일반적인 AWS 데이터 전송 요금이 별도로 붙습니다.

 

교차 영역 설정에 따라 대상별 부하가 크게 달라지며, 로드 밸런서는 트래픽과 관계없이 실행 시간만큼 요금이 발생합니다.

 

로드 밸런서 선택 핵심 정리

로드 밸런서는 리스너, 대상 그룹, 상태 검사로 동작하며 종류는 만든 뒤 바꿀 수 없습니다. 웹과 API는 경로·호스트 기반 규칙과 HTTPS 처리를 제공하는 ALB, 비 HTTP 트래픽과 고정 IP가 필요하면 NLB, 가상 보안 장비 연결에는 GWLB를 고릅니다. 교차 영역 기본값이 종류마다 다르다는 점과, 사용하지 않아도 시간당 요금이 발생한다는 점을 함께 기억해 두세요.

 

질문 QnA

Classic Load Balancer를 계속 써도 되나요?

동작은 하지만 이전 세대 제품이라 경로 기반 라우팅 같은 기능이 부족합니다. 새로 만드는 서비스라면 ALB나 NLB를 쓰고, 기존 CLB는 기회가 될 때 옮기는 것이 좋습니다.

대상이 계속 비정상으로 표시돼요.

대상 서버의 보안 그룹이 로드 밸런서에서 오는 상태 검사 트래픽을 허용하는지, 상태 검사 경로가 실제로 200 응답을 돌려주는지, 애플리케이션이 설정한 포트에서 실행 중인지 순서대로 확인해 보세요.

도메인은 어떻게 연결하나요?

로드 밸런서는 고정 IP 대신 DNS 이름을 제공하고, 이 이름이 가리키는 IP는 부하에 따라 바뀔 수 있습니다. Route 53을 쓴다면 별칭 레코드로 로드 밸런서를 가리키는 것이 가장 간단합니다.

서버가 한 대뿐이어도 로드 밸런서가 필요한가요?

한 대뿐이라면 분산 효과는 없지만, HTTPS 인증서 관리나 서버 교체 시 무중단 전환 같은 이점 때문에 쓰기도 합니다. 다만 시간당 요금이 발생하므로 필요성과 비용을 함께 따져 보세요.

 

로드 밸런서는 서비스 구조의 입구에 해당해서, 처음 고른 종류가 이후 라우팅 방식과 보안 구성까지 영향을 줍니다. 요구 사항을 먼저 정리하고 그에 맞는 종류를 고르는 순서가 가장 확실합니다.

 

지금 계획 중인 서비스가 있다면 HTTP 기반인지, 고정 IP가 필요한지, 경로별로 나눌 서비스가 있는지 세 가지를 먼저 적어 보세요. 이미 운영 중이라면 EC2 콘솔의 로드 밸런서 목록에서 트래픽 없이 남아 있는 로드 밸런서가 없는지도 확인해 보시길 권해드립니다.

함께 읽으면 좋은 글: VPC 퍼블릭·프라이빗 서브넷 차이 / AWS 숨은 비용 찾는 법

참고 자료: Elastic Load Balancing 작동 방식, Elastic Load Balancing 기능 비교, Elastic Load Balancing 요금

※ 본 글은 2026년 9월 기준 Elastic Load Balancing 사용 설명서와 요금 페이지를 참고해 작성했으며, 지원 기능과 기본값, 요금 기준은 변경될 수 있으니 최신 내용은 AWS 공식 문서에서 확인해 주세요.