| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- 로그백
- 냄새라도
- 단위테스트
- 클린아키텍처
- Ajax
- SEQUENCE
- 전전긍긍
- MVC요청플로우
- Transaction
- 사면초가
- string
- JPA
- JDBC
- TDD
- index
- SpringLegacy
- MVC
- springsecurity
- 공통기술
- OOP
- model
- 문제선택근거
- 이벤트핸들러this
- 공통규약
- 설정세팅
- 커뮤니티서버
- DDD
- 이벤트핸들러등록
- AOP
- 디스크i/o
- Today
- Total
개발이군고구마
NLB와 ALB의 차이 (Reverse Proxy 와 D-NAT) 본문
NLB와 ALB의 차이
OSI 7계층부터 Reverse Proxy와 D-NAT까지 깊게 이해하는 구조
NLB와 ALB를 비교할 때 가장 자주 빠지는 함정으로 기능 목록만 외우는 접근 방식. 진짜 차이는 메뉴 이름이 아니라 패킷과 요청이 어디서 어떻게 바뀌는지, 백엔드 서버가 누구를 연결 주체로 보게 되는지, 그리고 보안그룹이 어느 지점에서 무엇을 허용해야 하는지의 구조 차이.
1. 문제의 출발점
실무에서 가장 혼란스러운 상황으로 앞단 접속은 열려 있는데 뒤에서는 응답이 없는 상황.
대표 패턴으로 Client → NLB:443 → Web Server:8080/8089 → ALB → WAS 구조에서 NLB까지는 연결 확인이 되지만 실제 애플리케이션 응답은 오지 않는 현상.
왜 443은 열려 있는데 8080 또는 8089에서 막히는가의 질문.
왜 NLB와 ALB는 둘 다 앞단 장비인데 보안그룹 설계 방식이 달라지는가의 질문.
왜 어떤 구조에서는 원본 클라이언트 IP를 백엔드가 직접 보게 되고, 어떤 구조에서는 ALB를 요청 주체로 보게 되는가의 질문.
2. OSI 7계층과 L4·L7의 차이
로드 밸런서의 차이를 설명하는 가장 정확한 출발점으로 OSI 7계층 개념.
계층별로 Http 요청(=데이터)을 감쌈. 애플리케이션이 요청을 만들고, 운영체제(OS)가 네트워크용 포장
데이터 = 네트워크를 통해 전달되기 위해 각 계층이 자기 역할에 맞는 정보를 덧붙여 여러 겹으로 포장된 형태
L7 Application : HTTP, HTTPS, gRPC, WebSocket 같은 요청 의미 해석 계층 L6 Presentation : 인코딩, 압축, 암호화, 직렬화 같은 데이터 표현 계층 L5 Session : 세션 유지, 연결 문맥 관리 계층 L4 Transport : TCP, UDP, 포트, 연결, 재전송, 흐름 제어 계층 (✨TCP 세그먼트로 감싸기- 포트) L3 Network : IP 주소, 라우팅, 목적지 네트워크 선택 계층 (✨IP 패킷으로 감싸기 - IP) L2 Data Link : MAC 주소, 프레임 전달 계층 L1 Physical : 케이블, 전기 신호, 물리 매체 계층 👆 아래 계층은 “어디로 전달할지”를 보고, 👇 위 계층은 “무슨 요청인지”를 봄
L4 장비의 관점 - 연결(connection) 중심
판단 기준으로 IP, Port, TCP/UDP, 연결 상태의 관점.
질문 형식으로 어느 IP와 어느 Port로 보낼지의 관점.
HTTP Header, URL Path, Cookie 같은 애플리케이션 의미는 보지 않는 특성.
🙄 아, TCP 443으로 왔네.
🙄 이 연결을 어느 타겟으로 넘길까?
L7 장비의 관점 - 요청 내용(request content) 중심
판단 기준으로 Host, Path, Method, Header, Cookie의 관점.
질문 형식으로 어떤 웹 요청을 어떤 서비스로 보낼지의 관점.
요청을 해석하고 재구성하는 프록시 동작의 특성.
- NLB는 연결 전달 중심 구조
- ALB는 요청 해석과 프록시 중심 구조
- NLB는 보통 타깃이 클라이언트 IP를 더 직접적으로 인식하는 구조
- ALB는 백엔드가 ALB를 직접 연결 주체로 인식하고 원본 IP는 보통
X-Forwarded-For헤더로 확인하는 구조
3. NLB의 동작 원리
NLB의 핵심 동작으로 L4 계층에서 연결을 받아 타깃 IP와 Port로 전달하는 구조.
중요한 포인트로 애플리케이션 요청을 해석하는 장비가 아니라 연결을 중계하는 장비라는 점.
[NLB 관점의 핵심 흐름] Client -- TCP/TLS 연결 --> NLB NLB -- 타깃 선택 --> Target IP:Port NLB -- 전달 --> Web Server 핵심 관심사 1) 어느 타깃으로 보낼지 2) 어느 포트로 보낼지 3) 연결이 살아 있는지 4) 애플리케이션 메시지를 해석하지 않는지
패스스루 기본 개념
일반적인 NLB 설명에서 자주 쓰이는 표현으로 패킷을 그대로 던지는 구조.
이 표현의 정확한 의미로 HTTP 헤더, URL, 쿠키를 읽고 가공하는 프록시 장비가 아니라는 뜻.
특히 TCP 443 리스너를 사용하면 암호화된 트래픽을 복호화하지 않고 백엔드로 전달하는 패스스루 구성이 가능.
TLS 리스너 예외 개념
AWS NLB도 TLS 리스너를 지원하므로 NLB 앞단에서 인증서 처리가 가능한 구조.
이 경우 프런트 구간 TLS는 NLB에서 종료되고, 백엔드로는 새 연결이 생성되는 구조.
따라서 NLB는 무조건 TLS를 건드리지 않는 장비라고 단정하는 설명은 부정확한 설명.
실무 설명에서 가장 유용한 표현으로 NLB는 목적지 정보를 타깃 기준으로 연결시키는 장비라는 설명.
단순화한 개념으로 Source는 원본 클라이언트 정보 보존 가능, Destination은 타깃 IP와 Port 기준 전환의 구조.
이 때문에 백엔드 보안그룹은 NLB의 리스너 포트만 보는 것이 아니라 실제 타깃 포트를 반드시 열어야 하는 구조.
NLB를 언제나 "패킷을 아무것도 안 바꾸는 장비"로 이해하면 오류 발생 가능성.
정확한 표현으로 L7 프록시처럼 요청 본문과 헤더를 재구성하지 않는 장비라는 설명.
프런트 리스너 종류가 TCP인지 TLS인지에 따라 TLS 종료 위치는 달라지는 구조.
4. ALB의 동작 원리
ALB의 핵심 동작으로 L7 계층에서 HTTP/HTTPS 요청을 받아 해석하고, 그 결과를 바탕으로 백엔드에 새 요청을 만드는 구조.
중요한 포인트로 ALB는 단순 전달자가 아니라 Reverse Proxy라는 점.
[ALB 관점의 핵심 흐름] Client -- HTTP/HTTPS 요청 --> ALB ALB -- 요청 분석 --> Host / Path / Header / Method 판단 ALB -- 새 요청 생성 --> Target Server Target -- 응답 --> ALB --> Client 핵심 관심사 1) 어떤 URL과 Header인지 2) 어떤 서비스로 라우팅할지 3) 인증서 종료와 웹 기능을 어디서 처리할지 4) 백엔드가 원본 IP를 헤더로 받을지
프록시 본질
ALB는 클라이언트와 서버 사이에서 각각 별도의 연결을 맺는 구조.
즉, 클라이언트는 ALB와 연결되고, 백엔드 서버도 ALB와 연결되는 구조.
백엔드 관점에서는 ALB가 새로운 클라이언트처럼 요청하는 구조.
원본 IP 전달 방식
백엔드 애플리케이션이 실제 사용자 IP를 알고 싶다면 보통 X-Forwarded-For 헤더를 확인하는 방식.
즉, 소켓 연결의 원본과 HTTP 의미상의 원본이 분리되는 구조.
백엔드 서버가 실제 TCP 연결 주체로 ALB를 보기 때문.
따라서 WAS 인바운드는 대개 ALB 보안그룹 또는 ALB가 위치한 경로를 기준으로 허용하는 구조.
5. 장애 시나리오 분석
구조 예시로 Spark EC2 → NLB:443 → Web Server:8080/8089 → ALB → WAS 흐름.
[증상] 1) NLB:443 까지는 연결 확인 성공 2) 그 이후 애플리케이션 응답 실패 [원인] 1) Web Server 실제 리스닝 포트는 8080 또는 8089 2) Web Server 보안그룹 인바운드에 Spark IP 대역 허용 누락 3) 결과적으로 NLB를 통과한 뒤 Target Port에서 차단 발생 [핵심] 리스너 포트 443 오픈과 타깃 포트 8080/8089 오픈은 서로 다른 문제
NLB까지의 연결 성공은 타깃 포트 인바운드 허용을 보장하지 않는 사실.
실제 차단 지점은 대개 타깃 인스턴스의 실제 서비스 포트 보안그룹인 경우가 많은 패턴.
6. 보안그룹 설계 원칙
NLB 뒤 서버 보안그룹
중요 기준으로 실제 타깃 포트 허용 여부 확인.
원본 클라이언트 IP 보존 구조라면 타깃 서버 SG는 클라이언트 대역 허용 필요 가능성.
NLB 보안그룹 사용 구성이라면 NLB SG 참조 방식도 가능.
ALB 뒤 서버 보안그룹
백엔드 연결 주체가 ALB이므로 타깃 서버는 보통 ALB SG를 인바운드에 허용하는 구조.
원본 클라이언트 IP는 애플리케이션 또는 웹서버 로그에서 X-Forwarded-For로 확인하는 구조.
[실무 체크 순서] 1) 외부 사용자가 접속하는 포트 확인 2) 로드 밸런서 리스너 포트 확인 3) 대상 그룹 타깃 포트 확인 4) 실제 서버 프로세스 리스닝 포트 확인 5) 각 구간 보안그룹 인바운드·아웃바운드 확인 6) 헬스체크 포트와 애플리케이션 포트가 다른지 확인 7) ALB인 경우 X-Forwarded-For 활용 여부 확인 8) NLB인 경우 Client IP 보존 구조 여부 확인
7. NLB와 ALB 핵심 비교표
| 항목 | NLB | ALB |
|---|---|---|
| 주 계층 | L4 중심 구조 | L7 중심 구조 |
| 핵심 판단 기준 | IP, Port, TCP/UDP, 연결 상태 | Host, Path, Header, Method, Cookie |
| 본질 | 연결 전달 장비 | Reverse Proxy 장비 |
| 원본 IP 전달 | 구성에 따라 클라이언트 IP 보존 가능 | 보통 X-Forwarded-For 헤더 전달 |
| TLS 처리 | TCP 443 패스스루 가능, TLS 리스너 종료 가능 | HTTPS 리스너에서 TLS 종료 일반적 |
| 백엔드가 보는 연결 주체 | 구성에 따라 원본 클라이언트에 가깝게 인식 가능 | ALB를 직접 연결 주체로 인식 |
| 보안그룹 포인트 | 실제 타깃 포트 허용이 핵심 | 타깃은 ALB SG 허용이 핵심 |
| 적합한 사용 사례 | 고성능 TCP/UDP, 고정 IP, 낮은 레벨 전달 | 웹 라우팅, 마이크로서비스, URL 기반 분기 |
8. 참고 자료
기술 설명의 기준 자료로 AWS 공식 문서 중심 참고.
- Listeners for your Network Load Balancers
- Edit target group attributes for your Network Load Balancer
- Update the security groups for your Network Load Balancer
- HTTP headers and Application Load Balancers
- Application Load Balancers
NLB를 이해하는 핵심 문장으로 목적지 기준 연결 전달 장비라는 정의.
ALB를 이해하는 핵심 문장으로 요청을 해석하고 새 요청을 만드는 Reverse Proxy라는 정의.
장애 분석의 핵심 문장으로 앞단 443 성공과 뒤단 8080·8089 성공은 전혀 다른 검사 항목이라는 정의.

'Cloud Deploy' 카테고리의 다른 글
| 배포 흐름으로 이해하는 AWS 인프라 구조 (0) | 2026.04.04 |
|---|---|
| Git revert, revert의 이해 (1) | 2026.04.03 |
| Git의 원리: 객체, 브랜치, HEAD, 병합, 원격 저장소 (0) | 2026.03.21 |
| Gitlab MR 병목현상 (0) | 2026.03.15 |
| 빌드(CI)와 배포(CD) (0) | 2026.03.10 |