Cloud/AWS

AWS에서 HTTP/HTTPS에 대한 ALB/NLB 선택 기준 - Part 1

지기(ZIGI) 2026. 2. 23. 16:48

Today Keys : ALB, NLB, HTTP, HTTPS, TCP, TLS, L4, L7, 정적 IP, Path Routing, WAF, OIDC, WebSocket, gRPC

이번 포스팅은 AWS에서 HTTP/HTTPS 기반의 웹 서비스를 구성할 때, Application Load Balancer(이하 ALB) 와 Network Load Balancer(이하 NLB) 중 어떤 로드 밸런서로 선택할지에 대한 기준에 대해서 알아봅니다. 

일반적으로 웹 서비스라고 하면 ALB를 먼저 떠올리게 되지만, HTTP나 HTTPS를 사용한다고 해서 반드시 ALB만 선택해야 하는 것은 아닙니다. NLB 역시 TCP와 TLS 리스너를 통해 80/443 기반 서비스의 앞단에 배치할 수 있기 때문에, 실제 선택 기준은 “웹 서비스냐 아니냐”보다 어느 계층에서 어떤 기능을 필요로 하느냐에 더 가깝습니다.

이번 포스에서는 HTTP/HTTPS 서비스 기준으로 ALB와 NLB가 모두 후보가 될 수 있는 이유와, 실제 설계 시 어떤 기준으로 ALB와 NLB를 선택하면 좋은지 정리해보겠습니다.

HTTP/HTTPS인데도 NLB가 후보가 되는 이유

ALB는 HTTP/HTTPS 기반의 애플리케이션 트래픽을 처리하는 L7 로드 밸런서입니다.

즉, 단순히 80번이나 443번 포트로 들어오는 연결을 전달하는 것이 아니라, HTTP 요청 자체를 이해하고 제어하는 로드 밸런서라고 볼 수 있습니다. Path, Host Header, Query String, Header 값 등을 기준으로 요청을 분기할 수 있고, 웹 서비스에 필요한 다양한 기능들도 함께 제공합니다.

반면 NLB는 TCP, TLS, UDP 등의 트래픽을 처리하는 L4 로드 밸런서입니다.

HTTP/HTTPS 서비스라고 하더라도, 결국 네트워크 관점에서는 TCP 80, TCP 443 기반 통신이 이루어지기 때문에 NLB를 앞단에 두는 것도 가능합니다.

특히 NLB는 TLS 리스너를 통해 앞단에서 TLS를 종료할 수도 있고, TCP 443 리스너를 사용해 TLS를 백엔드까지 그대로 전달하는 패스스루 구성도 가능합니다.

즉, HTTP/HTTPS를 사용한다는 사실만으로 ALB가 자동으로 선택되는 것은 아닙니다.

실제 기준은 로드 밸런서가 HTTP 요청을 이해하고 제어해야 하는지, 아니면 TCP/TLS 연결을 안정적으로 전달하면 충분한지에 따라 달라집니다.

 

HTTP/HTTPS에서 ALB가 더 적합한 경우

HTTP/HTTPS 서비스에서 웹 요청 자체를 기준으로 분기하거나 제어해야 한다면 ALB가 더 적합합니다.

대표적인 예가 Path 기반 라우팅이나 Host 기반 라우팅입니다.

예를 들어 하나의 도메인으로 들어오는 요청에 대해 /api 는 API 서버로, /admin 은 관리자 서버로, /app 은 일반 웹 서비스 서버로 전달해야 하는 경우가 있습니다. 이러한 구조는 HTTP 요청 내용을 이해할 수 있어야 가능하며, 이 경우에는 ALB가 자연스러운 선택이 됩니다.

또한 웹 서비스 운영에 필요한 기능을 로드 밸런서 단에서 처리하고 싶은 경우에도 ALB가 잘 맞습니다.'

AWS WAF를 통해 웹 공격을 방어하거나, OIDC 또는 Cognito 기반 인증을 앞단에서 적용하거나, 리다이렉트와 같은 웹 서비스 제어 기능을 로드 밸런서에서 수행하려는 경우가 이에 해당합니다.

즉, ALB는 단순히 트래픽을 분산하는 장비가 아니라, 웹 서비스의 정책과 흐름을 제어하는 지점으로 활용할 수 있습니다.

WebSocket, HTTP/2, gRPC와 같은 웹 애플리케이션 중심 기능이 필요한 경우도 ALB가 더 적합합니다.

따라서 일반적인 웹 포털, API 서비스, 관리자 페이지, 마이크로서비스 프론트엔드와 같은 구조에서는 보통 ALB를 기본 선택지로 검토하는 것이 좋습니다.

운영 관점에서도 ALB는 HTTP/HTTPS 서비스에 유리한 점이 있습니다.

Access Log를 통해 요청 경로, 응답 코드, 처리 시간 등 웹 요청 단위의 정보를 확인할 수 있기 때문에, 서비스 분석이나 장애 분석에도 더 적합합니다.

정리하면, ALB는 다음과 같은 경우에 선택하는 것이 좋습니다.

  • Path 기반, Host 기반 등 HTTP 요청 내용을 기준으로 라우팅이 필요한 경우
  • WAF, 인증, 리다이렉트 등 웹 서비스 기능을 로드 밸런서에서 처리하고 싶은 경우
  • WebSocket, HTTP/2, gRPC 등 웹 애플리케이션 중심 기능이 필요한 경우
  • 요청 경로, 응답 코드, 처리 시간 등 웹 요청 단위의 로그 분석이 필요한 경우

 

