ELB

로드 밸런싱은 ELB의 핵심 기능으로, 단일 엔드포인트로 들어오는 클라이언트의 트래픽을 여러 백엔드 대상(예: EC2 인스턴스, 컨테이너, IP 주소)에 자동으로 분배하는 작업을 의미한다. 이는 단일 서버에 과도한 부하가 집중되는 것을 방지하여 애플리케이션의 처리량, 응답 시간 및 전반적인 성능을 향상시킨다.

트래픽 분배는 사전에 정의된 라우팅 알고리즘에 따라 이루어진다. 가장 일반적인 알고리즘은 라운드 로빈으로, 요청을 대상 그룹 내 서버에 순차적으로 분배한다. 또한, 최소 미해결 요청 알고리즘은 현재 가장 적은 연결 수를 가진 대상으로 트래픽을 보내 부하를 더욱 정교하게 분산시킨다.

로드 밸런싱의 수준은 ELB의 유형에 따라 다르다. Application Load Balancer는 HTTP/HTTPS 트래픽을 기반으로 애플리케이션 계층(OSI 7계층)에서 동작하며, 요청의 내용(예: URL 경로, 호스트 헤더)에 따라 다른 대상 그룹으로 라우팅할 수 있다. 반면, Network Load Balancer는 초고성능과 초저지연 시간이 요구되는 경우에 사용되며, TCP/UDP 트래픽을 전송 계층(OSI 4계층)에서 분산한다.

이러한 분산 메커니즘은 애플리케이션의 확장성과 내구성을 보장한다. 트래픽이 증가하면 Auto Scaling 그룹과 연동하여 새로운 대상을 자동으로 추가하고 부하를 분산할 수 있으며, 특정 대상이 장애 상태가 되면 해당 대상으로의 트래픽 전송을 중지하여 사용자에게 지속적인 서비스를 제공한다.

ELB는 단일 장애 지점을 제거하여 애플리케이션의 가용성을 극대화하도록 설계되었다. 이를 위해 ELB는 기본적으로 여러 가용 영역에 걸쳐 배포된다. 사용자는 ELB를 생성할 때 두 개 이상의 가용 영역을 지정하며, ELB는 지정된 각 가용 영역에 로드 밸런서 노드를 자동으로 프로비저닝한다. 이 노드들은 트래픽을 수신하고 라우팅하는 역할을 담당한다.

하나의 가용 영역에 장애가 발생하더라도 ELB 서비스는 다른 정상적인 가용 영역의 노드를 통해 트래픽을 계속 라우팅한다. 이는 애플리케이션의 다운타임을 방지하는 핵심 메커니즘이다. 또한, ELB 뒤에 배치된 대상 그룹의 인스턴스들도 여러 가용 영역에 분산 배치하는 것이 권장된다. 이렇게 하면 특정 가용 영역의 인스턴스 그룹 전체에 문제가 생겨도, ELB가 자동으로 건강한 인스턴스가 있는 다른 가용 영역으로 트래픽을 전환한다.

ELB의 내결함성은 상태 확인 기능과 밀접하게 연동되어 작동한다. ELB는 정기적으로 등록된 대상(예: EC2 인스턴스, IP 주소, 람다 함수)의 건강 상태를 모니터링한다. 상태 확인에 실패한 대상으로는 새로운 연결을 라우팅하지 않으며, 기존 연결도 종료된다[1]. 이 자동 감지 및 제거 메커니즘은 최종 사용자에게는 투명하게 작동하며, 장애가 발생한 백엔드 리소스로 인한 서비스 중단을 효과적으로 방지한다.

상태 확인은 ELB가 백엔드에 등록된 대상(예: EC2 인스턴스, IP 주소, 컨테이너)의 건강 상태를 주기적으로 점검하는 프로세스이다. 이를 통해 ELB는 정상적으로 요청을 처리할 수 있는 대상에게만 트래픽을 라우팅하고, 비정상적인 대상은 라우팅 대상에서 자동으로 제외한다. 이 기능은 애플리케이션의 전반적인 가용성과 신뢰성을 유지하는 데 핵심적인 역할을 한다.

상태 확인은 사용자가 정의한 프로토콜(HTTP, HTTPS, TCP), 포트, 경로를 기반으로 수행된다. 예를 들어, 웹 서버 대상 그룹의 경우 ELB는 정해진 간격(예: 30초)으로 지정된 경로(예: /health)에 HTTP GET 요청을 보낸다. 서버가 미리 정의된 성공 코드(예: HTTP 200)를 반환하면 해당 대상은 'healthy' 상태로 판단된다. 반대로, 연속적인 실패 횟수 임계값을 초과하면 대상은 'unhealthy' 상태가 되어 트래픽 수신이 중단된다.

