Oyentes para Equilibrador de carga de aplicación

Un oyente es un proceso que comprueba las solicitudes de conexión utilizando el protocolo y el puerto configurados. Antes de comenzar a utilizar el Equilibrador de carga de aplicación, debe agregar al menos un oyente. Si su equilibrador de carga no cuenta con oyentes, no puede recibir tráfico de los clientes. Las reglas que definas para tus oyentes determinan cómo el balanceador de cargas dirige las solicitudes a los destinos que registras, como EC2 las instancias.

Configuración del oyente

Los oyentes son compatibles con los siguientes protocolos y puertos:

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

Si debe asegurarse de que los destinos descifren el tráfico HTTPS en lugar del equilibrador de carga, puede crear un Equilibrador de carga de red con un oyente TCP en el puerto 443. Con un oyente TCP, el equilibrador de carga transfiere el tráfico cifrado a los destinos sin descifrarlo. Para obtener más información, consulte la Guía del usuario de Equilibradores de carga de red.

Los balanceadores de carga de aplicaciones ofrecen soporte nativo para. WebSockets Puede convertir una conexión HTTP/1.1 existente en una WebSocket (wsowss) conexión mediante una actualización de la conexión HTTP. Al actualizar, la conexión TCP utilizada para las solicitudes (tanto al balanceador de carga como al destino) se convierte en una WebSocket conexión persistente entre el cliente y el destino a través del balanceador de cargas. Puedes utilizarla WebSockets con dispositivos de escucha HTTP y HTTPS. Las opciones que elija para su agente de escucha se aplican tanto a WebSocket las conexiones como al tráfico HTTP. Para obtener más información, consulta Cómo funciona el WebSocket protocolo en la Guía para CloudFront desarrolladores de Amazon.

Los equilibradores de carga de apliación proporcionan soporte nativo para HTTP/2 con oyentes HTTPS. Puede enviar hasta 128 solicitudes a la vez con una conexión HTTP/2. Se puede usar la versión del protocolo para enviar la solicitud a los destinos mediante HTTP/2. Para obtener más información, consulte Versión del 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 equilibrador de carga. No puede utilizar la característica server-push de HTTP/2.

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

Atributos del oyente

Los siguientes son los atributos de escucha de los balanceadores de carga de aplicaciones

Reglas del oyente

Cada oyente tiene una acción predeterminada, que se conoce también como regla predeterminada. La regla predeterminada no se puede eliminar y siempre se ejecuta en último lugar. Cada una consta de una prioridad, de una o varias acciones y de 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 oyente, 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 oyente, se realiza la acción de la regla predeterminada.

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

Prioridad de las reglas

Cada regla tiene una prioridad. Las reglas 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 Actualizar la prioridad de una regla.

Acciones de las reglas

Cada acción de regla tiene un tipo, una prioridad 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 las reglas

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 las reglas.

Tipos de acción de regla

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

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

Si la versión del protocolo es gRPC o HTTP/2, las únicas acciones admitidas son las 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 del Equilibrador de carga de aplicación.

[
  {
      "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 oyente 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 persistente. Para asegurarse de que se respetan las sesiones persistente, habilite la persistencia del grupo de destino para la regla. Cuando el balanceador de cargas dirige por primera vez una solicitud a un grupo objetivo ponderado, genera una cookie con el nombre AWSALBTG que codifica la información sobre el grupo objetivo 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 equilibrador de carga. Cuando el equilibrador 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 equilibradores de carga de aplicaciones 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 adherencia original más este SameSite atributo. Los clientes reciben ambas 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
          }
      }
  }
]

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.

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

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 del Equilibrador de carga de aplicación.

ejemplo Ejemplo de acciones de redirección mediante 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}”.

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

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

Tipos de condición de las reglas

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

Cada regla puede incluir también hasta una de las siguientes condiciones: host-header, http-request-method, path-pattern y source-ip. Cada regla puede incluir también una o más 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 de solicitudes avanzado.

Condiciones de los encabezados 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.

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

Condiciones de 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é.

