AWS ALB와 NLB 함께 쓰기: 지원되는 2가지 패턴과 피할 연결

ALB와 NLB를 함께 쓰는 대표 구조는 NLB → ALB와 병렬 진입점이다. ALB → NLB를 AWS 리소스끼리 직접 연결하는 구조는 지원되는 target type이 아니므로 피해야 한다. ALB target group이 등록할 수 있는 대상은 instance, IP address, Lambda이고 NLB 자체는 대상이 아니다.

선택 기준은 단순히 L4와 L7 중 어느 쪽이 더 빠른지가 아니다. 필요한 프로토콜, 고정 IP, PrivateLink, HTTP 라우팅과 WAF를 먼저 적어야 한다.

패턴 1: NLB에서 ALB로 전달하기

AWS가 공식 지원하는 결합은 NLB target group의 target type을 alb로 만드는 방식이다.

Client
  │
  ▼
NLB  ── static IP, PrivateLink 진입점
  │  TCP
  ▼
ALB  ── HTTPS, host/path/header routing, WAF
  │
  ▼
Application targets

이 구조는 NLB의 고정 IP 또는 AWS PrivateLink 진입점이 필요하면서, 뒤에서는 ALB의 HTTP 라우팅을 유지해야 할 때 의미가 있다. 다만 다음 제약을 함께 봐야 한다.

• NLB target group protocol은 TCP여야 한다.
• target group port는 ALB listener port와 같아야 한다.
• NLB와 ALB는 같은 VPC와 계정에 있어야 한다.
• ALB target은 IPv4 통신만 지원한다.
• target group 하나에는 ALB 하나만 등록할 수 있다.
• 한 ALB를 최대 두 NLB에 연결할 수 있지만, NLB마다 별도 target group이 필요하다.

WAF는 NLB가 아니라 뒤의 ALB에 연결한다. NLB가 앞에 있다고 해서 WAF가 TCP payload 전반을 검사하는 것은 아니다. WAF의 연결 대상과 검사 한계는 AWS WAF 위치와 검사 범위에 따로 정리했다.

패턴 2: ALB와 NLB를 병렬로 두기

하나의 연결 사슬로 만들 이유가 없다면 프로토콜별 진입점을 분리하는 편이 더 명확하다.

api.example.com  ── ALB ── HTTP/HTTPS/gRPC 서비스
mqtt.example.com ── NLB ── TCP/TLS 서비스

ALB는 HTTP·HTTPS뿐 아니라 HTTP/2와 gRPC target protocol version도 지원한다. 따라서 gRPC니까 반드시 NLB라는 기준은 맞지 않는다. gRPC의 package, service, method 기준 라우팅과 HTTP 계층 기능이 필요하면 ALB가 후보가 된다. 반면 raw TCP·UDP, NLB TLS listener, PrivateLink 서비스, 고정 주소가 핵심이면 NLB가 맞을 수 있다.

병렬 구조는 DNS 이름, 인증서, health check와 보안 정책도 각각 관리한다. 같은 애플리케이션을 두 진입점에 무심코 노출하면 인증 정책이나 관측 지표가 갈라질 수 있으므로, 어떤 클라이언트가 어느 주소를 쓰는지 계약을 명시해야 한다.

요구사항	우선 검토할 진입점
host/path/header 기반 HTTP 라우팅	ALB
HTTP/2·gRPC 애플리케이션 라우팅	ALB
WAF 연결	ALB 또는 CloudFront
raw TCP·UDP	NLB
PrivateLink endpoint service	NLB
고정 IP와 ALB 기능을 동시에 사용	NLB → ALB

피할 구조: ALB에서 NLB로 직접 전달하기

다음 그림은 직관적으로 보이지만 ALB listener의 정상적인 forward 대상으로 NLB를 지정할 수 없다.

ALB ──X──> NLB

NLB가 현재 해석한 IP 주소를 ALB의 IP target으로 수동 등록하는 우회도 설계 기반으로 삼지 않는 편이 좋다. NLB 리소스를 target으로 등록한 것이 아니며, 주소 변화와 health check 책임을 떠안게 된다. /api는 ALB, 스트림은 NLB로 보내고 싶다면 DNS 또는 클라이언트가 서로 다른 진입점을 선택하는 병렬 구조가 더 분명하다.

고정 anycast IP만 필요하고 PrivateLink가 목적이 아니라면 AWS Global Accelerator도 ALB를 endpoint로 둘 수 있다. 별도 서비스가 추가되므로 비용, 클라이언트 위치, 장애 전환 요구를 보고 NLB 조합과 비교한다.

선택 순서

1. HTTP 계층 라우팅과 WAF가 필요한지 확인한다.
2. raw TCP·UDP 또는 PrivateLink가 필요한지 확인한다.
3. 고정 IP가 반드시 필요한 진입점인지 확인한다.
4. 한 사슬이 필요한지, 프로토콜별 병렬 진입점이 더 단순한지 비교한다.
5. 지원 target type, port, VPC·계정, IP version 제약을 문서로 검증한다.

ALB의 listener와 target group이 요청을 처리하는 방식은 AWS ALB 요청 흐름에서 더 자세히 이어진다.

참고 자료

• NLB target으로 ALB 사용하기
• ALB target group과 target type
• AWS Global Accelerator 동작 방식