상태 확인의 주요 구성 요소는 다음과 같다.

효과적인 상태 확인 경로를 구성하는 것은 중요하다. 이 경로는 애플리케이션의 핵심 종속성(예: 데이터베이스 연결, 캐시 서버 상태)을 점검하는 간단한 엔드포인트여야 한다. 단순히 웹 서버 프로세스만 확인하는 것이 아니라, 애플리케이션이 실제로 요청을 처리할 수 있는지 검증해야 한다. 잘 설계된 상태 확인은 장애를 가진 인스턴스로 인한 사용자 경험 저하를 사전에 방지하고, Auto Scaling 그룹과 연동되어 비정상 인스턴스를 자동으로 교체하는 트리거 역할도 한다.

SSL/TLS 종료는 ELB가 클라이언트와의 암호화된 HTTPS 연결을 수신한 후, 로드 밸런서 단계에서 암호화를 해제하는 기능이다. 이 과정을 통해 백엔드 인스턴스는 복호화된 일반 HTTP 트래픽을 처리하게 된다. 이는 애플리케이션 서버의 CPU 부하를 크게 줄여주는 핵심적인 역할을 한다. SSL/TLS 암호화 및 복호화는 계산 집약적인 작업이므로, 이를 ELB에 위임함으로써 백엔드 서버는 순수한 비즈니스 로직 처리에 자원을 집중할 수 있다.

이 기능을 구성하기 위해 사용자는 ELB에 SSL 인증서를 업로드해야 한다. AWS Certificate Manager (ACM)를 사용하면 무료로 공인 인증서를 발급받고 자동으로 갱신 관리할 수 있어 편리하다. 인증서가 적용되면, ELB의 리스너는 지정된 포트(예: 443)에서 HTTPS 연결을 수락하고, 사전에 정의된 정책에 따라 암호화 스위트와 프로토콜 버전을 협상한다.

SSL/TLS 종료는 보안 아키텍처에도 영향을 미친다. ELB와 백엔드 인스턴스 간의 트래픽은 암호화되지 않은 상태로 전송될 수 있으므로, 이 구간을 사설 서브넷에 배치하거나 VPC 내부 트래픽에 대한 추가 암호화를 고려해야 한다. 또한, Application Load Balancer (ALB)는 종료된 트래픽의 헤더에 X-Forwarded-Proto 같은 정보를 추가하여 백엔드 애플리케이션이 원래 연결이 보안되었는지 판단할 수 있게 한다.

Application Load Balancer는 OSI 모델의 7계층(애플리케이션 계층)에서 동작하는 로드 밸런서이다. HTTP와 HTTPS 트래픽을 처리하도록 설계되었으며, 요청의 내용(예: URL 경로, 호스트 헤더, HTTP 헤더)을 기반으로 라우팅 결정을 내릴 수 있다. 이는 마이크로서비스나 컨테이너 기반 애플리케이션에서 특정 서비스로 트래픽을 유연하게 분산시키는 데 적합하다.

ALB의 핵심 구성 요소는 리스너와 대상 그룹이다. 리스너는 지정된 프로토콜과 포트로 연결 요청을 확인하며, 사전 정의된 라우팅 규칙에 따라 요청을 적절한 대상 그룹으로 전달한다. 라우팅 규칙은 다음과 같은 조건을 기반으로 구성할 수 있다.

ALB는 웹소켓 및 HTTP/2와 같은 최신 프로토콜을 기본적으로 지원한다. 또한 SSL/TLS 종료 기능을 제공하여 백엔드 인스턴스의 암호화/복호화 부하를 줄여준다. 내장된 상태 확인 기능은 등록된 대상(예: EC2 인스턴스, IP 주소, 람다 함수)의 건강 상태를 주기적으로 점검하여 비정상 대상으로의 트래픽 전송을 방지한다.

ALB는 컨테이너 오케스트레이션 서비스인 Amazon ECS 및 Amazon EKS와의 통합이 원활하다. 이를 통해 동적으로 변경되는 컨테이너 환경에서 서비스 디스커버리와 로드 밸런싱을 효과적으로 관리할 수 있다. 또한 AWS WAF(웹 애플리케이션 방화벽)와 통합되어 일반적인 웹 공격으로부터 애플리케이션을 보호하는 기능도 제공한다[3].

Network Load Balancer는 OSI 모델의 4계층(전송 계층)에서 동작하는 로드 밸런서이다. TCP, UDP, TLS 트래픽을 처리하도록 설계되었으며, 초당 수백만 건의 요청을 처리할 수 있는 극도로 높은 처리량과 초저 지연 시간을 제공하는 것이 특징이다. 연결 수준에서 트래픽을 라우팅하며, 패킷의 내용을 검사하지 않고 소스 IP 주소와 포트, 대상 IP 주소와 포트, 프로토콜과 같은 정보를 기반으로 라우팅 결정을 내린다.

