Elastic Load Balancing
Application Load Balancer

애플리케이션 로드 밸런서를 위한 리스너

Application Load Balancer를 사용하기 전에 먼저 하나 이상의 리스너를 추가해야 합니다. 리스너는 구성한 프로토콜 및 포트를 사용하여 연결 요청을 확인하는 프로세스입니다. 리스너에 대해 정의한 규칙에 따라 로드 밸런서가 하나 이상의 대상 그룹에서 대상으로 요청을 라우팅하는 방법이 결정됩니다.

리스너 구성

리스너는 다음과 같은 프로토콜 및 포트를 지원합니다.

  • 프로토콜: HTTP, HTTPS

  • 포트: 1-65535

애플리케이션이 비즈니스 로직에 집중할 수 있도록 HTTPS 리스너를 사용하여 암호화 및 암호 해독 작업을 로드 밸런서로 오프로드할 수 있습니다. 리스너 프로토콜이 HTTPS인 경우에는 리스너에 한 개 이상의 SSL 서버 인증서를 반드시 배포해야 합니다. 자세한 정보는 Application Load Balancer용 HTTPS 리스너 생성 단원을 참조하십시오.

Application Load Balancer는 WebSockets에 대한 기본 지원을 제공합니다. HTTP 및 HTTPS 리스너 모두에서 WebSockets를 사용할 수 있습니다.

Application Load Balancer는 HTTPS 리스너에서 HTTP/2에 대한 기본 지원을 제공합니다. 하나의 HTTP/2 연결을 이용해 최대 128개의 요청을 동시에 전송할 수 있습니다. 로드 밸런서는 이러한 요청을 개별 HTTP/1.1 요청으로 변환하고 대상 그룹의 정상 상태 대상 간에 배포합니다. HTTP/2는 프런트 엔드 연결을 보다 효율적으로 사용하기 때문에 클라이언트와 로드 밸런서 간의 연결을 줄일 수 있습니다. HTTP/2의 서버 푸시 기능을 사용할 수 없습니다.

자세한 내용은 Elastic Load Balancing 사용 설명서라우팅 요청을 참조하십시오.

리스너 규칙

각 리스너는 기본 규칙을 가지고 있으며, 선택에 따라 추가 규칙을 정의할 수 있습니다. 각 규칙은 우선 순위, 하나 이상의 작업, 하나 이상의 조건으로 구성됩니다. 언제든 규칙을 추가하거나 편집할 수 있습니다. 자세한 내용은 규칙 편집 단원을 참조하십시오.

기본 규칙

리스너를 생성할 때 기본 규칙에 대한 작업을 정의합니다. 기본 규칙은 조건을 가질 수 없습니다. 리스너의 규칙에 대한 조건이 충족되지 않으면 기본 규칙에 대해 작업이 수행됩니다.

다음은 콘솔에 나타난 기본 규칙을 보여줍니다.


                    리스너를 위한 기본값 규칙.

규칙 우선 순위

각 규칙마다 우선 순위가 있습니다. 규칙은 가장 낮은 값에서 가장 높은 값에 이르기까지 우선 순위에 따라 평가됩니다. 기본 규칙은 마지막에 평가됩니다. 기본이 아닌 규칙의 우선 순위는 언제든지 변경이 가능합니다. 기본 규칙의 우선 순위는 변경할 수 없습니다. 자세한 내용은 규칙 재정렬 단원을 참조하십시오.

규칙 작업

각 규칙 작업에는 작업을 수행하는 데 필요한 유형, 순서 및 정보가 있습니다. 자세한 내용은 규칙 작업 유형 단원을 참조하십시오.

규칙 조건

각 규칙 조건에는 유형과 구성 정보가 있습니다. 규칙에 대한 조건이 충족되면 작업이 수행됩니다. 자세한 내용은 규칙 조건 형식 단원을 참조하십시오.

규칙 작업 유형

규칙에 대해 지원되는 작업 유형은 다음과 같습니다.

authenticate-cognito

[HTTPS 리스너] Amazon Cognito를 사용하여 사용자를 인증합니다. 자세한 내용은 Application Load Balancer를 사용하여 사용자 인증 단원을 참조하십시오.

authenticate-oidc

[HTTPS 리스너] OpenID Connect(OIDC)와 호환되는 자격 증명 공급자를 사용하여 사용자를 인증합니다.

fixed-response

사용자 지정 HTTP 응답을 반환합니다. 자세한 내용은 고정 응답 작업 단원을 참조하십시오.

