Agentes de escucha de los Application Load Balancers - Elastic Load Balancing

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Agentes de escucha de los Application Load Balancers

Antes de comenzar a utilizar Balanceador de carga de aplicaciones, debe agregar uno o varios agentes de escucha. Un agente de escucha es un proceso que comprueba las solicitudes de conexión utilizando el protocolo y el puerto configurados. Las reglas que defina para un agente de escucha determinan cómo el balanceador de carga va a direccionar las solicitudes a sus destinos registrados.

Configuración del agente de escucha

Los agentes de escucha admiten los siguientes protocolos y puertos:

  • Protocolos de : HTTP, HTTPS

  • Puertos de : 1-65535

Puede utilizar un agente de escucha HTTPS para trasladar la carga de cifrado y descifrado al balanceador de carga, de modo que las aplicaciones puedan concentrarse en la lógica de negocio. Si el protocolo del agente de escucha es HTTPS, debe implementar al menos un certificado de servidor SSL en el agente de escucha. Para obtener más información, consulte Crear un agente de escucha HTTPS para suBalanceador de carga de aplicaciones.

El Application Load Balancers de WebSockets proporciona compatibilidad nativa con . Puede actualizar una conexión HTTP/1.1 existente a una conexión WebSocket (ws o wss) mediante una actualización de conexión HTTP. Al actualizar, la conexión TCP utilizada para las solicitudes (al balanceador de carga o al destino) se convierte en una conexión de WebSocket persistente entre el cliente y el destino a través del balanceador de carga. : puede utilizar WebSockets con los agentes de escucha HTTP y HTTPS. Las opciones que elija para su agente de escucha se aplican a las conexiones de WebSocket, así como al tráfico HTTP. Para obtener más información, consulte Cómo funciona el protocolo de WebSocket en la Guía para desarrolladores de Amazon CloudFront.

Los Application Load Balancers proporcionan compatibilidad nativa con HTTP/2 con agentes de escucha HTTPS. Puede enviar hasta 128 solicitudes a la vez con una conexión HTTP/2. De forma predeterminada, el balanceador de carga los convierte en solicitudes HTTP/1.1 individuales y las distribuye entre los destinos del grupo de destino que se encuentran en buen estado. Sin embargo, puede utilizar la versión de protocolo para enviar la solicitud a los destinos mediante HTTP/2. Para obtener más información, consulte Versión de protocolo. Como HTTP/2 usa las conexiones frontend de una forma más eficaz, es posible que observe que se establecen menos conexiones entre los clientes y el balanceador de carga. No puede utilizar la característica server-push de HTTP/2.

Para obtener más información, consulte Direccionamiento de solicitudes en la Guía del usuario de Elastic Load Balancing.

Reglas del agente de escucha

Cada agente de escucha tiene una regla predeterminada, pero, si lo desea, puede definir reglas adicionales. Cada regla consta de una prioridad, una o varias acciones y una o varias condiciones. Puede agregar y editar reglas en cualquier momento. Para obtener más información, consulte Editar una regla.

Reglas predeterminadas

Cuando crea un agente de escucha, define acciones para la regla predeterminada. Las reglas predeterminadas no pueden tener condiciones. Si no se cumplen las condiciones de ninguna de las reglas del agente de escucha, se realiza la acción de la regla predeterminada.

A continuación, se muestra un ejemplo de una regla predeterminada vista en la consola:


                    Regla predeterminada de un agente de escucha.

Prioridad de la regla

Cada regla tiene una prioridad. Las normas se evalúan por orden de prioridad, desde el valor más bajo hasta el valor más alto. La regla predeterminada se evalúa en último lugar. Puede cambiar la prioridad de una regla no predeterminada en cualquier momento. No puede cambiar la prioridad de la regla predeterminada. Para obtener más información, consulte Reordenar reglas.

Acciones de regla

Cada acción de regla tiene un tipo, un orden y la información necesaria para realizar la acción. Para obtener más información, consulte Tipos de acción de regla.

Condiciones de regla

