Reglas de listener y enrutamiento basado en rutas

Un listener de ALB es un proceso que comprueba las solicitudes de conexión mediante el protocolo y el puerto que especifique (por ejemplo, HTTP en el puerto 80 o HTTPS en el puerto 443). Cada listener tiene una o más reglas que determinan adónde reenviar las solicitudes según su contenido.

Un listener debe tener una regla predeterminada (la acción general que se aplica cuando no coincide ninguna otra regla) y puede tener hasta 100 reglas adicionales. Las reglas se evalúan según el orden de prioridad (el número más bajo tiene la prioridad más alta). Cuando una solicitud coincide con la condición de una regla, se aplica la acción correspondiente y no se evalúan más reglas.

Las reglas de listener hacen coincidir las solicitudes según condiciones. Puede combinar varias condiciones en una regla (todas deben coincidir para que se aplique la regla). Tipos de condición disponibles:

• host-header: coincide con el encabezado HTTP Host (por ejemplo, api.example.com)
• path-pattern: coincide con la ruta URL (por ejemplo, /api/*, /images/*.jpg)
• http-header: coincide con cualquier nombre de encabezado HTTP y patrón de valor
• http-request-method: coincide con métodos HTTP (GET, POST, DELETE, etc.)
• query-string: coincide con pares clave-valor de la cadena de consulta
• source-ip: coincide con rangos CIDR de IP de cliente

El enrutamiento basado en rutas dirige las solicitudes a distintos grupos de destinos según la ruta URL. Este es el patrón de enrutamiento más común para microservicios detrás de un único ALB. Ejemplo de reglas en un ALB:

• La ruta es /api/* → Grupo de destinos: api-service
• La ruta es /images/* → Grupo de destinos: image-processor
• La ruta es /admin/* → Grupo de destinos: admin-app
• Predeterminado → Grupo de destinos: frontend-app

Esto permite que un único ALB sirva de frontend para varios servicios independientes sin necesidad de varios balanceadores de carga, lo que reduce los costes y la complejidad del DNS.

El enrutamiento basado en hosts dirige las solicitudes según el encabezado HTTP Host, lo que permite servir varios nombres de dominio (hosts virtuales) desde un único ALB. Ejemplo:

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

Cada nombre de dominio tiene un registro CNAME o ALIAS que apunta al mismo nombre DNS del ALB, pero el ALB dirige cada solicitud al backend adecuado según el encabezado de host. El enrutamiento basado en hosts es ideal para SaaS multiinquilino o para aplicaciones monolíticas que se están dividiendo en microservicios.

Cuando coinciden las condiciones de una regla, el ALB ejecuta una de estas acciones:

• forward: reenvía la solicitud a uno o más grupos de destinos (con pesos opcionales)
• redirect: devuelve una redirección HTTP (301 o 302) a una URL nueva; es útil para redirigir de HTTP a HTTPS
• fixed-response: devuelve una respuesta HTTP estática con un código de estado, un tipo de contenido y un cuerpo especificados; es útil para páginas de mantenimiento o respuestas sencillas de comprobación de estado
• authenticate-cognito: autentica a los usuarios mediante un User Pool de Cognito antes de reenviar la solicitud
• authenticate-oidc: autentica a los usuarios mediante cualquier proveedor de identidad compatible con OIDC

El patrón de regla de listener más común consiste en redirigir HTTP a HTTPS:

1. Cree un listener HTTP en el puerto 80 con una regla: redirigir todo el tráfico (/*) a HTTPS con un código de estado 301
2. Cree un listener HTTPS en el puerto 443 con las reglas de enrutamiento reales que apunten a los grupos de destinos

Esto garantiza que los usuarios que escriban http:// o sigan enlaces HTTP antiguos sean redirigidos de forma transparente a HTTPS sin cambios en el nivel de la aplicación. La redirección se gestiona por completo en la capa del balanceador de carga.

La acción de respuesta fija devuelve una respuesta HTTP estática desde el ALB sin reenviar la solicitud a ningún destino. Utilícela para:

• Devolver una página de mantenimiento 503 para rutas específicas durante el mantenimiento
• Proporcionar un endpoint ligero de comprobación de estado directamente desde el ALB (devuelve 200 OK al instante sin sobrecarga del backend)
• Bloquear rutas específicas con una respuesta 403 Forbidden

Las respuestas fijas son útiles para retirar temporalmente rutas del servicio sin modificar el código de la aplicación ni volver a implementarla, mediante el ajuste dinámico de las reglas del listener.

La acción authenticate-cognito del ALB se integra con Amazon Cognito User Pools para gestionar la autenticación de usuarios antes de reenviar las solicitudes a su aplicación. Cuando un usuario no autenticado llega a una regla de listener protegida, el ALB lo redirige a la interfaz de usuario alojada en Cognito para iniciar sesión. Después de autenticarse correctamente, el ALB establece una cookie cifrada y reenvía la solicitud con encabezados de identidad del usuario.

Esto descarga por completo la lógica de autenticación de su aplicación. Su backend recibe los encabezados X-Amzn-Oidc-Identity, X-Amzn-Oidc-Data y X-Amzn-Oidc-Access-Token con las claims del usuario autenticado.

Las reglas del listener de ALB pueden enrutar según parámetros de la cadena de consulta y encabezados HTTP, lo que permite un enrutamiento detallado de las solicitudes:

• Enrute los clientes móviles detectando el encabezado User-Agent: *Mobile* para dirigirlos a un backend optimizado para móviles
• Enrute las solicitudes de API premium comprobando el encabezado personalizado X-API-Tier: premium para dirigirlas a un grupo de destino más rápido
• Enrute las variantes de una prueba A/B leyendo el parámetro de la cadena de consulta ?variant=beta

El enrutamiento basado en encabezados permite implementar indicadores de funciones y dividir el tráfico en la capa de infraestructura sin modificar el código de la aplicación.

Las reglas se evalúan en orden ascendente de prioridad. Primero se evalúan los números de prioridad más bajos. Se aplica la acción de la primera regla coincidente y no se evalúan más reglas. La regla predeterminada no tiene número de prioridad y siempre se evalúa al final como regla general.

Práctica recomendada: asigne números de prioridad en incrementos de 10 (10, 20, 30...), en lugar de usar enteros consecutivos. Así deja espacio para insertar nuevas reglas entre las existentes sin tener que renumerarlas. Las reglas más específicas (por ejemplo, las que combinan ruta y encabezado de host) deben tener números más bajos (mayor prioridad) que las reglas genéricas.

Un solo ALB puede situarse delante de toda una plataforma de microservicios mediante reglas del listener. Este es un ejemplo real que combina los tres tipos de condiciones:

• Prioridad 10: Host=api.example.com + Path=/v2/* → grupo de destino api-v2
• Prioridad 20: Host=api.example.com + Path=/v1/* → grupo de destino api-v1
• Prioridad 30: Host=auth.example.com → grupo de destino auth-service
• Prioridad 40: Host=www.example.com + Path=/static/* → redirección a CloudFront
• Predeterminada: Host=www.example.com → grupo de destino frontend

Este diseño reduce los costes al eliminar la necesidad de usar load balancers independientes para cada servicio.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) tratados en esta lección.

En esta lección ha aprendido que: las reglas del listener enrutan las solicitudes según el host, la ruta, los encabezados, los métodos y las cadenas de consulta; las reglas se evalúan por orden de prioridad y prevalece la primera coincidencia; y las acciones incluyen el reenvío, la redirección, la respuesta fija y la autenticación de Cognito. El enrutamiento basado en rutas y hosts permite que un solo ALB se sitúe delante de varios microservicios. A continuación, exploraremos la terminación de SSL y las sesiones persistentes.