Listeners para seu Application Load Balancers - Elastic Load Balancing

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Listeners para seu Application Load Balancers

Antes de começar a usar seu Application Load Balancer, você deve adicionar um ou maisouvintes. Listener é um processo que verifica a solicitações de conexão, usando o protocolo e a porta que você configurar. As regras que você define para um listener determinam como o load balancer roteia solicitações para seus destinos registrados.

Configuração do listener

Os listeners são compatíveis com os seguintes protocolos e portas:

  • Protocolos: HTTP, HTTPS

  • Portas: 1-65535

Você pode usar um listener HTTPS para redirecionar o trabalho de criptografia e descriptografia ao seu load balancer, de forma que os aplicativos possam se concentrar na respectiva lógica de negócios. Se o protocolo de listener for HTTPS, você deverá implantar pelo menos um certificado de servidor SSL no listener. Para obter mais informações, consulte Criar um listener HTTPS para seu Application Load Balancer.

Os Application Load Balancers oferecem suporte nativo para WebSockets. Você pode atualizar uma conexão HTTP/1.1 existente para um WebSocket (wsouwss) conexão usando uma atualização de conexão HTTP. Quando você atualiza, a conexão TCP usada para solicitações (para o balanceador de carga e para o destino) se torna persistente WebSocket Conexão entre o cliente e o destino por meio do load balancer. Você pode usar WebSockets Com listeners HTTP e HTTPS. As opções que você escolher para seu listener se aplicam a WebSocket conexões, bem como ao tráfego HTTP. Para obter mais informações, consulteComo o WebSocket Protocol funcionanoAmazônia CloudFront Guia do desenvolvedor.

Os Application Load Balancers oferecem suporte nativo para HTTP/2 com listeners HTTPS. Você pode enviar até 128 solicitações em paralelo usando uma conexão HTTP/2. Você pode usar a versão do protocolo para enviar a solicitação aos destinos usando HTTP/2. Para obter mais informações, consulte Versão do protocolo. Como HTTP/2 usa conexões front-end de forma mais eficiente, você pode perceber menos conexões entre clientes e o load balancer. Você não pode usar o recurso server-push do HTTP/2.

Para obter mais informações, consulteRoteamento de solicitaçãonoGuia do usuário do Elastic Load Balancing.

Regras do listener

Cada listener tem uma regra padrão, e você pode definir regras adicionais. Cada regra consiste em uma prioridade, uma ou mais ações e uma ou mais condições. Você pode adicionar ou editar regras a qualquer momento. Para obter mais informações, consulte Editar uma regra.

Regras padrão

Ao criar um listener, você define as ações para a regra padrão. As regras padrão não podem ter condições. Se nenhuma das condições das regras do listener for atendida, a ação para a regra padrão será executada.

Veja a seguir um exemplo de uma regra padrão como mostrado no console:


                    A regra padrão para um ouvinte.

Prioridade das regras

Cada regra tem uma prioridade. As regras são avaliadas em ordem de prioridade, do valor mais baixo para o valor mais alto. A regra padrão é avaliada por último. Você pode alterar a prioridade de uma regra não padrão a qualquer momento. Você não pode alterar a prioridade da regra padrão. Para obter mais informações, consulte Reordenar regras.

Ações da regra

Toda ação de regra tem um tipo, uma ordem e as informações necessárias para execução da ação. Para obter mais informações, consulte Tipos de ação da regra.

Condições da regra

Cada condição de regra possui um tipo e informações de configuração. Quando as condições de uma regra forem atendidas, a ação será executada. Para obter mais informações, consulte Tipos de condição de regra.

Tipos de ação da regra

Veja a seguir os tipos de ação compatíveis para uma regra de listener:

authenticate-cognito

[Listeners HTTPS] Usa o Amazon Cognito para autenticar usuários. Para obter mais informações, consulte Autenticar usuários usando um Application Load Balancer.

