AWS ALB 요청 흐름: Listener Rule·Target Group·TLS

Application Load Balancer(ALB)는 HTTP·HTTPS 요청을 받아 listener rule로 평가한 뒤 target group의 정상 target으로 전달한다. 이해할 때는 listener → rule → action → target group → target 순서로 보면 된다. ALB 내부 구현을 추측하기보다 AWS가 보장하는 이 설정 단위를 기준으로 설계하는 편이 안전하다.

Client request
    │
    ▼
Listener :443 (HTTPS)
    │
    ▼
Listener rules (priority 순서)
    │
    ├─ /api/*  ──> api target group
    └─ default ──> web target group
                         │
                         ▼
                    healthy target

Listener가 연결을 받는다

Listener는 protocol과 port를 조합한 진입 설정이다. HTTPS listener에서는 ALB가 클라이언트 TLS 연결을 종료하므로 인증서와 security policy가 필요하다. 이 사실이 ALB 뒤 구간은 항상 평문이라는 뜻은 아니다. target group protocol을 HTTPS로 설정하면 ALB가 target과 별도의 TLS 연결을 만든다.

즉, 두 구간을 따로 결정해야 한다.

• Client → ALB: HTTP 또는 HTTPS listener
• ALB → target: HTTP 또는 HTTPS target group protocol

뒤 구간 HTTPS에서 ALB는 target 인증서를 사용해 TLS 연결을 만들지만, AWS 문서상 target 인증서 검증을 수행하지 않는다. 인터넷에 직접 노출된 서버의 인증서 검증 모델과 같다고 가정하지 말고, VPC 경계와 보안 그룹을 함께 설계해야 한다.

Listener rule이 요청을 분류한다

Listener rule에는 priority, condition, action이 있다. 숫자가 낮은 priority부터 평가하고, 조건이 맞는 첫 규칙의 action을 실행한다. 마지막에는 별도 priority가 없는 default rule이 있다.

조건에는 다음 항목을 사용할 수 있다.

• host header
• path pattern
• HTTP header와 request method
• query string
• source IP

대표 action은 target group으로 전달하는 forward, URL을 바꾸는 redirect, 응답을 직접 돌려주는 fixed-response, HTTPS listener에서 OIDC 또는 Cognito 인증을 수행하는 authenticate-*다. 여러 target group에 가중치를 줄 수도 있지만, 가중치 라우팅은 실패한 target group의 트래픽을 다른 그룹으로 자동 재분배하는 기능으로 간주하면 안 된다.

Target group이 실제 대상을 묶는다

ALB target group의 target type은 instance, IP address, Lambda다. instance 또는 IP target에는 HTTP·HTTPS를 사용하고, protocol version으로 HTTP/1.1, HTTP/2, gRPC를 선택할 수 있다.

gRPC는 ALB에서도 지원된다. HTTPS listener와 forward action을 사용하고 instance 또는 IP target을 연결한다. gRPC는 무조건 NLB라는 구분보다, HTTP/2 기반 gRPC 라우팅·health check가 필요한지 또는 raw TCP 흐름이 필요한지를 봐야 한다.

ALB는 health check를 통과한 target으로 요청을 보낸다. health check path, 성공 코드, timeout과 threshold를 애플리케이션의 준비 상태에 맞춰야 한다. 단순히 프로세스가 떠 있다는 응답만 사용하면 의존 서비스가 끊긴 target으로도 트래픽이 갈 수 있다.

원래 클라이언트 IP는 헤더로 전달된다

ALB 뒤 target에서 TCP peer 주소만 보고 원래 사용자의 IP라고 판단해서는 안 된다. ALB는 X-Forwarded-For에 클라이언트 IP를 전달한다. X-Forwarded-Proto와 X-Forwarded-Port도 원래 요청 protocol과 port를 전달하는 데 쓰인다.

다만 애플리케이션이 인터넷에서 임의로 들어온 X-Forwarded-For를 그대로 신뢰하면 위조가 가능하다. ALB를 신뢰 프록시로 지정하고, 프레임워크의 proxy trust 설정과 보안 그룹으로 실제 경로를 제한해야 한다. 여러 프록시를 거치면 헤더에 주소가 추가되므로 어느 위치를 신뢰할지도 정한다.

ALB의 DNS 주소와 보안 경계

ALB에는 DNS 이름이 제공되고 그 이름이 해석하는 IP는 바뀔 수 있다. 현재 조회한 IP를 장기 allowlist에 고정하는 방식은 피한다. 고정 IP가 필요하면 요구사항에 따라 NLB의 ALB target 또는 Global Accelerator를 검토할 수 있다. 지원되는 조합과 제약은 ALB와 NLB 조합 패턴에 정리했다.

WAF도 ALB 내부 장비로 이해하면 안 된다. Web ACL을 ALB 리소스에 연결하는 별도 서비스이며, 검사 크기와 rule action에 경계가 있다. 자세한 내용은 AWS WAF 위치와 검사 한계에서 이어진다.

설계 전에 확인할 목록

• client 구간과 target 구간의 protocol을 각각 정했는가?
• listener rule priority와 default rule이 의도대로인가?
• target type과 protocol version이 서비스 방식에 맞는가?
• health check가 실제 준비 상태를 반영하는가?
• 애플리케이션이 전달 헤더를 신뢰할 경계를 정했는가?
• 고정 IP나 PrivateLink가 정말 필요한가?

참고 자료

• Application Load Balancer 소개
• ALB listener rule
• ALB target group
• ALB의 X-Forwarded 헤더
• ALB HTTPS listener 생성