forward

요청을 지정된 대상 그룹으로 전달합니다.

redirect

한 URL의 요청을 다른 URL로 리디렉션합니다. 자세한 내용은 리디렉션 작업 단원을 참조하십시오.

가장 낮은 순서 값이 있는 작업이 첫 번째로 수행됩니다. 각 규칙에는 forward, redirect 또는 fixed-response 작업 중 하나가 꼭 포함되어 있어야 하며, 이 작업이 수행할 마지막 작업이어야 합니다.

고정 응답 작업

fixed-response 작업을 사용하여 클라이언트 요청을 삭제하고 사용자 지정 HTTP 응답을 반환할 수 있습니다. 이 작업을 사용하여 2XX, 4XX, 5XX 응답 코드와 선택적 메시지를 반환할 수 있습니다.

fixed-response 작업이 수행되면 해당 작업과 리디렉션 대상의 URL이 액세스 로그에 기록됩니다. 자세한 내용은 액세스 로그 항목 섹션을 참조하십시오. 성공한 fixed-response 작업의 개수는 HTTP_Fixed_Response_Count 지표에 보고됩니다. 자세한 내용은 Application Load Balancer 지표을(를) 참조하십시오.

예 AWS CLI의 고정 응답 작업 예

규칙을 만들거나 수정할 때 작업을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 작업은 지정된 상태 코드와 메시지 본문이 있는 고정 응답을 보냅니다.

[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]

전달 작업

forward 작업을 사용하여 요청을 지정된 대상 그룹으로 라우팅할 수 있습니다.

예 AWS CLI의 Forward 작업 예

규칙을 만들거나 수정할 때 작업을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 작업은 요청을 지정된 대상 그룹으로 전달합니다.

[ { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a06" } ]

리디렉션 작업

redirect 작업을 사용하여 한 URL의 클라이언트 요청을 다른 URL로 리디렉션할 수 있습니다. 요구 사항에 따라 리디렉션을 임시(HTTP 302) 또는 영구(HTTP 301)로 구성할 수 있습니다.

URI는 다음과 같은 구성 요소로 이루어집니다.

protocol://hostname:port/path?query

리디렉션 루프를 피하기 위해 프로토콜, 호스트 이름 포트, 경로 중 최소 하나를 수정해야 합니다. 수정하지 않은 구성 요소는 원래 값을 유지합니다.

protocol

프로토콜(HTTP 또는 HTTPS)입니다. HTTP를 HTTP로, HTTP를 HTTPS로, HTTPS를 HTTPS로 리디렉션할 수 있습니다. HTTPS를 HTTP로 리디렉션할 수는 없습니다.

hostname

호스트 이름입니다. 호스트 이름은 대/소문자를 구분하지 않고, 길이가 최대 128자일 수 있으며, 영숫자, 와일드카드(* 및 ?), 하이픈(-)으로 구성됩니다.

port

포트입니다(1~65535).

경로

"/"로 시작하는 절대 경로입니다. 경로는 대/소문자를 구분하고, 길이가 최대 128자일 수 있으며, 영숫자, 와일드카드(* 및 ?), &(& 사용), 특수 문자 _-.$/~"'@:+로 구성됩니다.

query

쿼리 파라미터입니다

다음 예약 키워드를 사용하여 원래 URL의 URI 구성 요소를 대상 URL에 다시 사용할 수 있습니다.

  • #{protocol} - 프로토콜을 포함합니다. protocol 및 query 구성 요소에 사용합니다.

  • #{host} - 도메인을 포함합니다. hostname, path, query 구성 요소에 사용합니다.

  • #{port} - 포트를 포함합니다. port, path, query 구성 요소에 사용합니다.

  • #{path} - 경로를 포함합니다. path 및 query 구성 요소에 사용합니다.

  • #{query} - 쿼리 파라미터를 포함합니다. query 구성 요소에 사용합니다.

redirect작업이 수행되면 액세스 로그에 작업이 기록됩니다. 자세한 내용은 액세스 로그 항목 섹션을 참조하십시오. 성공한 redirect 작업의 개수는 HTTP_Redirect_Count 지표에 보고됩니다. 자세한 내용은 Application Load Balancer 지표을(를) 참조하십시오.

예 콘솔을 사용한 리디렉션 작업 예

다음 규칙은 HTTPS 프로토콜과 지정된 포트(40443)를 사용하는 URL로의 영구 리디렉션을 설정하지만, 원래 호스트 이름, 경로, 쿼리 파라미터를 포함합니다. 이 화면은 "https://#{host}:40443/#{path}?#{query}"와 동일합니다.


                         HTTPS 프로토콜과 지정된 포트(40443)를 사용하는 URL로 요청을 리디렉션하지만, 원본 URL의 원본 도메인, 원본 경로, 원본 쿼리 파라미터를 포함하는 규칙입니다.

다음 규칙은 원래 프로토콜, 포트, 호스트 이름, 쿼리 파라미터를 포함하는 URL로의 영구 리디렉션을 설정하고, #{path} 키워드를 사용하여 수정된 경로를 생성합니다. 이 화면은 "#{protocol}://#{host}:#{port}/new/#{path}?#{query}"와 동일합니다.


                         원본 프로토콜, 원본 포트, 원본 호스트 이름, 원본 쿼리 파라미터를 포함하는 URL로 요청을 리디렉션하고, #{path} 키워드를 사용하여 수정된 경로를 생성하는 규칙입니다.

예 AWS CLI의 리디렉션 작업 예

규칙을 만들거나 수정할 때 작업을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 작업은 포트 443에서 HTTP 요청을 HTTPS 요청으로 리디렉션합니다. 호스트 이름, 경로, 쿼리 문자열은 HTTP 요청과 동일합니다.

[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]

규칙 조건 형식

규칙에 대해 지원되는 조건 형식은 다음과 같습니다.

host-header

각 요청의 호스트 이름을 기반으로 라우팅합니다. 자세한 내용은 호스트 조건 단원을 참조하십시오.

http-header

각 요청의 HTTP 헤더를 기반으로 라우팅합니다. 자세한 내용은 HTTP 헤더 조건 단원을 참조하십시오.

http-request-method

각 요청의 HTTP 요청 메서드를 기반으로 라우팅합니다. 자세한 내용은 HTTP 요청 메서드 조건 단원을 참조하십시오.

path-pattern

요청 URL의 경로 패턴을 기반으로 라우팅합니다. 자세한 내용은 경로 조건 단원을 참조하십시오.

query-string

쿼리 문자열의 키/값 페어 또는 값을 기반으로 라우팅합니다. 자세한 내용은 쿼리 문자열 조건 단원을 참조하십시오.

source-ip

각 요청의 소스 IP 주소를 기반으로 라우팅합니다. 자세한 내용은 소스 IP 주소 조건 단원을 참조하십시오.

각 규칙에는 host-header, http-request-method, path-pattern, source-ip 조건 중 0개 또는 1개가 포함될 수 있으며, http-headerquery-string 조건 중 0개 이상이 포함될 수 있습니다.

조건당 최대 3개의 일치 평가를 지정할 수 있습니다. 예를 들어 각 http-header 조건에 대해 요청의 HTTP 헤더 값과 비교할 최대 3개의 문자열을 지정할 수 있습니다. 문자열 중 하나가 HTTP 헤더 값과 일치하면 조건이 충족됩니다. 모든 문자열이 일치하도록 요구하려면 일치 평가마다 조건 하나를 만듭니다.

규칙당 최대 5개의 일치 평가를 지정할 수 있습니다. 예를 들어 조건 5개 각각에 일치 평가가 하나씩 있는 규칙을 만들 수 있습니다.

http-header, host-header, path-pattern, query-string 조건의 일치 평가에 와일드카드 문자를 포함시킬 수 있습니다. 규칙당 와일드카드 문자는 5개로 제한됩니다.

HTTP 헤더 조건

HTTP 헤더 조건을 사용하여 요청의 HTTP 헤더를 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. 표준 또는 사용자 지정 HTTP 헤더 필드의 이름을 지정할 수 있습니다. 헤더 이름과 일치 평가는 대/소문자를 구분하지 않습니다. 비교 문자열에서는 *(0개 이상의 문자 일치) 및 ?(정확히 1자 일치) 와일드카드 문자가 지원됩니다. 와일드카드 문자는 헤더 이름에서는 지원되지 않습니다.

예 AWS CLI의 HTTP 헤더 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 지정된 문자열 중 하나와 일치하는 User-Agent 헤더가 있는 요청에 의해 충족됩니다.

[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]

HTTP 요청 메서드 조건

HTTP 요청 메서드 조건을 사용하여 요청의 HTTP 요청 메서드를 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. 표준 또는 사용자 지정 HTTP 메서드를 지정할 수 있습니다. 일치 평가는 대/소문자를 구분합니다. 와일드카드 문자는 지원되지 않으므로 메서드 이름이 정확히 일치해야 합니다.

GET 및 HEAD 요청을 동일한 방식으로 라우팅하는 것이 좋습니다. HEAD 요청에 대한 응답이 캐싱될 수 있기 때문입니다.

예 AWS CLI의 HTTP 메서드 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 지정된 메서드를 사용하는 요청에 의해 충족됩니다.

[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["CUSTOM-METHOD"] } } ]