NLB는 하나의 정적 IP 주소를 각 가용 영역에 할당받으며, 탄력적 IP 주소를 연결할 수도 있다. 이는 클라이언트 IP 주소를 보존하는 기능과 결합되어, 백엔드 애플리케이션이 연결 클라이언트의 실제 소스 IP를 확인할 수 있게 한다. 이러한 특성은 IP 화이트리싱이 필요한 애플리케이션, 게임 서버, IoT 디바이스 통신, 그리고 초고성능이 요구되는 금융 거래 시스템에 적합하다.

주요 구성 요소와 특징은 다음과 같다.

NLB는 Zonal Isolation 아키텍처를 채택하여, 한 가용 영역의 실패가 다른 영역의 성능에 영향을 미치지 않도록 설계되었다. 또한 AWS PrivateLink 서비스의 기반이 되어, VPC 내부에서 AWS 서비스 및 타사 서비스에 비공개로 안전하게 접근할 수 있는 기능을 제공한다[4].

Gateway Load Balancer는 AWS에서 제공하는 ELB 유형 중 하나로, 3계층과 4계층에서 동작하며 가상 어플라이언스의 배포, 확장 및 관리에 특화되어 있다. 주로 방화벽, 침입 탐지 시스템, 침입 방지 시스템과 같은 보안 가상 어플라이언스의 트래픽을 투명하게 분산시키는 데 사용된다.

GWLB의 핵심 구성 요소는 GENEVE 프로토콜을 사용하는 Gateway Load Balancer 엔드포인트이다. 이 엔드포인트는 VPC의 트래픽을 가로채어 등록된 가상 어플라이언스 인스턴스로 라우팅한 후, 검사 및 처리가 완료된 트래픽을 원래 목적지로 다시 전송한다. 이를 통해 애플리케이션의 아키텍처나 클라이언트 구성을 변경하지 않고도 네트워크 트래픽에 대한 보안 검사를 쉽게 삽입할 수 있다.

GWLB는 주로 다음과 같은 사용 사례에 적합하다.

이러한 설계로 인해 GWLB는 하이브리드 클라우드 환경이나 복잡한 규정 준수 요구사항이 있는 조직에서 중앙 집중식 네트워크 보안 검사를 구현하는 데 유용한 도구가 된다.

Classic Load Balancer는 AWS에서 가장 먼저 출시된 로드 밸런서 유형이다. 이는 OSI 모델의 4계층(전송 계층)과 7계층(응용 계층)에서 동작하며, TCP/SSL 트래픽과 HTTP/HTTPS 트래픽을 모두 처리할 수 있다. 주로 EC2 인스턴스와 같은 대상으로 트래픽을 분산시키는 데 사용되었으나, 현재는 보다 세분화된 기능을 제공하는 Application Load Balancer와 Network Load Balancer로 대체되는 추세이다.

주요 기능으로는 연결 기반의 로드 밸런싱, 상태 확인, SSL/TLS 종료 등이 있다. 라우팅 알고리즘으로는 라운드 로빈 방식을 기본으로 사용한다. 또한 고정 세션 기능을 통해 특정 클라이언트의 요청을 항상 동일한 백엔드 인스턴스로 라우팅할 수 있다.

새로운 애플리케이션을 구축할 때는 ALB나 NLB를 사용하는 것이 권장된다. 그러나 기존에 Classic Load Balancer를 사용하던 레거시 애플리케이션을 운영 중이거나, EC2-Classic 네트워크에서 애플리케이션을 실행하는 경우에는 여전히 필요하다.

리스너는 ELB가 클라이언트의 연결 요청을 검사하는 구성 요소이다. 리스너는 지정된 프로토콜과 포트를 사용하여 연결 요청을 대기하며, 사전에 정의된 규칙에 따라 수신된 트래픽을 적절한 대상 그룹으로 전달하는 역할을 한다.

리스너를 구성할 때는 프로토콜, 포트, 그리고 트래픽을 라우팅할 대상 그룹을 필수적으로 지정해야 한다. 사용 가능한 프로토콜은 선택한 ELB 유형에 따라 달라진다. 예를 들어, Application Load Balancer는 HTTP와 HTTPS 프로토콜을, Network Load Balancer는 TCP, TLS, UDP 프로토콜을 주로 사용한다. HTTPS 또는 TLS 리스너를 구성하는 경우, SSL/TLS 암호화를 처리하기 위해 SSL/TLS 인증서를 리스너에 연결해야 한다.

