Cerramos el módulo 2 con un diagnóstico incómodo: todo lo que AlpinaShop ha construido está expuesto. La VM alpinashop-web-1 tiene el puerto 80 abierto a internet y el 22 accesible desde cualquier dirección, la instancia alpinashop-pedidos es alcanzable por IP pública, el Service de GKE publicó una IP sin HTTPS y no existe ninguna frontera entre lo que debe ser público y lo que jamás debería serlo. Esta lección construye esa frontera.

La red es la capa sobre la que se apoya todo lo demás. Antes de poner un balanceador, un CDN o un WAF hay que decidir dónde vive cada máquina, qué rangos de direcciones usa, quién puede hablar con quién y por dónde sale el tráfico a internet. En Google Cloud esa decisión se materializa en una VPC (Virtual Private Cloud): una red privada definida por software, aislada del resto de clientes, dentro de la cual conviven tus instancias, tus clústeres, tus bases de datos y tus balanceadores.

La red VPC de Google Cloud tiene una propiedad que sorprende a quien viene de AWS o de un centro de datos tradicional: es global. Una única red puede abarcar todas las regiones del planeta, y dos máquinas en Bélgica y en Tokio dentro de la misma VPC se hablan por IP privada sin túneles ni pasarelas. Las subredes, en cambio, son regionales. Entender esa asimetría es el 80 % de entender la red de Google.

En esta lección diseñarás e implementarás la red alpinashop-vpc con sus subredes, planificarás el direccionamiento sin solapes, escribirás el conjunto real de reglas de firewall de AlpinaShop, darás salida a internet a máquinas sin IP pública con Cloud NAT, alcanzarás las APIs de Google sin pasar por internet con Private Google Access y conectarás por fin alpinashop-pedidos por IP privada.

Aviso. Esta lección tiene implicaciones de seguridad directas. El diseño que se propone es razonable para una pyme como AlpinaShop, pero cualquier arquitectura de red que vaya a producción debe revisarla un profesional de seguridad, y si tratas datos personales o medios de pago, también un responsable de cumplimiento normativo.

1. Qué es una VPC y en qué se diferencia de una red tradicional
2. Red por defecto, modo automático y modo personalizado
3. Planificación del direccionamiento: CIDR sin solapes
4. Creación de alpinashop-vpc y sus subredes
5. Rangos secundarios para GKE
6. Direcciones IP internas y externas, efímeras y estáticas
7. Reglas de firewall VPC: el modelo completo
8. El conjunto real de reglas de AlpinaShop
9. Rutas y la puerta de enlace por defecto
10. Cloud NAT: salida a internet sin IP pública
11. Private Google Access: llegar a las APIs sin salir a internet
12. Acceso privado a servicios: Cloud SQL por IP privada
13. VPC Flow Logs: diagnóstico y auditoría
14. Qué queda fuera de esta lección

En un centro de datos clásico, la red es física: switches, VLAN, cableado, rangos que alguien apuntó en una hoja de cálculo hace ocho años. En Google Cloud, la red es una abstracción de software montada sobre la red global de Google. Las diferencias prácticas son estas:

Tres consecuencias que conviene grabar desde el principio:

• La red es un recurso global del proyecto. No pertenece a una región. Cuando creas alpinashop-vpc en alpinashop-prod, existe en todas partes.
• Las subredes son regionales, no zonales. Una subred en europe-west1 cubre europe-west1-b, -c y -d. Una VM en cualquiera de esas zonas puede tomar una IP de esa subred. Esto es lo que permite que el MIG regional alpinashop-web-mig reparta instancias entre tres zonas usando una sola subred.
• El firewall no está "en un sitio". No hay un cortafuegos perimetral por el que pase el tráfico: cada regla se aplica en el hipervisor, en la propia interfaz de red de cada VM. Por eso el tráfico entre dos VM de la misma subred también está sujeto a reglas, y por eso no puedes "saltarte" el firewall poniendo las máquinas juntas.

Cuando creaste el proyecto alpinashop-prod, Google creó automáticamente una red llamada default. Es cómoda para probar y mala idea para producción. Veamos por qué.

Existen dos modos de red:

La red default es de modo automático y además trae reglas de firewall preconfiguradas que abren el puerto 22 (SSH) y el 3389 (RDP) a todo internet. Eso es exactamente el problema que AlpinaShop arrastra desde el módulo 2.

