Cómo crear un ALB paso a paso para redes y balanceadores privados

Introducción

En el ámbito de las infraestructuras en la nube y los centros de datos virtuales, los balanceadores de carga son elementos críticos para garantizar alta disponibilidad, escalabilidad y la distribución eficiente del tráfico. Entre las diversas opciones, el Application Load Balancer (ALB) se destaca por operar en la capa 7 del modelo OSI, lo que ofrece un control granular sobre el enrutamiento basado en la lógica de HTTP/HTTPS.

Este artículo técnico desarrolla un enfoque detallado y paso a paso para diseñar y configurar un Application Load Balancer con configuraciones avanzadas orientadas a redes privadas y balanceadores internos. Partiremos desde conceptos básicos hasta escenarios complejos que incluyen discriminación por rutas, reglas HTTP personalizadas y respuestas estáticas. El objetivo es brindar al lector un recurso completo, que además de explicar cómo hacerlo, permita entender las mejores prácticas y resolver dudas comunes sobre ALBs.

¿Qué es un Application Load Balancer (ALB)?

El ALB es un balanceador de carga que trabaja en la capa de aplicación (capa 7), lo que le permite analizar la información contenida en las solicitudes HTTP o HTTPS para tomar decisiones inteligentes sobre el enrutamiento del tráfico. Esta capacidad avanzada supera a balanceadores de capa 4 (como los Network Load Balancer), que solo consideran IP y puerto.

Gracias a sus funcionalidades, el ALB puede dirigir solicitudes específicas hacia diferentes conjuntos de servidores (target groups) dependiendo de la ruta, cabezales HTTP, método de petición o incluso cookies, permitiendo un enrutamiento más flexible y adaptado a arquitecturas complejas.

Componentes clave del ALB

• Forwarding Rules (Reglas de reenvío): Determinan el punto de entrada al ALB, especificando una combinación única de IP y puerto donde escucha el tráfico.
• HTTP Rules (Reglas HTTP): Se refieren al conjunto de condiciones que analizan la petición y deciden qué target group atiende cada solicitud.
• Target Groups: Conjuntos de servidores o recursos que reciben las solicitudes según las reglas.

Arquitectura y Conceptos Fundamentales

Las Forwarding Rules: definiciones y limitaciones

Las forwarding rules establecen el punto de acceso al ALB y están formadas por la combinación IP + Puerto. Es importante tener en cuenta que por cada IP y puerto solo puede existir una única forwarding rule, impidiendo la duplicación en un mismo endpoint.

Esta regla es esencial para mantener orden en el balanceador y para permitir que desde un único endpoint (por ejemplo, una IP pública y puerto 80), se puedan manejar múltiples comportamientos mediante las reglas HTTP asociadas.

HTTP Rules: el poder del enrutamiento a nivel de aplicación

Las HTTP rules se configuran dentro de cada forwarding rule y determinan cómo se enruta el tráfico basado en las características de la petición. Estas condiciones pueden inspeccionar:

• La ruta o URI de la petición.
• Headers HTTP.
• Métodos HTTP (GET, POST, etc.).
• Cookies específicas.
• Query strings.
• IP de origen.

Cada regla HTTP puede ejecutar acciones de tipo Forward (redirigir a un target group), Redirect (redirigir a una URL externa con código HTTP 3xx), o devolver Static Response (una respuesta predefinida estática).

Target Groups: definición y gestión

Los target groups son colecciones de instancias o servicios que se encargan de procesar las solicitudes que reciben tras ser enrutadas por el ALB. Pueden estar formados por:

• Direcciones IP estáticas.
• Instancias virtuales o físicas.
• Contenedores o servicios backend.

La gestión centralizada de target groups permite crear arquitecturas escalables y flexibles, facilitando el mantenimiento y la evolución del sistema bajo demanda.

Escenario 1: Balanceo Básico entre Dos Servidores

Objetivo

Configurar un ALB que distribuya tráfico HTTP entrante (puerto 80) entre dos servidores web (Web Server 1 y Web Server 2), replicando la funcionalidad básica de un network load balancer pero con las capacidades avanzadas de un ALB.

Paso 1: Crear el Target Group con ambos servidores

1. Identificar las IPs de los servidores (por ejemplo, 107.230.11.X y 107.230.11.Y).
2. Desde la gestión de recursos, crear un Target Group llamado web1.
3. Agregar cada servidor al Target Group, asignándole puerto 80 y pesos (por ejemplo, peso 1 para cada uno para balanceo equitativo).

Paso 2: Configurar la Forwarding Rule del ALB

1. Asignar una IP pública al ALB, que podrá ser una IP reservada previamente.
2. Crear una forwarding rule que escuche en esa IP y puerto 80.
3. Asegurarse que esta es la única forwarding rule para esa combinación IP/puerto.

Paso 3: Vincular la regla HTTP de tipo Forward

