Configurar un balanceador de carga de aplicaciones en AWS es una de las habilidades más prácticas para garantizar que tu aplicación sea altamente disponible. A lo largo de este laboratorio se recorre cada paso dentro de la consola de Amazon, desde la creación del balanceador hasta la verificación de salud de los servidores, pasando por detalles como security groups, listeners y target groups que marcan la diferencia entre una arquitectura funcional y una que falla en producción.
¿Cómo se crea un Application Load Balancer en la consola de AWS?
El proceso comienza en la consola de EC2, donde en el menú lateral izquierdo se encuentra la sección load balancing [0:08]. Al dar clic en load balancers, AWS presenta tres opciones: Application Load Balancer, Network Load Balancer y Gateway Load Balancer. Para una aplicación web que recibe tráfico HTTP, la elección correcta es el Application Load Balancer (ALB) [1:08].
Al crear el balanceador se deben definir varios parámetros esenciales:
- Nombre del balanceador: un identificador claro como "Mi primer ALB".
- Esquema: internet facing, porque recibe tráfico del exterior, a diferencia de los balanceadores internos que tienen casos de uso más específicos [1:30].
- Tipo de dirección IP: IPv4, que corresponde a las direcciones IP convencionales utilizadas en el laboratorio [1:52].
¿En qué subredes debe ubicarse el balanceador?
En la sección de network mapping se selecciona la VPC previamente creada y las zonas de disponibilidad [2:05]. La pregunta clave es: ¿subred pública o privada? El balanceador vive en la subred pública porque necesita recibir tráfico desde internet. Se selecciona la pública uno en la zona A y la pública dos en la zona B [2:40]. Esto permite que el ALB distribuya tráfico hacia los servidores que residen en las subredes privadas correspondientes de cada zona.
¿Por qué es necesario un security group exclusivo para el ALB?
Como buena práctica, se crea un security group dedicado para el balanceador [3:08]. Este grupo de seguridad habilita tráfico HTTP (puerto 80) desde cualquier origen (anywhere), ya que el ALB es el punto de entrada público. Sin esta regla, el balanceador no podría recibir peticiones de los usuarios.
¿Qué son el listener y el target group en un balanceador?
El listener define por dónde "escucha" el balanceador [3:50]. Sin un certificado de seguridad configurado, el ALB escucha por HTTP en el puerto 80. Este listener necesita saber hacia dónde enviar el tráfico, lo cual se resuelve con el target group.
El target group es el grupo de destinos donde el balanceador envía las peticiones. En este caso, los destinos son instancias EC2 [4:18]. Al crear el target group se configura:
- Tipo de destino: instancias (también se puede balancear entre IPs, funciones Lambda u otros ALBs).
- Protocolo y puerto: HTTP, puerto 80.
- VPC: la misma del laboratorio.
Dentro del target group se registran las instancias específicas, el server A y el server B, como destinos que recibirán tráfico [7:02].
¿Cómo funciona el health check del balanceador de carga?
El health check es el mecanismo mediante el cual el balanceador verifica si cada servidor está saludable antes de enviarle tráfico [4:55]. El ALB consulta una ruta del servidor (por defecto la raíz /) usando el protocolo HTTP.
Los parámetros más relevantes del health check son:
- Healthy threshold: número consecutivo de respuestas positivas necesarias para declarar un servidor saludable. Con valor dos, el ALB pregunta dos veces y si ambas respuestas son positivas, envía tráfico [5:25].
- Unhealthy threshold: número de respuestas fallidas para marcarlo como no saludable.
- Timeout: tiempo máximo de espera por respuesta; si no responde en ese lapso, deja de enviar tráfico [5:55].
- Interval: tiempo entre cada verificación de salud.
- Código de éxito: un HTTP 200 confirma que el servidor está operando correctamente [6:40].
Un detalle crucial que suele pasarse por alto: el security group de los servidores privados debe permitir tráfico HTTP desde el security group del ALB [8:18]. Sin esta regla, el balanceador no puede completar el health check y los servidores aparecen como no saludables.
¿Cómo se verifica que el balanceo de carga funciona correctamente?
Una vez que el balanceador alcanza el estado active, se copia el DNS que AWS asigna automáticamente y se pega en el navegador [9:48]. Al refrescar la página repetidamente, el tráfico alterna entre el server A y el server B, confirmando que el balanceo está funcionando.
Para simular una falla, se detiene una de las instancias desde la consola de EC2 [10:22]. El ALB detecta mediante sus health checks que ese servidor dejó de responder y deja de enviarle tráfico automáticamente, redirigiendo todas las peticiones al servidor que permanece saludable [10:55]. Este comportamiento demuestra la alta disponibilidad: aunque un servidor caiga, la aplicación sigue respondiendo sin intervención manual.
Este laboratorio integra conceptos fundamentales como redes, zonas de disponibilidad, grupos de seguridad y balanceo de carga para construir una arquitectura resiliente en AWS. Si quieres evitar cobros inesperados, no olvides eliminar todos los recursos una vez que termines de practicar.
