Application Load Balancers

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

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

내용

• 리소스 맵
• 로드 밸런서를 위한 서브넷
• 로드 밸런서 보안 그룹
• 로드 밸런서 상태
• 로드 밸런서 속성
• IP 주소 유형
• 로드 밸런서 연결
• 교차 영역 로드 밸런싱
• 삭제 방지
• Desync Mitigation Mode
• Host header preservation
• AWS WAF
• 로드 밸런서 생성
• 가용 영역 업데이트
• 보안 그룹 업데이트
• 주소 유형 업데이트
• 태그 업데이트
• 로드 밸런서 삭제
• 영역 이동

리소스 맵으로 리소스를 시각화하세요

리소스 맵에는 리소스 간의 관계 및 라우팅 경로를 포함하여 로드 밸런서의 모든 리소스가 시각적 형식으로 표시됩니다.

리소스 맵에는 다음과 같은 로드 밸런서 리소스가 표시됩니다.

• 리스너

• 규칙

• 대상 그룹

• 대상

리소스 맵을 사용하여 로드 밸런서의 아키텍처를 이해하고, 로드 밸런서에 있는 리스너 수, 어떤 규칙이 어떤 리스너로 전달되는지, 어떤 대상 그룹이 어떤 대상으로 라우팅되는지 확인할 수 있습니다.

또한 리소스 맵을 사용하여 바람직하지 않거나 잘못된 구성과 비정상 대상을 식별할 수 있습니다. 리소스 맵 내에서 규칙 등의 리소스를 선택하여 해당 리소스의 구성을 편집할 수 있는 링크를 만들 수 있습니다.

로드 밸런서의 리소스를 시각화하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 리소스 맵 탭을 선택하여 리소스 시각화를 표시합니다.

   리소스 맵 탐색하기

   • 리소스 타일에 마우스를 갖다 대거나 선택하면 해당 타일과 다른 리소스 간의 관계가 강조 표시됩니다.

   • 리소스 타일을 선택하면 해당 리소스에 대한 추가 세부 정보를 볼 수 있습니다.

   • 타일 내에서 리소스 이름을 선택하면 해당 리소스의 세부 정보 페이지로 이동합니다.

5. 모든 리소스에 대한 추가 정보를 보려면 리소스 세부 정보 보기를 활성화합니다.

   • 규칙 조건: 각 규칙의 조건.

   • 대상 그룹 건강 요약: 각 건강 상태에 등록된 대상 수.

   • 대상 건강 상태: 대상의 현재 건강 상태 및 설명.

6. (선택 사항) 현재 비정상 대상 및 이와 관련된 리소스를 모두 표시하려면 비정상 대상 맵을 선택합니다.

7. (선택 사항) 내보내기를 선택하면 Application Load Balancer 리소스 맵의 현재 보기를 PDF로 내보내는 옵션이 제공됩니다.

로드 밸런서를 위한 서브넷

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

고려 사항

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

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

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

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

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

가용 영역 서브넷

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

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

• 로드 밸런서가 적절하게 확장 가능하도록 로드 밸런서의 각 가용 영역 서브넷에 /27 비트 마스크(예: 10.0.0.0/27)가 하나 이상인 CIDR 블록이 있고 서브넷당 사용 가능한 IP 주소가 8개 이상 있는지 확인합니다. 필요한 경우 로드 밸런서를 확장하려면 이러한 이 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 또는 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

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

로드 밸런서 속성

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

access_logs.s3.enabled

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

access_logs.s3.bucket

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

access_logs.s3.prefix

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

client_keep_alive.seconds

클라이언트의 keepalive 값 (초 단위) 기본값은 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 헤더 이름이 HTTP 필드 이름 레지스트리에 설명된 바와 같이 정규 표현식 [-A-Za-z0-9]+를 준수해야 합니다. 각 이름은 영숫자 또는 하이픈으로 구성되어야 합니다. 이 패턴을 준수하지 않는 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-enabled 로드 밸런서가 요청을 대상으로 전달할 수 없는 경우 요청을 대상으로 라우팅하도록 허용할지 여부를 나타냅니다. AWS WAF가능한 값은 true와 false입니다. 기본값은 false입니다.