Cada condición de regla tiene un tipo e información de configuración. Cuando se cumplen las condiciones de una regla, se llevan a cabo sus acciones. Para obtener más información, consulte Tipos de condición de regla.

Tipos de acción de regla

Se admiten los siguientes tipos de acción para una regla de agente de escucha:

authenticate-cognito

[Agentes de escucha HTTPS] Utilice Amazon Cognito para autenticar a los usuarios. Para obtener más información, consulte Autenticar a usuarios mediante unBalanceador de carga de aplicaciones.

authenticate-oidc

[Agentes de escucha HTTPS] Utilizar un proveedor de identidad compatible con OpenID Connect (OIDC) para autenticar a los usuarios.

fixed-response

Devuelve una respuesta HTTP personalizada. Para obtener más información, consulte Acciones de respuesta fija.

forward

Reenvíe las solicitudes a los grupos de destino especificados. Para obtener más información, consulte Acciones de reenvío.

redirect

Direcciona las solicitudes de una URL a otra. Para obtener más información, consulte Acciones de redirección.

Primero se realiza la acción con el valor de orden más bajo. Cada regla debe incluir exactamente una de las siguientes acciones: forward, redirect o fixed-response, y debe ser la última acción que se va a realizar.

Si la versión del protocolo es gRPC o HTTPS, las únicas acciones admitidas son acciones de forward.

Acciones de respuesta fija

Puede utilizar acciones fixed-response para omitir las solicitudes del cliente y devolver una respuesta HTTP personalizada. Puede utilizar esta acción para devolver un código de respuesta 2XX, 4XX o 5XX junto con un mensaje opcional.

Cuando se ejecuta una acción fixed-response, la acción y la URL del destino se graban en los registros de acceso. Para obtener más información, consulte Entradas de los registros de acceso. El número de acciones fixed-response correctas se registra en la métrica HTTP_Fixed_Response_Count. Para obtener más información, consulte Métricas de Balanceador de carga de aplicaciones.

ejemplo Ejemplo de acción de respuesta fija para laAWS CLI

Puede especificar una acción al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La acción siguiente envía una respuesta fija con el código de estado y cuerpo de mensaje especificados.

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

Acciones de reenvío

Puede utilizar acciones forward para direccionar solicitudes a uno o más grupos de destino. Si especifica varios grupos de destino para una acción forward, debe especificar una ponderación para cada grupo de destino. Cada ponderación de grupo de destino es un valor de 0 a 999. Las solicitudes que coinciden con una regla del agente de escucha con los grupos de destino ponderados se distribuyen a estos grupos de destino en función de sus ponderaciones. Por ejemplo, si especifica dos grupos de destino, cada uno con una ponderación de 10, cada grupo de destino recibe la mitad de las solicitudes. Si especifica dos grupos de destino, uno con una ponderación de 10 y el otro con una ponderación de 20, el grupo de destino con una ponderación de 20 recibe el doble de solicitudes que el otro grupo de destino.

De forma predeterminada, la configuración de una regla para distribuir tráfico entre los grupos de destino ponderados no garantiza que se cumplan las sesiones sticky. Para asegurarse de que se respetan las sesiones sticky, habilite la persistencia del grupo de destino para la regla. Cuando el balanceador de carga direcciona por primera vez una solicitud a un grupo de destino ponderado, genera una cookie llamada AWSALBTG que codifica información sobre el grupo de destino seleccionado, cifra la cookie e incluye la cookie en la respuesta al cliente. El cliente debe incluir la cookie que recibe en las solicitudes posteriores al balanceador de carga. Cuando el balanceador de carga recibe una solicitud que coincide con una regla con la persistencia del grupo de destino activada y que contiene la cookie, la solicitud se direcciona al grupo de destino especificado en la cookie.

Los Application Load Balancers no admiten valores de cookies codificados como URL.

Con las solicitudes CORS (intercambio de recursos de varios orígenes), algunos navegadores requieren SameSite=None; Secure para habilitar la persistencia. En este caso, Elastic Load Balancing genera una segunda cookie, AWSALBTGCORS, que incluye la misma información que la cookie de persistencia original, además de este atributo SameSite. Los clientes reciben ambas cookies.

