Balanceador HTTPS con certificado en Google Cloud

Configurar un balanceador de carga en Google Cloud es la forma recomendada para exponer tráfico hacia Internet siguiendo buenas prácticas. Aquí descubrirás qué tipos existen, qué componentes necesitas y cómo desplegar uno HTTPS funcional con certificado gestionado por Google, ideal si te preparas para la certificación Google Cloud Associate Engineer.

Qué tipos de balanceadores de carga existen en Google Cloud

Google Cloud divide sus balanceadores en dos grandes grupos según el alcance del tráfico que manejan.

En el grupo de balanceo global encontrarás el más utilizado de todos: el HTTPS, donde puedes configurar certificados SSL. También están el proxy SSL y el proxy TCP, pensados para escenarios específicos de tráfico cifrado o de capa de transporte.

En el grupo de balanceadores regionales el tráfico solo se distribuye dentro de una misma región. Aquí entran los balanceadores TCP y UDP, que suelen usarse cuando el tráfico va por puertos distintos a 443 o 8080.

¿Cuándo uso un balanceador regional en lugar de uno global? Cuando tu tráfico se dirige a puertos específicos no estándar (distintos de 443 u 8080) y no necesitas distribuir carga entre regiones, como ocurre con servicios TCP o UDP.

Qué componentes debes configurar al crear un balanceador

Antes de armar el balanceador conviene tener claros sus cuatro pilares, porque cada uno cumple un rol distinto en el flujo del tráfico.

• IP frontal: la IP pública (o privada) por la que responde el balanceador.
• Reglas de reenvío: configuraciones para que un dominio o path vaya a un backend específico.
• Servicios de backend: destinos como máquinas virtuales, clústeres de Kubernetes o servicios serverless tipo Cloud Run, App Engine o Cloud Run Functions.
• Health checks: verificaciones periódicas de que el backend responde correctamente.

Además de balancear, estos servicios centralizan configuraciones clave como el WAF Cloud Armor, la generación automática de certificados y la redirección de dominios sin tocar el ingress de Kubernetes [01:50].

Cómo preparar el backend con Nginx y un instance group

El camino más sencillo para probar un balanceador es desplegar un servidor Nginx sobre una máquina virtual existente.

Desde Compute Engine entras a tu máquina por SSH e instalas el servidor con sudo apt install nginx. Una vez verificado que responde, necesitas agruparla, porque un balanceador HTTPS no acepta máquinas virtuales sueltas: deben pertenecer a un instance group [03:30].

Por qué elegir un Unmanaged Instance Group

Los grupos administrados crean y eliminan máquinas a partir de una imagen, comportamiento que aquí no necesitas. Selecciona New Unmanaged Instance Group, define la zona donde vive tu VM, escoge la red Platzi VPC, su subred y agrega la instancia Platzi.

Cómo abrir el firewall para los health checks

Los balanceadores de Google usan rangos de IP públicos específicos para validar la salud del backend. Sin esa regla, tu health check fallará aunque Nginx esté funcionando.

Crea una regla de firewall llamada Allow Google Health Check, dirección de entrada, tráfico permitido a todas las instancias de la red, y agrega los dos rangos de IP de origen que Google publica en su documentación. Define el puerto 80, que es por donde responde Nginx.

Cómo configurar un balanceador HTTPS con certificado gestionado

En la barra de búsqueda escribe load balancer y elige Crear balanceador de cargas de tipo HTTP/HTTPS, público, global y de aplicaciones. Llámalo Platzi Load Balancer.

Cómo configurar el frontend con HTTPS y certificado de Google

Nombra el frontend como Platzi-frontend y selecciona protocolo HTTPS con dirección IP efímera y puerto 443. Al crear un nuevo certificado llamado Platzi Cert, Google te ofrece su propia entidad certificadora de forma gratuita, similar a Let's Encrypt pero gestionada por Google [06:50].

Define el dominio, por ejemplo web.platzi-training.com. El certificado validará automáticamente contra la IP que el balanceador genere, así que ese registro DNS deberá apuntar correctamente para que la emisión funcione.

Cómo enlazar el backend y la verificación de estado

Crea un servicio de backend llamado simplemente Backend sobre un grupo de instancias con protocolo HTTP en el puerto 80. Cloud CDN puede quedar deshabilitado por ahora.

Agrega una verificación de estado healthcheck-tcp-80, que enviará solicitudes periódicas para confirmar que Nginx responde. Si el nombre de la política de seguridad da error, recórtalo: tiene un límite de longitud.

¿Para qué sirve un health check en un balanceador? Comprueba periódicamente que cada backend responde correctamente, retirando del balanceo cualquier instancia que falle hasta que vuelva a estar saludable.

Cómo apuntar tu dominio y validar el certificado

Una vez creado el balanceador, copia la IP pública que se generó y crea un registro tipo A en tu proveedor DNS, por ejemplo GoDaddy, con el subdominio Web apuntando a esa IP.

El certificado aparecerá en estado Aprovisionando mientras Google verifica que el dominio resuelve a la IP del balanceador. El proceso puede tardar hasta 24 horas, aunque el promedio ronda los 15 minutos [10:30]. Cuando pase a estado activo, abre el dominio por HTTPS y verás Nginx respondiendo con tráfico cifrado.

¿Por qué tarda tanto en activarse el certificado de Google? Porque la entidad certificadora valida que tu dominio realmente apunte a la IP del balanceador, y la propagación DNS más la verificación pueden demorar entre 15 minutos y 24 horas.

Si ves errores al inicio, ten paciencia: la replicación del DNS y la emisión del certificado no son inmediatas. ¿Ya configuraste tu primer balanceador HTTPS? Cuéntame en los comentarios qué backend conectaste.