호스트 조건

호스트 조건을 사용하여 호스트 헤더의 호스트 이름을 기반으로 요청을 라우팅하는 규칙을 정의할 수 있습니다(호스트 기반 라우팅이라고도 함). 따라서 단일 로드 밸런서를 사용하여 여러 개의 도메인을 지원할 수 있습니다.

호스트 이름은 대/소문자를 구별하지 않고 최대 255자이며 다음과 같은 문자를 포함할 수 있습니다:

  • A–Z, a–z, 0–9

  • - .

  • * (0개 이상의 문자에 해당)

  • ?(정확히 1자 일치)

최소 "." 한 글자 포함해야 합니다. 마지막 "." 문자 다음에는 알파벳만 포함할 수 있습니다.

호스트 이름 예제

  • example.com

  • test.example.com

  • *.example.com

규칙 *.example.comtest.example.com과 일치하나 example.com과 일치하지 않습니다.

예 AWS CLI의 호스트 헤더 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 지정된 문자열과 일치하는 호스트 헤더가 있는 요청에 의해 충족됩니다.

[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } } ]

경로 조건

경로 조건을 사용하여 요청의 URL을 기반으로 요청을 라우팅하는 규칙을 정의할 수 있습니다(경로 기반 라우팅이라고도 함).

경로 패턴은 쿼리 파라미터가 아닌 URL의 경로에만 적용됩니다.

경로 이름은 대/소문자를 구별하지 않고 최대 128자이며 다음과 같은 문자를 포함할 수 있습니다.

  • A–Z, a–z, 0–9

  • _ - . $ / ~ " ' @ : +

  • &(& 사용)

  • * (0개 이상의 문자에 해당)

  • ?(정확히 한 글자에 해당)

경로 패턴 예제

  • /img/*

  • /js/*

경로 패턴은 요청을 라우팅하는 데 사용되지만 요청을 변경하지 않습니다. 예를 들어 /img/*라는 경로 패턴을 가진 규칙은 /img/picture.jpg에 대한 요청을 /img/picture.jpg를 위한 요청으로서 지정된 대상 그룹에 전달합니다.

예 AWS CLI의 경로 패턴 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 지정된 문자열이 포함된 URL이 있는 요청에 의해 충족됩니다.

[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } } ]

쿼리 문자열 조건

쿼리 문자열 조건을 사용하여 쿼리 문자열의 키/값 페어 또는 값을 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. 일치 평가는 대/소문자를 구분하지 않습니다. *(0개 이상의 문자 일치) 및 ?(정확히 1자 일치) 와일드카드 문자가 지원됩니다.

예 AWS CLI의 쿼리 문자열 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 키/값 페어 "version=v1" 또는 “example”로 설정된 키가 포함된 쿼리 문자열이 있는 요청에 의해 충족됩니다.

[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Value": "example" } ] } } ]

소스 IP 주소 조건

소스 IP 주소 조건을 사용하여 요청의 소스 IP 주소를 기반으로 요청을 라우팅하는 규칙을 구성할 수 있습니다. IP 주소는 CIDR 형식으로 지정해야 합니다. IPv4 및 IPv6 주소를 모두 사용할 수 있습니다. 와일드카드 문자는 지원되지 않습니다.

클라이언트가 프록시 뒤에 있는 경우, 이는 클라이언트의 IP 주소가 아니라 프록시의 IP 주소입니다.

이 조건은 X-Forwarded-For 헤더의 주소에 의해 충족되지 않습니다. X-Forwarded-For 헤더에서 주소를 검색하려면 http-header 조건을 사용합니다.

예 AWS CLI의 소스 IP 조건 예

규칙을 만들거나 수정할 때 조건을 지정할 수 있습니다. 자세한 내용은 create-rulemodify-rule 명령을 참조하십시오. 다음 조건은 지정된 CIDR 블록 중 하나에 소스 IP 주소가 있는 요청에 의해 충족됩니다.

[ { "Field": "source-ip", "SourceIpConfig": { "Values": ["192.0.2.0/24", "198.51.100.10/32"] } } ]