ejemplo Ejemplo de acción de reenvío con un grupo de destino

Puede especificar una acción al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La acción siguiente reenvía las solicitudes al grupo de destino especificado.

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

ejemplo Acción de reenvío de ejemplo con dos grupos de destino ponderados

La siguiente acción reenvía las solicitudes a los dos grupos de destino especificados, basándose en la ponderación 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 } ] } } ]

ejemplo Ejemplo de acción de reenvío con la persistencia habilitada

Si tiene una acción de reenvío con varios grupos de destino y uno o más de ellos tienen habilitadas las sesiones sticky, debe habilitar la persistencia del grupo de destino.

La siguiente acción reenvía las solicitudes a los dos grupos de destino especificados, con la persistencia del grupo de destino activada. Las solicitudes que no contienen la cookie de permanencia se enrutan en función de la ponderación 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 } } } ]

Acciones de redirección

Puede usar acciones redirect para redirigir las solicitudes de los clientes de una URL a otra. Puede configurar las acciones de redirección como temporales (HTTP 302) o permanentes (HTTP 301), en función de sus necesidades.

Un URI está formado por los siguientes componentes:

protocol://hostname:port/path?query

Debe modificar al menos uno de los siguientes componentes para evitar que se produzca un bucle de redirección: protocolo, nombre de host, puerto o ruta. Los elementos que no se modifiquen conservarán sus valores originales.

protocolo

Protocolo (HTTP o HTTPS). Puede redirigir HTTP a HTTP, HTTP a HTTPS y HTTPS a HTTPS. No puede redirigir HTTPS a HTTP.

hostname

Nombre del host. Un nombre de host no distingue entre mayúsculas y minúsculas, puede tener hasta 128 caracteres de longitud y constar de caracteres alfanuméricos, comodines (* y ?) y guiones (-).

puerto

Puerto (entre 1 y 65535).

path

Ruta absoluta, comenzando desde la primera "/". Una ruta distingue entre mayúsculas y minúsculas, puede tener hasta 128 caracteres de longitud y constar de caracteres alfanuméricos, comodines (* y ?), & (mediante &) y los caracteres especiales siguientes: _-.$/~"'@:+.

query

Parámetros de la consulta. La longitud máxima es de 128 caracteres.

Puede reutilizar los componentes del URI de la URL original en la URL de destino utilizando las siguientes palabras clave reservadas:

  • #{protocol} - Mantiene el protocolo. Se usa en los componentes de protocolo y consulta.

  • #{host} - Mantiene el dominio. Se usa en los componentes de nombre de host, ruta y consulta.

  • #{port} - Mantiene el puerto. Se usa en los componentes de puerto, ruta y consulta.

  • #{path} - Mantiene la ruta. Se usa en los componentes de ruta y consulta.

  • #{query} - Mantiene los parámetros de consulta. Se usa en el componente de consulta.

Cuando se ejecuta una acción redirect, esta acción se graba en los registros de acceso. Para obtener más información, consulte Entradas de los registros de acceso. El número de acciones redirect correctas se registra en la métrica HTTP_Redirect_Count. Para obtener más información, consulte Métricas de Balanceador de carga de aplicaciones.

ejemplo Ejemplo de acciones de redireccionamiento con la consola

La siguiente regla configura una redirección permanente a una URL que utiliza el protocolo HTTPS y el puerto especificado (40443), pero mantiene el nombre de host, la ruta y los parámetros de consulta originales. Esta pantalla es equivalente a "https://#{host}:40443/#{path}?#{query}".


                        Regla que redirige la solicitud a una URL que usa el protocolo HTTPS y el puerto especificado (40443), pero mantiene el dominio, la ruta y los parámetros de consulta originales de la URL de origen.

La siguiente regla configura una redirección permanente a una URL que utiliza el protocolo, el puerto, el nombre de host y los parámetros de consulta originales y utiliza la palabra clave #{path} para crear una ruta modificada. Esta pantalla es equivalente a "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".


                        Regla que redirige la solicitud a una URL que conserva el protocolo, el puerto, el nombre de host y los parámetros de consulta originales, y utiliza la palabra clave #{path} para crear una ruta modificada.

