ALB를 통한 트래픽 흐름

이재영·2025년 4월 7일

Client <---> ALB(Application Load Balancer) <---> EC2 의 통신 흐름을 정리해보고자 합니다. 로드 밸런서가 요청을 해석하고 헤더를 조작 어쩌고... 한다는데 또 까먹을거 같아, 빠르게 직관적으로 ALB(Application Load Balancer)를 사용할 때의 네트워크 동작과 클라이언트 IP 추적 방식을 정리해봅니다...

📦 전체적인 트래픽 흐름

1️⃣ 클라이언트가 ALB에 요청

클라이언트(공인 IP: 12.34.56.78)가 https://example.com 요청
이 요청은 인터넷 → ALB(퍼블릭 IP 또는 DNS 주소)로 전달됨
ALB는 이 요청을 수신하고 종료(terminate)함

여기서 말하는 "종료"는 전체 통신이 끝난다는 뜻이 아니라,
클라이언트와 ALB 사이의 TLS 연결 또는 TCP 세션을 ALB가 처리(종료)하고,
그 이후에 ALB가 새로운 연결로 EC2에 전달한다는 의미!
약간, 전화 교환원(?)이라고 생각하면 편하다

상황을 간단히 요약하자면....
클라이언트 ← HTTPS 연결 → ALB ← HTTP 연결 → EC2(사설IP) 임.

2️⃣ ALB가 새로운 연결로 EC2(사설IP)에 전달

ALB는 클라이언트의 원래 요청을 기반으로
자기 내부 IP(사설 IP)로 EC2(사설IP)에게 다시 요청을 전송함
EC2는 ALB의 사설 IP로부터 요청을 받음
즉, EC2는 클라이언트의 IP를 직접 알 수 없음
- 클라이언트의 IP는 이미 ALB에서 "끊기고 새로 만들어진 요청"에 포함되지 않음

3️⃣ ALB가 요청 헤더에 클라이언트 정보를 담아줌

ALB는 HTTP 요청 헤더에 추가 정보를 자동으로 삽입함:

헤더	내용
`X-Forwarded-For`	클라이언트의 실제 IP 주소 (`12.34.56.78`)
`X-Forwarded-Port`	클라이언트가 사용한 포트 (`443` 등)
`X-Forwarded-Proto`	클라이언트가 사용한 프로토콜 (`http` 또는 `https`)

이 헤더들을 통해 EC2는 "아, 실제 사용자는 이 IP였구나"를 유추할 수 있음

💡 예시: EC2에서 로그로 보면 이런 식

GET / HTTP/1.1
Host: example.com
X-Forwarded-For: 12.34.56.78
X-Forwarded-Port: 443
X-Forwarded-Proto: https
User-Agent: Mozilla/5.0 ...

✅ 이게 왜 중요한가??

로그, 보안 감사, IP 기반 필터링 등을 하려면 클라이언트의 실제 IP가 필요함
그런데 ALB는 직접 통신하지 않기 때문에 EC2는 기본적으로 클라이언트 IP를 모름
따라서 애플리케이션은 반드시 이 X-Forwarded-For 헤더를 파싱해서 사용해야 함

예: Nginx, Apache, Node.js 등에서 이 헤더를 읽도록 설정 필요

🚨 주의사항

만약 애플리케이션에서 X-Forwarded-For를 신뢰한다면,
보안적으로 신뢰 가능한 소스(ALB) 에서만 요청이 오도록 방화벽/보안 그룹을 구성해야 함
이 헤더는 클라이언트가 조작할 수 있으므로, 신뢰할 수 없는 환경에서는 위험할 수 있음!

📌 요약

항목	설명
ALB가 클라이언트 요청을 수신	클라이언트 IP는 `12.34.56.78`
ALB가 연결을 종료함	HTTPS 핸드셰이크도 ALB에서 수행
ALB → EC2로 새로운 요청 전송	ALB의 사설 IP로 요청
EC2는 클라이언트 IP를 직접 알 수 없음	대신 `X-Forwarded-For` 등 헤더 사용
애플리케이션은 이 헤더를 파싱해야 함	로깅/보안 분석/통계에 필요