AWS Elastic Load Balancer 정리

Published: June 29, 2026 by

Categories:
AWS 2
dev 12

AWS Elastic Load Balancer 정리

AWS Elastic Load Balancer 정리

웹 서비스나 API를 운영할 때 한 대의 서버에 모든 요청이 몰리면 응답이 느려지고, 서버가 죽으면 서비스 전체가 중단된다. 로드 밸런서(Load Balancer) 는 들어오는 네트워크 트래픽을 여러 대상(서버, 컨테이너, IP) 으로 나눠 보내는 역할을 한다.

AWS에서는 이 기능을 Elastic Load Balancer(ELB) 라는 관리형 서비스로 제공한다. 서버를 직접 설치·운영할 필요 없이, AWS 콘솔이나 API로 생성하고 헬스 체크(Health Check) · 자동 장애 복구 · 트래픽 분산 을 설정할 수 있다.

이 글은 ELB의 개념, 세 가지 종류(ALB / NLB / GWLB), 핵심 구성 요소(Listener, Target Group 등), 그리고 실무에서 어떤 상황에 무엇을 쓰면 좋은지 한 곳에 정리한다.

0. 개요 한눈에 보기

먼저 ELB가 트래픽을 어떻게 받아서 백엔드로 넘기는지부터 짚고 간다.

┌─────────────┐                    ┌─────────────────────┐                    ┌─────────────┐
│   Client    │ ─── HTTP/HTTPS ──▶ │  Elastic Load       │ ─── 분산 라우팅 ──▶ │  EC2 / ECS  │
│ (브라우저 등) │                    │  Balancer (ELB)     │                    │  / IP 대상   │
└─────────────┘                    └─────────────────────┘                    └─────────────┘
                                              │
                                              ▼
                                   비정상 대상은 자동 제외
                                   정상 복구 시 다시 트래픽 전달

구성 요소	역할
Listener	클라이언트 요청을 어떤 포트·프로토콜로 받을지 정의 (예: HTTPS 443)
Listener Rule	URL 경로, 호스트명 등 조건에 따라 어느 Target Group으로 보낼지 결정
Target Group	실제 트래픽을 받을 대상(EC2, IP, Lambda 등) 묶음
Health Check	대상이 정상인지 주기적으로 확인 → 비정상이면 트래픽 중단

ELB 종류	OSI 계층	대표 용도
ALB (Application Load Balancer)	Layer 7 (HTTP/HTTPS)	웹/API, 경로·호스트 기반 라우팅
NLB (Network Load Balancer)	Layer 4 (TCP/UDP)	초저지연, 고정 IP, 대용량 TCP
GWLB (Gateway Load Balancer)	Layer 3 (IP)	방화벽·IDS 등 가상 어플라이언스 삽입

ELB는 단일 DNS 이름 하나로 여러 대상에 트래픽을 분산한다. 클라이언트는 백엔드 서버 IP를 직접 알 필요가 없다.

1. Load Balancer란 무엇인가?

1-1. 기본 개념

로드 밸런서는 네트워크 트래픽을 여러 대상으로 분산하는 서비스다.

효과	설명
가용성(Availability)	한 대가 죽어도 나머지 대상이 요청을 처리 → 서비스 중단 최소화
확장성(Scalability)	서버를 추가하면 로드 밸런서가 자동으로 트래픽 분산
유지보수	특정 인스턴스를 Target Group에서 빼면 무중단 배포·롤링 업데이트 가능

로드 밸런서 없이 운영할 때

Client ──▶ EC2 #1 (과부하 / 장애 시 서비스 전체 다운)

로드 밸런서를 사용할 때

                    ┌──▶ EC2 #1
Client ──▶ ELB ────┼──▶ EC2 #2
                    └──▶ EC2 #3

1-2. Elastic Load Balancer (ELB)

Elastic Load Balancer는 AWS가 제공하는 관리형(Managed) 로드 밸런서 서비스다.

특징	설명
관리형 서비스	서버 설치·패치·용량 계획을 AWS가 담당
다양한 대상	EC2, ECS/Fargate, Lambda, IP 주소, ALB(중첩) 등
자동 장애 복구	헬스 체크로 비정상 대상 감지 → 해당 대상으로 라우팅 중단
자동 복구	대상이 다시 정상으로 감지되면 트래픽 재개
가용 영역(AZ)	여러 AZ에 걸쳐 배치해 단일 AZ 장애에도 견딤