authenticate-oidc

[Listeners HTTPS] Usa um provedor de identidade compatível com OpenID Connect (OIDC) para autenticar usuários.

fixed-response

Retorna uma resposta HTTP personalizada. Para obter mais informações, consulte Ações de resposta fixa.

forward

Encaminha as solicitações para os grupos de destino especificados. Para obter mais informações, consulte Ações progressivas.

redirect

Redireciona solicitações de um URL para outro. Para obter mais informações, consulte Ações de redirecionamento.

A ação com a ordem de menor valor é executada primeiro. Cada regra deve incluir exatamente uma das seguintes ações: forward, redirect ou fixed-response e deve ser a última ação a ser executada.

Se a versão do protocolo for gRPC ou HTTP/2, as únicas ações suportadas serãoforwardações.

Ações de resposta fixa

Você pode usar ações de fixed-response para descartar solicitações do cliente e retornar uma resposta HTTP personalizada. Você pode usar essa ação para retornar um código de resposta 2XX, 4XX e 5XX e uma mensagem opcional.

Quando uma ação de fixed-response é executada, a ação e o URL do destino do redirecionamento são registrados no logs de acesso. Para obter mais informações, consulte Entradas do log de acesso. A contagem de ações de fixed-response com êxito é relatada na métrica HTTP_Fixed_Response_Count. Para obter mais informações, consulte Métricas do Application Load Balancer.

exemplo Exemplo de ação de resposta fixa para oAWS CLI

Você pode especificar uma ação ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A ação a seguir envia uma resposta fixa com o código de status e o corpo da mensagem especificados.

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

Ações progressivas

É possível usar ações forward a fim de rotear solicitações para um ou mais grupos de destino. Se especificar vários grupos de destino para uma ação forward, você deverá especificar um peso para cada grupo de destino. Cada peso de grupo de destino é um valor de 0 a 999. As solicitações que correspondem a uma regra de listener com grupos de destino ponderados são distribuídas para esses grupos de destino com base em seus pesos. Por exemplo, se você especificar dois grupos de destino, cada um com um peso de 10, cada grupo de destino receberá metade das solicitações. Se você especificar dois grupos de destino, um com peso de 10 e o outro com peso de 20, o grupo de destino com peso de 20 receberá duas vezes mais solicitações do que o outro grupo de destino.

Por padrão, configurar uma regra para distribuir o tráfego entre grupos de destino ponderados não garante que as sticky sessions sejam honradas. Para garantir que as sticky sessions sejam honradas, habilite a perdurabilidade do grupo de destino para a regra. Quando o load balancer primeiro roteia uma solicitação para um grupo de destino ponderado, ele gera um cookie chamado AWSALBTG Que codifica informações sobre o grupo de destino selecionado, criptografa o cookie e inclui o cookie na resposta ao cliente. O cliente deve incluir o cookie recebido nas solicitações subsequentes ao load balancer. Quando o load balancer recebe uma solicitação que corresponde a uma regra com a perdurabilidade do grupo de destino habilitada e contém o cookie, a solicitação é roteada para o grupo de destino especificado no cookie.

Os Application Load Balancers não comportam valores de cookie codificados por URL.

Com solicitações de CORS (cross-origin resource sharing, compartilhamento de recursos de origem cruzada), alguns navegadores exigem SameSite=None; Secure para habilitar a perdurabilidade. Nesse caso, o Elastic Load Balancing gera um segundo cookie, AWSALBTGCORS, que inclui as mesmas informações que o cookie de perdurabilidade original, além desteSameSiteAttribute. Os clientes recebem ambos os cookies.

exemplo Exemplo de ação para a frente com um grupo-alvo

Você pode especificar uma ação ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A ação a seguir encaminha solicitações para o grupo de destino especificado.

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

exemplo Exemplo de ação direta com dois grupos-alvo ponderados