[
  {
      "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 permite admitir varios subdominios y diferentes dominios de nivel superior a través de un único equilibrador 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:

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

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

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

La evaluación de la regla se realiza solo después de que se produzca la normalización del URI.

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.

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

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

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

[
  {
      "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 ambas IPv6 direcciones IPv4 y. No se admiten caracteres comodín. No puede especificar el CIDR 255.255.255.255/32 para la condición de la regla IP de origen.

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

Las direcciones del X-Forwarded-For encabezado no cumplen esta condición. Para buscar direcciones en el X-Forwarded-For encabezado, utilice una http-header condición.

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

Encabezados HTTP y balanceadores de tipo equilibrador de carga de aplicaciones

Las solicitudes y respuestas HTTP utilizan campos de encabezado para enviar información sobre los mensajes HTTP. Los encabezados HTTP se añaden automáticamente. Los campos de encabezado son pares nombre-valor separados por signos de dos puntos, separados a su vez por un retorno de carro (CR) y un salto de línea (LF). Un conjunto estándar de campos de encabezado HTTP se define en RFC 2616, Encabezados de mensaje. También hay encabezados HTTP no estándar disponibles que se agregan automáticamente y que se suelen utilizar ampliamente en las aplicaciones. Algunos de los encabezados HTTP no estándar tienen un prefijo X-Forwarded. Los Equilibradores de carga de aplicación admiten los siguientes encabezados X-Forwarded.

Para obtener más información acerca de las conexiones HTTP, consulte Enrutamiento de solicitudes en la Guía del usuario de Elastic Load Balancing.

X-Forwarded-For

El encabezado de solicitud X-Forwarded-For ayuda a identificar la dirección IP de un cliente cuando se utiliza un equilibrador de carga HTTP o HTTPS. Dado que los equilibradores de carga interceptan el tráfico entre los clientes y los servidores, los registros de acceso al servidor contienen únicamente la dirección IP del equilibrador de carga. Para ver la dirección IP del cliente, utilice el atributo routing.http.xff_header_processing.mode. Este atributo permite modificar, conservar o eliminar el encabezado X-Forwarded-For en la solicitud HTTP antes de que el Equilibrador de carga de aplicación envíe la solicitud al destino. Los valores posibles para este atributo son append, preserve y remove. El valor predeterminado de este atributo es append.

Anexar

De manera predeterminada, el Equilibrador de carga de aplicación almacena la dirección IP del cliente en el encabezado de solicitud X-Forwarded-For y se lo pasa al encabezado de su servidor. Si el encabezado de solicitud X-Forwarded-For no se incluye en la solicitud original, el equilibrador de carga crea uno con la dirección IP del cliente como el valor de la solicitud. De lo contrario, el equilibrador de carga agrega la dirección IP del cliente al encabezado existente y se lo pasa al servidor. El encabezado de solicitud X-Forwarded-For puede contener varias direcciones IP separadas por comas.

El encabezado de solicitud X-Forwarded-For tiene el siguiente formato:

X-Forwarded-For: client-ip-address

A continuación se muestra un ejemplo de un encabezado de solicitud X-Forwarded-For cuya dirección IP de cliente es 203.0.113.7.

X-Forwarded-For: 203.0.113.7

A continuación se muestra un ejemplo de encabezado de X-Forwarded-For solicitud para un cliente con una IPv6 dirección de2001:DB8::21f:5bff:febf:ce22:8a2e.

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

Cuando el atributo de conservación del puerto del cliente (routing.http.xff_client_port.enabled) está habilitado en el equilibrador de carga, el encabezado de la solicitud X-Forwarded-For incluye el atributo client-port-number adjunto al atributo client-ip-address, separado por dos puntos. El encabezado luego tiene el siguiente formato:

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

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

Por IPv6 ejemplo, ten en cuenta que cuando el balanceador de cargas añade la dirección client-ip-address al encabezado existente, incluye la dirección entre corchetes.

A continuación se muestra un ejemplo de encabezado de X-Forwarded-For solicitud para un cliente con una IPv4 dirección 12.34.56.78 y un número de puerto de. 8080

X-Forwarded-For: 12.34.56.78:8080

A continuación se muestra un ejemplo de encabezado de X-Forwarded-For solicitud para un cliente con una IPv6 dirección 2001:db8:85a3:8d3:1319:8a2e:370:7348 y un número de puerto de8080.

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

Conservar

El modo preserve del atributo garantiza que el encabezado X-Forwarded-For de la solicitud HTTP no se modifique de ninguna manera antes de enviarse a los destinos.

Quitar

El modo remove del atributo elimina el encabezado X-Forwarded-For de la solicitud HTTP antes de enviarla a los destinos.

En la siguiente tabla se muestran ejemplos del encabezado X-Forwarded-For que recibe el destino al seleccionar el modo append, preserve o el modo remove. En este ejemplo, la dirección IP de la última transferencia es 127.0.0.1.

Para modificar, conservar o eliminar el X-Forwarded-For encabezado mediante el AWS CLI

Utilice el modify-load-balancer-attributescomando con el routing.http.xff_header_processing.mode atributo.

X-Forwarded-Proto

El encabezado de solicitud X-Forwarded-Proto ayuda a identificar el protocolo (HTTP o HTTPS) que un cliente utiliza para conectarse al equilibrador de carga. Los registros de acceso al servidor contienen únicamente el protocolo que se utiliza entre el servidor y el equilibrador de carga; sin embargo, no contienen información sobre el protocolo utilizado entre el cliente y el equilibrador de carga. Para determinar el protocolo utilizado entre el cliente y el equilibrador de carga, utilice el encabezado de solicitud X-Forwarded-Proto. Elastic Load Balancing almacena el protocolo utilizado entre el cliente y el equilibrador de carga en el encabezado de solicitud X-Forwarded-Proto y se lo pasa al servidor.

La aplicación o el sitio web pueden utilizar el protocolo almacenado en el encabezado de solicitud X-Forwarded-Proto para generar una respuesta que redirija a la URL correspondiente.

El encabezado de solicitud X-Forwarded-Proto tiene el siguiente formato:

X-Forwarded-Proto: originatingProtocol

El siguiente ejemplo contiene un encabezado de solicitud X-Forwarded-Proto correspondiente a una solicitud originada en el cliente como solicitud HTTPS:

X-Forwarded-Proto: https

X-Forwarded-Port

El encabezado de solicitud X-Forwarded-Port ayuda a identificar el puerto de destino que el cliente utiliza para conectarse al equilibrador de carga.