Preguntas frecuentes sobre Elastic Load Balancing

Application Load Balancer es compatible con destinos con cualquier sistema operativo que admita el servicio Amazon EC2.

El Application Load Balancer es compatible con el balanceo de carga de aplicaciones mediante los protocolos HTTP y HTTPS (HTTP seguro).

Sí. El balanceador de carga de aplicaciones dispone de compatibilidad nativa con HTTP/2. Los clientes que admiten HTTP/2 pueden conectarse a un balanceador de carga de aplicaciones a través de TLS.

Puede enviar tráfico desde el equilibrador de carga de red, lo que ofrece compatibilidad con PrivateLink y una dirección IP estática por zona de disponibilidad para el equilibrador de carga de aplicación. Cree un grupo de destino del tipo balanceador de carga de aplicaciones, registre el balanceador de carga de aplicaciones en el grupo y configure el balanceador de carga de red para enviar tráfico al grupo de destino del tipo balanceador de carga de aplicaciones.

Puede realizar el balanceo de carga para los siguientes puertos TCP: 1-65535.

Sí. El Application Load Balancer dispone de compatibilidad nativa con WebSockets y Secure WebSockets, que están listos para su uso.

Sí. El seguimiento de solicitudes está habilitado por defecto en el Application Load Balancer.

Aunque hay cierto solapamiento, no hay paridad de características entre los dos tipos de equilibradores de carga. Los balanceadores de carga de aplicaciones formarán las bases de nuestra plataforma de balanceo de carga en la capa de la aplicación en el futuro.

Sí.

Sí.

No. Los equilibradores de carga de aplicación requieren un nuevo conjunto de interfaces de programación de aplicaciones (API).

La consola de ELB le permite administrar balanceadores de carga clásicos y de aplicaciones a través de la misma interfaz. Si utiliza la interfaz de línea de comandos (CLI) o un kit de desarrollo de software (SDK), utilizará un “servicio” diferente para el balanceador de carga de aplicaciones. Por ejemplo, en la CLI describirá sus balanceadores de carga clásicos con "aws elb describe-load-balancers" y sus balanceadores de carga de aplicaciones con "aws elbv2 describe-load-balancers".

No, no puede convertir un tipo de balanceador de carga en otro.

Sí. Puede migrar a un equilibrador de carga de aplicación desde un equilibrador de carga clásico a través una de las opciones incluidas en este documento.

No. Si necesita características de capa 4, debería usar Network Load Balancer.

Sí, puede correlacionar el puerto 80 HTTP y el puerto 443 HTTPS con un Application Load Balancer individual.

Sí. Para obtener un historial de las llamadas a la API del equilibrador de carga de aplicación realizadas en su cuenta, utilice AWS CloudTrail.

Sí, puede terminar la conexión HTTPS en el Application Load Balancer. Debe instalar un certificado de Capa de conexión segura (SSL) en su balanceador de carga. El balanceador de carga utiliza este certificado para terminar la conexión y luego descifra las solicitudes de los clientes antes de enviarlas a los destinos.

Puede utilizar AWS Certificate Manager para aprovisionar un certificado SSL/TLS, o bien obtenerlo de otras fuentes al crear una solicitud de certificado, obtener la solicitud de certificado firmada por una CA y luego cargar el certificado con el servicio AWS Certification Manager o AWS Identity and Access Management (IAM).

El Application Load Balancer se integra con AWS Certificate Manager (ACM). La integración con ACM simplifica la vinculación de un certificado al balanceador de carga, lo que agiliza todo el proceso de descarga de SSL. Comprar, cargar y renovar certificados SSL/TLS es un proceso complejo, manual y que requiere mucho tiempo. Gracias a la integración de ACM con el Application Load Balancer, el proceso se reduce a solicitar un certificado SSL/TLS de confianza y a seleccionar el certificado ACM para aprovisionarlo con el balanceador de carga.

No, con un Application Load Balancer solo se admite el cifrado en el back-end.

La SNI se activa automáticamente cuando asocia más de un certificado TLS con el mismo agente de escucha seguro en un balanceador de carga. De manera similar, el modo SNI para un agente de escucha seguro se desactiva automáticamente cuando solo tiene un certificado asociado con un agente de escucha.

Sí, puede asociar varios certificados para el mismo dominio con un agente de escucha seguro. R: Por ejemplo, puede asociar:

• Certificados ECDSA y RSA
• Certificados con diferentes tamaños de claves (p. ej., 2048 y 4096 bits) para certificados SSL/TLS
• Certificados de dominio único, multidominio (SAN) y de comodín

Sí, IPv6 es compatible con el Application Load Balancer.

Puede configurar reglas para cada uno de los agentes de escucha en el equilibrador de carga. Las reglas incluyen condiciones y acciones correspondientes si se cumplen las condiciones. Las condiciones admitidas son el encabezado del host, la ruta, los encabezados HTTP, los métodos, los parámetros de consulta y el enrutamiento entre dominios sin clase de IP fuente (CIDR). Las acciones compatibles son la redirección, la respuesta fija, la autenticación y el reenvío. Una vez que haya configurado esto, el balanceador de carga usará las reglas para determinar cómo debe dirigirse una solicitud HTTP en particular. Puede usar múltiples condiciones y acciones en una regla y en cada condición puede especificar una coincidencia con varios valores.

Su cuenta de AWS dispone de estos límites para el equilibrador de carga de aplicación.