1. Crear una regla HTTP (http rule) llamada web1, de tipo Forward.
2. Asignar como target group el web1 creado.
3. Dejar las condiciones de la regla HTTP vacías para que actúe sobre todas las peticiones.

Paso 4: Validación

Realizar peticiones HTTP repetidas a la IP pública del ALB y verificar que las respuestas alternan entre web server 1 y web server 2, demostrando el balanceo de carga efectivo.

Escenario 2: Balanceo Diferenciado por Rutas (Webs Distintas)

Desafío

Utilizar la misma IP pública y puerto del ALB para dirigir tráfico a diferentes servidores dependiendo de la ruta solicitada. Por ejemplo:

SSL Offloading qué es y cómo funciona en redes privadas y balanceo

• / → Servidor Web 1
• /new → Servidor Web 2

Paso 1: Crear dos Target Groups separados

• webalt: contiene servidor web 1.
• webnew: contiene servidor web 2.

Paso 2: Mantener forwarding rule única

Como el ALB no permite duplicar forwarding rules en la misma IP y puerto, se mantiene la forwarding rule existente para la IP y puerto 80.

Paso 3: Crear dos HTTP rules con condiciones específicas

• HTTP rule “webalt”: condición para rutas que no comienzan con /new (p.ej., path no empieza con /new).
• HTTP rule “webnew”: condición para rutas que empiezan con /new.

Paso 4: Asociación y orden de reglas

Ambas reglas se asocian a la misma forwarding rule. El ALB evalúa las reglas en orden y ejecuta la primera que coincide, enviando la petición al target group indicado.

Validación

Realizar pruebas con peticiones a:

• http://[IP_ALB]/ debe responder el servidor web 1.
• http://[IP_ALB]/new debe responder el servidor web 2.

Profundizando en las HTTP Rules: Condiciones y Acciones

Las HTTP rules pueden realizar varias acciones con base en las condiciones que se evalúan en la petición HTTP.

Condiciones comunes en HTTP Rules

• Path o URI: prefijo, sufijo, coincidencia exacta, regex.
• Headers HTTP: existencia o valor específico.
• Método HTTP: GET, POST, PUT, DELETE, etc.
• Cookies: presencia o valor.
• IP origen: filtrar o permitir ciertos rangos.
• Query strings específicos.

Acciones principales en HTTP Rules

Escenario 3: Redirección HTTP con el ALB

Introducción

Más allá del reenvío de tráfico, el ALB puede configurarse para redirigir ciertas peticiones a URLs externas o internas, usando códigos HTTP estándar como 301 o 302. Esto es especialmente útil para migrar rutas, campañas especiales o fortalecer la seguridad HTTPS.

Implementación