ejemplo Ejemplo de acción de redireccionamiento para laAWS CLI

Puede especificar una acción al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La siguiente acción redirige una solicitud HTTP a una solicitud HTTPS en el puerto 443, con el mismo nombre de host, ruta y cadena de consulta que la solicitud HTTP.

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

Tipos de condición de regla

Se admiten los siguientes tipos de condición para una regla:

host-header

Ruta basada en el nombre de host de cada solicitud. Para obtener más información, consulte Condiciones de host.

http-header

Ruta basada en los encabezados HTTP de cada solicitud. Para obtener más información, consulte Condiciones de encabezado HTTP.

http-request-method

Ruta basada en el método de solicitud HTTP de cada solicitud. Para obtener más información, consulte Condiciones del método de solicitud HTTP.

path-pattern

Ruta basada en patrones de ruta en la solicitud URLs. Para obtener más información, consulte Condiciones de ruta.

query-string

Ruta basada en pares clave/valor o en valores en las cadenas de consulta. Para obtener más información, consulte Condiciones de cadena de consulta.

source-ip

Ruta basada en la dirección IP de origen de cada solicitud. Para obtener más información, consulte Condiciones de dirección IP de origen.

Cada regla puede incluir opcionalmente hasta una de las siguientes condiciones: host-header , http-request-method, path-pattern y source-ip. Cada regla puede incluir también una o varias de las siguientes condiciones: http-header y query-string.

Puede especificar hasta tres evaluaciones de coincidencia por condición. Por ejemplo, para cada condición http-header, puede especificar hasta tres cadenas que comparar con el valor del encabezado HTTP en la solicitud. La condición se satisface si una de las cadenas coincide con el valor del encabezado HTTP. Para requerir que todas las cadenas sean una coincidencia, cree una condición por evaluación de coincidencia.

Puede especificar hasta cinco evaluaciones de coincidencia por regla. Por ejemplo, puede crear una regla con cinco condiciones donde cada condición tenga una evaluación de coincidencia.

Puede incluir caracteres comodín en las evaluaciones de coincidencia para http-header, host-header, path-pattern y query-string. Hay un límite de cinco caracteres comodín por regla.

Las reglas se aplican solo a los caracteres ASCII visibles; se excluyen los caracteres de control (0x00 a 0x1f y 0x7f).

Para ver demostraciones, consulte Direccionamiento avanzado de solicitudes.

Condiciones de encabezado HTTP

Puede utilizar las condiciones de encabezado HTTP para configurar reglas que dirijan solicitudes basadas en los encabezados HTTP para la solicitud. Puede especificar los nombres de campos de encabezado HTTP estándar o personalizados. El nombre del encabezado y la evaluación de coincidencia no distinguen entre mayúsculas y minúsculas. Los siguientes caracteres comodín se admiten en las cadenas de comparación: * (coincide con 0 o más caracteres) y ? (coincide exactamente con 1 carácter). Los caracteres comodín no se admiten en el nombre del encabezado.

ejemplo Ejemplo de condición de encabezado HTTP para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente se satisface mediante solicitudes con un encabezado usuario-agente que coincida con una de las cadenas especificadas.

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

Condiciones del método de solicitud HTTP

Puede utilizar las condiciones de método de solicitud HTTP para configurar reglas que dirijan solicitudes basadas en el método de solicitud HTTP de la solicitud. Puede especificar métodos HTTP estándar o personalizados. La evaluación de coincidencia distingue entre mayúsculas y minúsculas. Los caracteres comodín no se admiten; por tanto, el nombre del método tiene que ser una coincidencia exacta.

Le recomendamos direccionar las solicitudes GET y HEAD de la misma forma, porque la respuesta a una solicitud HEAD se podría almacenar en caché.

ejemplo Ejemplo de condición de método HTTP para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente se satisface mediante solicitudes que utilizan el método especificado.

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