Puede integrar su equilibrador de carga de aplicación con Web Application Firewall (WAF) de AWS, un firewall de aplicaciones web que ayuda a proteger las aplicaciones web de ataques y permite configurar reglas basadas en direcciones IP, encabezados HTTP y cadenas de identificadores uniformes de recursos (URI) personalizados. Usando estas reglas, AWS WAF puede bloquear, autorizar o monitorizar (contar) solicitudes web para su aplicación web. Puede obtener más información en la Guía para desarrolladores de AWS WAF.

Puede usar cualquier dirección IP del CIDR de VPC del equilibrador de carga para los destinos dentro de la VPC del equilibrador de carga y cualquier dirección IP de los rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16) o del rango RFC 6598 (100.64.0.0/10) para destinos ubicados fuera de la VPC del equilibrador de carga (por ejemplo, destinos en Peered VPC, Amazon EC2 Classic y ubicaciones locales accesibles a través de AWS Direct Connect o una conexión de VPN).

Existen varias maneras de lograr un equilibrio de cargas híbrido. Si una aplicación se ejecuta en destinos distribuidos entre una VPC y una ubicación local, puede añadirlos al mismo grupo de destinos mediante el uso de direcciones IP. Para migrar a AWS sin afectar a su aplicación, añada gradualmente destinos VPC al grupo de destino y quite los locales. 

Si tiene dos aplicaciones diferentes y los destinos de una aplicación se encuentran en una VPC y los destinos de otras aplicaciones se encuentran en una ubicación local, puede colocar los destinos de VPC en un grupo de destino y los destinos locales en otro grupo y, a continuación, usar el direccionamiento basado en contenido para direccionar tráfico a cada grupo. También puede usar balanceadores de carga independientes para destinos on-premise y VPC, y usar ponderación de DNS para lograr un equilibrio de carga ponderado entre los destinos en VPC y on-premise.

No puede equilibrar cargas en instancias EC2-Classic cuando registra sus ID de instancia como destinos. Sin embargo, si vincula estas instancias EC2-Classic con la VPC del balanceador de carga mediante ClassicLink y usa IP privadas de estas instancias EC2-Classic como destinos, entonces puede equilibrar cargas en las instancias EC2-Classic. Si en la actualidad utiliza instancias EC2-Classic con un Classic Load Balancer, puede migrar fácilmente a un Application Load Balancer.

El equilibrio de cargas entre zonas está activado de manera predeterminada en Application Load Balancer.

Debe usar la autenticación de usuarios mediante Amazon Cognito si:

• Quiere ofrecer a sus usuarios la flexibilidad para autenticarse mediante identidades de redes sociales (Google, Facebook y Amazon) o identidades empresariales (SAML) o mediante sus propios directorios de usuarios provistos por el grupo de usuarios de Amazon Cognito.
• Administra varios proveedores de identidades, incluido OpenID Connect y desea crear una regla de autenticación única en el balanceador de carga de aplicaciones (ALB) que pueda usar Amazon Cognito para federar todos los proveedores.
• Debe administrar activamente los perfiles de usuario con uno o más proveedores identidades de OpenID Connect o redes sociales desde un lugar central. Por ejemplo, puede incluir usuarios en grupos y añadir atributos personalizados para representar su estatus de usuario y controlar el acceso de usuarios pagos.

Alternativamente, si ha invertido en el desarrollo de soluciones de IdP personalizadas y simplemente desea autenticarse con un único proveedor de identidad compatible con OpenID Connect, es posible que prefiera utilizar la solución OIDC nativa del balanceador de carga de aplicaciones.

Se admiten los siguientes tres tipos de redirecciones.

HTTP a HTTP
http://hostA to http://hostB

HTTP a HTTPS
http://hostA to https://hostB
https://hostA:portA/pathA to https://hostB:portB/pathB

HTTPS a HTTPS
https://hostA to https://hostB

Se admiten los siguientes tipos de contenido: texto/sin formato, texto/css, texto/html, aplicación/javascript, aplicación/json.

Las solicitudes HTTP(S) recibidas por un equilibrador de carga las procesan las reglas de enrutamiento basadas en contenido. Si el contenido de la solicitud coincide con la regla, con una acción para reenviarlo a un grupo objetivo a través de una función Lambda como objetivo, se invoca la función Lambda correspondiente. El contenido de la solicitud (incluidos los encabezados y el cuerpo) se transmite a la función Lambda en formato de notación de objetos JavaScript (JSON). La respuesta de la función Lambda debe estar en formato JSON. La respuesta de la función Lambda se transforma en una respuesta HTTP y se envía al cliente. El balanceador de carga invoca su función Lambda mediante la API Invoke de AWS Lambda y requiere que proporcione permisos de invocación para su función Lambda al servicio Elastic Load Balancing.

Sí. El balanceador de carga de aplicaciones admite la invocación Lambda para solicitudes a través del protocolo HTTP y HTTPS.

Puede utilizar Lambda como destino con el equilibrador de carga de aplicación en las regiones de AWS Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Norte de California), Oeste de EE. UU. (Oregón), Asia-Pacífico (Bombay), Asia-Pacífico (Seúl), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Canadá (centro), UE (Fráncfort), UE (Irlanda), UE (Londres), UE (París), América del Sur (São Paulo) y GovCloud (Oeste de EE. UU.).