참고

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

IP 주소 유형

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

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에서 해당 로드 밸런서의 AAA DNS 레코드를 제공합니다. IPv4 주소를 사용하여 로드 밸런서와 통신하는 클라이언트는 A DNS 레코드를 확인합니다. IPv6 주소를 사용하여 로드 밸런서와 통신하는 클라이언트는 AAA DNS 레코드를 확인합니다.

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

로드 밸런서 연결

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

연결 유휴 제한 시간

연결 유휴 제한 시간은 로드 밸런서가 연결을 종료하기 전에 기존 클라이언트 또는 대상 연결이 데이터를 보내거나 받지 않고 비활성 상태를 유지할 수 있는 기간입니다.

파일 업로드와 같이 시간이 오래 걸리는 작업을 완료할 시간을 확보하려면 각 유휴 제한 시간이 경과하기 전에 최소 1바이트의 데이터를 전송하고 필요에 따라 유휴 제한 시간을 늘리십시오. 또한 애플리케이션의 유휴 제한 시간을 로드 밸런서에 구성된 유휴 제한 시간보다 크게 설정하는 것이 좋습니다. 그렇게 하지 않으면 애플리케이션이 로드 밸런서에 대한 TCP 연결을 비정상적으로 닫을 경우, 로드 밸런서가 연결이 닫혔음을 가리키는 패킷을 받기 전에 애플리케이션에 요청을 전송할 수 있습니다. 이 경우 로드 밸런서는 HTTP 502 잘못된 게이트웨이 오류를 클라이언트에게 을전송합니다.

기본적으로 Elastic Load Balancing은 로드 밸런서의 유휴 제한 시간 값을 60초, 즉 1분으로 설정합니다. 다른 유휴 제한 시간 값을 설정하려면 다음 절차를 따르세요.

콘솔을 사용하여 연결 유휴 제한 시간 값을 업데이트하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 트래픽 구성에서 연결 유휴 제한 시간 값을 입력합니다. 유효 범위는 1~4000초입니다.

6. 변경 사항 저장를 선택합니다.

를 사용하여 유휴 제한 시간 값을 업데이트하려면 AWS CLI

modify-load-balancer-attributes명령을 속성과 함께 사용합니다. idle_timeout.timeout_seconds

HTTP 클라이언트 연결 유지 기간

HTTP 클라이언트 연결 유지 기간은 Application Load Balancer가 클라이언트에 대한 지속적인 HTTP 연결을 유지하는 최대 시간입니다. 구성된 HTTP 클라이언트 keepalive 기간이 경과하면 Application Load Balancer는 요청 하나를 수락하고 연결을 정상적으로 종료하는 응답을 반환합니다.

로드 밸런서가 보내는 응답 유형은 클라이언트 연결에 사용되는 HTTP 버전에 따라 달라집니다. HTTP 1.x를 사용하여 연결된 클라이언트의 경우 로드 밸런서는 필드가 포함된 HTTP 헤더를 보냅니다. Connection: close HTTP/2를 사용하여 연결된 클라이언트의 경우 로드 밸런서가 프레임을 전송합니다. GOAWAY

기본적으로 애플리케이션 로드 밸런서는 HTTP 클라이언트 keepalive 기간 값을 3600초, 즉 1시간으로 설정합니다. HTTP 클라이언트 keepalive 기간을 끄거나 최소 60초 미만으로 설정할 수 없지만 HTTP 클라이언트 keepalive 기간을 최대 604800초 또는 7일로 늘릴 수 있습니다. Application Load Balancer는 클라이언트에 대한 HTTP 연결이 처음 설정될 때 HTTP 클라이언트 연결 유지 기간을 시작합니다. 지속 기간은 트래픽이 없을 때 계속 실행되며 새 연결이 설정될 때까지 재설정되지 않습니다.

