Application Load Balancers - Elastic Load Balancing
로드 밸런서를 위한 서브넷로드 밸런서 보안 그룹로드 밸런서 상태로드 밸런서 속성IP 주소 유형로드 밸런서 연결교차 영역 로드 밸런싱DNS 이름

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Application Load Balancers

로드 밸런서는 클라이언트에 대한 단일 접점 역할을 수행합니다. 클라이언트는 로드 밸런서에 요청을 보내고 로드 밸런서는 EC2 인스턴스와 같은 대상으로 요청을 보냅니다. 로드 밸런서를 구성하려는 경우, 대상 그룹을 생성한 다음 대상을 해당 대상 그룹에 등록합니다. 리스너를 생성하여 클라이언트의 연결 요청을 확인하고, 클라이언트에서 하나 이상의 대상 그룹에 있는 대상으로 요청을 라우팅하는 리스너 규칙을 만듭니다.

자세한 내용은 Elastic Load Balancing 사용 설명서의 Elastic Load Balancing 작동 방식을 참조하세요.

목차

로드 밸런서를 위한 서브넷

Application Load Balancer를 생성할 때는 대상이 포함된 영역을 활성화해야 합니다. 영역을 활성화하려면 영역에 서브넷을 지정합니다. Elastic Load Balancing은 지정한 각 영역에 로드 밸런서 노드를 생성합니다.

고려 사항

  • 활성화된 각 영역에 등록된 대상이 하나 이상 있는지 확인하는 경우에 로드 밸런서가 가장 효과적입니다.

  • 영역에 대상을 등록하지만 영역을 활성화하지 않는 경우 이러한 등록된 대상은 로드 밸런서로부터 트래픽을 수신하지 않습니다.

  • 로드 밸런서에 여러 영역을 활성화하는 경우 영역은 동일한 유형이어야 합니다. 예를 들어 가용 영역과 로컬 영역을 모두 활성화할 수는 없습니다.

  • 자신이 사용자와 공유한 서브넷은 지정할 수 있습니다.

Application Load Balancer는 다음 서브넷 유형을 지원합니다.

가용 영역 서브넷

두 개 이상의 가용 영역 서브넷을 선택해야 합니다. 다음과 같은 제한 사항이 있습니다.

  • 각 서브넷이 서로 다른 가용 영역에 속해야 합니다.

  • 로드 밸런서가 제대로 확장될 수 있도록 로드 밸런서의 각 가용 영역 서브넷에 최소 /27 하나의 비트마스크(예: 10.0.0.0/27)와 서브넷당 최소 8개의 사용 가능한 IP 주소가 있는 CIDR 블록이 있는지 확인합니다. 필요한 경우 로드 밸런서를 확장하려면 이러한 이 IP 주소 8개가 필요합니다. 로드 밸런서는 이러한 IP 주소를 사용하여 대상에 대한 연결을 설정합니다. 이 기능이 없으면 Application Load Balancer 노드가 어려울 수도 있으며 이로 인해 노드 교체가 실패 상태로 전환될 수도 있습니다.

    참고: 확장을 시도하는 동안 Application Load Balancer 서브넷의 사용 가능한 IP 주소가 부족하면 애플리케이션 로드 밸런서는 충분한 용량으로 실행됩니다. 이 기간에 기존 노드는 계속해서 트래픽을 처리하지만 확장 시도가 중단되면 연결 설정 시도 시 5xx 오류가 발생하거나 시간 초과가 발생할 수도 있습니다.

로컬 영역 서브넷

하나 이상의 로컬 영역 서브넷을 지정할 수 있습니다. 다음과 같은 제한 사항이 있습니다.

  • 로드 밸런서와 AWS WAF 함께를 사용할 수 없습니다.

  • Lambda 함수를 대상으로 사용할 수 없습니다.

  • 스티키 세션 또는 애플리케이션 고정성은 사용할 수 없습니다.

Outpost 서브넷

