Distribuir el tráfico de manera inteligente entre regiones es fundamental para ofrecer una experiencia rápida y confiable a los usuarios. En esta práctica se integra un balanceador de carga HTTP(S) en Google Cloud que conecta instance groups ubicados en Europa y Norteamérica, se valida su funcionamiento con tráfico simulado y se añade una capa de seguridad con Cloud Armor para bloquear solicitudes no deseadas.
¿Cómo se crea un load balancer HTTP(S) en Google Cloud?
Desde la consola de Google Cloud, el punto de partida es el menú Network Services y luego la opción Load Balancing [01:06]. Al crear un nuevo balanceador se eligen distintos tipos: TCP, UDP o HTTPS. Para aplicaciones web que operan en capa siete del modelo OSI, se selecciona el balanceador HTTPS.
El asistente pregunta si el tráfico será interno o externo. Interno significa comunicación entre máquinas dentro de la misma red; externo se refiere a tráfico proveniente de Internet hacia la infraestructura. En un escenario orientado a usuarios finales se elige externo [01:28].
¿Qué es un backend y cómo se configura?
El backend es el destino real al que el balanceador dirige las peticiones. En este caso se asocian dos instance groups: uno en Europa y otro en Norteamérica [01:52]. Cada backend se configura con:
- Puerto 8080, que es donde la aplicación escucha.
- Modo de balanceo por rate, es decir, la tasa de solicitudes por segundo.
- Umbral de escalado: treinta solicitudes por segundo con una capacidad del 75 % para Europa y 70 % para Norteamérica.
Estos valores determinan cuándo el autoscaler debe crear nuevas instancias.
¿Por qué es importante el health check?
El health check verifica periódicamente que cada máquina virtual responde correctamente [02:48]. Se configura con solicitudes TCP al puerto 8080, intervalos de diez segundos y un timeout de cinco segundos. Si una instancia responde en dos intentos consecutivos, se marca como saludable. Si falla en tres intentos consecutivos, se marca como no saludable y se destruye automáticamente.
Este mecanismo implica que los instance groups deben usarse con aplicaciones sin estado (stateless): no deben almacenar datos persistentes como bases de datos, ya que las instancias pueden destruirse y recrearse en cualquier momento [03:18].
¿Cómo se define el frontend y las reglas de firewall necesarias?
El frontend determina cómo llegan las peticiones al balanceador. Se elige protocolo HTTP, dirección IPv4 y puerto 80 [03:56]. La IP puede ser efímera para ambientes de desarrollo o reservada para producción.
Una vez creado el balanceador, no responde de inmediato: necesita entre cinco y diez minutos para configurar las rutas globales [04:48]. Pero incluso después de ese tiempo, puede seguir fallando si falta una regla de firewall.
Para la red VPC personalizada se crea una regla que permite tráfico hacia el puerto 8080 desde los rangos de IP del balanceador [05:20]. Sin esta regla, las máquinas rechazan las solicitudes que el load balancer les reenvía. Una vez aplicada, la IP del balanceador responde correctamente y dirige el tráfico al grupo de instancias más cercano y disponible según la ubicación del usuario.
¿Cómo validar el autoescalado y proteger la infraestructura con Cloud Armor?
Para comprobar que el autoescalado funciona, se crea una máquina virtual auxiliar y se instala una herramienta de prueba de carga (siege) que simula doscientos usuarios concurrentes haciendo peticiones a la IP del balanceador [06:38]. En la sección de Monitoring del balanceador se visualiza en tiempo real el incremento de solicitudes, y en los instance groups se observa cómo se crean nuevas máquinas automáticamente sin intervención manual [08:06].
¿Cómo bloquear tráfico malicioso con Cloud Armor?
El crecimiento automático por tráfico no genuino representa un riesgo de costos y disponibilidad. Cloud Armor permite crear políticas de seguridad desde Network Security [08:38].
- Se define una política con acción predeterminada de rechazar todas las solicitudes, respondiendo con un código 404.
- Se añaden reglas específicas por dirección IP con prioridad cero (la más alta) para bloquear fuentes identificadas como maliciosas.
De esta forma, cualquier solicitud proveniente de una IP bloqueada recibe un 404, generando la impresión de que el recurso no existe. Esta combinación de balanceo global, autoescalado y políticas de seguridad ofrece una solución robusta para aplicaciones distribuidas.
¿Ya has probado Cloud Armor en tus proyectos? Comparte tu experiencia o dudas sobre la configuración de balanceadores en los comentarios.