Application Load Balancer는 초기 연결 중에 HTTP 클라이언트에 keepalive 기간을 한 번 할당합니다. HTTP 클라이언트 keepalive 기간을 업데이트하면 HTTP 클라이언트 keepalive 기간 값이 서로 다른 동시 연결이 발생할 수 있습니다. 기존 연결은 초기 연결 시 적용된 HTTP 클라이언트 keepalive 기간 값을 유지하며, 새 연결은 업데이트된 HTTP 클라이언트 keepalive 기간 값을 받게 됩니다.

콘솔을 사용하여 클라이언트 keepalive 기간 값을 업데이트하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 트래픽 구성에서 HTTP 클라이언트 연결 유지 기간 값을 입력합니다. 유효 범위는 60초에서 604800초입니다.

6. 변경 사항 저장를 선택합니다.

다음을 사용하여 클라이언트 keepalive 기간 값을 업데이트하려면 AWS CLI

modify-load-balancer-attributes명령을 속성과 함께 사용합니다. client_keep_alive.seconds

교차 영역 로드 밸런싱

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

교차 영역 로드 밸런싱은 대상 그룹 수준에서 해제할 수 있습니다. 자세한 설명은 교차 영역 로드 밸런싱 해제 섹션을 참조하세요.

삭제 방지

로드 밸런서가 실수로 삭제되지 않도록 삭제 방지 기능을 활성화할 수 있습니다. 기본 설정상 로드 밸런서에 대한 삭제 방지 기능은 비활성화되어 있습니다.

로드 밸런서용 삭제 방지 기능을 활성화하는 경우 로드 밸런서를 삭제하기 전에 이 기능을 먼저 비활성화해야 합니다.

콘솔을 사용하여 삭제 방지 기능을 활성화하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 구성에서 삭제 방지를 켭니다.

6. 변경 사항 저장를 선택합니다.

콘솔을 사용하여 삭제 방지 기능을 비활성화하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 구성 페이지에서 삭제 방지를 끕니다.

6. 변경 사항 저장를 선택합니다.

를 사용하여 삭제 보호를 활성화 또는 비활성화하려면 AWS CLI

modify-load-balancer-attributes명령을 deletion_protection.enabled 속성과 함께 사용합니다.

Desync Mitigation Mode

Desync Mitigation Mode는 HTTP Desync로 인한 문제로부터 애플리케이션을 보호합니다. 로드 밸런서는 위협 수준에 따라 각 요청을 분류하고 안전한 요청을 허용한 다음 지정한 완화 모드에서 지정한 대로 위험을 완화합니다. Desync Mitigation Mode는 Monitor, Defensive 또는 Strictest 모드입니다. 기본값은 Defensive 모드입니다. 이 모드는 애플리케이션의 가용성을 유지하면서 HTTP Desync에 대한 지속적인 완화를 제공합니다. 애플리케이션에서 RFC 7230을 준수하는 요청만 수신하도록 Strictest 모드로 전환할 수 있습니다.

http_desync_guardian 라이브러리는 HTTP Desync 공격을 방지하기 위해 HTTP 요청을 분석합니다. 자세한 내용은 HTTP 비동기화 가디언 켜기를 참조하십시오. GitHub

분류

분류는 다음과 같습니다.

• 규정 준수 - 요청이 RFC 7230을 준수하며 알려진 보안 위협이 없습니다.

• 허용 가능 - 요청이 RFC 7230을 준수하지 않지만 알려진 보안 위협이 없습니다.

• 모호 - 요청이 RFC 7230을 준수하지 않지만 다양한 웹 서버와 프록시가 다르게 처리할 수 있으므로 위험을 초래합니다.

• 심각 - 요청이 높은 보안 위험을 초래합니다. 로드 밸런서는 요청을 차단하고 클라이언트에 대해 400 응답을 제공하고 클라이언트 연결을 종료합니다.

요청이 RFC 7230을 준수하지 않는 경우 로드 밸런서는 DesyncMitigationMode_NonCompliant_Request_Count 지표를 증가시킵니다. 자세한 설명은 Application Load Balancer 지표 섹션을 참조하세요.

각 요청에 대한 분류는 로드 밸런서 액세스 로그에 포함됩니다. 요청이 준수하지 않는 경우, 액세스 로그에 분류 사유 코드가 포함됩니다. 자세한 설명은 분류 이유 섹션을 참조하세요.