단일 Outpost 서브넷을 지정할 수 있습니다. 다음과 같은 제한 사항이 있습니다.

  • 온프레미스 데이터 센터에 Outpost가 설치 및 구성되어 있어야 합니다. Outpost와 AWS 리전 간에 안정적인 네트워크 연결이 있어야 합니다. 자세한 내용은 AWS Outposts 사용 설명서를 참조하세요.

  • 로드 밸런서는 로드 밸런서 노드용 Outpost에 두 개의 large 인스턴스가 필요합니다. 지원되는 인스턴스 유형은 다음 표에 나와 있습니다. 로드 밸런서는 필요에 따라 확장되어 노드 크기를 한 번에 한 개씩(large에서 xlarge, 그 후 xlarge에서 2xlarge, 그 후 2xlarge에서 4xlarge) 조정합니다. 노드를 가장 큰 인스턴스 크기로 확장한 후 추가 용량이 필요한 경우, 로드 밸런서가 4xlarge 인스턴스를 로드 밸런서 노드로 추가합니다. 로드 밸런서를 확장하기 위한 인스턴스 용량이 충분하지 않거나 사용 가능한 IP 주소가 없는 경우 로드 밸런서는 이벤트를 AWS Health Dashboard에 보고하며 로드 밸런서 상태는 active_impaired입니다.

  • 인스턴스 ID 또는 IP 주소로 대상을 등록할 수 있습니다. Outpost에 대해 AWS 리전에 대상을 등록하는 경우 해당 대상은 사용되지 않습니다.

  • 대상으로서 Lambda 함수, AWS WAF 통합, Sticky Session, 인증 지원, AWS Global Accelerator와의 통합 기능은 사용할 수 없습니다.

Application Load Balancer는 Outpost의 c5/c5d, m5/m5d, or r5/r5d 인스턴스에 배포할 수 있습니다. 다음 표에는 로드 밸런서가 Outpost에서 사용할 수 있는 인스턴스 유형당 크기 및 EBS 볼륨이 나와 있습니다.

인스턴스 유형 및 크기 EBS 볼륨(GB)
c5/c5d
large 50
xlarge 50
2xlarge 50
4xlarge 100
m5/m5d
large 50
xlarge 50
2xlarge 100개
4xlarge 100
r5/r5d
large 50
xlarge 100개
2xlarge 100개
4xlarge 100

로드 밸런서 보안 그룹

보안 그룹은 로드 밸런서와 송수신이 허용되는 트래픽을 제어하는 방화벽 역할을 합니다. 인바운드 및 아웃바운드 트래픽을 허용하는 포트 및 프로토콜을 선택할 수 있습니다.

로드 밸런서와 관련된 보안 그룹에 대한 규칙은 리스너와 상태 확인 포트 모두에서 양방향으로 트래픽을 허용해야 합니다. 로드 밸런서에 리스너를 추가하거나 대상 그룹의 상태 확인 포트를 업데이트할 때마다 보안 그룹 규칙을 검토하여 양방향으로 새로운 포트에서 양방향 트래픽을 허용하는지 확인해야 합니다. 자세한 내용은 권장 규칙 단원을 참조하세요.

로드 밸런서 상태

로드 밸런서는 다음 중 하나의 상태일 수 있습니다.

provisioning

로드 밸런서를 설정하는 중입니다.

active

로드 밸런서가 완전히 설정되어 트래픽을 라우팅할 준비가 되었습니다.

active_impaired

로드 밸런서가 트래픽을 라우팅하지만 확장에 필요한 리소스가 없습니다.

failed

로드 밸런서를 설정할 수 없습니다.

로드 밸런서 속성

해당 속성을 편집하여 Application Load Balancer를 구성할 수 있습니다. 자세한 내용은 로드 밸런서 속성 편집 단원을 참조하십시오.

다음은 로드 밸런서의 속성입니다.

access_logs.s3.enabled

Amazon S3의 액세스 로그를 저장할지 여부를 나타냅니다. 기본값은 false입니다.

access_logs.s3.bucket

액세스 로그에 대한 Amazon S3 버킷 이름입니다. 이 속성은 액세스 로그가 활성화된 경우에 필요합니다. 자세한 내용은 액세스 로그 활성화 단원을 참조하십시오.

access_logs.s3.prefix

Amazon S3 버킷의 위치에 대한 접두사입니다.

client_keep_alive.seconds

클라이언트 연결 유지 기간 값(초)입니다. 기본값은 3600초입니다.

deletion_protection.enabled

삭제 방지 기능의 활성화 여부를 나타냅니다. 기본값은 false입니다.

idle_timeout.timeout_seconds

유휴 제한 시간 값(초). 기본값은 60초입니다.

ipv6.deny_all_igw_traffic

로드 밸런서에 대한 인터넷 게이트웨이(IGW) 액세스를 차단하여 인터넷 게이트웨이를 통한 내부 로드 밸런서에 대한 의도하지 않은 액세스를 방지합니다. 인터넷 연결 로드 밸런서에 대해서는 false로, 내부 로드 밸런서에 대해서는 true로 설정됩니다. 이 속성은 비IGW 인터넷 액세스(예: 피어링, Transit Gateway, AWS Direct Connect또는를 통한 액세스)를 방지하지 않습니다 AWS VPN.

routing.http.desync_mitigation_mode

애플리케이션에 보안 위험을 초래할 수 있는 요청을 로드 밸런서에서 처리하는 방법을 결정합니다. 가능한 값은 monitor, defensive 및 strictest 입니다. 기본값은 defensive입니다.