Toda organización seria usa modo personalizado por tres motivos:

1. Control del direccionamiento. Si mañana AlpinaShop conecta su oficina por VPN (tema de 07-03), los rangos no pueden chocar. Con modo automático, Google decide por ti en todas las regiones presentes y futuras.
2. Superficie de ataque mínima. No hay subredes en regiones que no usas ni reglas permisivas que alguien olvidó revisar.
3. Reproducibilidad. La red se describe en código (Terraform, en 06-07) y se recrea idéntica en alpinashop-dev.

La primera tarea real, entonces, es crear una red personalizada y dejar de usar default:

Más adelante, cuando todo esté migrado, la red default se elimina. No se elimina el primer día: hay recursos vivos dentro. El orden correcto es crear la red nueva → mover cargas → borrar la vieja.

Antes de escribir un solo comando, se planifica en papel. Un plan de direccionamiento malo se paga durante años, porque el rango primario de una subred se puede ampliar, pero no reducir ni mover, y porque dos redes con rangos solapados no se pueden conectar nunca.

Recordatorio mínimo de CIDR:

Google reserva cuatro direcciones en cada subred: la de red, la puerta de enlace (siempre la segunda, x.x.x.1), y dos reservadas para uso futuro (las dos últimas). Por eso un /24 da 252 IP utilizables, no 254.

El plan de AlpinaShop reserva el bloque privado 10.10.0.0/16 para producción y deja espacio deliberado entre subredes:

Reglas de oro al planificar:

• Nunca uses 10.0.0.0/24 ni 192.168.1.0/24. Son los rangos que usa medio mundo, incluida la red doméstica de tus compañeros; el día que haya VPN, chocarán.
• Deja huecos. Es más fácil pedir perdón que reorganizar direcciones.
• Documenta el plan y versiónalo. El documento de direccionamiento vive en el repositorio, no en la memoria de Marta.
• Los rangos de pods de Kubernetes son grandes. Un /16 para pods no es exagerado: GKE reserva un bloque por nodo.

Con el plan cerrado, la implementación son tres órdenes:

Dos parámetros merecen explicación:

• --subnet-mode=custom: no crea ninguna subred automáticamente. Es lo que queremos.
• --bgp-routing-mode=global: cuando en el futuro haya un Cloud Router (VPN o Interconnect, tema de 07-03), las rutas aprendidas se propagarán a todas las regiones, no solo a la del router. Es el valor correcto para una red que puede crecer; cambiarlo después obliga a reconfigurar el router.

Qué hace cada opción, en detalle:

• --range: el rango primario. Es el que se reparte entre las interfaces de las VM.
• --enable-private-ip-google-access: permite que una VM sin IP pública llegue a las APIs de Google (Cloud Storage, BigQuery, Secret Manager…). Lo desarrollamos en el apartado 11. Actívalo siempre; no tiene coste ni contraindicación.
• --enable-flow-logs y sus parámetros: activa el registro de flujos. --logging-flow-sampling=0.5 muestrea la mitad de los flujos, lo que reduce el coste de logs a la mitad manteniendo utilidad de diagnóstico. Lo vemos en el apartado 13.

Comprobación:

Verás que gatewayAddress es 10.10.0.1: la puerta de enlace siempre es la segunda dirección del rango, y no es una máquina que puedas tocar, sino una función distribuida de la red.

El clúster alpinashop-cluster que creamos en 02-05 necesita direcciones para pods y para services, y esas direcciones no salen del rango primario de la subred, sino de rangos secundarios (lo que Google llama alias IP ranges). Este es el modelo de red nativo de VPC de GKE, y es el que se usa siempre en Autopilot.

Por qué rangos tan grandes:

La consecuencia de mayor calado: con red nativa de VPC, un pod tiene una IP real de la VPC. No hay NAT interno entre pods y VM. Eso significa que una regla de firewall puede referirse directamente al rango de pods, y que una VM de sn-datos-euw1 puede recibir tráfico de un pod y ver su IP de origen auténtica. Es más simple de razonar y más fácil de auditar.

Al crear un clúster nuevo se indican los rangos así (referencia para cuando recrees el clúster en la red nueva):

Cada VM tiene siempre una IP interna (de la subred) y, opcionalmente, una IP externa. Y cada una puede ser efímera (se asigna al arrancar y se pierde al parar la máquina) o estática (reservada, sobrevive a la instancia).

