Regras de listener e roteamento baseado no caminho

Um listener do ALB é um processo que verifica solicitações de conexão usando um protocolo e uma porta especificados por você (por exemplo, HTTP na porta 80 ou HTTPS na porta 443). Cada listener tem uma ou mais regras que determinam para onde encaminhar as solicitações com base no conteúdo delas.

Um listener deve ter uma regra padrão (a ação abrangente usada quando nenhuma outra regra corresponde) e pode ter até 100 regras adicionais. As regras são avaliadas na ordem de prioridade (o número mais baixo = prioridade mais alta). Quando uma solicitação corresponde à condição de uma regra, a ação correspondente é aplicada e nenhuma regra adicional é avaliada.

As regras de listener correspondem às solicitações com base em condições. Você pode combinar várias condições em uma regra (todas as condições devem corresponder para que a regra seja aplicada). Tipos de condição disponíveis:

• host-header: corresponde ao cabeçalho HTTP Host (por exemplo, api.example.com)
• path-pattern: corresponde ao caminho da URL (por exemplo, /api/*, /images/*.jpg)
• http-header: corresponde a qualquer nome de cabeçalho HTTP e padrão de valor
• http-request-method: corresponde aos métodos HTTP (GET, POST, DELETE etc.)
• query-string: corresponde a pares de chave e valor na sequência de consulta
• source-ip: corresponde a intervalos CIDR de IP do cliente

O roteamento baseado em caminho direciona as solicitações para grupos de destinos diferentes com base no caminho da URL. Esse é o padrão de roteamento mais comum para microsserviços atrás de um único ALB. Exemplo de regras em um ALB:

• O caminho é /api/* → Grupo de destinos: api-service
• O caminho é /images/* → Grupo de destinos: image-processor
• O caminho é /admin/* → Grupo de destinos: admin-app
• Padrão → Grupo de destinos: frontend-app

Isso permite que um único ALB atenda a vários serviços distintos sem exigir vários balanceadores de carga, reduzindo o custo e a complexidade do DNS.

O roteamento baseado em host direciona as solicitações com base no cabeçalho HTTP Host, permitindo que vários nomes de domínio (hosts virtuais) sejam atendidos por um único ALB. Exemplo:

• O host é api.example.com → grupo de destinos api-service
• O host é admin.example.com → grupo de destinos admin-app
• O host é www.example.com → grupo de destinos frontend

Cada nome de domínio tem seu registro CNAME ou ALIAS apontando para o mesmo nome DNS do ALB, mas o ALB direciona cada solicitação ao backend apropriado com base no cabeçalho de host. O roteamento baseado em host é ideal para SaaS multilocatário ou aplicações monolíticas que estão sendo divididas em microsserviços.

Quando as condições de uma regra correspondem, o ALB executa uma destas ações:

• forward: encaminha a solicitação para um ou mais grupos de destinos (com pesos opcionais)
• redirect: retorna um redirecionamento HTTP (301 ou 302) para uma URL nova; é útil para redirecionamentos de HTTP para HTTPS
• fixed-response: retorna uma resposta HTTP estática com um código de status, um tipo de conteúdo e um corpo especificados; é útil para páginas de manutenção ou respostas simples de verificações de integridade
• authenticate-cognito: autentica usuários por meio de um Cognito User Pool antes do encaminhamento
• authenticate-oidc: autentica usuários por meio de qualquer provedor de identidade compatível com OIDC

O padrão mais comum de regra de listener é redirecionar HTTP para HTTPS:

1. Crie um listener HTTP na porta 80 com uma regra: redirecione todo o tráfego (/*) para HTTPS com um código de status 301
2. Crie um listener HTTPS na porta 443 com suas regras de roteamento reais apontando para grupos de destinos

Isso garante que os usuários que digitarem http:// ou seguirem links HTTP antigos sejam redirecionados de forma transparente para HTTPS, sem alterações no nível da aplicação. O redirecionamento é tratado inteiramente na camada do balanceador de carga.

A ação de resposta fixa retorna uma resposta HTTP estática do ALB sem encaminhar a solicitação a nenhum destino. Use-a para:

• Retornar uma página de manutenção 503 para caminhos específicos durante a manutenção
• Fornecer um endpoint leve de verificação de integridade diretamente do ALB (retorna 200 OK instantaneamente, sem sobrecarga do backend)
• Bloquear caminhos específicos com uma resposta 403 Forbidden

As respostas fixas são úteis para retirar caminhos do serviço temporariamente sem modificar o código da aplicação nem fazer uma nova implantação, ajustando as regras de listener dinamicamente.

A ação authenticate-cognito do ALB integra-se aos Cognito User Pools da Amazon para lidar com a autenticação dos usuários antes de encaminhar as solicitações à sua aplicação. Quando um usuário não autenticado acessa uma regra de listener protegida, o ALB o redireciona para a interface hospedada pelo Cognito para fazer login. Após a autenticação bem-sucedida, o ALB define um cookie criptografado e encaminha a solicitação com cabeçalhos de identidade do usuário.

Isso remove completamente da sua aplicação a responsabilidade pela lógica de autenticação. Seu backend recebe os cabeçalhos X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data e X-Amzn-Oidc-Access-Token com as declarações do usuário autenticado.

As regras do listener ALB podem fazer o roteamento com base em parâmetros da string de consulta e em cabeçalhos HTTP, permitindo um roteamento detalhado das solicitações:

• Encaminhe clientes móveis detectando o cabeçalho User-Agent: *Mobile* e direcionando-os para um backend otimizado para dispositivos móveis
• Encaminhe solicitações de API premium verificando o cabeçalho personalizado X-API-Tier: premium e direcionando-as para um grupo de destino mais rápido
• Encaminhe variantes de testes A/B lendo o parâmetro da string de consulta ?variant=beta

O roteamento baseado em cabeçalhos permite implementar sinalizadores de recursos e divisão de tráfego na camada de infraestrutura sem modificar o código da aplicação.

As regras são avaliadas em ordem crescente de prioridade. Os números de prioridade menores são avaliados primeiro. A ação da primeira regra correspondente é aplicada, e nenhuma outra regra é avaliada. A regra padrão não tem número de prioridade e é sempre avaliada por último, funcionando como regra abrangente.

Prática recomendada: atribua números de prioridade em incrementos de 10 (10, 20, 30...), em vez de usar números inteiros sequenciais. Isso deixa espaço para inserir novas regras entre as existentes sem precisar renumerá-las. Regras mais específicas (por exemplo, caminho + cabeçalho de host) devem ter números menores (prioridade maior) do que regras genéricas.

Um único ALB pode ficar à frente de toda uma plataforma de microsserviços usando regras de listener. Veja um exemplo real combinando os três tipos de condição:

• Prioridade 10: Host=api.example.com + Caminho=/v2/* → grupo de destino api-v2
• Prioridade 20: Host=api.example.com + Caminho=/v1/* → grupo de destino api-v1
• Prioridade 30: Host=auth.example.com → grupo de destino auth-service
• Prioridade 40: Host=www.example.com + Caminho=/static/* → redirecionamento para CloudFront
• Padrão: Host=www.example.com → grupo de destino frontend

Esse design reduz os custos ao eliminar a necessidade de balanceadores de carga separados para cada serviço.

Teste sua compreensão dos conceitos de AWS Solutions Architect (SAA-C03) apresentados nesta lição.

Nesta lição, você aprendeu que: as regras de listener encaminham solicitações com base no host, caminho, cabeçalhos, métodos e strings de consulta; as regras são avaliadas em ordem de prioridade, e a primeira correspondência vence; e as ações incluem encaminhamento, redirecionamento, resposta fixa e autenticação do Cognito. O roteamento baseado em caminho e host permite que um único ALB fique à frente de vários microsserviços. A seguir, exploraremos a terminação de SSL e as sessões persistentes.