Sí, el equilibrador de carga de aplicación está disponible en la zona local de Los Ángeles. Dentro de la zona local de Los Angeles, el balanceador de carga de aplicaciones opera en una subred única y escala de manera automática para satisfacer los diversos niveles de la carga de la aplicación sin intervención manual.

Se le cobra cada hora u hora parcial que se ejecute el Application Load Balancer y la cantidad de unidades de capacidad de balanceo de carga (LCU) utilizadas por hora.

Una LCU es una nueva métrica que ayuda a determinar el pago del Application Load Balancer. Una LCU define el recurso máximo consumido en cualquiera de las dimensiones (conexiones nuevas, conexiones activas y ancho de banda) en las que el Application Load Balancer procesa el tráfico.

No, los Classic Load Balancer seguirán facturándose en función del ancho de banda y uso por hora.

Exponemos el uso de las cuatro dimensiones que constituyen una LCU a través de Amazon CloudWatch.

La cantidad de LCU por hora depende del recurso máximo consumido entre las cuatro dimensiones que constituyen una LCU.

Sí.

Sí. Las cuentas nuevas de AWS tienen acceso a una capa gratuita del Application Load Balancer que incluye 750 horas y 15 LCU. Esta oferta de capa gratuita está disponible exclusivamente para los nuevos clientes de AWS y solo durante 12 meses a partir de la fecha de inscripción en AWS.

Sí. Puede usar tanto el balanceador de carga clásico como el de aplicaciones para 15 GB y 15 LCU respectivamente. Las 750 horas de balanceo de carga se comparten entre el Classic y el Application Load Balancer.

Las evaluaciones de regla se definen como el producto de la cantidad de reglas procesadas y la tasa de solicitudes promedio en una hora.

El tamaño de las claves de los certificados únicamente afecta el número de conexiones nuevas por segundo en el cálculo de la LCU para facturación. La siguiente tabla incluye el valor de esta dimensión para diferentes tamaños de claves para certificados RSA y ECDSA.

Certificados RSA
Tamaño de clave: <=2000 
Nuevas conexiones/segundo: 25

Tamaño de clave: <=4000 
Nuevas conexiones/segundo: 5

Tamaño de clave: <=8000 
Nuevas conexiones/segundo: 1

Tamaño de clave: >8000
Nuevas conexiones/segundo: 0,25

Certificados ECDSA
Tamaño de clave: <=256
Nuevas conexiones/segundo: 25

Tamaño de clave: <=384
Nuevas conexiones/segundo: 5

Tamaño de clave: <=521 
Nuevas conexiones/segundo: 1

Tamaño de clave: >521 
Nuevas conexiones/segundo: 0,25

No. Dado que el equilibrio de carga entre zonas distintas está siempre activado con el balanceador de carga de aplicaciones, no se le aplicará ningún costo por este tipo de transferencias de datos regionales.

No existe un cargo separado para la activación de la funcionalidad de autenticación en Application Load Balancer. Cuando use Amazon Cognito con Application Load Balancer, se aplicarán los precios de Amazon Cognito.

Como de costumbre, se cobra cada hora u hora parcial que se ejecute el equilibrador de carga de aplicación y la cantidad de unidades de capacidad del equilibrador de carga (LCU) utilizadas por hora. Para los destinos Lambda, cada LCU ofrece 0,4 GB de bytes procesados por hora, 25 nuevas conexiones por segundos, 3000 conexiones activas por minuto y 1000 evaluaciones de regla por segundo. Para la dimensión de bytes procesados, cada LCU proporciona 0,4 GB por hora para objetivos Lambda frente a 1 GB por hora para todos los demás tipos de objetivos, como instancias, contenedores y direcciones IP de Amazon EC2. Tenga en cuenta que el balanceador de carga de aplicaciones aplica los cargos de AWS Lambda habituales a las invocaciones de Lambda.

Los equilibradores de carga de aplicación son compatibles con dos nuevas métricas de CloudWatch. La métrica LambdaTargetProcessedBytes indica los bytes procesados por destinos Lambda y la métrica StandardProcessedBytes indica los bytes procesados por todos los demás tipos de destinos.

Sí. Los balanceadores de carga de red son compatibles con los agentes de escucha TCP, UDP y TCP+UDP (capa 4) y también con los TLS.

El equilibrador de carga de red ofrece equilibrio de carga TCP y UDP (capa 4). Está diseñado para manejar millones de solicitudes por segundo y patrones de tráfico volátiles repentinos, y proporciona latencias extremadamente bajas. Asimismo, el balanceador de carga de red conserva la IP fuente de sus clientes y admite interrupción de TLS, proporciona un soporte de IP estable y aísla las zonas. También admite conexiones de larga duración que son útiles para aplicaciones de tipo WebSocket.

Sí. Para hacerlo, puede utilizar un agente de escucha TCP+UDP. Por ejemplo, para un servicio DNS que usa tanto TCP como UDP, puede crear un agente de escucha TCP+UDP en el puerto 53, y el balanceador de carga procesará el tráfico para las solicitudes UDP y TCP en ese puerto. Tiene que asociar un agente de escucha TCP+UDP con un grupo de destino TCP+UDP.

El equilibrador de carga de red conserva la IP de origen del cliente, la cual no se conserva en el equilibrador de carga clásico. Los clientes pueden usar el protocolo del proxy con el balanceador de carga clásico para obtener la IP fuente. El balanceador de carga de red proporciona automáticamente una IP estática por zona de disponibilidad (AZ) al balanceador de carga y también permite asignar una IP elástica al balanceador de carga por AZ. El balanceador de carga clásico no admite estas funciones.