Reservamos ya la IP global que usará el balanceador de la próxima lección y las IP que necesitará Cloud NAT:

Reservar la IP de salida de NAT tiene una ventaja concreta: la pasarela de pago de AlpinaShop exige una lista de IP autorizadas. Si la IP de salida fuese efímera, cambiaría al recrear el NAT y el cobro dejaría de funcionar un martes por la tarde sin motivo aparente.

Una advertencia de facturación: una IP externa estática reservada y no asociada a nada se factura igualmente, y a una tarifa mayor que si estuviera en uso. Es una de las fugas de coste más habituales. Revísalas periódicamente:

El firewall de VPC es stateful (si permites la conexión de entrada, la respuesta sale sin necesidad de regla) y distribuido (se aplica en cada interfaz). Una regla tiene estos elementos:

Además existen cuatro reglas implícitas que no ves en la lista y no puedes borrar:

La consecuencia práctica es la que define la disciplina de trabajo: por defecto no entra nada y sale todo. Todo lo que quieras permitir de entrada hay que escribirlo; todo lo que quieras impedir de salida, también.

Es la decisión de diseño más importante del firewall. Se puede seleccionar a qué máquinas se aplica una regla de dos maneras:

AlpinaShop usa un modelo mixto y explícito: etiquetas para las reglas de entrada desde internet (donde la legibilidad importa y las máquinas son del MIG) y cuentas de servicio para el acceso a datos. Y documenta esa decisión, porque mezclar los dos criterios sin criterio es una fuente clásica de agujeros.

Este es el conjunto completo. Léelo entero antes de ejecutarlo: cada regla responde a una necesidad concreta.

Diagrama del resultado:

Es el patrón más extendido y el más peligroso. Abrir tcp:22 a 0.0.0.0/0 significa literalmente que cualquier máquina del planeta puede intentar autenticarse en tu servidor. Las consecuencias no son teóricas:

• Un servidor con el 22 abierto recibe miles de intentos de autenticación al día desde el primer minuto. Los escáneres automáticos barren los rangos de todos los proveedores de nube continuamente.
• Basta una credencial débil, una clave reutilizada o un fallo en sshd para que se convierta en una intrusión.
• El ruido en los logs esconde los ataques reales.
• Cierra la puerta a la trazabilidad: no sabes quién entró, solo qué clave se usó.

La alternativa correcta es IAP TCP forwarding, la regla número 2 del bloque anterior. Con ella:

• Las VM no necesitan IP pública.
• El acceso pasa por Google, que exige autenticación con la identidad corporativa (Marta, Dani) y aplica IAM: quien no tenga el rol roles/iap.tunnelResourceAccessor no llega ni al saludo de SSH.
• Cada sesión queda registrada con la identidad real de la persona.

Los detalles de IAP y sus permisos los desarrollamos en 03-04 (IAM); aquí basta con saber que la regla de firewall del 22 apunta a 35.235.240.0/20 y nunca a internet.

Las rutas deciden por dónde sale un paquete. Cada VPC nace con dos tipos de ruta automáticas:

Que la ruta por defecto se pueda borrar es una herramienta de seguridad muy potente: si eliminas la ruta 0.0.0.0/0 de una VPC, ninguna máquina de esa red puede salir a internet, ni siquiera con IP pública. Es el patrón de las redes aisladas para tratamiento de datos sensibles. AlpinaShop no llega ahí en producción, pero es útil para el proyecto de análisis de Lucía si algún día trata datos personales.

Las rutas personalizadas (por ejemplo, enviar cierto tráfico a un appliance de red) y las rutas aprendidas por BGP desde una VPN pertenecen a 07-03.

Ya hemos dicho que las VM no deben tener IP pública. Pero necesitan salir a internet para actualizar paquetes del sistema, instalar dependencias de Python o llamar a la API de la pasarela de pago. La solución es Cloud NAT: un servicio gestionado, sin instancias que mantener, que traduce las direcciones privadas a una o varias IP públicas de salida.

Puntos clave:

• Cloud NAT es solo de salida. Nadie puede iniciar una conexión desde internet hacia una VM a través de él. Es exactamente lo que queremos.
• No es una máquina: no hay cuello de botella que dimensionar ni parches que aplicar.
• Se configura por región y se asocia a un Cloud Router, que en este caso no hace BGP: es solo el punto de anclaje del servicio.

Detalle de las opciones:

• --nat-custom-subnet-ip-ranges: solo estas dos subredes salen por NAT. La alternativa (--nat-all-subnet-ip-ranges) es cómoda pero menos explícita.
• --nat-external-ip-pool=alpinashop-nat-ip: usa nuestra IP estática. Esa es la dirección que AlpinaShop comunica a la pasarela de pago para su lista de autorizados. La alternativa --auto-allocate-nat-external-ips deja que Google elija, y las IP pueden cambiar.
• --min-ports-per-vm=128: cada VM reserva 128 puertos de origen. Es el parámetro que causa el fallo más típico de Cloud NAT: si una máquina abre muchas conexiones salientes simultáneas (por ejemplo, un trabajo que descarga miles de ficheros) y se queda sin puertos, las conexiones nuevas fallan con un error confuso. El síntoma se ve en las métricas como nat_allocation_failed.
• --log-filter=ERRORS_ONLY: registra solo los fallos. ALL genera un volumen de logs considerable y coste asociado.

Verificación desde una VM sin IP pública:

Cuando una VM sin IP pública llama a storage.googleapis.com para leer del bucket alpinashop-catalogo, ¿por dónde va ese tráfico? Hay dos respuestas posibles, y la buena no es la evidente.

• Sin Private Google Access: la petición sale por Cloud NAT, va a internet, resuelve una IP pública de Google y vuelve. Funciona, pero sale de la red de Google, consume capacidad de NAT y se factura como tráfico de salida.
• Con Private Google Access activado en la subred: la petición se enruta internamente hacia los frontales de las APIs de Google. No pasa por internet, no consume puertos de NAT y no se factura como egress a internet.

Ya lo activamos al crear las subredes con --enable-private-ip-google-access. Si necesitas activarlo después:

Es una opción que debe estar activada siempre, en todas las subredes, en todos los entornos. No tiene coste, no tiene contraindicación y afecta a casi todo lo que hará AlpinaShop: leer el bucket, escribir en BigQuery (módulo 4), leer un secreto de Secret Manager (03-06) o descargar una imagen de Artifact Registry.

Existe una variante, Private Service Connect, que permite alcanzar APIs de Google o servicios de terceros por una IP privada tuya, con control de DNS. Es una pieza de arquitecturas más grandes y se estudia en 07-03.

En 02-03 creamos alpinashop-pedidos con IP pública y nos conectamos con el Auth Proxy. Funcionaba, pero la instancia era alcanzable desde internet (aunque protegida por redes autorizadas y credenciales). Ahora la movemos a IP privada, que es la configuración correcta.

El mecanismo se llama acceso privado a servicios y consiste en esto: cedes un rango de tu VPC a Google, Google crea allí los recursos gestionados (la instancia de Cloud SQL) y establece un emparejamiento entre tu red y la suya. Desde tu VPC, la base de datos aparece con una IP normal de ese rango.

Implementación, paso a paso:

Con la conexión establecida, se asigna la IP privada a la instancia y se retira la pública:

Detalles que evitan sustos:

• --no-assign-ip retira la IP pública. Hazlo solo cuando hayas verificado que la conexión privada funciona desde una VM; si no, te quedas sin acceso hasta revertirlo.
• El rango cedido no se puede reducir después sin recrear la conexión. Un /20 da margen para instancias futuras (la réplica alpinashop-pedidos-replica-informes también consume direcciones de ahí).
• La cadena de conexión de la aplicación Flask cambia de la IP pública a la privada; el Auth Proxy sigue siendo válido y sigue siendo la opción recomendada porque añade cifrado y autenticación IAM, pero ya no es la única forma de llegar.
• El cambio de red de una instancia de Cloud SQL implica reinicio. Planifícalo fuera de horario comercial.

Los registros de flujo graban una muestra de las conexiones que atraviesan las interfaces de las VM: origen, destino, puertos, bytes, paquetes, y si fueron permitidas o denegadas. Sirven para tres cosas:

1. Diagnosticar por qué algo no conecta (¿llegó el paquete? ¿lo denegó una regla?).
2. Auditar: ver a qué destinos externos habla realmente tu infraestructura.
3. Analizar coste de tráfico entre zonas y regiones.

Ya los activamos al crear las subredes. Una consulta típica en Cloud Logging (el servicio se estudia a fondo en 06-06; aquí lo usamos como herramienta):

Consideraciones de coste y privacidad:

• Los flow logs se facturan por volumen de logs ingeridos. En una red con tráfico intenso, el muestreo al 100 % puede ser caro. 0.5 es un punto de partida razonable; 0.1 para tráfico muy alto.
• Contienen direcciones IP de clientes, que en la Unión Europea son dato personal. Fija una política de retención acorde con el RGPD y documenta el tratamiento. Esta es una de esas decisiones que debe validar el responsable de cumplimiento antes de producción.

Además de los flow logs, para diagnóstico puntual está Network Intelligence Center y su herramienta de pruebas de conectividad, que simula un paquete y te dice exactamente qué regla lo permitió o denegó, sin generar tráfico real:

Para que no te quede la sensación de hueco, esto es lo que existe y no hemos tratado aquí:

• Usar la red default en producción. Trae subredes en todas las regiones y reglas que abren SSH y RDP a internet. Crea una red personalizada desde el principio y borra la default cuando ya no queden recursos dentro.
• Abrir tcp:22 a 0.0.0.0/0. El error clásico. Usa IAP con la regla desde 35.235.240.0/20 y quita las IP públicas de las VM.
• Olvidar los rangos del balanceador. Si no permites 130.211.0.0/22 y 35.191.0.0/16, las comprobaciones de estado fallan, el backend se marca no saludable y el balanceador devuelve 502 sin explicación clara. Es, con diferencia, el fallo número uno de la próxima lección.
• Elegir rangos "cómodos" como 10.0.0.0/16 o 192.168.1.0/24. Chocarán el día de la VPN. Planifica y documenta el direccionamiento antes de crear nada.
• Creer que las subredes son zonales. Son regionales. No necesitas una subred por zona; una subred regional sirve a un MIG regional en tres zonas.
• Confundir prioridad alta con número alto. En el firewall de VPC gana el número menor. Una regla allow con prioridad 100 vence a una deny con prioridad 1000.
• Dejar IP externas estáticas reservadas sin usar. Se facturan, y a tarifa superior. Audita gcloud compute addresses list --filter="status=RESERVED" cada mes.
• No activar Private Google Access. Sin él, todo el tráfico a las APIs de Google sale por NAT a internet: más coste, más latencia y agotamiento de puertos de NAT.
• Retirar la IP pública de Cloud SQL antes de comprobar la privada. Verifica primero la conectividad privada desde una VM y después aplica --no-assign-ip.
• Dimensionar mal min-ports-per-vm en Cloud NAT. Un trabajo por lotes con muchas conexiones salientes agota los puertos y provoca fallos intermitentes difíciles de atribuir. Vigila la métrica de fallos de asignación.
• Confiar solo en el firewall. El firewall de VPC controla el nivel de red. La autenticación, la autorización y la validación de entrada siguen siendo responsabilidad de la aplicación.

Marta necesita replicar la red en el proyecto alpinashop-dev. El requisito es que los rangos no solapen con producción (10.10.0.0/16, secundarios 10.20.0.0/16 y 10.21.0.0/20, acceso privado a servicios 10.30.0.0/20) ni con la oficina (192.168.10.0/24), porque en el futuro se conectarán ambos entornos.

Diseña el plan (red, dos subredes en europe-west1, rangos secundarios de GKE y rango para servicios gestionados) y escribe los comandos gcloud que lo crean, con Private Google Access activado.

Lucía necesita una VM de informes llamada alpinashop-informes-1 en sn-datos-euw1, con la etiqueta informes, que cumpla:

1. Solo Lucía y Marta pueden entrar por SSH, y únicamente a través de IAP.
2. La VM debe poder consultar la réplica alpinashop-pedidos-replica-informes por el puerto 5432.
3. La VM no debe recibir tráfico desde internet ni desde la capa web.
4. La VM debe poder descargar paquetes de PyPI (salida a internet) sin tener IP pública.

Escribe las reglas de firewall necesarias y explica qué componente resuelve el punto 4.

Tras crear el balanceador (adelanto de la próxima lección), el catálogo devuelve 502 y en la consola los backends del MIG aparecen como UNHEALTHY. La aplicación responde correctamente si haces curl http://10.10.0.5:8080/salud desde otra VM de la misma subred.

Enumera las tres causas más probables por orden de probabilidad y el comando que usarías para confirmar o descartar cada una.

Solución 1

Plan propuesto (bloque 10.60.0.0/16 reservado en el documento de direccionamiento para desarrollo):