Modes

다음 표에서는 Application Load Balancer가 모드 및 분류를 기준으로 요청을 처리하는 방법에 대해 설명합니다.

Classification	Monitor 모드	Defensive 모드	Strictest 모드
규정 준수	Allowed	허용됨	Allowed
허용 가능	Allowed	Allowed	차단됨
모호	Allowed	허용¹	차단됨
심각	Allowed	차단됨	차단됨

¹ 요청을 라우팅하지만 클라이언트 연결과 대상 연결을 종료합니다. 로드 밸런서가 Defensive 모드에서 모호한 요청을 대량으로 수신하는 경우 추가 요금이 발생할 수 있습니다. 이는 초당 새 연결 수가 증가하여 시간당 사용되는 LCU(로드 밸런서 용량 단위)에 기여하기 때문입니다. NewConnectionCount 지표를 사용하여 로드 밸런서가 Monitor 모드 및 Defensive 모드에서 새 연결을 설정하는 방법을 비교할 수 있습니다.

콘솔을 사용하여 Desync Mitigation Mode를 업데이트하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 패킷 처리 아래의 비동기 완화 모드에서 방어적, 가장 엄격 또는 모니터링을 선택합니다.

6. 변경 사항 저장를 선택합니다.

를 사용하여 비동기 완화 모드를 업데이트하려면 AWS CLI

routing.http.desync_mitigation_mode속성이monitor, defensive 또는 로 설정된 상태에서 modify-load-balancer-attributes명령을 사용하십시오. strictest

Host header preservation

Preserve host header 속성을 활성화하면 Application Load Balancer가 HTTP 요청의 Host 헤더를 보존한 뒤 수정하지 않고 대상에 헤더를 보냅니다. Application Load Balancer가 여러 Host 헤더를 받는 경우 이를 모두 보존합니다. 리스너 규칙은 첫 번째 Host 헤더에만 적용됩니다.

기본적으로, Preserve host header 속성이 활성화되지 않은 경우 Application Load Balancer는 다음과 같은 방식으로 Host 헤더를 수정합니다:

호스트 헤더 보존이 활성화되어 있지 않고 리스너 포트가 기본 포트가 아닌 경우: 기본 포트(포트 80 또는 443)를 사용하지 않을 때 클라이언트가 호스트 헤더에 포트 번호를 아직 추가하지 않은 상태라면 포트 번호가 추가됩니다. 예를 들어, 리스너 포트가 8080 등의 기본 포트가 아닌 경우 Host: www.example.com를 포함하는 HTTP 요청의 Host 헤더가 Host: www.example.com:8080(으)로 수정됩니다.

호스트 헤더 보존이 활성화되어 있지 않고 리스너 포트가 기본 포트(포트 80 또는 443)인 경우: 기본 리스너 포트(포트 80 또는 443)의 경우 발신 호스트 헤더에 포트 번호가 추가되지 않습니다. 수신 호스트 헤더에 이미 있던 모든 포트 번호가 제거됩니다.

다음 표에 Application Load Balancer가 리스너 포트를 기반으로 HTTP 요청에서 호스트 헤더를 처리하는 방법에 대한 추가 예제가 나와 있습니다.

리스너 포트	요청 예제	요청의 호스트 헤더	호스트 헤더 보존이 비활성화됨(기본 동작)	호스트 헤더 보존이 활성화됨
요청이 기본 HTTP/HTTPS 리스너에서 전송됩니다.	GET /index.html HTTP/1.1 Host: example.com	example.com	example.com	example.com
요청은 기본 HTTP 리스너에서 전송되며 호스트 헤더에는 포트 (예: 80 또는 443) 가 있습니다.	GET /index.html HTTP/1.1 Host: example.com:80	example.com:80	example.com	example.com:80
요청에 절대 경로가 있습니다.	GET https://dns_name/index.html HTTP/1.1 Host: example.com	example.com	dns_name	example.com
요청이 기본이 아닌 리스너 포트에서 전송되며 호스트 헤더에는 포트(예 8080)가 있습니다.	GET /index.html HTTP/1.1 Host: example.com:8080	example.com	example.com:8080	example.com