리스너 규칙은 ALB에서 트래픽 라우팅을 세부적으로 제어하는 데 사용된다. 각 규칙은 우선순위, 하나 이상의 조건, 그리고 하나 이상의 동작으로 구성된다. 조건은 들어오는 요청의 패턴(예: 호스트 헤더, 경로 패턴, HTTP 헤더, 쿼리 문자열 등)을 평가하는 데 사용된다. 조건이 일치하면 정의된 동작(예: 특정 대상 그룹으로 포워딩, 고정 응답 반환, 인증 요구 등)이 실행된다. 규칙은 우선순위 순서대로 평가되며, 첫 번째로 일치하는 규칙의 동작이 적용된다.

이러한 리스너 구성은 ELB가 다양한 애플리케이션 요구사항에 따라 유연하게 트래픽을 분배하고, SSL/TLS 종료와 같은 기능을 효율적으로 수행할 수 있는 기반을 제공한다.

대상 그룹은 ELB가 트래픽을 전달할 실제 컴퓨팅 리소스의 논리적 집합을 가리킨다. ELB는 하나 이상의 대상 그룹에 연결되며, 리스너 규칙에 따라 트래픽을 적절한 대상 그룹으로 라우팅한다. 각 대상 그룹은 동일한 애플리케이션을 실행하는 하나 이상의 대상(예: EC2 인스턴스, IP 주소, 람다 함수, 컨테이너)으로 구성된다. 대상 그룹의 구성은 사용 중인 ELB 유형에 따라 달라진다.

주요 대상 유형은 다음과 같다.

ELB는 대상 그룹에 등록된 각 대상의 상태를 주기적으로 확인한다. 상태 확인은 구성된 프로토콜과 경로를 사용하여 대상의 응답 가능 여부를 판단한다. 상태 확인에 실패한 대상은 라우팅 대상에서 자동으로 제외되어 트래픽을 받지 않으며, 다시 정상 상태로 돌아오면 트래픽 수신이 자동으로 재개된다. 이는 애플리케이션의 전반적인 내결함성을 높이는 데 기여한다.

ELB는 트래픽을 백엔드 대상(예: EC2 인스턴스, 컨테이너, IP 주소)으로 분배할 때 사용하는 라우팅 알고리즘을 제공합니다. 기본적으로는 라운드 로빈 알고리즘이 사용되지만, Application Load Balancer와 Network Load Balancer는 각각의 유형에 맞춘 추가 알고리즘을 지원합니다.

Application Load Balancer (ALB)의 라우팅 알고리즘

ALB는 주로 7계층(응용 계층)에서 동작하며, HTTP/HTTPS 요청의 내용을 기반으로 지능적인 라우팅이 가능합니다. 기본 알고리즘은 다음과 같습니다.

* 라운드 로빈 (Round Robin): 요청을 등록된 대상 그룹 내의 대상들에 순차적으로 분배합니다. 모든 대상의 처리 능력이 동일할 때 효과적입니다.

* 최소 미해결 요청 (Least Outstanding Requests): 현재 처리 중인 요청(미해결 요청)의 수가 가장 적은 대상으로 새 요청을 라우팅합니다. 이는 대상 인스턴스의 부하 상태를 실시간으로 반영하여 처리 시간이 긴 요청이 있을 때 유리합니다.

Network Load Balancer (NLB)의 라우팅 알고리즘

NLB는 4계층(전송 계층)에서 동작하며, 초당 수백만 개의 요청을 처리하는 데 최적화되어 있습니다. TCP, UDP, TLS 트래픽을 처리하며, 사용 가능한 알고리즘은 다음과 같습니다.

* 라운드 로빈 (Round Robin): TCP/UDP 연결 또는 패킷을 대상들에 순차적으로 분배합니다.

* 최소 미해결 요청 (Least Outstanding Requests): 활성 TCP 연결 수가 가장 적은 대상으로 새 연결을 라우팅합니다. 이는 ALB의 동일한 알고리즘과 유사하지만, TCP 연결 수준에서 동작합니다.

* 해시 기반 (5-튜플 해시): 패킷의 5가지 요소(소스 IP, 소스 포트, 대상 IP, 대상 포트, 프로토콜)를 기반으로 해시 값을 계산하여 특정 대상으로 트래픽을 고정시킵니다. 이를 통해 하나의 클라이언트 세션의 모든 패킷이 동일한 대상으로 전송되어 세션 지속성이 보장됩니다[5].

사용자는 대상 그룹을 생성할 때 원하는 라우팅 알고리즘을 선택합니다. 선택은 애플리케이션의 특성(연결 지속성 필요 여부, 요청 처리 시간의 편차 등)과 성능 목표에 따라 결정됩니다.