A ação a seguir encaminha solicitações para os dois grupos de destino especificados, com base no peso de cada grupo de destino.

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ] } } ]

exemplo Exemplo de ação de encaminhamento com a aderência ativada

Se você tiver uma ação de encaminhamento com vários grupos de destino e um ou mais grupos de destino tiversticky sessionshabilitado, é necessário habilitar a adesão do grupo de destino.

A ação a seguir encaminha solicitações para os dois grupos de destino especificados, com a perdurabilidade do grupo de destino habilitada. As solicitações que não contêm os cookies de perdurabilidade são roteadas com base no peso de cada grupo de destino.

[ { "Type": "forward", "ForwardConfig": { "TargetGroups": [ { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/blue-targets/73e2d6bc24d8a067", "Weight": 10 }, { "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/green-targets/09966783158cda59", "Weight": 20 } ], "TargetGroupStickinessConfig": { "Enabled": true, "DurationSeconds": 1000 } } } ]

Ações de redirecionamento

Você pode usar ações de redirect para redirecionar solicitações de clientes de um URL para outro. Você pode configurar redirecionamentos como temporários (HTTP 302) ou permanentes (HTTP 301) com base em suas necessidades.

Um URI consiste nos seguintes componentes:

protocol://hostname:port/path?query

Você deve modificar pelo menos um dos seguintes componentes para evitar um loop de redirecionamento: protocolo, nome do host, porta ou caminho. Todos os componentes que você não modificar manterão seus valores originais.

protocolo

O protocolo (HTTP or HTTPS). Você pode redirecionar HTTP para HTTP, HTTP para HTTPS e HTTPS para HTTPS. Você não pode redirecionar HTTPS para HTTP.

hostname

O nome do host. Um nome de host não diferencia maiúsculas de minúsculas, pode ter até 128 caracteres e consiste em caracteres alfanuméricos, curingas (* e ?) e hifens (-).

port

A porta (1 a 65535).

path

O caminho absoluto, começando com a "/" inicial. Um caminho diferencia maiúsculas de minúsculas, pode ter até 128 caracteres e consiste em caracteres alfanuméricos, curingas (* e ?), & (usando &) e nos seguintes caracteres especiais: _-.$/~"'@:+.

query

Os parâmetros da consulta. O tamanho máximo é 128 caracteres.

Você pode reutilizar os componentes do URI do URL original no URL de destino usando as seguintes palavras-chave reservadas:

  • #{protocol} – mantém o protocolo. Use no protocolo e nos componentes de consulta.

  • #{host} – mantém o domínio. Use no nome de host, no caminho e nos componentes de consulta.

  • #{port} – mantém a porta. Use na porta, no caminho e nos componentes de consulta.

  • #{path} – mantém o caminho. Use no caminho e nos componentes de consulta.

  • #{query} – mantém os parâmetros da consulta. Use no componente de consulta.

Quando uma ação de redirect é executada, a ação é registrada nos logs de acesso. Para obter mais informações, consulte Entradas do log de acesso. A contagem de ações de redirect com êxito é relatada na métrica HTTP_Redirect_Count. Para obter mais informações, consulte Métricas do Application Load Balancer.

exemplo Exemplo de ações de redirecionamento usando o console

A regra a seguir define um redirecionamento permanente para um URL que usa o protocolo HTTPS e a porta especificada (40443), mas mantém o nome do host, o caminho e os parâmetros de consulta originais. Esta tela é equivalente a "https://#{host}:40443/#{path}?#{query}".


                        Uma regra que redireciona a solicitação para um URL que usa o protocolo HTTPS e a porta especificada (40443), mas mantém o domínio, o caminho e os parâmetros de consulta originais do URL original.

A seguinte regra define um redirecionamento permanente para um URL que usa o protocolo, a porta, nome de host e os parâmetros de consulta originais, e usa a palavra-chave #{path} para criar um caminho modificado. Esta tela é equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".


                        Uma regra que redireciona a solicitação para um URL que mantém o protocolo original, a porta, nome de host e os parâmetros de consulta, e usa o#{path}palavra-chave para criar um caminho modificado.

exemplo Exemplo de ação de redirecionamento para oAWS CLI

Você pode especificar uma ação ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A ação a seguir redireciona uma solicitação HTTP para uma solicitação HTTPS na porta 443, com o mesmo nome de host, caminho e string de consulta que a solicitação HTTP.

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

Tipos de condição de regra

Veja a seguir os tipos de condição compatíveis para uma regra:

host-header

Rota com base no nome do host de cada solicitação. Para obter mais informações, consulte Condições do host.

http-header

Rota com base nos cabeçalhos HTTP de cada solicitação. Para obter mais informações, consulte Condições do cabeçalho HTTP.

http-request-method

Rota com base no método de solicitação HTTP de cada solicitação. Para obter mais informações, consulte Condições do método de solicitação HTTP.

path-pattern

Rota com base nos padrões de caminho nos URLs de solicitação. Para obter mais informações, consulte Condições do caminho.

query-string

Rota com base em pares de chave/valor ou valores nas strings de consulta. Para obter mais informações, consulte Condições da string de consulta.

source-ip

Rota com base no endereço IP de origem de cada solicitação. Para obter mais informações, consulte Condições de endereço IP de origem.

Cada regra pode, opcionalmente, incluir até uma de cada uma das seguintes condições: host-header, http-request-method, path-pattern e source-ip. Cada regra também pode, opcionalmente, incluir uma ou mais de cada uma das seguintes condições: http-header e query-string.

Você pode especificar até três avaliações de correspondência por condição. Por exemplo, para cada condição http-header, você pode especificar até três strings para serem comparadas ao valor do cabeçalho HTTP na solicitação. A condição é atendida se uma das strings corresponder ao valor do cabeçalho HTTP. Para exigir que todas as strings sejam uma correspondência, crie uma condição por avaliação de correspondência.

Você pode especificar até cinco avaliações de correspondência por regra. Por exemplo, você pode criar uma regra com cinco condições em que cada condição tenha uma avaliação de correspondência.

Você pode incluir caracteres curinga nas avaliações de correspondência para as condições http-header, host-header, path-pattern e query-string. Existe um limite de cinco caracteres curinga por regra.

As regras são aplicadas apenas a caracteres ASCII visíveis; caracteres de controle (0x00 a 0x1f e 0x7f) são excluídos.

Para demonstrações, consulteRoteamento avançado de solicitação.

Condições do cabeçalho HTTP

Você pode usar condições de cabeçalho HTTP para configurar regras que roteiam solicitações com base nos cabeçalhos HTTP da solicitação. Você pode especificar os nomes dos campos de cabeçalho HTTP padrão ou personalizados. O nome do cabeçalho e a avaliação de correspondência não diferenciam maiúsculas de minúsculas. Os caracteres curinga a seguir são compatíveis com as strings de comparação: * (corresponde a 0 ou mais caracteres) e ? (corresponde exatamente a 1 caractere). Caracteres curinga não são compatíveis com o nome do cabeçalho.

exemplo Exemplo de condição de cabeçalho HTTP para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações com um cabeçalho User-Agent que corresponda a uma das strings especificadas.

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

Condições do método de solicitação HTTP

Você pode usar condições do método de solicitação HTTP para configurar regras que roteiam solicitações com base no método de solicitação HTTP da solicitação. Você pode especificar métodos HTTP padrão ou personalizados. A avaliação de correspondência faz distinção entre maiúsculas e minúsculas. Caracteres curinga não são compatíveis; portanto, o nome do método deve ser uma correspondência exata.

Recomendamos que você roteie as solicitações GET e HEAD da mesma maneira, porque a resposta a uma solicitação HEAD pode ser armazenada em cache.

exemplo Exemplo de condição do método HTTP para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações que usam o método especificado.

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

Condições do host

Você pode usar as condições do host para definir regras que roteiam solicitações com base no nome do host no cabeçalho de host (também conhecido como roteamento baseado em host). Isso permite que você ofereça suporte a vários subdomínios e domínios de nível superior diferentes usando um único load balancer.

Um nome de host não diferencia maiúsculas de minúsculas, pode ter até 128 caracteres e conter qualquer um dos caracteres a seguir:

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

  • - .

  • * (corresponde a 0 ou mais caracteres)

  • ? (corresponde a exatamente 1 caractere)

É necessário incluir pelo menos um caractere ".". Você pode incluir somente caracteres alfabéticos após o "." final.

Por exemplo, os hostnames

  • example.com

  • test.example.com

  • *.example.com

A regra *.example.com corresponde a test.example.com, mas não corresponde a example.com.

exemplo Exemplo de condição de cabeçalho do host para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações com um cabeçalho de host que corresponda à string especificada.

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

Condições do caminho

Você pode usar as condições de caminho para definir regras que roteiam solicitações com base no URL da solicitação (também conhecido como roteamento baseado em caminho).

O padrão de caminho é aplicado apenas ao caminho do URL, não aos seus parâmetros de consulta. Ele é aplicado somente a caracteres ASCII visíveis; caracteres de controle (0x00 a 0x1f e 0x7f) são excluídos.

O padrão do caminho diferencia maiúsculas de minúsculas, pode ter até 128 caracteres e conter qualquer um dos caracteres a seguir.

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

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

  • & (usando &)

  • * (corresponde a 0 ou mais caracteres)

  • ? (corresponde a exatamente 1 caractere)

Se a versão do protocolo for gRPC, as condições podem ser específicas para um pacote, serviço ou método.

Exemplo de padrões de caminho HTTP

  • /img/*

  • /img/*/pics

Exemplo de padrões de caminho do gRPC

  • /package

  • /package.service

  • /package.service/método

O caminho padrão é usado para rotear as solicitações, mas não as altera. Por exemplo, se uma regra tiver um padrão de caminho de/img/*, a regra encaminha uma solicitação para/img/picture.jpgPara o grupo de destino especificado como uma solicitação para/img/picture.jpg.

exemplo Exemplo de condição de padrão de caminho para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações com um URL que contém a string especificada.

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

Condições da string de consulta

Você pode usar condições de string de consulta para configurar regras que roteiam solicitações com base em pares de chave/valor ou valores na string de consulta. A avaliação de correspondência não diferencia maiúsculas de minúsculas. Os caracteres curinga a seguir são compatíveis: * (corresponde a 0 ou mais caracteres) e ? (corresponde exatamente a 1 caractere).

exemplo Exemplo de condição de string de consulta para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações com uma string de consulta que inclui um par de chave/valor de "version=v1" ou qualquer chave definida como "example".

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

Condições de endereço IP de origem

Você pode usar condições de endereço IP de origem para configurar regras que roteiam solicitações com base no endereço IP de origem da solicitação. O endereço IP deve ser especificado no formato CIDR. Você pode usar endereços IPv4 e IPv6. Caracteres curinga não são compatíveis. Você não pode especificar o255.255.255.255/32CIDR para a condição de regra de IP de origem.

Se um cliente estiver por trás de um proxy, este é o endereço IP do proxy e não o endereço IP do cliente.

Essa condição não é atendida pelos endereços no cabeçalho X-Forwarded-For. Para procurar endereços no cabeçalho X-Forwarded-For, use uma condição http-header.

exemplo Exemplo de condição de IP de origem para oAWS CLI

Você pode especificar condições ao criar ou modificar uma regra. Para obter mais informações, consulte os comandos create-rule e modify-rule. A condição a seguir é atendida por solicitações com um endereço IP de origem em um dos blocos CIDR especificados.

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