[ELB가 하는 일]

① 클라이언트 요청 수신 (고정 DNS / IP)
② 헬스 체크로 정상 대상만 선별
③ 설정된 알고리즘으로 대상에 분산 (Round Robin 등)
④ 비정상 대상 감지 시 → 라우팅 제외
⑤ 대상 복구 시 → 다시 라우팅 포함

2. ELB 종류 비교

AWS ELB는 용도에 따라 세 가지로 나뉜다.

2-1. Application Load Balancer (ALB)

Layer 7 (HTTP/HTTPS) 에서 동작한다. URL 경로, 호스트명, HTTP 헤더 등 애플리케이션 수준으로 라우팅할 수 있다.

항목	내용
프로토콜	HTTP, HTTPS, HTTP/2, WebSocket, gRPC
라우팅	경로(`/api/*`), 호스트(`api.example.com`), 헤더 기반
대상	EC2, ECS, Lambda, IP, ALB
대표 사용처	REST API, 마이크로서비스, 웹 애플리케이션

                    ┌── /api/*   ──▶ API Target Group (EC2 × 3)
Client ──▶ ALB ────┼── /static/* ──▶ Static Target Group (EC2 × 2)
                    └── default  ──▶ Web Target Group (EC2 × 2)

2-2. Network Load Balancer (NLB)

Layer 4 (TCP/UDP) 에서 동작한다. IP·포트 기준으로 빠르게 전달하며, 초저지연·고처리량이 필요할 때 적합하다.

항목	내용
프로토콜	TCP, UDP, TLS(SNI)
특징	AZ당 고정 Elastic IP 할당 가능
성능	ALB보다 지연 시간이 짧고 초당 연결 수가 많음
대표 사용처	게임 서버, IoT, 실시간 스트리밍, 레거시 TCP 앱

Client ──▶ NLB (고정 IP: 203.0.113.10)
              │
              ├── TCP:8080 ──▶ EC2 #1
              ├── TCP:8080 ──▶ EC2 #2
              └── TCP:8080 ──▶ EC2 #3

2-3. Gateway Load Balancer (GWLB)

Layer 3 (IP) 에서 동작한다. 트래픽을 가상 네트워크 어플라이언스(방화벽, IDS/IPS, 딥 패킷 검사 등)로 보내 인라인 검사 후 다시 원래 경로로 돌려보낸다.

항목	내용
프로토콜	IP (GENEVE 캡슐화)
특징	VPC 트래픽 미러링·보안 어플라이언스 삽입
대표 사용처	서드파티 방화벽, 네트워크 보안 장비 연동

VPC 트래픽 ──▶ GWLB ──▶ 방화벽 EC2 (어플라이언스) ──▶ 검사 후 원 경로

2-4. 세 종류 한눈에 비교

비교 항목	ALB	NLB	GWLB
OSI 계층	L7	L4	L3
라우팅 기준	URL, Host, Header	IP + Port	IP (어플라이언스로 전달)
고정 IP	❌ (DNS만)	✅ Elastic IP	❌
WebSocket / gRPC	✅	제한적	❌
Lambda 대상	✅	❌	❌
주 용도	HTTP API·웹	고성능 TCP/UDP	보안 어플라이언스

실무에서 가장 많이 쓰는 것은 ALB(웹/API)와 NLB(TCP 고성능)다. GWLB는 네트워크 보안 아키텍처를 구성할 때 사용한다.

3. ELB 핵심 구성 요소

ELB를 이해하려면 Listener → Rule → Target Group → Target 흐름을 알아야 한다.

3-1. 전체 구조 도식

flowchart LR
    Client[Client] --> Listener[Listener<br/>포트·프로토콜]
    Listener --> Rule[Listener Rule<br/>조건·우선순위]
    Rule --> TG[Target Group<br/>대상 묶음]
    TG --> T1[Target EC2 #1]
    TG --> T2[Target EC2 #2]
    TG --> T3[Target EC2 #3]
    TG -.-> HC[Health Check]
    HC -.-> T1
    HC -.-> T2
    HC -.-> T3

3-2. Listener (리스너)

Listener는 ELB가 어떤 포트·프로토콜로 클라이언트 요청을 받을지 정의한다.

설정 예시	설명
HTTP : 80	비암호화 HTTP 수신
HTTPS : 443	SSL/TLS 종료(termination) 후 백엔드로 전달
TCP : 8080	NLB에서 TCP 포트 수신

ELB DNS: my-alb-1234567890.ap-northeast-2.elb.amazonaws.com

Listener #1: HTTPS 443  ← 클라이언트는 여기로 접속
Listener #2: HTTP  80   ← (선택) HTTP → HTTPS 리다이렉트

HTTPS Listener에서는 ACM(AWS Certificate Manager) 인증서를 연결해 SSL/TLS를 ELB에서 종료할 수 있다. 백엔드 EC2까지 암호화가 필요하면 End-to-End TLS(리스너 + Target Group 모두 HTTPS)도 구성 가능하다.

3-3. Listener Rule (리스너 규칙)

ALB에서는 Listener 아래에 Rule을 둔다. 요청 조건에 따라 어느 Target Group으로 보낼지 결정한다.

규칙 요소	예시
Priority	숫자가 작을수록 먼저 평가 (1, 2, 3 …)
Condition	`Host = api.example.com`, `Path = /v1/*`
Action	Forward → Target Group A, Redirect, Fixed Response

Priority 1:  Host = api.example.com     → Forward → api-tg
Priority 2:  Path  = /admin/*           → Forward → admin-tg
Priority 3:  (default)                  → Forward → web-tg

Default Rule은 항상 존재하며, 다른 규칙에 매칭되지 않은 요청을 처리한다.

3-4. Target Group (타깃 그룹)

Target Group은 트래픽을 받을 대상들의 묶음이다.

대상 유형	설명
`instance`	EC2 인스턴스 ID
`ip`	사설/공인 IP (온프레미스 포함)
`lambda`	AWS Lambda 함수 (ALB만)
`alb`	다른 ALB (NLB → ALB 패턴)

Target Group 설정	설명
Protocol / Port	대상에 전달할 프로토콜·포트 (예: HTTP 8080)
Health Check	주기·경로·임계값으로 정상 여부 판단
Load Balancing Algorithm	Round Robin, Least Outstanding Requests 등

3-5. Health Check (헬스 체크)

ELB는 Target Group에 설정된 헬스 체크로 대상 상태를 판단한다.

[정상 흐름]
ELB ── GET /health ──▶ EC2 #1  → 200 OK  →  healthy  → 트래픽 전달 O

[비정상 흐름]
ELB ── GET /health ──▶ EC2 #2  → timeout →  unhealthy → 트래픽 전달 X
                                              (다른 healthy 대상으로만 분산)

파라미터	의미
Interval	헬스 체크 간격 (예: 30초)
Timeout	응답 대기 시간
Healthy threshold	연속 N회 성공 시 healthy
Unhealthy threshold	연속 N회 실패 시 unhealthy
Path (HTTP)	체크할 URL (예: `/health`)
Matcher	성공으로 볼 HTTP 코드 (예: `200`)

애플리케이션에 /health 같은 가벼운 헬스 엔드포인트를 두는 것이 일반적이다. DB 연결까지 검사할지는 운영 정책에 따라 결정한다.

4. 트래픽 흐름 (End-to-End)

4-1. ALB 기준 시퀀스

sequenceDiagram
    autonumber
    participant C as Client
    participant ALB as Application LB
    participant TG as Target Group
    participant EC2A as EC2 (healthy)
    participant EC2B as EC2 (unhealthy)

    Note over ALB,TG: 주기적 Health Check
    ALB->>EC2A: GET /health → 200
    ALB->>EC2B: GET /health → timeout
    ALB->>TG: EC2B unhealthy 등록

    C->>ALB: HTTPS GET /api/users
    ALB->>ALB: Listener Rule 평가 (/api/* → api-tg)
    ALB->>EC2A: HTTP GET /api/users
    EC2A-->>ALB: 200 + JSON
    ALB-->>C: 200 + JSON

4-2. 요청이 ELB를 거치는 이유 정리

① Client는 ELB DNS만 알면 됨 (백엔드 IP 변경·스케일 아웃 시에도 DNS 유지)
② ELB가 SSL 종료 → EC2 부하 감소 (선택)
③ 비정상 인스턴스 자동 제외
④ AZ 간 분산으로 단일 장애점 완화
⑤ Auto Scaling Group과 연동 시 인스턴스 증감에 자동 대응

5. 실무 구성 패턴

5-1. ALB + Auto Scaling (가장 흔한 웹/API 패턴)

Internet
    │
    ▼
┌─────────┐     ┌──────────────────┐     ┌─────────────────┐
│   ALB   │────▶│  Target Group    │────▶│  ASG (EC2 × N)  │
│ HTTPS   │     │  (app-servers)   │     │  min / max 설정  │
└─────────┘     └──────────────────┘     └─────────────────┘

구성	설명
ALB	Public Subnet, Internet-facing
EC2	Private Subnet (보안 그룹으로 ALB만 허용)
ASG	CPU·요청 수에 따라 인스턴스 자동 증감

5-2. NLB + ALB (고정 IP + L7 라우팅)

고정 IP가 필요하지만 HTTP 경로 라우팅도 필요할 때 NLB 앞단 + ALB 뒷단 조합을 쓰기도 한다.

Client ──▶ NLB (Elastic IP) ──▶ ALB ──▶ Target Groups

5-3. Internal ALB (내부 마이크로서비스)

VPC 내부 서비스 A ──▶ Internal ALB ──▶ 서비스 B, C Target Groups

항목	설명
Scheme	`internal` (VPC 내부 DNS만 제공)
용도	BFF → 내부 API, 서비스 간 HTTP 통신

6. 보안·네트워크 체크리스트

항목	권장 사항
Security Group	ALB SG: 443(Internet) 허용 / EC2 SG: ALB SG에서 오는 트래픽만 허용
HTTPS	Public ALB는 HTTPS Listener + ACM 인증서 사용
Private Subnet	EC2는 Private에 두고 ALB만 Public에 배치
WAF	ALB 앞에 AWS WAF 연동으로 SQL Injection·봇 차단 검토
Access Log	S3에 ALB 액세스 로그 저장 → 트래픽 분석·감사

[보안 그룹 예시]

ALB-SG:  Inbound 0.0.0.0/0 : 443
EC2-SG:  Inbound ALB-SG      : 8080
         (EC2에 443 직접 오픈하지 않음)

7. ALB vs NLB 선택 가이드

상황	추천
REST API, 웹사이트, 경로별 라우팅	ALB
WebSocket, HTTP/2, gRPC	ALB
Lambda를 HTTP 대상으로	ALB
초저지연 TCP, 초당 수백만 연결	NLB
AZ별 고정 IP 필요	NLB
UDP 프로토콜	NLB
방화벽·IDS 인라인 삽입	GWLB

8. Classic Load Balancer (CLB) 참고

예전에는 Classic Load Balancer(CLB) 가 있었으나, 현재는 신규 구축 시 ALB 또는 NLB 사용을 권장한다.

구분	CLB	ALB / NLB
세대	1세대 (레거시)	2세대 (권장)
L7 라우팅	제한적	ALB에서 풍부한 Rule
기능	기본 분산	고급 라우팅·고정 IP·GWLB 등

기존 CLB가 남아 있다면 마이그레이션 계획을 세우는 것이 좋다.

9. 용어 정리

용어	설명
Load Balancer	트래픽을 여러 대상에 분산하는 장치·서비스
ELB	AWS Elastic Load Balancer. ALB·NLB·GWLB 포함
ALB	Application Load Balancer. HTTP/HTTPS L7
NLB	Network Load Balancer. TCP/UDP L4
GWLB	Gateway Load Balancer. 보안 어플라이언스용 L3
Listener	ELB가 요청을 수신하는 포트·프로토콜 설정
Target Group	트래픽을 받을 대상(EC2, IP, Lambda 등) 묶음
Health Check	대상 정상 여부를 주기적으로 검사하는 기능
AZ	Availability Zone. AWS 데이터센터 격리 단위
Sticky Session	동일 클라이언트를 같은 대상에 묶는 기능 (ALB, 쿠키 기반)

10. 마치며

Elastic Load Balancer는 AWS에서 가용성·확장성·운영 편의를 위해 트래픽을 자동 분산하는 핵심 서비스다.

핵심은 다음 세 가지다.

Listener → Rule → Target Group → Target 구조로 요청이 전달된다.
Health Check로 비정상 대상을 자동 제외하고, 복구 시 다시 포함한다.
ALB(HTTP/API), NLB(고성능 TCP/UDP), GWLB(보안 어플라이언스) 중 용도에 맞게 선택한다.

웹·API 서비스를 EC2나 ECS로 운영한다면 ALB + Target Group + Auto Scaling + Private Subnet 조합이 가장 많이 쓰이는 시작점이다. 트래픽이 늘면 Target Group에 대상만 추가하거나 ASG로 인스턴스를 늘리면 되고, ELB DNS는 그대로 유지된다.