ELB는 웹 애플리케이션을 호스팅하는 가장 일반적인 시나리오에서 핵심적인 역할을 수행한다. 주로 Application Load Balancer가 이 사용 사례에 적합하며, HTTP 및 HTTPS 트래픽을 웹 서버 인스턴스 그룹에 지능적으로 분산시킨다. 사용자 요청은 ELB의 단일 DNS 엔드포인트로 전달되며, 로드 밸런서는 사전에 정의된 라우팅 규칙에 따라 하나 이상의 가용 영역에 배치된 백엔드 Amazon EC2 인스턴스, 컨테이너 또는 IP 주소로 트래픽을 전달한다.

이 구성은 웹 애플리케이션의 확장성과 내구성을 크게 향상시킨다. 트래픽 증가에 따라 Auto Scaling 그룹과 연동하여 백엔드 인스턴스를 자동으로 추가하거나 제거할 수 있다. 또한 ELB는 지속적으로 백엔드 인스턴스의 상태를 확인하여 정상적인 인스턴스로만 트래픽을 라우팅함으로써 사용자에게 지속적인 서비스를 제공한다. 한 인스턴스나 가용 영역에 장애가 발생하더라도 트래픽은 자동으로 다른 정상 리소스로 전환된다.

고급 라우팅 기능을 통해 복잡한 웹 애플리케이션 구조를 효율적으로 관리할 수 있다. ALB는 호스트 또는 경로 기반 라우팅을 지원하여, 단일 로드 밸런서 뒤에 여러 애플리케이션 또는 서비스를 배치할 수 있다. 예를 들어, api.example.com으로 들어오는 트래픽은 API 서버 그룹으로, www.example.com/static 경로의 트래픽은 정적 콘텐츠 서버 그룹으로 라우팅할 수 있다.

이러한 특성으로 인해 ELB는 전자상거래 사이트, 콘텐츠 관리 시스템, 미디어 스트리밍 플랫폼 등 다양한 형태의 웹 애플리케이션 서비스를 구축하는 데 필수적인 기반 서비스가 되었다.

ELB는 마이크로서비스 아키텍처의 핵심 인프라 구성 요소로, 서비스 간의 효율적이고 유연한 통신을 가능하게 한다. 마이크로서비스 환경에서는 수십, 수백 개의 독립적인 서비스가 네트워크를 통해 서로 통신하며, 각 서비스는 자체적인 확장 주기와 부하 패턴을 가진다. ELB는 이러한 서비스 인스턴스들 앞에 위치하여 클라이언트의 요청을 적절한 서비스 인스턴스로 분산시킨다. 특히 Application Load Balancer는 HTTP 및 HTTPS 트래픽을 기반으로 한 고급 라우팅 기능을 제공하여, 요청의 경로(Path)나 호스트 헤더(Host Header)를 분석해 특정 마이크로서비스로 라우팅할 수 있다. 이는 단일 로드 밸런서 뒤에 여러 서비스를 배치하고, 요청의 내용에 따라 서로 다른 대상 그룹으로 전달하는 패턴을 구현하는 데 필수적이다.

ELB는 서비스 디스커버리(Service Discovery)와 서비스 간 부하 분산을 단순화한다. 새로운 서비스 인스턴스가 Auto Scaling 그룹이나 Amazon ECS 클러스터에서 시작되면, ELB의 대상 그룹에 자동으로 등록되어 트래픽 수신을 시작한다. 반대로 인스턴스가 종료되면 대상 그룹에서 제거되어 트래픽을 받지 않는다. 이 동적 등록 및 등록 취소 메커니즘은 마이크로서비스의 탄력적 확장과 장애 복구를 뒷받침한다. 또한, ELB의 상태 확인 기능은 비정상적인 서비스 인스턴스를 실시간으로 탐지하고 라우팅 대상에서 제외함으로써 시스템 전체의 견고성을 높인다.

마이크로서비스 간의 내부 통신에도 ELB를 활용할 수 있다. Network Load Balancer는 초고성능과 초저지연 시간이 요구되는 서비스 간 TCP/UDP 트래픽의 로드 밸런싱에 적합하다. 한편, 외부 API 게이트웨이 뒤에 ALB를 배치하여 내부 서비스에 대한 세분화된 라우팅 정책을 구성하는 아키텍처도 일반적이다. 이는 각 마이크로서비스가 독립적인 배포와 확장을 유지하면서도, 외부에 일관된 엔드포인트를 제공할 수 있게 한다. 결과적으로 ELB는 마이크로서비스 시스템이 복잡성을 관리하면서도 가용성, 확장성, 내결함성이라는 핵심 이점을 실현하도록 돕는 기반 서비스이다.

