기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.
Network Load Balancer를 위한 리스너
리스너는 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스입니다. Network Load Balancer를 사용하기 전에 리스너를 하나 이상 추가해야 합니다. 로드 밸런서에 리스너가 없는 경우 클라이언트로부터 트래픽을 수신할 수 없습니다. 리스너에 대해 정의하는 규칙에 따라 로드 밸런서가 EC2 인스턴스와 같이 등록한 대상으로 요청을 라우팅하는 방법이 결정됩니다.
내용
리스너 구성
리스너는 다음과 같은 프로토콜 및 포트를 지원합니다.
-
프로토콜: TCP, TLS, UDP, TCP_UDP, QUIC, TCP_QUIC
-
포트: 1-65535
애플리케이션이 비즈니스 로직에 집중할 수 있도록 TLS 리스너를 사용하여 암호화 및 암호 해독 작업을 로드 밸런서로 오프로드할 수 있습니다. 리스너 프로토콜이 TLS인 경우에는 리스너에 한 개 이상의 SSL 서버 인증서를 반드시 배포해야 합니다. 자세한 내용은 서버 인증서 단원을 참조하십시오.
대상이 로드 밸런서 대신 TLS 트래픽을 해독하도록 하려면 TLS 리스너를 생성하는 대신 포트 443에서 수신하는 TCP 리스너를 생성합니다. TCP 리스너를 사용하여 로드 밸런서는 암호화된 트래픽을 해독하지 않고 대상으로 전달합니다.
QUIC 리스너를 사용하여 QUIC 트래픽을 수락할 수 있습니다. Network Load Balancer는 RFC9000
동일한 포트에서 TCP와 UDP를 모두 지원하려면 TCP_UDP 리스너를 만드십시오. TCP_UDP 리스너의 대상 그룹은 TCP_UDP 프로토콜을 사용해야 합니다.
동일한 포트에서 TCP와 QUIC를 모두 지원하려면 TCP_QUIC 리스너를 만드십시오. TCP_QUIC 리스너의 대상 그룹은 TCP_QUIC 프로토콜을 사용해야 합니다.
듀얼스택 로드 밸런서의 UDP 리스너는 IPv6 대상 그룹을 필요로 합니다.
WebSockets는 TCP, TLS, TCP_UDP 및 TCP_QUIC 리스너에서만 지원됩니다.
QUIC 트래픽은 버전 협상을 지원하지 않습니다. QUIC v1이 유일하게 지원되는 QUIC 버전입니다.
구성된 리스너로 전송된 모든 네트워크 트래픽은 의도된 트래픽으로 분류됩니다. 구성된 리스너와 일치하지 않는 네트워크 트래픽은 의도하지 않은 트래픽으로 분류됩니다. 유형 3 이외의 ICMP 요청도 의도하지 않은 트래픽으로 간주됩니다. Network Load Balancer는 의도하지 않은 트래픽을 대상에 전달하지 않고 삭제합니다. 새 연결이 아니거나 활성 TCP 연결의 일부가 아닌 구성된 리스너에 대해 리스너 포트로 전송된 TCP 데이터 패킷은 RST(TCP 재설정)를 통해 거부됩니다.
자세한 내용은 Elastic Load Balancing 사용 설명서의 라우팅 요청을 참조하세요.
기본 작업
리스너를 생성할 때 요청 라우팅을 위한 기본 작업을 지정합니다. 기본 작업은 지정한 대상 그룹으로 요청을 전달합니다.
다중 대상 그룹으로 트래픽 배포
기본 작업에 다중 대상 그룹을 지정하면, 요청은 상대적인 가중치에 따라 이 대상 그룹들로 배포됩니다. 각 대상 그룹에 대해 0에서 999 사이의 가중치를 지정해야 합니다. 가중치가 0인 대상 그룹은 트래픽을 수신하지 않습니다. 대상 그룹을 추가하거나 대상 그룹 가중치를 업데이트한 후, 새 연결은 새 대상 그룹 가중치에 따라 라우팅됩니다. 기존 연결은 영향을 받지 않으며 평소처럼 닫힐 때까지 계속됩니다.
예를 들어, 각각 가중치가 10인 두 개의 대상 그룹을 지정하면 각 대상 그룹은 요청의 절반을 수신합니다. 하나의 가중치가 10이고 다른 하나의 가중치가 20인 두 개의 대상 그룹을 지정하면, 가중치가 20인 대상 그룹은 가중치가 10인 대상 그룹보다 두 배 많은 요청을 수신합니다.
일반적인 사용 사례는 트래픽을 한 대상 그룹에서 다른 대상 그룹으로 마이그레이션하는 것입니다. 즉, 원래 대상 그룹의 가중치를 0이 될 때까지 점진적으로 줄이면서 새 대상 그룹의 가중치를 점차 늘립니다. 대상 그룹의 가중치를 0으로 업데이트하면, 짧은 시간이 지난 후 새로운 연결은 수신하지 않으며 기존 연결은 닫힙니다.
스티키 세션 및 가중 대상 그룹
리스너의 전달 작업은 대상 그룹 고정 활성화 여부를 지정할 수 있습니다. 활성화되면, 대상 그룹 고정은 동일한 소스 IP 주소로부터의 후속 연결이 이전에 선택된 대상 그룹을 선호하도록 합니다.
고려 사항
-
TLS 리스너의 경우, TCP 대상 그룹과 TLS 대상 그룹을 모두 리스너 규칙에 추가할 수 없습니다. 모든 대상 그룹은 동일한 프로토콜을 사용해야 합니다.
-
TLS 리스너의 경우 대상 그룹 고정은 지원되지 않습니다.
-
듀얼스택 로드 밸런서의 경우, IPv4 대상 그룹과 IPv6 대상 그룹을 동일한 기본 작업에 모두 추가할 수 없습니다. 기본 작업의 모든 대상 그룹은 동일한 IP 주소 유형을 사용해야 합니다.
-
리스너의 경우, 전달 작업에 여러 대상 그룹이 포함되어 있고 그 중 하나라도 고정이 활성화된 경우, 전달 작업 역시 대상 그룹 고정이 활성화되어 있어야 합니다.
리스너 속성
다음은 Network Load Balancer의 리스너 속성입니다.
tcp.idle_timeout.seconds-
TCP 유휴 제한 시간 값(초). 값의 범위는 60~6,000초입니다. 기본값은 350초입니다.
자세한 내용은 유휴 제한 시간 업데이트 단원을 참조하십시오.
리스너 규칙
Network Load Balancer의 리스너 규칙은 요청을 대상으로 라우팅하는 방법을 결정합니다. 각 리스너에는 지정된 대상 그룹에 요청을 전달하는 기본 작업이 있습니다. 수신 트래픽의 소스 IP 주소 유형에 따라 조건을 평가하고 트래픽을 다른 대상 그룹으로 라우팅하는 사용자 지정 규칙을 추가할 수 있습니다. 이를 통해 단일 듀얼 스택 로드 밸런서를 사용하여 IPv4 및 IPv6 트래픽을 별도의 대상 그룹으로 라우팅할 수 있으므로 IPv4/IPv6 프로토콜 변환이 필요 없고 end-to-end 소스 IP 연결을 유지할 수 있습니다.
규칙 기본 사항
-
각 규칙은 우선 순위, 작업 및 조건의 구성 요소로 구성됩니다.
-
리스너를 생성할 때 기본 규칙에 대한 작업을 정의합니다. 기본 규칙은 조건을 가질 수 없습니다. 다른 규칙에 대한 조건이 충족되지 않으면 기본 규칙에 대한 작업이 수행됩니다.
-
규칙은 가장 낮은 값에서 가장 높은 값에 이르기까지 우선 순위에 따라 평가됩니다. 기본 규칙은 마지막에 평가됩니다. 기본 규칙의 우선순위는 변경할 수 없습니다.
-
각 규칙에는 요청을 하나 이상의 대상 그룹으로 라우팅하는 정확히 하나의
forward작업이 포함되어야 합니다. -
리스너 규칙은 듀얼 스택 Network Load Balancer에서만 사용할 수 있습니다.
규칙 조건
각 규칙 조건에는 유형과 구성 정보가 있습니다. 규칙 조건이 충족되면 규칙의 작업이 수행됩니다.
다음은 Network Load Balancer 리스너 규칙에 지원되는 조건 유형입니다.
source-ip-
소스 트래픽의 IP 주소 유형에 따라 라우팅합니다.
ipv4또는IpAddressType값을 지정합니다ipv6. 수신 요청의 소스 IP 버전이 조건과 일치하면 규칙 작업이 수행됩니다.다음은 source-ip 조건의 예입니다.
{ "Field": "source-ip", "SourceIpConfig": { "IpAddressType": "ipv4" } }
참고
Network Load Balancer의 source-ip 조건은 IpAddressType를 사용하여 IP 버전(IPv4 또는 IPv6)별로 트래픽을 일치시킵니다. 이는 CIDR 범위를 사용하여 특정 소스 IP 주소와 일치하는 Application Load Balancer source-ip 조건과 다릅니다.
규칙 작업
각 규칙 작업에는 유형과 구성 정보가 있습니다. 다음은 Network Load Balancer 리스너 규칙에 지원되는 작업 유형입니다.
forward-
요청을 하나 이상의 지정된 대상 그룹에 전달합니다.
forward작업에 대해 여러 대상 그룹을 지정하는 경우 각 대상 그룹에 대해 가중치를 지정해야 합니다. 각 대상 그룹 가중치는 0과 999 사이의 값입니다. 가중 대상 그룹이 있는 리스너 규칙과 일치하는 요청은 가중치를 기준으로 이러한 대상 그룹에 배포됩니다. 예를 들어, 각각 가중치가 10인 두 개의 대상 그룹을 지정하면 각 대상 그룹은 요청을 절반씩 받습니다. 가중치가 10인 대상 그룹과 가중치가 20인 대상 그룹 두 개를 지정하면 가중치가 20인 대상 그룹이 다른 대상 그룹보다 두 배 많은 요청을 받습니다.
다음은 단일 대상 그룹으로 라우팅하는 전달 작업의 예입니다.
{ "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-ipv4-tg/target-group-id" }
다음은 두 개의 가중치 대상 그룹으로 라우팅하는 전달 작업의 예입니다.
{ "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-tg-1/target-group-id", "Weight": 70 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:region:account-id:targetgroup/my-tg-2/target-group-id", "Weight": 30 } ] } }
규칙 우선 순위
각 규칙마다 우선 순위가 있습니다. 규칙은 가장 낮은 값에서 가장 높은 값에 이르기까지 우선 순위에 따라 평가됩니다. 기본 규칙은 마지막에 평가됩니다. set-rule-priorities 명령을 사용하여 언제든지 기본이 아닌 규칙의 우선 순위를 변경할 수 있습니다.
각 규칙에는 고유한 우선 순위 값이 있어야 합니다. 우선 순위가 동일한 규칙을 여러 개 생성할 수 없습니다. 여러 규칙이 수신 트래픽과 일치하는 경우 우선 순위가 가장 높은 규칙(가장 낮은 숫자 값)이 우선합니다.
규칙 평가
트래픽이 Network Load Balancer 리스너에 도착하면 규칙은 다음 순서로 평가됩니다.
-
기본값이 아닌 규칙은 우선 순위(최저 값 먼저)로 평가됩니다.
-
규칙 조건이 충족되면 규칙의 작업이 수행됩니다.
-
규칙 조건이 충족되지 않으면 기본 작업이 수행됩니다.
리스너 규칙이 모든 트래픽 시나리오(IPv4 및 IPv6 모두)를 포함하는 경우 기본 작업이 사용되지 않을 수 있습니다. 그러나 기본 작업은 항상 필요합니다.
고려 사항
- 사전 조건
-
리스너 규칙에는 듀얼 스택 Network Load Balancer가 필요합니다. VPC와 서브넷에는 IPv6 CIDR 블록이 연결되어 있어야 하며 서브넷 라우팅 테이블은 IPv6 트래픽을 라우팅해야 합니다.
- 규칙 평가 및 기본 작업
-
규칙은 우선 순위에 따라 평가되며, 우선 순위가 낮은 번호가 먼저 평가됩니다. 규칙 없음과 일치하는 트래픽은 기본 작업으로 전달됩니다. 기본 작업을 대체할 IP 주소 패밀리로 설정합니다.
- 프로토콜 및 대상 그룹
-
리스너 규칙은 TCP, UDP, TCP_UDP 및 TLS 리스너에 적용됩니다. 듀얼 스택 Network Load Balancer의 UDP 리스너에는 IPv6 대상 그룹이 필요하므로 UDP 트래픽을 분할하기 전에 IPv6 대상 그룹이 존재하는지 확인합니다.
- 건전성 체크
-
각 대상 그룹 상태는 자체 IP 주소 패밀리를 통해 대상을 확인합니다. 대상 보안 그룹이 IPv4 및 IPv6를 통해 로드 밸런서의 상태 확인 트래픽을 허용하는지 확인합니다.
- 성능 및 가용성
-
통합 듀얼 스택 Network Load Balancer는 IPv4 및 IPv6 주소 패밀리의 결합된 트래픽을 모두 전달하므로 두 개의 개별 Network Load Balancer에 비해 부하가 두 배가 될 수 있습니다. 하나의 Network Load Balancer는 간소화를 제공하지만 두 개의 개별 Network Load Balancer는 주소 패밀리당 자연적인 장애 격리를 제공합니다. 통합하기 전에 규모 및 가용성 요구 사항을 평가합니다.
- 기존 Network Load Balancer 기능과의 호환성
-
리스너 규칙은 연결 드레이닝(등록 취소 지연), 대상 그룹 고정(스티키 세션), 교차 영역 로드 밸런싱, 클라이언트 IP 보존(
preserve_client_ip) 및 TLS 리스너의 TLS 종료와 같은 기존 Network Load Balancer 기능 세트와 함께 작동합니다. 각 대상 그룹은 자체 구성을 유지합니다. - 소스 IP 보존
-
클라이언트 및 대상 IP 버전이 일치하면(리스너 규칙에 의해 활성화됨) 트래픽은 프로토콜 변환 없이 직접 흐르며 end-to-end 소스 IP 보존을 유지합니다. 이를
preserve_client_ip위해서는 대상 그룹에서를 활성화해야 합니다. - 가중 대상 그룹
-
리스너 규칙은 여러 가중치 대상 그룹을
ForwardConfig지원하므로 canary 롤아웃 또는 점진적 마이그레이션에 유용합니다. 각 대상 그룹은 0~999의 가중치를 사용하며 가중치가 0인 그룹은 새 연결을 수신하지 않습니다. - Application Load Balancer 리스너 규칙과의 관계
-
Network Load Balancer와 Application Load Balancer 모두
source-ip조건을 사용하지만 서로 다른 속성에서 일치합니다. Application Load Balancer는 소스 주소를 하나 이상의 CIDR 블록(SourceIpConfig.Values)과 일치시키는 반면, Network Load Balancer는 소스 연결()의 IP 주소 유형과 일치시킵니다SourceIpConfig.IpAddressType. 간단히 말해서 Application Load Balancer는 특정 주소 범위별로 라우팅되고 Network Load Balancer는 IP 버전별로 라우팅됩니다. - 요금 및 가용성
-
리스너 규칙은 모든 AWS 상용 리전 및 AWS GovCloud(미국) 리전에서 사용할 수 있습니다. 기능에 대한 추가 요금은 없습니다. Load Balancer서 시간 및 LCUs. 별도의 IPv4 및 IPv6 Network Load Balancer를 단일 듀얼 스택 Network Load Balancer에 통합하면 두 번째 로드 밸런서의 시간과 LCU 요금이 제거됩니다.
자세한 내용은 Network Load Balancer에 대한 리스너 규칙 단원을 참조하십시오.
보안 리스너
TLS 리스너를 사용하려면 로드 밸런서에 한 개 이상의 서버 인증서를 반드시 배포해야 합니다. 로드 밸런서는 서버 인증서를 사용해 프런트 엔드 연결을 종료한 다음, 대상으로 전송하기 전에 클라이언트의 요청을 해독합니다. 암호화된 트래픽을 로드 밸런서의 해독 없이 대상으로 전달해야 하는 경우, TLS 리스너를 생성하는 대신 포트 443에서 수신하는 TCP 리스너를 생성합니다. 로드 밸런서는 요청을 해독하지 않고 있는 그대로 대상으로 전달합니다.
Elastic Load Balancing은 보안 정책이라고 하는 TLS 협상 구성을 사용해 클라이언트와 로드 밸런서 간에 TLS 연결을 협상합니다. 보안 정책은 프로토콜과 암호의 조합입니다. 프로토콜은 클라이언트와 서버 간에 보안 연결을 설정하여 클라이언트와 로드 밸런서 간에 전달되는 모든 데이터를 안전하게 보호합니다. 암호는 코딩된 메시지를 생성하기 위해 암호화 키를 사용하는 암호화 알고리즘입니다. 프로토콜은 여러 개의 암호를 사용해 인터넷 상의 데이터를 암호화합니다. 연결 협상이 이루어지는 동안 클라이언트와 로드 밸런서는 각각이 지원하는 암호 및 프로토콜 목록을 선호도 순으로 표시합니다. 서버의 목록에서 클라이언트의 암호 중 하나와 일치하는 첫 번째 암호가 보안 연결을 위해 선택됩니다.
Network Load Balancer는 상호 TLS 인증(mTLS)을 지원하지 않습니다. mTLS를 지원하려면 TLS 리스너 대신 TCP 리스너를 생성합니다. 로드 밸런서는 요청을 있는 그대로 전달하므로 대상에서 mTLS를 구현할 수 있습니다.
Network Load Balancer는 TLS 1.3의 경우 PSK를 사용한 TLS 재개(resumption)를, TLS 1.2 이하의 경우 세션 티켓을 사용한 재개를 지원합니다. 세션 ID를 사용한 재개 또는 SNI를 사용하여 리스너에 여러 인증서가 구성된 경우에는 지원되지 않습니다. 0-RTT 데이터 기능 및 early_data 확장은 구현되지 않았습니다.
관련 데모는 Network Load Balancer에 대한 TLS 지원
ALPN 정책
ALPN(Application-Layer Protocol Negotiation)은 최초 TLS 핸드셰이크 hello 메시지를 통해 전송되는 TLS 확장입니다. ALPN을 사용하면 애플리케이션 계층이 HTTP/1 및 HTTP/2 같은 보안 연결을 통해 사용해야 하는 프로토콜을 협상할 수 있습니다.
클라이언트가 ALPN 연결을 시작하면 로드 밸런서는 클라이언트 ALPN 기본 설정 목록을 해당 ALPN 정책과 비교합니다. 클라이언트가 ALPN 정책의 프로토콜을 지원하는 경우 로드 밸런서는 ALPN 정책의 기본 설정 목록을 기반으로 연결을 설정합니다. 그렇지 않을 경우 로드 밸런서는 ALPN을 사용하지 않습니다.
지원되는 ALPN 정책
지원되는 ALPN 정책은 다음과 같습니다.
HTTP1Only-
HTTP/1.*만 협상합니다. ALPN 기본 설정 목록은 http/1.1, http/1.0입니다.
HTTP2Only-
HTTP/2만 협상합니다. ALPN 기본 설정 목록은 h2입니다.
HTTP2Optional-
HTTP/2보다 HTTP/1.*를 선호합니다(HTTP/2 테스트에 유용할 수 있음). ALPN 기본 설정 목록은 http/1.1, http/1.0, h2입니다.
HTTP2Preferred-
HTTP/1.*보다 HTTP/2를 선호합니다. ALPN 기본 설정 목록은 h2, http/1.1, http/1.0입니다.
None-
ALPN을 협상하지 않습니다. 이 값이 기본값입니다.
ALPN 연결 활성화
TLS 리스너를 생성하거나 수정할 때 ALPN 연결을 활성화할 수 있습니다. 자세한 내용은 리스너 추가 및 ALPN 정책 업데이트 섹션을 참조하세요.