Ninguno solapa con 10.10/16, 10.20/16, 10.21/20, 10.30/20 ni con 192.168.10.0/24.

Nota: los rangos secundarios se pueden dar en la creación con --secondary-range o añadirse después con --add-secondary-ranges.

Solución 2

Punto 4: lo resuelve Cloud NAT. La pasarela alpinashop-nat-euw1 ya cubre sn-datos-euw1, de modo que la VM, sin IP pública, sale a internet para instalar desde PyPI. Además, para descargar del bucket alpinashop-catalogo o escribir en BigQuery no usará NAT, sino Private Google Access, que está activo en la subred.

En cuanto a "solo Lucía y Marta": el firewall no distingue personas. Esa parte se resuelve con IAM dando roles/iap.tunnelResourceAccessor y roles/compute.osLogin únicamente a los grupos correspondientes; se ve en 03-04.

Solución 3

Por orden de probabilidad:

1. Falta la regla de firewall para los rangos de comprobación de estado. Es la causa más frecuente con diferencia. La comprobación se origina en 130.211.0.0/22 y 35.191.0.0/16, no en internet ni en la subred.

2. La etiqueta de red no coincide. La regla apunta a web-catalogo pero la plantilla de instancia del MIG no aplica esa etiqueta a las máquinas nuevas.

3. La comprobación apunta a un puerto o ruta equivocados. La aplicación escucha en 8080 y expone /salud, pero la comprobación está configurada en el 80 o en /.

Herramienta transversal: los logs de firewall de fw-deny-all-ingress mostrarán los intentos denegados desde 35.191.0.0/16 si la causa es la primera, y la prueba de conectividad de Network Intelligence Center confirma la regla exacta que bloquea.

AlpinaShop ya tiene una red de verdad. Has entendido la propiedad que define la red de Google —la VPC es global, las subredes son regionales— y por qué eso simplifica arquitecturas que en otros proveedores exigen malabares. Has descartado la red default con argumentos y has creado alpinashop-vpc en modo personalizado, con enrutamiento global y un plan de direccionamiento documentado que reserva 10.10.0.0/16 para producción, deja hueco para crecer y no choca con la oficina ni con alpinashop-dev.

Sobre esa red has creado sn-web-euw1 (10.10.0.0/24) y sn-datos-euw1 (10.10.1.0/24), con rangos secundarios gke-pods (10.20.0.0/16) y gke-servicios (10.21.0.0/20) para que alpinashop-cluster use red nativa de VPC y sus pods tengan direcciones reales. Has reservado la IP global alpinashop-lb-ip para el balanceador que construimos ahora mismo y la IP alpinashop-nat-ip para que la pasarela de pago pueda autorizar una dirección de salida estable.

Has aprendido el modelo de firewall completo —stateful, distribuido, prioridad donde gana el número menor, cuatro reglas implícitas, selección por etiqueta o por cuenta de servicio— y has escrito el conjunto real de AlpinaShop: HTTP y comprobaciones de estado solo desde 130.211.0.0/22 y 35.191.0.0/16, SSH solo desde el rango de IAP 35.235.240.0/20, PostgreSQL solo desde la cuenta de servicio sa-catalogo-web, y una denegación explícita con registro que te enseña qué está llamando a la puerta. Y sabes por qué 0.0.0.0/0 en el 22 no es una comodidad sino un incidente pendiente.

Por último, las máquinas ya no necesitan IP pública: Cloud NAT les da salida controlada con una IP estática conocida, Private Google Access las lleva a las APIs de Google sin pisar internet, el acceso privado a servicios ha puesto alpinashop-pedidos en una IP privada del rango 10.30.0.0/20, y los VPC Flow Logs convierten los problemas de red en consultas de log en lugar de conjeturas.

La red está lista, pero el catálogo todavía se sirve por la IP de una máquina. En la siguiente lección, 03-02, Balanceo de carga en la nube, ponemos delante un balanceador HTTP(S) externo global: una única dirección anycast que atiende desde el punto de presencia más cercano a cada cliente europeo, reparte el tráfico entre las instancias del MIG alpinashop-web-mig, sirve las imágenes directamente desde el bucket alpinashop-catalogo mediante un mapa de URL, y comprueba la salud de los backends por esa ruta /salud que ya hemos autorizado en el firewall. Todas las piezas de red que acabamos de colocar existen precisamente para que ese balanceador funcione a la primera.