ELB는 AWS 클라우드 환경 내의 서비스뿐만 아니라, 온프레미스 데이터 센터나 다른 퍼블릭 클라우드에 위치한 애플리케이션으로의 트래픽을 분산시키는 하이브리드 및 멀티 클라우드 아키텍처를 구성하는 데 핵심적인 역할을 합니다. 이를 통해 기존 인프라를 유지하면서 클라우드의 확장성과 유연성을 점진적으로 도입하거나, 여러 클라우드 공급자의 서비스를 통합적으로 활용할 수 있습니다.

특히 Network Load Balancer는 이 시나리오에서 중요한 구성 요소입니다. NLB는 TCP, UDP, TLS 트래픽을 로드 밸런싱하며, 하나의 정적 IP 주소를 제공합니다. 이 IP 주소는 AWS PrivateLink를 통해 생성된 VPC 엔드포인트 서비스에 연결될 수 있습니다. 온프레미스 환경은 AWS Direct Connect 또는 VPN 터널을 통해 Amazon VPC에 연결한 후, 이 NLB의 고정 IP를 대상으로 트래픽을 전송할 수 있습니다. NLB는 그 트래픽을 사전에 정의된 대상 그룹으로 전달하며, 이 대상 그룹에는 AWS 내의 Amazon EC2 인스턴스나 컨테이너는 물론, VPC 피어링 연결을 통한 다른 VPC의 리소스 또는 하이브리드 클라우드 연결을 통해 등록된 온프레미스 서버(IP 주소 형태)가 포함될 수 있습니다[6].

이러한 아키텍처는 다음과 같은 주요 사용 사례를 가능하게 합니다.

결과적으로 ELB는 물리적 위치에 구애받지 않고 애플리케이션 엔드포인트를 통합된 단일 접점으로 제공함으로써, 복잡한 하이브리드 및 멀티 클라우드 환경에서도 일관된 트래픽 관리와 고가용성을 실현하는 인프라의 관문 역할을 수행합니다.

ELB의 보안을 강화하기 위해 AWS는 네트워크 수준의 방어 메커니즘으로 보안 그룹과 네트워크 ACL을 제공한다. 이 두 요소는 서로 다른 계층에서 작동하며, 함께 사용될 때 효과적인 방어 체계를 구성한다.

보안 그룹은 ELB 및 백엔드 인스턴스에 연결되는 가상 방화벽 역할을 한다. 이는 상태 저장(stateful) 규칙을 적용하여, 허용된 인바운드 트래픽에 대한 아웃바운드 응답을 자동으로 허용한다. 일반적으로 ELB의 보안 그룹은 클라이언트로부터의 특정 포트(예: HTTP용 80, HTTPS용 443)로의 인바운드 트래픽만 허용하도록 구성된다. 반대로, ELB에서 백엔드 인스턴스로의 트래픽을 허용하기 위해서는 백엔드 인스턴스의 보안 그룹에서 ELB의 보안 그룹을 소스로 지정하는 규칙이 필요하다.

네트워크 ACL은 서브넷에 대한 추가적인 보안 계층으로, 상태 비저장(stateless) 패킷 필터링을 수행한다. ELB가 위치한 퍼블릭 서브넷과 백엔드 인스턴스가 위치한 프라이빗 서브넷 각각에 대해 별도의 네트워크 ACL 규칙을 정의할 수 있다. 이는 특정 IP 주소 범위로부터의 비정상적 접근을 차단하는 데 유용하다. 네트워크 ACL 규칙은 번호 순으로 평가되며, 인바운드와 아웃바운드 트래픽에 대한 규칙을 별도로 정의해야 한다는 점이 보안 그룹과 다르다.

AWS WAF는 웹 애플리케이션 방화벽으로, 일반적인 웹 취약점으로부터 애플리케이션을 보호합니다. Application Load Balancer 및 CloudFront와 통합되어, 애플리케이션 계층(OSI 7계층의 7계층)에서 들어오는 트래픽을 실시간으로 검사하고 필터링합니다.

ELB와 WAF 통합의 주요 보호 기능은 다음과 같습니다.

관리자는 AWS 관리형 규칙 집합을 쉽게 활성화하거나, 특정 애플리케이션 요구 사항에 맞춰 자체 규칙을 작성할 수 있습니다. WAF는 ALB 앞에 배치되어, 규칙에 따라 허용된 트래픽만 로드 밸런서를 통해 백엔드 대상으로 전달됩니다. 이 구성은 애플리케이션 로직을 변경하지 않고도 중앙에서 웹 보안 정책을 적용하고 관리할 수 있게 합니다.