Sí. R: Puede migrar a un balanceador de carga de red desde un balanceador de carga clásico mediante una de las opciones incluidas en este documento.

Sí. Consulte la documentación sobre límites del equilibrador de carga de red para obtener más información.

Sí, puede usar la consola de administración de AWS, AWS CLI o la API para configurar un Network Load Balancer.

Para crear un Classic Load Balancer, use la API 2012-06-01. Para crear un Network Load Balancer o un Application Load Balancer, use la API 2015-12-01.

Sí, puede crear el equilibrador de carga de red en una sola zona de disponibilidad al proporcionar una subred única cuando crea el equilibrador de carga.

Sí, puede utilizar las características de recuperación ante errores a nivel de DNS y la comprobación de estado de Amazon Route 53 para mejorar la disponibilidad de las aplicaciones que se ejecutan en segundo plano de los Network Load Balancer. Mediante la conmutación por error a nivel de DNS de Route 53, puede ejecutar aplicaciones en varias zonas de disponibilidad de AWS y designar balanceadores de carga alternativos para la conmutación por error en las distintas regiones. 

En caso de que tenga configurado el balanceador de carga de red para multi-AZ, si no hay instancias de Amazon EC2 registradas funcionando correctamente con el balanceador de carga para esa zona de disponibilidad, o si los nodos del balanceador de carga en una zona determinada no funcionan correctamente, Route 53 fallará para alternar los nodos del balanceador de carga en otras zonas de disponibilidad que funcionen correctamente.

Usted o un ELB deben tener el control absoluto de las direcciones de un Network Load Balancer. Esto es para garantizar que cuando use IP elásticas con un Network Load Balancer, ninguna de las direcciones que conocen sus clientes cambiará.

No. Para cada subred asociada en la que se encuentre un equilibrador de carga de red, este solo puede ser compatible con una única dirección IP pública/orientada a Internet.

Las direcciones IP elásticas que se asociaron con su equilibrador de carga volverán al grupo asignado y estarán disponibles para uso futuro.

El equilibrador de carga de red se puede configurar como un equilibrador de carga que se conecta a Internet o un equilibrador de carga interno, similar a lo que se puede hacer con el equilibrador de carga de aplicación y el equilibrador de carga clásico.

Por cada subred asociada en la que se encuentre el balanceador de carga, Network Load Balancer solo puede admitir una sola IP privada.

