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 ouvintes determinam como o balanceador de carga encaminha as solicitações para os destinos que você registra, como EC2 instâncias.

Configuração do receptor

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

Você pode usar um HTTPS ouvinte para transferir o trabalho de criptografia e decodificação para seu balanceador de carga, para que seus aplicativos possam se concentrar em sua lógica de negócios. Se o protocolo do ouvinte forHTTPS, você deverá implantar pelo menos um certificado de SSL servidor no ouvinte. Para obter mais informações, consulte Crie um HTTPS ouvinte para seu Application Load Balancer.

Se você precisar garantir que os destinos descriptografem o HTTPS tráfego em vez do balanceador de carga, você pode criar um Network Load Balancer com um ouvinte na porta 443. TCP Com um TCP ouvinte, o balanceador de carga passa o tráfego criptografado para os destinos sem decifrá-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 HTTP conexão. Quando você atualiza, a TCP conexão usada para solicitações (com o balanceador de carga e com 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 ambos HTTP e com HTTPS ouvintes. As opções que você escolhe para seu ouvinte se aplicam tanto às WebSocket conexões quanto ao HTTP tráfego. Para obter mais informações, consulte Como o WebSocket protocolo funciona no Amazon CloudFront Developer Guide.

Os Application Load Balancers fornecem suporte nativo para HTTP /2 com HTTPS ouvintes. 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 com mais eficiência, você pode notar menos conexões entre os clientes e o balanceador de carga. Você não pode usar o recurso server-push de /2. HTTP

Para obter mais informações, consulte Roteamento de solicitação no Guia do usuário do Elastic Load Balancing.

Atributos do receptor

A seguir estão os atributos do ouvinte para Application Load Balancers

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 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:

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 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 obter 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 obter 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:

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 g RPC ou HTTP /2, as únicas ações suportadas serão forward ações.

Ações de resposta fixa

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

Quando uma fixed-response ação é executada, a ação e a URL do alvo de redirecionamento são registradas nos registros 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.

[
  {
      "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 oferecem suporte a valores de cookie URL codificados.

Com solicitações CORS (compartilhamento de recursos entre origens), alguns navegadores precisam ativar SameSite=None; Secure a aderência. 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.

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

[
  {
      "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
              }
          ]
      }
  }
]