ELB는 SSL/TLS 암호화 트래픽을 처리하기 위해 공개 키 인증서를 필요로 한다. 사용자는 AWS Certificate Manager를 통해 무료로 발급받은 ACM 인증서를 로드 밸런서에 쉽게 연결할 수 있다. ACM을 사용하면 인증서의 갱신 주기를 자동으로 관리할 수 있어, 만료로 인한 서비스 중단 위험을 줄인다.

또는 사용자가 자체적으로 구매하거나 내부 인증 기관에서 발급한 인증서를 AWS Identity and Access Management 서비스를 통해 업로드하여 사용할 수도 있다. 이 경우 인증서의 유효 기간을 직접 모니터링하고 수동으로 갱신 및 교체해야 하는 관리 부담이 발생한다.

인증서 관리는 보안 정책의 핵심 요소이다. ELB는 전송 계층 보안 프로토콜의 최신 버전을 지원하며, 보안 수준이 낮은 오래된 프로토콜과 암호화 제품군을 비활성화하는 정책을 구성할 수 있다. 이를 통해 Man-in-the-Middle 공격과 같은 보안 위협으로부터 애플리케이션을 보호한다.

ELB는 Amazon CloudWatch와 긴밀하게 통합되어 다양한 성능 지표를 실시간으로 제공한다. 이러한 지표는 로드 밸런서와 등록된 대상의 상태, 트래픽 패턴, 성능 문제를 모니터링하고 경고를 설정하는 데 핵심적이다. 지표는 ELB 유형별로 약간의 차이가 있지만, 일반적으로 HTTP/HTTPS 요청 수, 데이터 처리량, 응답 시간, 오류율 등을 포함한다.

주요 CloudWatch 지표는 다음과 같은 범주로 나눌 수 있다.

사용자는 CloudWatch 콘솔, AWS CLI, 또는 SDK를 통해 이러한 지표에 접근하고 시각화할 수 있다. 또한, 특정 지표에 대한 임계값을 설정하여 CloudWatch 알람을 생성할 수 있다. 예를 들어, HealthyHostCount가 0으로 떨어지거나 TargetResponseTime이 허용 기준을 초과할 때 운영팀에 알림을 보내는 자동화된 모니터링을 구축하는 것이 일반적이다. 이를 통해 애플리케이션의 가용성과 성능을 사전에 보장할 수 있다.

ELB의 액세스 로그는 로드 밸런서로 들어오는 각 요청에 대한 상세한 정보를 기록한 파일이다. 이 로그는 Amazon S3 버킷에 저장되며, Application Load Balancer와 Classic Load Balancer에서 활성화할 수 있다. 로그는 5분 간격으로 배치 처리되어 전송된다.

액세스 로그는 각 요청에 대해 타임스탬프, 클라이언트 IP 주소, 요청 경로, 응답 상태 코드, 백엔드 인스턴스 정보 등을 포함한 포괄적인 레코드를 제공한다. 일반적인 로그 항목의 구성 요소는 다음과 같다.

이 로그는 트래픽 패턴 분석, 이상 징후 탐지, 보안 감사 및 성능 문제 해결에 필수적이다. 예를 들어, 특정 IP에서의 비정상적 요청 빈도나 높은 지연 시간을 보이는 요청을 식별할 수 있다. 로그 분석을 위해 Amazon Athena를 사용해 S3에 저장된 로그를 직접 쿼리하거나, Amazon CloudWatch Logs Insights로 스트리밍하여 분석할 수 있다.

Auto Scaling은 AWS에서 제공하는 서비스로, 애플리케이션의 로드를 모니터링하고 용량을 자동으로 조정하여 안정적인 성능을 유지하면서 비용을 최소화합니다. 이 서비스는 ELB와 긴밀하게 통합되어 작동합니다. Auto Scaling 그룹은 동일한 애플리케이션을 실행하는 EC2 인스턴스의 모음으로, ELB의 대상 그룹에 등록되어 트래픽을 수신합니다.

Auto Scaling의 핵심은 확장 정책을 정의하는 것입니다. 사용자는 CPU 사용률, 네트워크 트래픽, CloudWatch 사용자 지정 지표 등의 조건에 따라 인스턴스 수를 자동으로 늘리거나 줄이는 정책을 설정할 수 있습니다. 예를 들어, 평균 CPU 사용률이 70%를 초과하면 2개의 인스턴스를 추가하고, 30% 미만으로 떨어지면 1개의 인스턴스를 제거하는 규칙을 구성할 수 있습니다. 이 과정에서 새로 시작된 인스턴스는 자동으로 ELB에 등록되고, 종료되는 인스턴스는 ELB에서 제거되어 서비스 무결성을 유지합니다.