routing.http.drop_invalid_header_fields.enabled

헤더 필드가 유효하지 않은 HTTP 헤더가 로드 밸런서(true)에 의해 제거되는지 아니면 대상()으로 라우팅되는지 여부를 나타냅니다false. 기본값은 false입니다. Elastic Load Balancing을 사용하려면 HTTP 필드 이름 레지스트리에 설명된 [-A-Za-z0-9]+대로 유효한 HTTP 헤더 이름이 정규 표현식을 준수해야 합니다. 각 이름은 영숫자 또는 하이픈으로 구성되어야 합니다. 이 패턴을 준수하지 않는 HTTP 헤더를 요청에서 제거true하려면를 선택합니다.

routing.http.preserve_host_header.enabled

Application Load Balancer가 HTTP 요청의 Host 헤더를 보존하고 변경 없이 대상에 전송해야 하는지 여부를 나타냅니다. 가능한 값은 true와 false입니다. 기본값은 false입니다.

routing.http.x_amzn_tls_version_and_cipher_suite.enabled

협상된 TLS 버전 및 암호 제품군에 대한 정보가 포함된 두 헤더(x-amzn-tls-version 및 x-amzn-tls-cipher-suite)가 대상에 전송하기 전에 클라이언트 요청에 추가되는지 여부를 나타냅니다. x-amzn-tls-version 헤더에는 클라이언트와 협상된 TLS 프로토콜 버전에 대한 정보가 있고 x-amzn-tls-cipher-suite 헤더에는 클라이언트와 협상된 암호 제품군에 대한 정보가 있습니다. 두 헤더 모두 OpenSSL 형식입니다. 이 속성에 사용 가능한 값은 true 및 false입니다. 기본값은 false입니다.

routing.http.xff_client_port.enabled

X-Forwarded-For 헤더가 클라이언트의 로드 밸런서 연결에 사용한 소스 포트를 보존해야 하는지 여부를 나타냅니다. 가능한 값은 true과 false입니다. 기본값은 false입니다.

routing.http.xff_header_processing.mode

Application Load Balancer가 대상에 요청을 보내기 전에 HTTP 요청의 X-Forward-For 헤더를 수정, 보존 또는 제거할 수 있습니다. 가능한 값은 append, preserve 및 remove 입니다. 기본값은 append입니다.

  • 값이 인 경우 append Application Load Balancer는 대상에 전송하기 전에 HTTP 요청의 X-Forward-For 헤더에 클라이언트 IP 주소(마지막 홉의 주소)를 추가합니다.

  • 값이 인 경우 preserve Application Load Balancer는 HTTP 요청의 X-Forward-For 헤더를 보존하고 변경 없이 대상에 전송합니다.

  • 값이 인 경우 remove Application Load Balancer는 HTTP 요청의 X-Forward-For 헤더를 대상으로 보내기 전에 제거합니다.

routing.http2.enabled

HTTP/2가 활성화되었는지 여부를 나타냅니다. 기본값은 true입니다.

waf.fail_open.enabled

요청을 전달할 수 없는 경우 활성화된 로드 AWS WAF밸런서가 대상에 요청을 라우팅하도록 허용할지 여부를 나타냅니다 AWS WAF. 가능한 값은 true와 false입니다. 기본값은 false입니다.

참고

이 routing.http.drop_invalid_header_fields.enabled 속성은 HTTP 비동기화 보호를 제공하기 위해 도입되었습니다. 애플리케이션에 대한 HTTP 비동기화로부터 보다 포괄적인 보호를 제공하기 위해 routing.http.desync_mitigation_mode 속성이 추가되었습니다. 두 속성을 모두 사용할 필요는 없으며 애플리케이션 요구 사항에 따라 둘 중 하나를 선택할 수 있습니다.

IP 주소 유형

클라이언트가 인터넷 연결 내부 로드 밸런서에 액세스하기 위해 사용할 수 있는 IP 주소 유형을 설정할 수 있습니다.

Application Load Balancer는 다음 IP 주소 유형을 지원합니다.

ipv4

클라이언트는 IPv4 주소(예: 192.0.2.1)를 사용하여 로드 밸런서에 연결해야 합니다.

dualstack

클라이언트는 IPv4 주소(예: 192.0.2.1)와 IPv6 주소(예: 2001:0db8:85a3:0:0:8a2e:0370:7334)를 모두 사용하여 로드 밸런서에 연결할 수 있습니다.

