Configuração do receptor Regras do listener Tipos de ação de regra Tipos de condição de regra

Receptores para seus Application Load Balancers

Um receptor é um processo que verifica solicitações de conexão usando o protocolo e a porta configurados por você. Antes de começar a usar seu Application Load Balancer, você deve adicionar ao menos um receptor. Se seu balanceador de carga não tiver receptores, ele não poderá receber tráfego dos clientes. As regras que você define para seus receptores determinam como o balanceador de carga roteia solicitações para os destinos registrados, como instâncias do EC2.

Conteúdo

Configuração do receptor

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

Protocolos: HTTP, HTTPS
Ports (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 ter mais informações, consulte Criar um receptor HTTPS para seu Application Load Balancer.

Se você precisar garantir que os destinos descriptografem o tráfego HTTPS em vez do balanceador de carga, é possível criar um Network Load Balancer com um receptor TCP na porta 443. Com um receptor TCP, o balanceador de carga transmite o tráfego criptografado para os destinos sem descriptografá-lo. Para obter mais informações, consulte o Guia do usuário de network load balancers.

Os Application Load Balancers fornecem suporte nativo para WebSockets. Você pode atualizar uma conexão HTTP/1.1 existente em uma conexão WebSocket (wsouwss) 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 uma WebSocket conexão persistente entre o cliente e o destino por meio do balanceador de carga. Você pode usar WebSockets com ouvintes HTTP e HTTPS. As opções que você escolhe para seu ouvinte se aplicam às WebSocket conexões e ao tráfego HTTP. Para obter mais informações, consulte Como o WebSocket protocolo funciona no Amazon CloudFront Developer Guide.

Application Load Balancers têm compatibilidade nativa para HTTP/2 com receptores 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 ter 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, consulte Roteamento de solicitação no Guia do usuário do Elastic Load Balancing.

Regras do listener

Cada receptor tem uma ação padrão, também conhecida como regra padrão. Não é possível excluir a regra padrão e ela sempre é executada por último. É possível criar regras adicionais e elas consistirão em uma prioridade, uma ou mais ações e uma ou mais condições. Você pode adicionar ou editar regras a qualquer momento. Para ter 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:

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 ter mais informações, consulte Atualizar prioridade de regra.

Ações de regra

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

Condições de 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 ter mais informações, consulte Tipos de condição de regra.

Tipos de ação de regra

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

authenticate-cognito: [Receptores HTTPS] Use o Amazon Cognito para autenticar usuários. Para ter 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 ter mais informações, consulte Ações de resposta fixa.
forward: Encaminha as solicitações para os grupos de destino especificados. Para ter mais informações, consulte Ações de encaminhamento.
redirect: Redireciona solicitações de um URL para outro. Para ter mais informações, consulte Ações de redirecionamento.

A ação com a menor prioridade é 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 compatíveis serão ações forward.

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 ter 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 ter mais informações, consulte Métricas do Application Load Balancer.

exemplo Exemplo de ação de resposta fixa para a AWS 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 de encaminhamento

É 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 balanceador de carga encaminha pela primeira vez uma solicitação para um grupo-alvo ponderado, ele gera um cookie chamado AWSALBTG que codifica informações sobre o grupo-alvo 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 são compatíveis com 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 do cookie de aderência original mais esse atributo. SameSite Os clientes recebem ambos os cookies.

exemplo Exemplo de ação de encaminhamento com um grupo de destino

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 de encaminhamento com dois grupos ponderados de destino

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 perdurabilidade habilitada

Se você tiver uma regra de encaminhamento com vários grupos de destino e um ou mais grupos de destino tiver sessões persistentes habilitadas, você deverá habilitar a perdurabilidade 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 (-).
porta: A porta (1 a 65535).
caminho: 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: _-.$/~"'@:+.
consulta: 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 ter 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 ter 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}".

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}".

exemplo Exemplo de ação de redirecionamento para a AWS 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 ter mais informações, consulte Condições do host.
http-header: Rota com base nos cabeçalhos HTTP de cada solicitação. Para ter mais informações, consulte Condições de cabeçalho HTTP.
http-request-method: Rota com base no método de solicitação HTTP de cada solicitação. Para ter 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 ter 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 ter mais informações, consulte Condições de string de consulta.
source-ip: Rota com base no endereço IP de origem de cada solicitação. Para ter 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, consulte Roteamento avançado de solicitação.

Condições de 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 a AWS 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 a AWS CLI


[
  {
      "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 a diferentes domínios de nível superior usando um só balanceador de carga.

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 de host para a AWS CLI


[
  {
      "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.

A avaliação da regra é realizada somente após a normalização do URI ocorrer.

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 de um pacote, serviço ou método.

Exemplos de padrões de caminho HTTP

/img/*
/img/*/pics

Exemplos de padrões de caminho gRPC

/package
/package.service
/package.service/method

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 /img/*, a regra encaminhará uma solicitação de /img/picture.jpg ao grupo de destino especificado como uma solicitação para /img/picture.jpg.

exemplo Exemplo de condição de padrão de caminho para a AWS CLI


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

Condições de 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 a AWS 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 o CIDR 255.255.255.255/32 para a condição da 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 a AWS 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"]
      }
  }
]

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Mudança de zona

Criar um receptor HTTP