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 agente de HTTPS escucha para delegar el trabajo de cifrado y descifrado en su balanceador de cargas, de modo que sus aplicaciones puedan centrarse en su lógica empresarial. Si el protocolo de escucha lo esHTTPS, debe implementar al menos un SSL certificado de servidor en el agente de escucha. Para obtener más información, consulte Cree un agente de HTTPS escucha para su Application Load Balancer.

Si debe asegurarse de que los destinos descifren el HTTPS tráfico en lugar del balanceador de carga, puede crear un Network Load Balancer con TCP un listener en el puerto 443. Con un agente de TCP escucha, el balanceador de cargas pasa 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 HTTP conexión. Al actualizar, la TCP conexión 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 carga. Se puede utilizar tanto WebSockets con los oyentes como con los HTTP oyentes. HTTPS Las opciones que elija para su oyente se aplican tanto a WebSocket las conexiones como al HTTP tráfico. Para obtener más información, consulta Cómo funciona el WebSocket protocolo en la Guía para CloudFront desarrolladores de Amazon.

Los balanceadores de carga de aplicaciones ofrecen soporte nativo para HTTP /2 con los HTTPS oyentes. Puede enviar hasta 128 solicitudes en paralelo mediante una conexión HTTP /2. Puedes usar la versión del protocolo para enviar la solicitud a los objetivos mediante HTTP /2. Para obtener más información, consulte Versión del protocolo. Como HTTP /2 usa las conexiones front-end de manera más eficiente, es posible que notes menos conexiones entre los clientes y el balanceador de cargas. No puedes usar la función de inserción de servidores de /2. HTTP

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

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 g RPC o HTTP /2, las únicas acciones admitidas son forward las acciones.

Acciones de respuesta fija

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

Cuando se fixed-response realiza una acción, la acción y la del objetivo URL de redireccionamiento se registran 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 balanceadores de carga de aplicaciones no admiten valores de cookies codificados. URL

En el caso de las solicitudes CORS (uso compartido de recursos entre orígenes), algunos navegadores deben SameSite=None; Secure 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 utilizar redirect acciones para redirigir las solicitudes de los clientes de una URL a otra. Puedes configurar los redireccionamientos como temporales (HTTP302) o permanentes (HTTP301) en función de tus necesidades.

A URI consta de 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 URI los componentes del original URL en el destino URL 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 usa el HTTPS protocolo y el puerto especificado (40443), pero conserva 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 a URL que conserva el protocolo, el puerto, el nombre de host y los parámetros de consulta originales, y utiliza la #{path} palabra clave 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 http-header condición, puede especificar hasta tres cadenas para compararlas con el valor del HTTP encabezado de la solicitud. La condición se cumple si una de las cadenas coincide con el valor del HTTP encabezado. 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 ASCII caracteres visibles; se excluyen los caracteres de control (0x00 a 0x1f y 0x7f).

Para ver demostraciones, consulte Direccionamiento de solicitudes avanzado.

HTTPcondiciones de cabecera

Puede usar las condiciones de HTTP encabezado para configurar reglas que enruten las solicitudes en función de HTTP los encabezados de la solicitud. Puede especificar los nombres de los campos de HTTP encabezado 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*"]
      }
  }
]

HTTPcondiciones del método de solicitud

Puede usar las condiciones del método de HTTP solicitud para configurar reglas que enruten las solicitudes en función del método de HTTP solicitud de la solicitud. Puede especificar HTTP métodos 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.

Se recomienda enrutar GET las HEAD solicitudes de la misma manera, ya que la respuesta a una HEAD solicitud puede estar 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 usar las condiciones de ruta para definir reglas que enruten las solicitudes en función de lo que URL aparece en la solicitud (también conocido como enrutamiento basado en rutas).

El patrón de ruta se aplica solo a la ruta delURL, no a sus parámetros de consulta. Se aplica únicamente a los ASCII caracteres 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. 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, servicio o 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 debe especificarse en CIDR formato. Puede utilizar ambas IPv6 direcciones IPv4 y. No se admiten caracteres comodín. No puede especificar la condición 255.255.255.255/32 CIDR 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.

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.

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

HTTPencabezados y balanceadores de carga de aplicaciones

HTTPlas solicitudes y HTTP respuestas utilizan campos de encabezado para enviar información sobre los HTTP mensajes. HTTPlos encabezados 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). En RFC 2616, HTTP Encabezados de mensajes, se define un conjunto estándar de campos de encabezado. También hay disponibles HTTP encabezados no estándar que se añaden automáticamente y que las aplicaciones los utilizan ampliamente. Algunos de los HTTP encabezados 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 sobre HTTP las conexiones, consulte Request Routing en la Guía del usuario de Elastic Load Balancing.

X-Forwarded-For

El encabezado de la X-Forwarded-For solicitud le ayuda a identificar la dirección IP de un cliente cuando utiliza un balanceador de HTTPS carga HTTP o. 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 le permite modificar, conservar o eliminar el X-Forwarded-For encabezado de la HTTP solicitud antes de que Application Load Balancer 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 balanceador de carga anexa la dirección IP del cliente al encabezado existente y, a continuación, pasa el encabezado 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

El siguiente es un ejemplo de encabezado de X-Forwarded-For solicitud para un cliente con una IPv6 dirección de. 2001: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 preserve modo del atributo garantiza que el X-Forwarded-For encabezado de la HTTP solicitud no se modifique de ninguna manera antes de enviarse a los destinos.

Remove

El remove modo del atributo elimina el X-Forwarded-For encabezado de la HTTP solicitud 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 la X-Forwarded-Proto solicitud te ayuda a identificar el protocolo (HTTPoHTTPS) que un cliente usó para conectarse a tu balanceador de cargas. 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.

Tu aplicación o sitio web puede usar el protocolo almacenado en el encabezado de la X-Forwarded-Proto solicitud para generar una respuesta que redirija al protocolo adecuado. URL

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

X-Forwarded-Proto: originatingProtocol

El siguiente ejemplo contiene un encabezado de X-Forwarded-Proto solicitud para una solicitud que se originó en el cliente como una HTTPS solicitud:

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.