Condiciones de host

Puede utilizar las condiciones de host para definir reglas que direccionen solicitudes en función del nombre del host en el encabezado del host (lo que también se conoce como direccionamiento basado en host). Esto le permite admitir varios subdominios y diferentes dominios de nivel superior con un único balanceador de carga.

Los nombre de host no distinguen entre mayúsculas y minúsculas, su longitud máxima es de 128 caracteres y pueden contener cualquiera de los siguientes caracteres:

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

  • - .

  • * (coincide con 0 o más caracteres)

  • ? (coincide exactamente con 1 carácter)

Debe incluir al menos un carácter ".". Solo puede contener caracteres alfabéticos detrás del carácter "." final.

Ejemplos de nombres de host

  • example.com

  • test.example.com

  • *.example.com

La regla *.example.com coincide con test.example.com pero no coincide con example.com.

ejemplo Ejemplo de condición de encabezado de host para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente se satisface mediante solicitudes con un encabezado de host que coincide con la cadena especificada.

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

Condiciones de ruta

Puede utilizar las condiciones de ruta para definir reglas que direccionen las solicitudes en función de la dirección URL de la solicitud (lo que también se conoce como direccionamiento basado en ruta).

El patrón de ruta se aplica únicamente a la ruta de la dirección URL, no a sus parámetros de consulta. Se aplica solo a los caracteres ASCII visibles; se excluyen los caracteres de control (0x00 a 0x1f y 0x7f).

Los patrones de ruta distinguen entre mayúsculas y minúsculas, su longitud máxima es de 128 caracteres y pueden contener cualquiera de los siguientes caracteres.

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

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

  • & (con &)

  • * (coincide con 0 o más caracteres)

  • ? (coincide exactamente con 1 carácter)

Si la versión del protocolo es gRPC, las condiciones pueden ser específicas de un paquete, servicio o método.

Ejemplos de patrones de ruta HTTP

  • /img/*

  • /img/*/pics

Ejemplos de patrones de ruta de gRPC

  • /paquete

  • /paquete.servicio/

  • /package.service/método

El patrón de ruta se utiliza para direccionar solicitudes, no para modificarlas. Por ejemplo, si una regla tiene un patrón de ruta de /img/*, la regla reenvía una solicitud de /img/picture.jpg al grupo de destino especificado como una solicitud de /img/picture.jpg.

ejemplo Ejemplo de condición de patrón de ruta para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente se satisface mediante solicitudes con una dirección URL que contenga la cadena especificada.

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

Condiciones de cadena de consulta

Puede utilizar condiciones de cadena de consulta para configurar reglas que dirijan solicitudes basadas en pares clave/valor o valores en la cadena de consulta. La evaluación de coincidencia no distingue entre mayúsculas y minúsculas. Se admiten los siguientes caracteres comodín: * (coincide con 0 o más caracteres) y ? (coincide exactamente con 1 carácter).

ejemplo Ejemplo de condición de cadena de consulta para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente la satisfacen las solicitudes con una cadena de consulta que incluye un par clave/valor de "version=v1" o cualquier clave definida en "example".

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

Condiciones de dirección IP de origen

Puede utilizar las condiciones de dirección IP de origen para configurar reglas que direccionen solicitudes en función de la dirección IP de origen de la solicitud. La dirección IP se debe especificar en formato CIDR. Puede utilizar las direcciones IPv4 y IPv6. No se admiten caracteres comodín.

Si un cliente está detrás de un proxy, esta es la dirección IP del proxy, no la dirección IP del cliente.

Esta condición no la satisfacen las direcciones en el encabezado X-Forwarded-For. Para buscar direcciones en el encabezado X-Forwarded-For, utilice una condición http-header.

ejemplo Ejemplo de condición de IP de origen para laAWS CLI

Puede especificar condiciones al crear o modificar una regla. Para obtener más información, consulte los comandos create-rule y modify-rule. La condición siguiente se satisface mediante solicitudes con una dirección IP de origen en uno de los bloques de CIDR especificados.

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