[
  {
      "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 redirect ações para redirecionar as solicitações do cliente de uma URL para outra. Você pode configurar redirecionamentos como temporários (HTTP302) ou permanentes (HTTP301) com base em suas necessidades.

A 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.

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

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 configura um redirecionamento permanente para um URL que usa o HTTPS protocolo 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 regra a seguir configura um redirecionamento permanente para um URL que retém o protocolo original, a porta, o nome do host e os parâmetros de consulta e usa a #{path} palavra-chave para criar um caminho modificado. Esta tela é equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".

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

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 http-header condição, você pode especificar até três cadeias de caracteres a serem comparadas ao valor do HTTP cabeçalho na solicitação. A condição é satisfeita se uma das cadeias corresponder ao valor do HTTP cabeçalho. 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 somente aos ASCII caracteres visíveis; os caracteres de controle (0x00 a 0x1f e 0x7f) são excluídos.

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

HTTPcondições do cabeçalho

Você pode usar condições de HTTP cabeçalho para configurar regras que roteiam solicitações com base nos HTTP cabeçalhos da solicitação. Você pode especificar os nomes dos campos de HTTP cabeçalho 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.

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

HTTPcondições do método de solicitação

Você pode usar as condições do método de HTTP solicitação para configurar regras que roteiam solicitações com base no HTTP método de solicitação da solicitação. Você pode especificar HTTP métodos 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 GET e HEAD solicite da mesma forma, pois a resposta a uma HEAD solicitação pode ser armazenada em cache.

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

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

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

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

Condições do caminho

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

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

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

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

Se a versão do protocolo for gRPC, as condições podem ser específicas de um pacote, serviço ou 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 /img/*, a regra encaminhará uma solicitação de /img/picture.jpg ao grupo de destino especificado como uma solicitação para /img/picture.jpg.

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

[
  {
      "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 CIDR formato. Você pode usar ambos IPv4 e IPv6 endereços. Caracteres curinga não são compatíveis. Você não pode especificar 255.255.255.255/32 CIDR 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 é satisfeita pelos endereços no X-Forwarded-For cabeçalho. Para pesquisar endereços no X-Forwarded-For cabeçalho, use uma http-header condição.

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

HTTPcabeçalhos e balanceadores de carga de aplicativos

HTTPsolicitações e HTTP respostas usam campos de cabeçalho para enviar informações sobre as HTTP mensagens. HTTPos cabeçalhos são adicionados automaticamente. Os campos de cabeçalho são pares de nome-valor separados por dois pontos e separados por um retorno de carro (CR) e um avanço de linha (LF). Um conjunto padrão de campos de HTTP cabeçalho é definido em RFC 2616, Cabeçalhos de mensagens. Também há HTTP cabeçalhos não padrão disponíveis que são adicionados automaticamente e amplamente usados pelos aplicativos. Alguns dos HTTP cabeçalhos não padrão têm um X-Forwarded prefixo. Os Application Load Balancers são compatíveis com os seguintes cabeçalhos X-Forwarded.

Para obter mais informações sobre HTTP conexões, consulte Roteamento de solicitações no Guia do Usuário do Elastic Load Balancing.

X-Forwarded-For

O cabeçalho da X-Forwarded-For solicitação ajuda a identificar o endereço IP de um cliente quando você usa um balanceador de HTTPS carga HTTP or. Como os balanceadores de carga interceptam o tráfego entre clientes e servidores, os logs de acesso do seu servidor vão conter apenas o endereço IP do balanceador de carga. Para ver o endereço IP do cliente, use o atributo routing.http.xff_header_processing.mode. Esse atributo permite que você modifique, preserve ou remova o X-Forwarded-For cabeçalho na HTTP solicitação antes que o Application Load Balancer envie a solicitação ao destino. Os valores possíveis para esse atributo são append, preserve e remove. O valor padrão desse atributo é append.

Anexar

Por padrão, o Application Load Balancer armazena o endereço IP do cliente no cabeçalho de solicitação X-Forwarded-For e encaminha o cabeçalho para o seu servidor. Se o cabeçalho de solicitação X-Forwarded-For não estiver incluído na solicitação original, o balanceador de carga criará um com o endereço IP do cliente como o valor da solicitação. Caso contrário, o balanceador de carga anexará o endereço IP do cliente ao cabeçalho existente e encaminhará o cabeçalho para o seu servidor. O cabeçalho de solicitação X-Forwarded-For pode conter vários endereços IP separados por vírgula.

O cabeçalho de solicitação X-Forwarded-For leva a seguinte forma:

X-Forwarded-For: client-ip-address

Veja a seguir um exemplo de cabeçalho de solicitação X-Forwarded-For para um cliente com o endereço IP 203.0.113.7.

X-Forwarded-For: 203.0.113.7

Veja a seguir um exemplo de cabeçalho de X-Forwarded-For solicitação para um cliente com IPv6 endereço de2001:DB8::21f:5bff:febf:ce22:8a2e.

X-Forwarded-For: 2001:DB8::21f:5bff:febf:ce22:8a2e

Quando o atributo de preservação da porta do cliente (routing.http.xff_client_port.enabled) estiver habilitado no balanceador de carga, o cabeçalho X-Forwarded-For da solicitação incluirá o client-port-number anexado ao client-ip-address, separado por dois pontos. Em seguida, o cabeçalho adotará a seguinte forma:

IPv4 -- X-Forwarded-For: client-ip-address:client-port-number

IPv6 -- X-Forwarded-For: [client-ip-address]:client-port-number

PoisIPv6, observe que quando o balanceador de carga anexa o client-ip-address ao cabeçalho existente, ele coloca o endereço entre colchetes.

Veja a seguir um exemplo de cabeçalho de X-Forwarded-For solicitação para um cliente com IPv4 endereço 12.34.56.78 e número de porta de8080.

X-Forwarded-For: 12.34.56.78:8080

Veja a seguir um exemplo de cabeçalho de X-Forwarded-For solicitação para um cliente com IPv6 endereço 2001:db8:85a3:8d3:1319:8a2e:370:7348 e número de porta de8080.

X-Forwarded-For: [2001:db8:85a3:8d3:1319:8a2e:370:7348]:8080

Preservar

O preserve modo no atributo garante que o X-Forwarded-For cabeçalho na HTTP solicitação não seja modificado de forma alguma antes de ser enviado aos destinos.

Remover

O remove modo no atributo remove o X-Forwarded-For cabeçalho na HTTP solicitação antes que ela seja enviada aos destinos.

A tabela a seguir mostra exemplos do cabeçalho X-Forwarded-For que o destino recebe quando você seleciona o modo append, preserve ou remove. Neste exemplo, o endereço IP do último salto é 127.0.0.1.

Para modificar, preservar ou remover o X-Forwarded-For cabeçalho usando o AWS CLI

Use o modify-load-balancer-attributescomando com o routing.http.xff_header_processing.mode atributo.

X-Forwarded-Proto

O cabeçalho da X-Forwarded-Proto solicitação ajuda você a identificar o protocolo (HTTPouHTTPS) que um cliente usou para se conectar ao seu balanceador de carga. Os logs de acesso do servidor contêm apenas o protocolo usado entre o servidor e o load balancer; eles não contêm informações sobre o protocolo usado entre o cliente e o load balancer. Para determinar o protocolo usado entre o cliente e o balanceador de carga, use o cabeçalho de solicitação X-Forwarded-Proto. O Elastic Load Balancing armazena o protocolo usado entre o cliente e o balanceador de carga no cabeçalho da solicitação X-Forwarded-Proto e encaminha o cabeçalho para seu servidor.

Seu aplicativo ou site pode usar o protocolo armazenado no cabeçalho da X-Forwarded-Proto solicitação para renderizar uma resposta que redireciona para a apropriada. URL

O cabeçalho de solicitação X-Forwarded-Proto leva a seguinte forma:

X-Forwarded-Proto: originatingProtocol

O exemplo a seguir contém um X-Forwarded-Proto cabeçalho de solicitação para uma solicitação originada do cliente como uma HTTPS solicitação:

X-Forwarded-Proto: https

X-Forwarded-Port

O cabeçalho de solicitação X-Forwarded-Port ajuda a identificar a porta de destino que o cliente usou para se conectar ao load balancer.