본문 바로가기

직접 만든 소프트웨어, 두 가지 개발 기록

구현 구조와 적용 범위, 확인한 기능과 남은 한계를 함께 기록합니다.

소프트웨어개발

ALB와 NLB 선택: HTTP 경로 분기·고정 IP·TLS 종료 위치부터 확인

by 아빠띠띠뽀 2026. 10. 18.

 

주소별 요청 분기와 일정한 연결 전달을 대비한 로드 밸런서 개념 그림
직접 생성한 개념 이미지입니다. 실제 서비스 화면이나 구축·성능 시험 결과가 아닙니다.

호스트·URL 경로에 따라 웹 요청을 나누려면 ALB를, TCP 연결이나 가용 영역별 고정 IP 요구가 중심이면 NLB를 먼저 검토하세요. 둘 다 TLS와 관련된 구성이 가능하므로 “HTTPS면 ALB, 나머지는 NLB”만으로 결정하지 말고 인증서가 어디에서 끝나야 하는지까지 적어야 합니다.

선택을 헷갈리게 하는 원인: 연결 조건과 HTTP 조건을 섞는 것

클라이언트가 요구하는 주소·포트와 애플리케이션이 요구하는 라우팅은 다른 항목입니다. 같은 443 포트를 사용하더라도 암호화된 연결을 서버까지 전달해야 하는 서비스와, 중간에서 HTTP 요청을 읽어 여러 API로 나눠야 하는 서비스의 설계는 달라집니다. 제품 이름을 먼저 정하면 인증서 관리와 방화벽 허용 목록을 뒤늦게 바꾸게 될 수 있습니다.

요구 우선 검토 확인할 조건
호스트·경로 분기 ALB HTTP 요청 규칙
TCP·고정 주소 NLB 프로토콜·가용 영역별 IP
고정 주소+HTTP 분기 NLB와 ALB 조합 추가 비용·대상 조건
TLS 종단 간 전달 연결 전달 경로 서버 인증서·분기 한계

1. 실제 이용자의 접속 요구를 네 줄로 정리한다

먼저 요청 프로토콜, HTTP 호스트·경로별 분기 여부, 고객 측 IP 허용 목록 요구, TLS 종료 위치를 적습니다. 예를 들어 api.example의 /orders와 /files를 다른 대상 그룹으로 보내는 웹 API라면 HTTP 내용을 보는 분기가 필요합니다. 반대로 특정 TCP 포트의 연결을 그대로 중계하고 고객 장비가 고정 주소만 허용한다면 주소와 연결 요구가 우선입니다. 이 예시는 판단 방법을 보여주는 가상 요구사항이며 실제 구축 사례가 아닙니다.

“고정 IP가 필요하다”는 요청도 다시 확인하세요. 고객이 도메인 기반 허용 규칙을 쓸 수 있는지, 가용 영역마다 다른 주소를 모두 등록할 수 있는지, 장애 시 목적지가 바뀌어도 되는지에 따라 요구가 달라집니다. DNS 이름을 한 번 조회한 결과를 영구 고정 주소처럼 등록하는 방식은 제품의 주소 보장을 대신하지 못합니다.

2. TLS 종료와 애플리케이션 분기를 따로 결정한다

인증서가 로드 밸런서에 있어야 하는지 대상 서버에 있어야 하는지 보안 담당자와 확인합니다. 암호화된 바이트를 그대로 전달하는 구성에서는 앞단이 HTTP 경로를 읽을 수 없습니다. 따라서 “서버에서만 복호화”와 “앞단에서 URL별 분기”를 동시에 요구한다면 요구의 충돌부터 해소해야 합니다.

NLB와 ALB를 함께 두는 구성도 AWS가 문서화하고 있습니다. 다만 두 제품의 장점을 합친다는 말만으로 채택하면 대상 그룹·상태 검사·관찰 지점이 늘어납니다. 단일 구성으로 요구를 충족하는지 먼저 확인하고, 복합 경로는 같은 VPC 등 공식 사전조건과 비용을 검토한 뒤 선택하세요.

3. 비용 비교에는 트래픽과 운영 범위를 같은 조건으로 넣는다

제품별 단가 하나를 비교하면 결과가 달라질 수 있습니다. 동일 리전, 활성화 시간, 연결 수명, 요청량, 데이터 처리량과 전송 경로를 견적의 공통 입력으로 둡니다. 복합 구성이라면 두 로드 밸런서와 관련 전송 비용까지 포함해 확인하세요. 이 글은 실제 트래픽을 측정하지 않았으므로 특정 제품이 몇 퍼센트 싸다는 결론을 내리지 않습니다.

운영자 관점에서는 인증서 갱신 책임, 대상 상태 검사, 접근 기록, 장애 대응 담당자가 누구인지도 견적 옆에 적는 편이 좋습니다. 비용이 낮아 보여도 요구한 관찰 정보를 얻지 못하거나 전환 절차가 복잡하면 운영 부담이 달라집니다.

확인 방법: DNS 전환 전 별도 시험 경로에서 요청을 대조한다

운영 DNS를 바로 바꾸지 말고 별도 시험 호스트와 승인된 테스트 대상으로 검증합니다. HTTP 경로·호스트가 의도한 대상으로 가는지, TLS 인증서 이름·신뢰 체인이 맞는지, 허용된 클라이언트에서 연결되는지, 대상 장애를 만들었을 때 기대한 동작을 하는지를 각각 기록하세요. 상태 검사가 정상이라는 사실만으로 이용자 요청 성공을 대신하지 않습니다.

전환 시에는 기존 경로를 보존하고 되돌릴 DNS 또는 클라이언트 설정과 담당자를 정합니다. 보안 그룹을 넓히거나 TLS 검증을 끄는 임시 조치로 성공을 만들지 마세요. 문제가 나오면 실패한 계층의 설정만 수정한 뒤 같은 요청으로 비교합니다.

FAQ

고정 IP와 URL 분기가 모두 필요하면? NLB 앞단과 ALB 대상 구성을 검토할 수 있지만 요구와 비용·사전조건을 먼저 확인합니다.

NLB를 쓰면 웹 요청이 무조건 더 빨라지나요? 실제 요청 특성과 구성을 측정하지 않은 상태에서는 그렇게 보장할 수 없습니다.

HTTPS만 쓰면 ALB로 정해도 되나요? TLS가 끝나는 위치와 HTTP 분기 필요 여부까지 확인해야 합니다.

공식 출처와 관련 글

자료 확인일: 2026년 10월 17일. 공식 문서 기반 설명이며 실제 서비스·명령 실행 시험은 수행하지 않았습니다. 설치 버전과 리전·지원 범위는 적용 전에 확인하세요.

AWS Application Load Balancer 개요

AWS Network Load Balancer 개요

NLB 대상 그룹에 ALB 등록

관련 글: 관리형 ALB와 직접 운영 Nginx의 책임 범위 비교

적용 전 원본 설정을 보존하고 승인된 시험 범위에서 결과를 확인하세요.