1. Crear una HTTP rule de tipo Redirect con un nombre identificativo (por ejemplo, “arsis”).
2. Establecer la URL de destino (p.ej., https://arsis.punes/).
3. Configurar la condición que dispare la redirección, por ejemplo, que la ruta comience con /arsis.
4. Definir el código HTTP a devolver (por defecto 301 para redireccionamiento permanente).
5. Decidir si mantener o no la query string original en la redirección.

Validación

Desde un terminal o navegador, solicitar la ruta que activa la redirección y verificar que el ALB responde con el código 301 y la URL de destino. En navegadores, esta redirección es procesada automáticamente.

Escenario 4: Respuestas Estáticas desde el ALB

Situación de uso

En ciertos casos es necesario responder al cliente con contenido estático directamente desde el ALB sin enviar la petición a un backend, como mensajes de error personalizados o páginas de mantenimiento.

Configuración

1. Crear una HTTP rule con acción Static Response.
2. Definir el código HTTP a devolver (por ejemplo, 200 o 500).
3. Elegir el Content-Type (application/json, text/html, etc.).
4. Escribir el contenido estático a devolver (por ejemplo, un mensaje JSON).
5. Configurar una condición (por ejemplo, ruta que empiece con /static).

Validación

Al hacer peticiones a la ruta definida, el ALB devolverá el contenido estático configurado, confirmado con herramientas como curl mostrando código HTTP, tipo de contenido y cuerpo de respuesta.

Para complementar esta guía con un recurso visual que explica paso a paso la configuración y casos prácticos del Application Load Balancer, te invitamos a ver este video tutorial.

Buenas Prácticas y Consejos para la Configuración de un ALB

• Reserva tus direcciones IP antes de asignarlas a forwarding rules para evitar conflictos y garantizar disponibilidad.
• Planifica tus target groups considerando escalabilidad y mantenimiento, separando servicios lógicamente.
• Utiliza condiciones claras en HTTP rules para evitar solapamientos que puedan causar errores inesperados.
• Monitoriza el comportamiento del balanceador y las respuestas para garantizar el correcto funcionamiento y detectar cuellos de botella.
• Documenta la configuración para facilitar futuras actualizaciones o traspasos de conocimiento en equipo.
• Evalúa la seguridad restringiendo accesos IP, usando HTTPS y revisando headers.

Comparativa: ALB vs Network Load Balancer (NLB)

Palabras Clave Relevantes y su Importancia

Balanceador

Elemento encargado de distribuir el tráfico de red o solicitudes entre distintos servidores o servicios backend. Es esencial para lograr escalabilidad, disponibilidad y tolerancia a fallos.

Forwarding Rule

Regla que define un punto de entrada para el ALB, especificando la IP y puerto donde el balanceador espera conexiones. Es la base sobre la cual se aplican reglas HTTP.

HTTP Rule

Condiciones y acciones aplicadas a peticiones HTTP que definen hacia dónde se enruta o cómo se trata cada solicitud, permitiendo configuraciones específicas basadas en ruta, headers, etc.

Target Group

Conjunto lógico de servidores o recursos que atienden las solicitudes derivadas por el ALB según las reglas definidas.

Cómo configurar SSL Offloading en redes privadas y balanceadores

Redirección (Redirect)

Acción que consiste en reenviar automáticamente a los clientes a otra URL o recurso, fundamental para reorganización de sitios o temas de SEO.

Respuesta Estática (Static Response)

Mecanismo que devuelve una respuesta fija directamente desde el ALB sin necesidad de pasar por backend, útil para control de errores o mensajes informativos.

Balanceo de carga

Técnica para distribuir equitativamente el tráfico o carga de trabajo entre múltiples recursos para evitar sobrecargas y mejorar la experiencia de usuario.

High Availability (Alta Disponibilidad)

Diseño y configuración orientados a que un sistema permanezca accesible y operativo incluso ante fallos parciales, utilizando componentes redundantes y balanceo de carga.

Preguntas Frecuentes (FAQ)

¿Puedo crear mi propio balanceador de carga?

Para crear un balanceador de carga de aplicaciones, debe proporcionar información básica como el nombre, esquema y tipo de dirección IP. Luego, se configuran detalles de red y uno o más agentes de escucha, los cuales supervisan solicitudes de conexión para tomar decisiones respecto al enrutamiento.

¿Cuál es la diferencia entre ELB y ALB?

ELB (Elastic Load Balancer) es un término genérico que puede referirse a diversos tipos de balanceadores dentro de AWS, incluyendo Classic Load Balancer. El ALB (Application Load Balancer) funciona específicamente en capa 7 y permite enrutamiento basado en contenido (rutas, headers, cookies), mientras que ELB clásico solo enruta basándose en IP y puerto.

¿Cómo encontrar la URL del balanceador de carga de AWS?

El ALB tiene asociado un DNS público o privado que se puede obtener desde la consola de AWS en la sección del balanceador. Esta URL dinámica es el punto de entrada para el tráfico, y las rutas se enrutan internamente según las HTTP rules definidas.

¿Se puede usar un ALB en una red privada sin acceso a Internet?

Sí, un ALB puede configurarse con IPs privadas dentro de una red virtual privada (VPC), funcionando como balanceador interno para distribuir tráfico entre recursos internos sin exponerlos a la Internet pública.

¿Puedo tener múltiples forwarding rules con la misma IP?

No, cada combinación única de IP y puerto solo puede tener una forwarding rule. Para usar múltiples reglas, debe usar diferentes IPs o puertos.

¿Qué pasa si dos reglas HTTP tienen condiciones que se solapan?

El ALB evalúa las HTTP rules en orden, y ejecuta la primera que coincide. Por lo tanto, es importante diseñar las reglas para que no existan solapamientos o se definan prioridades adecuadas para evitar comportamientos impredecibles.

¿Cómo se manejan las peticiones que no coinciden con ninguna regla HTTP?

Si una petición no cumple con ninguna condición de las reglas HTTP definidas, el ALB utiliza una regla por defecto, que usualmente puede ser una regla genérica con Forward a un target group o devolver un error 404.

¿Se pueden implementar certificados SSL en el ALB?

Sí, el ALB soporta terminación SSL/TLS exclusivamente, permitiendo manejar la seguridad HTTPS en la capa del balanceador antes de pasar el tráfico a los servidores backend.

Conclusión

El Application Load Balancer es una herramienta poderosa y flexible para diseñar arquitecturas de red eficientes, que requieren un control detallado del tráfico HTTP a nivel de aplicación. Desde balanceo básico entre servidores hasta enrutamientos complejos por rutas o condiciones específicas, el ALB facilita la alta disponibilidad y escalabilidad en todo tipo de infraestructuras cloud y centros de datos virtuales.

Cómo configurar las reglas del NLB para redes privadas y balanceadores

Si buscás implementar este tipo de soluciones en tu empresa, en Código6 podemos ayudarte. Somos especialistas en automatización, inteligencia artificial y transformación digital. Contactanos para comenzar tu proyecto hoy.