ELB와 Auto Scaling의 조합은 고가용성과 탄력성을 동시에 제공합니다. ELB는 들어오는 트래픽을 정상적인 인스턴스로만 분산시키고, Auto Scaling은 인스턴스의 상태를 확인하여 비정상 인스턴스를 교체하며, 필요에 따라 전체 용량을 조정합니다. 이 아키텍처는 트래픽 급증 시 확장하여 성능을 보장하고, 트래픽이 적을 때는 축소하여 불필요한 비용을 절감하는 데 핵심적입니다.

Route 53은 AWS에서 제공하는 고가용성과 확장성이 뛰어난 DNS 웹 서비스이다. ELB와의 통합은 애플리케이션의 트래픽을 효율적으로 분산하고 고가용성을 보장하는 데 핵심적인 역할을 한다. 사용자는 Route 53에서 도메인을 구매하고 관리하며, 도메인에 대한 DNS 쿼리에 응답하도록 구성한다.

ELB와 함께 사용될 때, Route 53은 도메인 이름(예: www.example.com)을 하나 이상의 ELB의 DNS 이름으로 매핑하는 A 레코드 또는 Alias 레코드를 호스팅한다. 특히 Alias 레코드는 표준 DNS 쿼리와 달리 AWS 리소스에 직접 매핑되어 추가 비용 없이 빠른 응답과 높은 가용성을 제공한다[9]. 이를 통해 최종 사용자는 단순한 도메인 이름으로 접속하지만, 내부적으로는 ELB가 트래픽을 백엔드의 여러 대상(예: EC2 인스턴스, 컨테이너)으로 분산한다.

Route 53의 고급 라우팅 정책은 ELB의 기능을 보완하여 더 정교한 트래픽 제어를 가능하게 한다. 주요 라우팅 정책은 다음과 같다.

이러한 통합을 통해 개발자는 DNS 수준에서의 지능적인 트래픽 라우팅과 애플리케이션 수준의 로드 밸런싱을 결합하여 탄력적이고 안정적인 서비스 인프라를 구축할 수 있다.

AWS Global Accelerator는 AWS가 제공하는 글로벌 네트워킹 서비스로, ELB와 같은 애플리케이션 엔드포인트로 사용자 트래픽을 효율적으로 라우팅하도록 설계되었다. 이 서비스는 전 세계에 분산된 AWS 엣지 로케이션 네트워크를 활용하여, 사용자 요청을 가장 가용성이 높고 지연 시간이 짧은 애플리케이션 엔드포인트로 지능적으로 연결한다. 이를 통해 애플리케이션의 가용성, 성능 및 내결함성을 향상시키는 데 목적이 있다.

AWS Global Accelerator의 핵심 구성 요소는 정적 IP 주소와 애니캐스트이다. 서비스를 생성하면 두 개의 고정된 글로벌 Anycast IP 주소가 할당되며, 이 주소는 전 세계의 AWS 엣지 위치에서 광고된다. 사용자의 DNS 쿼리는 지리적으로 가장 가까운 엣지 로케이션으로 라우팅되고, 해당 엣지 로케이션은 실시간으로 측정된 네트워크 조건과 애플리케이션 엔드포인트의 상태를 기반으로 최적의 경로를 선택한다. 이 과정은 TCP 및 UDP 트래픽 모두에 대해 작동하며, 애플리케이션 계층(7계층)이 아닌 네트워크 및 전송 계층(3-4계층)에서 동작한다는 점이 ALB와 차별화된다.

ELB와의 통합은 주요 사용 사례 중 하나이다. AWS Global Accelerator는 하나 이상의 지역에 배포된 ALB, NLB, EC2 인스턴스 또는 탄력적 IP 주소를 엔드포인트 그룹으로 지정할 수 있다. 이를 통해 멀티 리전 아키텍처를 구성할 때, 글로벌 사용자에게 단일 진입점(고정 IP)을 제공하면서도 백엔드의 특정 리전 ELB에 장애가 발생하면 트래픽을 다른 정상 리전의 ELB로 자동으로 전환할 수 있다. 이는 재해 복구(DR) 시나리오와 글로벌 사용자 기반을 위한 지연 시간 최소화에 매우 효과적이다.

다음 표는 ELB와 AWS Global Accelerator의 주요 연동 구성을 보여준다.

이러한 구조 덕분에 개발자는 DNS 기반 라우팅의 TTL 제약 없이, 네트워크 수준에서 빠른 장애 조치와 효율적인 글로벌 트래픽 관리를 구현할 수 있다. 결과적으로 AWS Global Accelerator는 ELB를 보완하여 애플리케이션의 글로벌 접근성과 복원력을 한층 강화하는 서비스로 평가된다.