고려 사항

  • 로드 밸런서는 대상 그룹의 IP 주소 유형에 따라 대상과 통신합니다.

  • 로드 밸런서에 대해 듀얼스택 모드를 활성화하면 Elastic Load Balancing은 로드 밸런서에 대한 DNS AAAA 레코드를 제공합니다. IPv4 주소를 사용하여 로드 밸런서와 통신하는 클라이언트는 A DNS 레코드를 확인합니다. IPv6 주소를 사용하여 로드 밸런서와 통신하는 클라이언트는 DNS AAAA Word 레코드를 확인합니다.

  • 의도하지 않은 인터넷 액세스를 방지하기 위해 인터넷 게이트웨이를 통한 내부 듀얼스택 로드 밸런서로의 액세스가 차단됩니다. 그러나 이렇게 해도 IGW 인터넷 액세스(예: 피어링, Transit Gateway AWS Direct Connect또는를 통한 액세스)는 방지되지 않습니다 AWS VPN.

dualstack-without-public-ipv4

클라이언트는 IPv6 주소(예: 2001:0db8:85a3:0:0:8a2e:0370:7334)를 사용하여 로드 밸런서에 연결해야 합니다.

고려 사항

  • Application Load Balancer 인증은 Identity Provider(IdP) 또는 Amazon Cognito 엔드포인트에 연결할 때 IPv4만 지원합니다. 퍼블릭 IPv4 주소가 없으면 로드 밸런서가 인증 프로세스를 완료할 수 없으므로 HTTP 500 오류가 발생합니다.

IP 주소 유형에 대한 자세한 내용은 Application Load Balancer의 IP 주소 유형 업데이트 섹션을 참조하세요.

로드 밸런서 연결

로드 밸런서는 요청을 처리할 때 클라이언트와의 연결과 대상과의 연결이라는 두 가지 연결을 유지합니다. 로드 밸런서와 클라이언트 사이의 연결은 프런트엔드 연결이라고도 합니다. 로드 밸런서와 대상 사이의 연결은 백엔드 연결이라고도 합니다.

교차 영역 로드 밸런싱

Application Load Balancer를 사용하면 기본적으로 교차 영역 로드 밸런싱이 켜져 있으며 로드 밸런서 수준에서 변경할 수 없습니다. 자세한 내용은 Elastic Load Balancing 사용 설명서의 교차 영역 로드 밸런싱 섹션을 참조하세요.

교차 영역 로드 밸런싱은 대상 그룹 수준에서 해제할 수 있습니다. 자세한 내용은 교차 영역 로드 밸런싱 해제 단원을 참조하십시오.

DNS 이름

각 Application Load Balancer는 다음 구문이 포함된 기본 도메인 이름 시스템(DNS) 이름을 받습니다.name-id.elb.region.amazonaws.com. 예: my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com.

기억하기 쉬운 DNS 이름을 사용하려면 사용자 지정 도메인 이름을 생성하고 Application Load Balancer의 DNS 이름과 연결할 수 있습니다. 클라이언트가이 사용자 지정 도메인 이름을 사용하여 요청하면 DNS 서버는 이를 Application Load Balancer의 DNS 이름으로 확인합니다.

먼저 인증된 도메인 등록 대행자를 이용해 도메인 이름을 등록합니다. 다음으로 도메인 등록 기관과 같은 DNS 서비스를 사용하여 요청을 Application Load Balancer로 라우팅하는 DNS 레코드를 생성합니다. 자세한 내용은 DNS 서비스에 대한 설명서를 참조하세요. 예를 들어 Amazon Route 53을 DNS 서비스로 사용하는 경우 Application Load Balancer를 가리키는 별칭 레코드를 생성합니다. 자세한 내용은 Amazon Route 53 개발자 안내서의 ELB 로드 밸런서에 트래픽 라우팅을 참조하세요.

Application Load Balancer는 활성화된 각 가용 영역에 대하여 하나의 IP 주소를 가집니다. 이는 Application Load Balancer 노드의 IP 주소입니다. Application Load Balancer의 DNS 이름이 이러한 주소로 확인됩니다. 예를 들어, Application Load Balancer의 사용자 지정 도메인 이름이 example.applicationloadbalancer.com이라고 가정해 보겠습니다. 다음 dig 또는 nslookup 명령을 사용하여 Application Load Balancer 노드의 IP 주소를 확인합니다.

Linux 또는 Mac

$ dig +short example.applicationloadbalancer.com

Windows

C:\> nslookup example.applicationloadbalancer.com

Application Load Balancer에는 노드에 대한 DNS 레코드가 있습니다. 다음 구문과 함께 DNS 이름을 사용하여 Application Load Balancer 노드의 IP 주소를 확인할 수 있습니다.az.name-id.elb.region.amazonaws.com.

Linux 또는 Mac

$ dig +short us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com

Windows

C:\> nslookup us-east-2b.my-load-balancer-1234567890abcdef.elb.us-east-2.amazonaws.com