호스트 헤더 보존 활성화

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 [Load Balancers]를 클릭합니다.

3. 로드 밸런서를 선택합니다.

4. 속성성(Attributes) 탭에서 편집(Edit)을 선택합니다.

5. 패킷 처리에서 호스트 헤더 보존을 켭니다.

6. 변경 사항 저장를 선택합니다.

를 사용하여 호스트 헤더를 보존할 수 있도록 하려면 AWS CLI

routing.http.preserve_host_header.enabled속성이 로 설정된 상태에서 modify-load-balancer-attributes명령을 사용합니다true.

애플리케이션 로드 밸런서 및 AWS WAF

Application Load AWS WAF Balancer와 함께 사용하여 웹 ACL (액세스 제어 목록) 의 규칙에 따라 요청을 허용하거나 차단할 수 있습니다. 자세한 내용은 AWS WAF Developer Guide( 개발자 안내서)의 Working with web ACLs(웹 ACL 작업)를 참조하세요.

기본적으로 로드 밸런서는 응답을 받을 AWS WAF수 없는 경우 HTTP 500 오류를 반환하고 요청을 전달하지 않습니다. 로드 밸런서가 연결할 수 없는 경우에도 요청을 대상으로 전달해야 하는 경우 통합을 AWS WAF 활성화할 수 있습니다. AWS WAF로드 밸런서가 다음과 통합되는지 확인하려면 에서 로드 밸런서를 선택하고 통합 서비스 AWS Management Console 탭을 선택합니다. AWS WAF

사전 정의된 웹 ACL

AWS WAF 통합을 활성화할 때 사전 정의된 규칙을 사용하여 새 웹 ACL을 자동으로 생성하도록 선택할 수 있습니다. 사전 정의된 웹 ACL에는 가장 일반적인 보안 위협에 대한 보호를 제공하는 세 가지 AWS 관리형 규칙이 포함되어 있습니다.

• AWSManagedRulesAmazonIpReputationList‐ Amazon IP 평판 목록 규칙 그룹은 일반적으로 봇 또는 기타 위협과 관련된 IP 주소를 차단합니다. 자세한 내용은 AWS WAF 개발자 안내서의 Amazon IP 평판 목록 관리 규칙 그룹을 참조하십시오.

• AWSManagedRulesCommonRuleSet‐ 핵심 규칙 세트 (CRS) 규칙 그룹은 OWASP Top 10과 같은 OWASP 간행물에 설명된 고위험 및 일반적으로 발생하는 일부 취약성을 포함하여 광범위한 취약성 악용으로부터 보호합니다. 자세한 내용은 개발자 안내서의 핵심 규칙 세트 (CRS) 관리 규칙 그룹을 참조하십시오.AWS WAF

• AWSManagedRulesKnownBadInputsRuleSet‐ 알려진 잘못된 입력 규칙 그룹은 유효하지 않은 것으로 알려져 있고 취약성 악용 또는 발견과 관련된 요청 패턴을 차단합니다. 자세한 내용은 AWS WAF 개발자 안내서의 알려진 잘못된 입력 관리 규칙 그룹을 참조하십시오.

콘솔을 AWS WAF 사용하여 활성화하려면

1. https://console.aws.amazon.com/ec2/에서 Amazon EC2 콘솔을 엽니다.

2. 탐색 창에서 로드 밸런서를 선택합니다.

3. 로드 밸런서를 선택합니다.

4. 통합 탭에서 AWS 웹 애플리케이션 방화벽 (WAF) 을 확장하고 WAF 웹 ACL 연결을 선택합니다.

5. 웹 ACL에서 사전 정의된 웹 ACL 자동 생성을 선택하거나 기존 웹 ACL을 선택합니다.

6. 규칙 동작에서 차단 또는 개수를 선택합니다.

7. 확인을 선택합니다.

AWS WAF 페일을 활성화하려면 다음을 사용하여 엽니다. AWS CLI

waf.fail_open.enabled속성이 로 설정된 상태에서 modify-load-balancer-attributes명령을 사용합니다true.