Sí, configure los agentes de escucha TCP que enrutan el tráfico a las instancias que implementan el protocolo WebSockets (https://tools.ietf.org/html/rfc6455 ). Dado que WebSockets es un protocolo de capa 7 y Network Load Balancer funciona en la capa 4, no hay un manejo especial del Network Load Balancer para WebSockets u otros protocolos de un nivel superior.

Sí. Puede usar cualquier dirección IP del CIDR de VPC del balanceador de carga para los destinos dentro de la VPC del balanceador de carga y cualquier dirección IP de los rangos RFC 1918 (10.0.0.0/8, 172.16.0.0/12 y 192.168.0.0/16) o del rango RFC 6598 (100.64.0.0/10) para destinos ubicados fuera de la VPC del balanceador de carga (EC2-Classic y ubicaciones on-premise accesibles a través de AWS Direct Connect). El balanceador de carga a la dirección IP es compatible solo con los agentes de escucha TCP y actualmente no es compatible con agentes de escucha UDP.

Sí, los equilibradores de carga de red con agentes de escucha TCP y TLS se pueden utilizar para configurar AWS PrivateLink. No puede configurar PrivateLink con agentes de escucha UDP en balanceadores de carga de red.

Si bien el protocolo de datagramas de usuario (UDP) no tiene conexión, el equilibrador de carga mantiene el estado de flujo UDP basado en un hash de 5 tuplas, lo que garantiza que los paquetes enviados en el mismo contexto se reenvíen de manera consistente al mismo destino. El flujo se considera activo mientras el tráfico fluya y hasta que se alcance el tiempo de espera de inactividad. Una vez que se alcanza el umbral de tiempo de espera, el balanceador de carga olvidará la afinidad y el paquete UDP entrante se considerará un nuevo flujo y se equilibrará la carga con un nuevo objetivo.

El tiempo de espera de inactividad del equilibrador de carga de red para conexiones TCP es de 350 segundos. El tiempo de espera de inactividad para los flujos UDP es de 120 segundos.

Cada contenedor en una instancia ahora puede tener su propio grupo de seguridad y no necesita compartir reglas de seguridad con otros contenedores. Puede adjuntar grupos de seguridad a un ENI y cada ENI de una instancia puede tener un grupo de seguridad diferente. Puede asignar un contenedor a la dirección IP de un ENI específico para asociar grupos de seguridad por contenedor. El equilibrio de cargas mediante direcciones IP también permite que varios contenedores que se ejecutan en una instancia usen el mismo puerto (por ejemplo, el puerto 80). La capacidad para usar el mismo puerto entre contenedores permite que los contenedores de una instancia se comuniquen entre sí mediante puertos conocidos en vez de por puertos aleatorios.

Existen varias maneras de lograr un equilibrio de cargas híbrido. Si una aplicación se ejecuta en destinos distribuidos entre una VPC y una ubicación local, puede añadirlos al mismo grupo de destinos mediante el uso de direcciones IP. Para migrar a AWS sin afectar a su aplicación, añada gradualmente destinos VPC al grupo de destino y quite los locales. También puede usar balanceadores de carga independientes para destinos on-premise y VPC, y usar ponderación de DNS para lograr un equilibrio de carga ponderado entre los destinos en VPC y on-premise.

No puede equilibrar cargas en instancias EC2-Classic cuando registra sus ID de instancia como destinos. Sin embargo, si vincula estas instancias EC2-Classic con la VPC del balanceador de carga mediante ClassicLink y usa IP privadas de estas instancias EC2-Classic como destinos, entonces puede equilibrar cargas en las instancias EC2-Classic. Si en la actualidad utiliza instancias EC2-Classic con un Classic Load Balancer, puede migrar fácilmente a un Network Load Balancer.

Puede activar el equilibrio de cargas entre zonas únicamente después de crear su Network Load Balancer. Esto se logra al modificar la sección de atributos del balanceador de carga y luego seleccionar la casilla de verificación de soporte del balanceador de carga entre zonas.

Sí, se le cobrará la transferencia de datos regional entre zonas de disponibilidad con el balanceador de carga de red cuando se active el equilibrio de cargas entre zonas. Consulte los costos en la sección de transferencia de datos de la página de precios de instancias bajo demanda de Amazon EC2.

Sí. Actualmente, el balanceador de carga de red admite 200 destinos por zona de disponibilidad. Por ejemplo, si se encuentra en dos zonas de disponibilidad, puede tener hasta 400 destinos registrados con el balanceador de carga de red. Si el balanceador de carga entre zonas está activado, los objetivos máximos se reducen de 200 por zona de disponibilidad a 200 por balanceador de carga. Por lo tanto, en el ejemplo anterior: cuando el balanceador de carga entre zonas está activado, aunque su balanceador de carga esté en dos zonas de disponibilidad, tiene un límite de 200 destinos que se pueden registrar en el balanceador de carga.

Sí, puede terminar conexiones TLS en el equilibrador de carga de red. Debe instalar un certificado SSL en su balanceador de carga. El balanceador de carga utiliza este certificado para terminar la conexión y luego descifra las solicitudes de los clientes antes de enviarlas a los destinos.

La IP de origen se conserva cuando se termina la conexión TLS en el equilibrador de carga de red.

Puede utilizar AWS Certificate Manager para aprovisionar un certificado SSL/TLS, o bien obtenerlo de otras fuentes al crear una solicitud de certificado, obtener la solicitud de certificado firmada por una autoridad de certificación (CA) y luego cargar el certificado con el servicio AWS Certification Manager (ACM) o AWS Identity and Access Management (IAM).

La SNI se activa automáticamente cuando asocia más de un certificado TLS con el mismo agente de escucha seguro en un balanceador de carga. De manera similar, el modo SNI para un agente de escucha seguro se desactiva automáticamente cuando solo tiene un certificado asociado con un agente de escucha.

El equilibrador de carga de red se integra en AWS Certificate Manager (ACM). Gracias a la integración con ACM, es muy sencillo vincular un certificado al balanceador de carga, por lo que todo el proceso de descarga SSL resulta muy fácil. La compra, carga y renovación de certificados SSL/TLS es un proceso manual y complejo que requiere bastante tiempo. Gracias a la integración de ACM con el balanceador de carga de red, el proceso se reduce a solicitar un certificado SSL/TLS de confianza y a seleccionar el certificado ACM para aprovisionarlo con el balanceador de carga. Una vez que haya creado un balanceador de carga de red, ahora puede configurar un agente de escucha TLS seguido de una opción para seleccionar un certificado de ACM o Identity Access Manager (IAM). Se trata de un proceso similar al que puede experimentar en el balanceador de carga de aplicaciones o en el balanceador de carga clásico.

No, solo es compatible con el cifrado en el backend con un equilibrador de carga de red.

El equilibrador de carga de red solo es compatible con certificados RSA con un tamaño de clave de 2K. Por el momento, el balanceador de carga de red no admite tamaños de clave de certificados RSA mayores de 2K ni certificados ECDSA.

Puede utilizar la interrupción de TLS con el equilibrador de carga de red en las regiones de AWS Este de EE. UU. (Norte de Virginia), Este de EE. UU. (Ohio), Oeste de EE. UU. (Norte de California), Oeste de EE. UU. (Oregón), Asia-Pacífico (Bombay), Asia-Pacífico (Seúl), Asia-Pacífico (Singapur), Asia-Pacífico (Sídney), Asia-Pacífico (Tokio), Canadá (centro), UE (Fráncfort), UE (Irlanda), UE (Londres), UE (París), América del Sur (São Paulo) y GovCloud (Oeste de EE. UU.).

Se le cobra cada hora u hora parcial que se ejecute el Network Load Balancer y la cantidad de unidades de capacidad de balanceo de carga (LCU) que utilice el Network Load Balancer por hora.

Una LCU es una nueva métrica que determina el pago del Network Load Balancer. Una LCU define el recurso máximo consumido en cualquiera de las dimensiones (conexiones/flujos nuevos, conexiones/flujos activos y ancho de banda) en las que el Network Load Balancer procesa el tráfico.

Las métricas LCU para el tráfico TCP son las siguientes:

• 800 conexiones nuevas por segundo.
• 100 000 conexiones de TCP activas (con muestras por minuto).
• 1 GB por hora para las instancias de Amazon EC2, contenedores y direcciones IP como destinos.

Las métricas LCU para el tráfico UDP son las siguientes:

• 400 flujos nuevos por segundo.
• 50 000 flujos de UDP activos (con muestras por minuto).
• 1 GB por hora para las instancias de Amazon EC2, contenedores y direcciones IP como destinos.

Las métricas LCU para el tráfico TLS son las siguientes:

• 50 conexiones TLS nuevas por segundo.
• 3 000 conexiones TLS activas (con muestras por minuto).
• 1 GB por hora para las instancias de Amazon EC2, contenedores y direcciones IP como destinos.

No, para cada protocolo se cobra solamente una de las tres dimensiones (la que tenga el mayor uso por hora).

No. Se pueden enviar varias solicitudes en una sola conexión.

No. Los equilibradores de carga clásicos se facturarán según el ancho de banda y el uso por hora.

Podrá ver el uso de las tres dimensiones que constituyen una LCU en Amazon CloudWatch.

No. La cantidad de LCU por hora depende del recurso máximo consumido entre las tres dimensiones que constituyen una LCU.

Sí.

Sí. Las cuentas nuevas de AWS tienen acceso a una capa gratuita del Network Load Balancer que incluye 750 horas y 15 LCU. Esta oferta de capa gratuita está disponible exclusivamente para los nuevos clientes de AWS y solo durante 12 meses a partir de la fecha de inscripción en AWS.

Sí. Puede usar una de aplicación y una de red durante 15 LCU cada uno y el clásico durante 15 GB respectivamente. Las 750 horas del balanceador de carga se comparten entre los balanceadores de carga de aplicaciones, de red y clásico.

Debe usar el balanceador de carga Gateway al implementar dispositivos virtuales en línea donde el tráfico de red no está destinado al balanceador de carga Gateway en sí. El balanceador de carga Gateway pasa de forma transparente todo el tráfico de la capa 3 a través de dispositivos virtuales de terceros y es invisible para el origen y el destino del tráfico. Para obtener más detalles sobre cómo se comparan estos equilibradores de carga, consulte la página de comparación de características.

El equilibrador de carga de puerta de enlace se ejecuta dentro de una zona de disponibilidad.

El equilibrador de carga de puerta de enlace ofrece capacidades de puerta de enlace de la capa 3 y de balance de carga de la capa 4. Se trata de un dispositivo BITW (bump-in-the-wire) transparente que no modifica ninguna parte del paquete. Está diseñado para manejar millones de solicitudes por segundo, patrones de tráfico volátiles y presenta latencias extremadamente bajas. Consulte las características del equilibrador de carga de puerta de enlace en esta tabla. 

El balanceador de carga Gateway no realiza la terminación de TLS y no mantiene ningún estado de la aplicación. Estas funciones las realizan los dispositivos virtuales de terceros a los que dirige y de los que recibe el tráfico.

El equilibrador de carga de puerta de enlace no mantiene el estado de la aplicación, pero sí la adherencia del flujo a un dispositivo específico usando 5 tuplas (para flujos TCP/UDP) o 3 tuplas (para flujos que no son TCP/UDP).

Por defecto, el equilibrador de carga de puerta de enlace define un flujo como una combinación de una tupla de 5 que se compone de la IP de origen, la IP de destino, el protocolo de IP, el puerto de origen y el puerto de destino. Mediante el uso del hash predeterminado de 5 tuplas, el equilibrador de carga de puerta de enlace se asegura de que las dos direcciones de un flujo (es decir, de origen a destino y de destino a origen) se reenvíen de manera sistemática al mismo destino. El flujo se considera activo mientras el tráfico fluya y hasta que se alcance el tiempo de espera de inactividad. Una vez alcanzado el umbral de tiempo de espera, el equilibrador de carga olvidará la afinidad, y el paquete de tráfico de entrada se considerará como un nuevo flujo y permitirá equilibrar la carga para un nuevo destino.

La persistencia predeterminada de 5 tuplas (IP de origen, IP de destino, protocolo de IP, puerto de origen y puerto de destino) proporciona una distribución óptima del tráfico hacia los destinos y es adecuada para la mayoría de las aplicaciones basadas en los protocolos de red TCP y UDP, con algunas excepciones. La persistencia predeterminada de 5 tuplas no es conveniente para aplicaciones basadas en protocolos de red TCP o UDP que utilizan flujos o números de puerto separados para el control y los datos, como FTP, Microsoft RDP, Windows RPC y SSL VPN. Los flujos de control y de datos de estas aplicaciones pueden aterrizar en diferentes dispositivos de destino y provocar la interrupción del tráfico. Si usted desea admitir este tipo de protocolos, debe habilitar la persistencia de flujos del equilibrador de cargas de puerta de enlace (GWLB) mediante la utilización de 3 tuplas (IP de origen, IP de destino, protocolo de IP) o 2 tuplas (IP de origen, IP de destino).

Algunas aplicaciones no utilizan el transporte TCP o UDP, sino protocolos de IP tales como SCTP y GRE. Con la persistencia predeterminada de 5 tuplas del GWLB, los flujos de tráfico de estos protocolos pueden aterrizar en diferentes dispositivos de destino y provocar interrupciones. Si usted desea admitir este tipo de protocolos, debe habilitar la persistencia de flujos del equilibrador de cargas de puerta de enlace (GWLB) mediante la utilización de 3 tuplas (IP de origen, IP de destino, protocolo de IP) o 2 tuplas (IP de origen, IP de destino).

Para obtener más información sobre cómo modificar el tipo de persistencia de flujo, consulte la documentación sobre la persistencia del flujo.

El tiempo de espera de inactividad del equilibrador de carga de puerta de enlace para conexiones TCP es de 350 segundos. El tiempo de espera de inactividad para los flujos que no son UDP es de 120 segundos. Estos tiempos de espera son fijos y no se pueden modificar.

Al ser un dispositivo bump-in-the-wire transparente, GWLB en sí mismo no fragmenta ni reensambla los paquetes.

El GWLB reenvía los fragmentos de UDP hacia o desde los dispositivos de destino. Sin embargo, el GWLB descarta los fragmentos de TCP e ICMP porque el encabezado de la capa 4 no está presente en estos fragmentos.

Además, si el dispositivo de destino convierte el paquete entrante original en fragmentos y envía los fragmentos recién creados al GWLB, el GWLB descarta estos fragmentos recién creados porque no contienen un encabezado de capa 4. Para evitar que se produzca fragmentación en el dispositivo de destino, recomendamos habilitar el marco Jumbo en su dispositivo de destino o configurar la interfaz de red de su dispositivo de destino para que utilice el máximo de MTU deseado, con lo que se logra un comportamiento de reenvío transparente al conservar el contenido de los paquetes originales tal cual. 

Cuando falla una única instancia de dispositivo virtual, el balanceador de carga Gateway la quita de la lista de enrutamiento y redirige el tráfico a una instancia de dispositivo en buen estado.

Si todos los dispositivos virtuales dentro de una zona de disponibilidad fallan, el equilibrador de carga de puerta de enlace eliminará el tráfico de red. Recomendamos implementar los balanceadores de carga Gateway en varias zonas de disponibilidad para obtener una mayor disponibilidad. Si todos los dispositivos fallan en una zona de disponibilidad, se pueden usar scripts para agregar dispositivos nuevos o dirigir el tráfico a un balanceador de carga Gateway en una zona de disponibilidad diferente.

Sí, varios balanceadores de carga Gateway pueden apuntar al mismo conjunto de dispositivos virtuales.

El equilibrador de carga de puerta de enlace es un dispositivo BITW transparente y escucha todo tipo de tráfico IP (lo que incluye TCP, UDP, ICMP, GRE, ESP y otros). Por lo tanto, solo se crea un agente de escucha IP en un balanceador de carga Gateway.

Sí, consulte la documentación sobre límites del equilibrador de carga de puerta de enlace para obtener más información.

Sí, puede usar la Consola de administración de AWS, la CLI de AWS o la API para configurar un equilibrador de carga de puerta de enlace.

Sí, puede crear el equilibrador de carga de puerta de enlace en una sola zona de disponibilidad al proporcionar una sola subred en el momento de crear el equilibrador de carga. Sin embargo, recomendamos usar varias zonas de disponibilidad para mejorar la disponibilidad. No puede agregar ni eliminar zonas de disponibilidad para un balanceador de carga Gateway después de crearlo.

De forma predeterminada, el equilibrio de cargas entre zonas está deshabilitado. Puede activar el balance de cargas entre zonas únicamente después de crear su balanceador de cargas Gateway. Para lograrlo, debe modificar la sección de atributos del equilibrio de cargas y, a continuación, seleccionar la casilla de verificación de compatibilidad con el equilibrio de cargas entre zonas.

Sí, se le cobrará la transferencia de datos entre zonas de disponibilidad con el equilibrador de carga de puerta de enlace cuando se habilite el equilibrio de cargas entre zonas. Consulte los costos en la sección de transferencia de datos de la página de precios de instancias bajo demanda de Amazon EC2.

Sí. Actualmente, el balanceador de carga Gateway admite 300 destinos por zona de disponibilidad. Por ejemplo, si crea un balanceador de carga Gateway en 3 zonas de disponibilidad, puede tener hasta 900 destinos registrados. Si el balance de cargas entre zonas está activado, entonces el número máximo de destinos se reduce de 300 por zona de disponibilidad a 300 por balanceador de carga Gateway.

Se cobra por cada hora u hora parcial en la que el equilibrador de carga de puerta de enlace se ejecute, así como por el número de unidades de capacidad del equilibrador de carga (LCU) utilizadas por el equilibrador de carga de puerta de enlace por hora.

Una LCU es una métrica de Elastic Load Balancing para determinar cómo se paga por un equilibrador de carga de puerta de enlace. Una LCU define el recurso máximo consumido en cualquiera de las dimensiones (conexiones o flujos nuevos, conexiones o flujos activos y banda ancha) en las que el balanceador de carga Gateway procesa el tráfico.

Las métricas LCU para el tráfico TCP son las siguientes:

• 600 flujos (o conexiones) nuevos por segundo.
• 60 000 flujos (o conexiones) activos (con muestras por minuto).
• 1 GB por hora para las instancias EC2, contenedores y direcciones IP como destinos.

No, se le cobra solamente una de las tres dimensiones (la que tenga el mayor uso por hora).

No. Se pueden enviar varias solicitudes en una sola conexión.

Puede hacer un seguimiento del uso de las tres dimensiones de una LCU a través de Amazon CloudWatch.

Sí.

Para ser valiosos, los dispositivos virtuales deben presentar la menor latencia adicional posible, y el tráfico que fluye hacia y desde el dispositivo virtual debe seguir una conexión segura. Los puntos de enlace del balanceador de carga Gateway crean las conexiones seguras y de baja latencia necesarias para cumplir con estos requisitos.

Con un punto de enlace del balanceador de carga Gateway, los dispositivos pueden residir en diferentes cuentas de AWS y VPC. Esto permite que los dispositivos se centralicen en una ubicación para facilitar la gestión y reducir los gastos operativos.

Los puntos de enlace del balanceador de carga Gateway son un nuevo tipo de punto de enlace de la VPC que utiliza la tecnología PrivateLink. A medida que el tráfico de red fluye de un origen (gateway de Internet, VPC, etc.) al balanceador de carga Gateway, y viceversa, un punto de enlace del balanceador de carga Gateway garantiza la conectividad privada entre los dos. Todo el tráfico fluye a través de la red de AWS y los datos nunca se exponen a Internet, lo que aumenta tanto la seguridad como el rendimiento.

Un punto de enlace de la interfaz PrivateLink se empareja con un Network Load Balancer (NLB, Balanceador de carga de red) para distribuir el tráfico TCP y UDP destinado a las aplicaciones web. Por el contrario, los puntos de enlace del balanceador de carga Gateway se utilizan con balanceadores de carga Gateway para conectar el origen y el destino del tráfico. El tráfico fluye desde el punto de conexión del equilibrador de carga de puerta de enlace hasta el equilibrador de carga de puerta de enlace a través de los dispositivos virtuales y de regreso al destino a través de conexiones PrivateLink seguras.

Un punto de conexión del equilibrador de carga de puerta de enlace es un punto de conexión de VPC y no hay límite respecto al número de puntos de conexión VPC que se pueden conectar a un servicio que usa un equilibrador de carga de la puerta de enlace. Sin embargo, recomendamos que no se conecten más de 50 puntos de conexión del equilibrador de carga de puerta de enlace por equilibrador de carga de la puerta de enlace para reducir el riesgo de un impacto mayor en caso de fallo del servicio.

El Classic Load Balancer admite instancias de Amazon EC2 con cualquiera de los sistemas operativos que admite actualmente el servicio de Amazon EC2.

El balanceador de carga clásico admite el balanceo de carga de aplicaciones que utilizan los protocolos HTTP, HTTPS (HTTP seguro), SSL (TCP seguro) y TCP.

Puede realizar el balanceo de carga para los siguientes puertos TCP:

• [EC2-VPC] 1-65535
• [EC2-Classic] 25, 80, 443, 465, 587, 1024-65535

Sí. Cada balanceador de carga clásico tiene un nombre DNS IPv4, IPv6 y de doble pila (tanto IPv4 como IPv6) asociado. IPv6 no es soportado en VPC. Puede usar el Application Load Balancer para lograr compatibilidad con IPv6 en VPC.

Sí.

Si utiliza Amazon Virtual Private Cloud, puede configurar los grupos de seguridad para el entorno frontend del equilibrador de carga clásico.

Sí, puede correlacionar el puerto 80 HTTP y el puerto 443 HTTPS con un balanceador de carga clásico individual.

El balanceador de carga clásico no limita el número de conexiones que puede intentar establecer con las instancias de Amazon EC2 de carga balanceada. Este probable que este número varíe con el número de solicitudes HTTP, HTTPS o SSL simultáneas o el número de conexiones TCP simultáneas que recibe el balanceador de carga clásico.

Puede equilibrar cargas de instancias de Amazon EC2 lanzadas con una AMI pagada de AWS Marketplace. Sin embargo, el equilibrador de carga clásico no admite las instancias implementadas con una AMI pagada del sitio de Amazon DevPay.

Sí. Consulte la página web de Elastic Load Balancing.

Sí. Para recibir un historial de todas las llamadas a la API del balanceador de carga clásico realizadas en su cuenta, solo tiene que activar CloudTrail en la consola de administración de AWS.

Sí, puede terminar SSL en el equilibrador de carga clásico. Debe instalar un certificado SSL en cada balanceador de carga. Los balanceadores de carga utilizan este certificado para terminar la conexión y luego descifra las solicitudes de los clientes antes de enviarlas a las instancias de back-end.

Puede utilizar AWS Certificate Manager para aprovisionar un certificado SSL/TLS, o bien obtenerlo de otras fuentes creando una solicitud de certificado, obteniendo la firma de una entidad certificadora y luego cargando el certificado mediante el servicio AWS Identity and Access Management (IAM).

El balanceador de carga clásico ya se integra con AWS Certificate Management (ACM). Gracias a esta integración es muy sencillo vincular un certificado a cada balanceador de carga, por lo que todo el proceso de descarga SSL resulta muy fácil. Normalmente, la compra, carga y renovación de certificados SSL/TLS es un proceso manual y complejo que requiere bastante tiempo. Gracias a la integración de ACM con los balanceadores de carga clásicos, el proceso se reduce a solicitar un certificado SSL/TLS de confianza y a seleccionar el certificado ACM para aprovisionarlo con cada balanceador de carga.

Puede activar el equilibrio de cargas entre zonas con la consola, la CLI de AWS o un SDK de AWS. Consulte la documentación sobre equilibrio de cargas entre zonas para obtener más detalles.

No, no se cobra la transferencia de datos regional entre zonas de disponibilidad cuando activa el equilibrio de cargas entre zonas para su equilibrador de carga clásico.