HTTP/HTTPS에서 NLB가 더 적합한 경우

HTTP/HTTPS 서비스라고 하더라도, 웹 요청 자체보다 네트워크 연결 특성이 더 중요하다면 NLB가 더 적합합니다.

대표적인 예가 고정 IP가 필요한 경우입니다.

인터넷형 NLB는 Availability Zone별로 Elastic IP를 연결할 수 있기 때문에, 외부 기관이나 파트너사 방화벽에서 특정 IP 주소만 허용해야 하는 환경에서 매우 유리합니다.

이처럼 외부 연동 정책이 도메인 기반이 아니라 IP 기반으로 이루어지는 경우에는 NLB가 더 직접적인 해결책이 됩니다.

또 다른 경우는 TLS를 백엔드까지 그대로 전달해야 하는 경우입니다.

예를 들어 애플리케이션 서버가 직접 인증서를 가지고 있어야 하거나, TLS 세션을 백엔드 서버에서 직접 종료해야 하는 구조라면 NLB의 TCP 443 패스스루 방식이 적합합니다.

이 경우 로드 밸런서는 TLS를 해제하지 않고 연결만 전달하며, 실제 TLS 종료는 백엔드 애플리케이션 또는 서버가 수행하게 됩니다.

또한 원본 클라이언트 IP를 직접 활용해야 하는 경우에도 NLB가 유리할 수 있습니다.

접근 제어, 감사 로그, 방화벽 정책, 애플리케이션 로그 등에서 원본 IP를 매우 중요하게 보는 환경에서는, 웹 서비스라고 하더라도 NLB가 더 적절한 선택이 될 수 있습니다.

즉, HTTP/HTTPS 서비스이긴 하지만 실제 핵심 요구사항이 웹 계층 기능보다는 정적 IP, TLS 패스스루, 네트워크 계층 정보 활용, 외부 화이트리스트 대응에 있다면 NLB를 선택하는 것이 더 적합합니다.

정리하면, NLB는 다음과 같은 경우에 선택하는 것이 좋습니다.

  • 고정 IP가 필요한 경우
  • 외부 방화벽에서 IP 기반으로만 접근 허용이 가능한 경우
  • TLS를 로드 밸런서에서 해제하지 않고 백엔드까지 그대로 전달해야 하는 경우
  • 원본 클라이언트 IP를 직접 활용해야 하는 경우
  • 웹 서비스이지만 실제 요구사항이 L7 제어보다 L4 연결 전달에 더 가까운 경우

 

HTTP/HTTPS에서 ALB와 NLB를 함께 사용하는 경우

경우에 따라서는 ALB와 NLB 중 하나만으로 요구사항을 모두 만족시키기 어려울 수도 있습니다.

대표적인 예는 외부에서는 고정 IP로 접근해야 하지만, 내부적으로는 Path 기반 라우팅 같은 L7 기능도 필요한 경우입니다.

이 경우 NLB를 앞단에 두고, NLB의 Target으로 ALB를 연결하는 방식으로 구성할 수 있습니다.

즉, 외부에서는 NLB의 고정 IP 주소를 통해 접근하고, 실제 HTTP 요청에 대한 경로 분기나 웹 서비스 기능은 ALB가 처리하는 구조입니다.

이러한 방식은 정적 IP와 L7 기능을 동시에 만족시켜야 하는 환경에서 유용합니다.

다만 로드 밸런서가 2단 구조로 구성되므로 설계와 운영이 단순하지는 않습니다.

따라서 일반적인 웹 서비스에서는 우선 ALB 단독 구성을 검토하고, 정적 IP와 같은 명확한 요구사항이 있을 때만 NLB+ALB 조합을 예외적으로 고려하는 것이 좋습니다.

 

HTTP/HTTPS 서비스 선택 기준 정리

구분 ALB NLB
선택 기준의 핵심 웹 요청 자체를 이해하고 제어해야 하는 경우 연결 자체를 안정적으로 전달하면 되는 경우
적합한 요구사항 경로(Path), 도메인(Host), 헤더(Header), 인증, 보안 정책, 리다이렉트, 요청 로그 분석 등이 중요한 경우 정적 IP, TLS 패스스루, 외부 화이트리스트, 원본 IP 활용 등 네트워크 계층 특성이 중요한 경우
로드 밸런서의 역할 웹 요청을 이해하고 제어하는 로드 밸런서 연결을 안정적으로 전달하는 로드 밸런서
한 줄 정리 웹 계층(L7)의 제어가 필요하면 ALB 네트워크 계층(L4)의 전달 특성이 중요하면 NLB

 

마무리

HTTP나 HTTPS를 사용한다고 해서 무조건 ALB를 선택해야 하는 것은 아닙니다.

실제로는 서비스가 어떤 방식으로 동작해야 하는지, 인증과 보안을 어디에서 처리할 것인지, 정적 IP가 필요한지, TLS를 어디에서 종료할 것인지에 따라 선택 기준이 달라집니다.

따라서 웹 서비스 설계 시에는 단순히 “웹 서비스니까 ALB” 혹은 “고정 IP가 필요하니까 NLB”처럼 결정하기보다,
서비스 요구사항이 L7 중심인지, L4 중심인지 먼저 구분해서 보는 것이 중요합니다.

저작자표시 비영리 변경금지 (새창열림)