Cuando creas un recurso en Google Cloud, casi siempre tienes que decidir dónde vive. Esa decisión, que la consola presenta como un simple desplegable, condiciona la latencia que sufren tus clientes, el precio que pagas, qué servicios tienes disponibles, si cumples la normativa de protección de datos y qué ocurre cuando falla un centro de datos. No es un detalle de configuración: es una decisión de arquitectura que después cuesta mucho revertir.

En esta lección aprenderemos la geografía de Google Cloud y qué significa que un servicio sea zonal, regional, multirregional o global; por qué la red troncal privada de Google y sus puntos de presencia importan para la latencia; qué criterios usar para elegir región, aplicados a la decisión real de AlpinaShop entre europe-west1 y europe-southwest1; qué protege desplegar en varias zonas y qué exige el multirregión; y cómo se reparte la responsabilidad entre Google y tú según el tipo de servicio, incluyendo cómo se leen los SLA y por qué un SLA no promete que nada falle nunca.

1. La geografía de Google Cloud
2. Alcance de los servicios: zonal, regional, multirregional y global
3. La red troncal privada y los puntos de presencia
4. Cómo elegir región: los cinco criterios
5. La decisión de AlpinaShop: europe-west1 frente a europe-southwest1
6. Dominios de fallo y disponibilidad
7. El modelo de responsabilidad compartida
8. SLA y créditos de servicio

Google Cloud organiza su infraestructura física en tres niveles:

Detalles importantes:

• Las zonas de una región están muy cerca entre sí, con latencias de red típicamente inferiores al milisegundo. Eso permite replicación síncrona entre zonas sin penalización perceptible: es la base de la alta disponibilidad regional.
• Las letras de zona no son estables entre proyectos. La zona europe-west1-b de tu proyecto y la de otro cliente pueden corresponder a hardware físico distinto. Google hace esta asignación deliberadamente para repartir la carga.
• La latencia entre regiones sí es significativa. Entre europe-west1 y europe-southwest1 hay del orden de una decena de milisegundos; entre Europa y Estados Unidos, en torno a 100 ms. Cualquier arquitectura que cruce regiones en el camino crítico de una petición lo notará.

Nombres de las regiones europeas más relevantes para una empresa española:

Cada servicio de Google Cloud tiene un alcance que determina dónde vive y a qué fallos sobrevive. Entenderlo es imprescindible para diseñar cualquier arquitectura.

Clasificación de los servicios concretos que aparecerán en el curso:

Dos casos merecen comentario aparte:

• La VPC global es una diferencia real frente a AWS y Azure, donde la red virtual es regional. En Google Cloud una misma VPC puede tener subredes en Bélgica, Madrid y Tokio, y las máquinas de todas ellas se comunican por IP privada sin configurar peering. Lo estudiaremos en la lección 03-01.
• La inmutabilidad de la ubicación en Cloud Storage y BigQuery es un detalle que atrapa a mucha gente: si creas el bucket alpinashop-catalogo en la región equivocada, la única solución es crear otro y copiar los datos, pagando el tráfico correspondiente.

Google opera una de las mayores redes privadas del mundo: fibra propia y capacidad contratada que une sus centros de datos entre sí y con más de un centenar de puntos de presencia (PoP) repartidos por el planeta, incluido Madrid.

Por qué importa esto en la práctica:

• El tráfico entra pronto en la red de Google. Cuando un cliente de AlpinaShop en Sevilla pide una página, su petición llega al PoP de Google más cercano (Madrid) tras unos pocos saltos por internet, y desde ahí viaja hasta europe-west1 por fibra de Google. La parte "impredecible" del trayecto se acorta.
• Menos latencia y, sobre todo, menos variabilidad. El internet público tiene picos de latencia impredecibles; una red privada gestionada extremo a extremo no.
• Es la base del balanceador global. El balanceador HTTP(S) externo de Google usa una única dirección IP anycast anunciada desde todos los PoP. El usuario se conecta automáticamente al punto más cercano y desde ahí el tráfico va por la red de Google al backend adecuado. Se estudia en la lección 03-02.
• Es la base de Cloud CDN. Los contenidos estáticos —las imágenes de producto de AlpinaShop, por ejemplo— pueden almacenarse en caché en esos PoP, sirviéndose desde a pocos milisegundos del cliente sin llegar a tocar el bucket. Lección 03-03.

Una consecuencia arquitectónica que conviene retener desde ya: con una CDN y un balanceador global bien configurados, la región donde vive tu backend importa menos de lo que parece para el contenido estático, pero sigue siendo decisiva para todo lo que requiera hablar con la base de datos.

Hay además dos niveles de servicio de red que afectan a coste y rendimiento:

Ampliemos los dos que más se subestiman.

Una confusión muy extendida: el RGPD no obliga, con carácter general, a que los datos de ciudadanos europeos permanezcan en un país concreto ni siquiera dentro de la UE. Lo que exige es que el tratamiento cumpla la normativa y que las transferencias internacionales dispongan de garantías adecuadas.

Dicho eso, en la práctica hay razones sólidas para mantener los datos en la UE:

• Evita por completo la complejidad jurídica de las transferencias internacionales.
• Muchos clientes corporativos y del sector público lo exigen contractualmente, aunque la ley no lo imponga.
• Determinados sectores (sanidad, banca, administración pública) sí tienen requisitos específicos más estrictos.

Google ofrece además políticas de organización para restringir por política en qué regiones se pueden crear recursos (gcp.resourceLocations), lo que convierte la residencia del dato en algo verificable y no solo en una intención. Se ve en la lección 07-07.

Para AlpinaShop, que vende a consumidores en España y Portugal y trata datos personales de clientes (nombre, dirección, historial de pedidos), la decisión es clara: todo dentro de la UE. La duda es entre Bélgica y Madrid.

No todas las regiones son iguales. Las regiones más antiguas y grandes tienen catálogo completo; las más nuevas van incorporando servicios progresivamente, y algunos tipos de máquina, aceleradores (GPU, TPU) o servicios de datos tardan en llegar.

El primer comando lista las regiones con su estado. El segundo usa --filter para quedarse solo con las dos regiones candidatas y --format con region.basename() para mostrar el nombre corto de la región en lugar de su URL completa. El tercero combina dos condiciones con AND y usa ~ para expresar "el nombre coincide con la expresión regular ^n2-", lo que permite comprobar si una familia de máquinas concreta está disponible antes de comprometerse con una región.

Marta analiza las dos candidatas con datos reales de la empresa: el 85 % de los pedidos vienen de España, el 10 % de Portugal y el 5 % del resto de Europa.

AlpinaShop elige europe-west1 como región principal para esta primera fase de la migración, con la zona europe-west1-b como zona por defecto. Las razones:

1. Es una región madura, con todos los servicios que el curso y la empresa necesitarán, incluidos los de datos e IA que llegarán más adelante. Empezar una migración en una región incompleta obliga a descubrir carencias en el peor momento.
2. El precio es menor en varios de los servicios que más consumirá.
3. La penalización de latencia es aceptable y mitigable: la diferencia de 20-25 ms es perceptible en una medición, pero se neutraliza en gran medida sirviendo el contenido estático desde Cloud CDN en el PoP de Madrid y aplicando caché a lo dinámico. El grueso de una página de catálogo son imágenes.
4. La residencia del dato se cumple: Bélgica es territorio de la Unión Europea, y AlpinaShop no tiene requisitos sectoriales que exijan territorio español.

Cuándo revisaría Marta esta decisión. Si AlpinaShop firmara un contrato con una administración pública española que exigiera datos en territorio nacional, o si el análisis de conversión mostrara que la latencia está costando ventas, la instancia de Cloud SQL alpinashop-pedidos y el bucket alpinashop-catalogo se replantearían hacia europe-southwest1. Por eso europe-southwest1 aparecerá varias veces en el curso: es la alternativa siempre presente cuando hablemos de latencia o residencia del dato en España.

Este par de comandos es de los más rentables del curso: sin ellos, muchos comandos usan valores por defecto o preguntan interactivamente, y es muy fácil acabar con recursos dispersos por medio mundo.

Un dominio de fallo es el conjunto de recursos que pueden caer juntos por una misma causa. Diseñar para la disponibilidad consiste en repartir tus recursos entre dominios de fallo distintos.

Qué implica cada salto:

• De una zona a varias zonas es el salto con mejor relación coste/beneficio, y el que cubre la inmensa mayoría de incidentes reales. Suele requerir: replicación síncrona de la base de datos (Cloud SQL con HA), varias instancias tras un balanceador, y almacenamiento regional en lugar de zonal. La latencia entre zonas es submilisegundo, así que la replicación síncrona es viable.
• De varias zonas a varias regiones cambia la naturaleza del problema. La latencia entre regiones hace inviable la replicación síncrona sin penalizar la escritura, así que hay que elegir entre replicación asíncrona (con posible pérdida de datos recientes) o bases de datos diseñadas para ello, como Spanner. Además hay que resolver el enrutamiento del tráfico y la conmutación.

Una advertencia contra el entusiasmo: el multirregión no es "más disponibilidad" gratis. Multiplica coste, complejidad y superficie de error, y hay incidentes que replica en lugar de contener (un despliegue defectuoso o un borrado accidental se propagan a todas las regiones). Para AlpinaShop, la respuesta correcta en esta fase es producción multizona dentro de europe-west1, con copias de seguridad en un bucket multirregión EU como protección adicional.

Los conceptos de SLO, RTO y RPO, y el diseño detallado de arquitecturas de alta disponibilidad y recuperación ante desastres, se estudian en la lección 07-06.

La seguridad en la nube siempre se comparte. Google responde de la seguridad de la nube; tú respondes de la seguridad en la nube. Dónde cae exactamente la línea depende del tipo de servicio.

Lo que nunca deja de ser tuyo, en ningún modelo de servicio:

1. Tus datos: qué recoges, cuánto tiempo lo guardas, cómo lo clasificas, si está cifrado con claves gestionadas por ti.
2. Quién accede: las políticas de IAM, la gestión de identidades, la rotación de credenciales.
3. Tu configuración: un bucket público, una regla de firewall que abre el 0.0.0.0/0 al puerto 22 o una base de datos con IP pública son responsabilidad exclusivamente tuya, y son la causa de la inmensa mayoría de brechas reales en la nube.
4. Tu código: las vulnerabilidades de tu aplicación y de tus dependencias.

Aplicado a AlpinaShop:

Una nota que sorprende a mucha gente: el cifrado en reposo está activado por defecto en todos los servicios de almacenamiento de Google Cloud, sin que tengas que hacer nada. Google gestiona las claves. Si necesitas gestionarlas tú (por requisito normativo o por política interna), existen las claves gestionadas por el cliente con Cloud KMS, tema de la lección 03-06.

Un SLA (Service Level Agreement) es el compromiso contractual de disponibilidad de un servicio. Leerlos bien evita tanto la ingenuidad como el cinismo.

Órdenes de magnitud típicos (verifica siempre las cifras vigentes en los términos oficiales de cada servicio, porque cambian):

Cómo leer un SLA de verdad:

• El SLA depende de tu arquitectura, no solo del servicio. Fíjate en la tabla: la misma VM tiene un compromiso muy distinto según esté sola en una zona o repartida entre varias. Google no te garantiza 99,99 % si tú despliegas en una sola zona.
• Un SLA no es una promesa de que no fallará. Es un compromiso económico: si Google incumple, tú tienes derecho a un crédito de servicio, es decir, un descuento en la factura de meses posteriores.
• Los créditos son ridículos comparados con el daño real. Un incumplimiento típico da lugar a un crédito del 10-25 % de la factura del servicio afectado durante ese periodo. Si AlpinaShop pierde una tarde de campaña de otoño, el crédito no cubrirá ni de lejos las ventas perdidas. El SLA no sustituye a diseñar para la resiliencia.
• Los créditos hay que reclamarlos. No se aplican solos: hay que presentar una solicitud dentro de un plazo, aportando registros que documenten la indisponibilidad. Otra razón para tener Cloud Monitoring bien configurado (lección 06-04).
• Existen exclusiones. El SLA no cubre lo causado por tu propia configuración, por software de terceros, por incumplir las cuotas, ni por servicios en fase preliminar.

La conclusión práctica: usa el SLA como una señal del nivel de fiabilidad que Google se atreve a comprometer para una arquitectura dada, y como criterio para elegir configuración, no como red de seguridad de tu negocio.

• Dejar la región por defecto. Muchos tutoriales y algunos valores por defecto apuntan a us-central1. Para AlpinaShop eso significaría 100 ms de latencia extra y datos fuera de la UE. Fija región y zona con gcloud config set desde el primer día.
• Confundir región con zona. Crear una VM "en europe-west1" no es posible: las VMs son zonales y viven en europe-west1-b, -c o -d.
• Creer que multizona y multirregión son lo mismo. Multizona protege contra la caída de un centro de datos y es asequible; multirregión protege contra la pérdida de una región entera y es caro y complejo.
• Crear un bucket o un dataset en la ubicación equivocada. La ubicación de Cloud Storage y BigQuery es inmutable: la única salida es crear otro y copiar los datos, pagando el traslado.
• Suponer que todas las regiones tienen todos los servicios. Comprueba disponibilidad antes de comprometerte, especialmente con GPUs, TPUs y servicios recientes.
• Pensar que "gestionado" significa "seguro por defecto". La configuración es tuya en todos los modelos. Un bucket público es un bucket público aunque el servicio sea serverless.
• Confiar en el SLA como plan de continuidad. El crédito de servicio no paga las ventas perdidas.
• Consejo: mide, no supongas. Antes de decidir región por latencia, mide desde donde están tus usuarios reales.
• Consejo: separa la decisión de región de la de arquitectura. Primero decide dónde deben vivir los datos (normativa, latencia) y después cómo se despliega el cómputo.
• Consejo: usa una política de organización para restringir regiones. Es la única forma de garantizar que nadie crea un recurso en Iowa por descuido.

Para cada recurso de AlpinaShop, indica su alcance (zonal, regional, multirregional o global) y qué ocurre si cae completamente la zona europe-west1-b:

1. Una instancia de Compute Engine que sirve el Nginx heredado, creada en europe-west1-b.
2. La instancia Cloud SQL alpinashop-pedidos configurada con alta disponibilidad en europe-west1.
3. El bucket alpinashop-catalogo creado como multirregión EU.
4. La política de IAM que da a Lucía permiso de lectura sobre BigQuery.
5. Un clúster GKE alpinashop-cluster creado como zonal en europe-west1-b.
6. El balanceador HTTP(S) externo que publica la tienda.

AlpinaShop firma un acuerdo con una cadena de tiendas de deporte en Alemania: la nueva plataforma B2B servirá pedidos mayoristas desde Alemania, tratará datos de empresas alemanas y el contrato exige que los datos permanezcan en territorio alemán. El volumen previsto es pequeño y no requiere GPUs ni servicios exóticos.

1. ¿Qué región elegirías y por qué?
2. ¿Deberían los datos B2B convivir en la misma base de datos tienda que el resto? Justifícalo.
3. ¿Qué mecanismo usarías para garantizar técnicamente que nadie crea por error recursos de ese proyecto fuera de Alemania?

Analiza estos cinco incidentes reales y determina, en cada caso, si la responsabilidad es de Google o de AlpinaShop, y qué medida concreta lo habría evitado:

1. El bucket alpinashop-catalogo quedó configurado con acceso público y un buscador indexó facturas que se habían subido allí por error.
2. Una zona de europe-west1 sufrió un corte eléctrico de 40 minutos y la VM que servía la tienda quedó inaccesible.
3. Un atacante entró por SSH a la VM heredada usando una contraseña débil de un usuario del sistema.
4. Una vulnerabilidad crítica en la versión de PostgreSQL que usa Cloud SQL fue parcheada sin intervención de nadie de AlpinaShop.
5. La aplicación Flask tenía una vulnerabilidad de inyección SQL en el buscador de productos.

Solución 1

1. Zonal. Se pierde la instancia y con ella el servicio, hasta que se recree en otra zona. El disco persistente zonal asociado también queda inaccesible.
2. Regional. Cloud SQL con HA mantiene una réplica en espera en otra zona de la región y conmuta automáticamente. Hay un breve corte durante la conmutación (del orden de decenas de segundos), pero el servicio se restablece solo.
3. Multirregional. No le afecta en absoluto: los datos están replicados entre varias regiones de la UE. Es el nivel de resiliencia más alto de los que aparecen aquí.
4. Global. IAM no tiene ubicación; la política sigue vigente y Lucía conserva su acceso.
5. Zonal. Se pierde el plano de control del clúster y todos sus nodos. Un clúster regional habría replicado el plano de control en tres zonas y mantenido los nodos de las zonas supervivientes.
6. Global. El balanceador no se ve afectado, pero dejará de enviar tráfico a los backends de la zona caída. Si todos los backends estaban en esa zona, no tiene a dónde enviar el tráfico: el balanceador global no crea disponibilidad por sí solo, la reparte.

Solución 2

1. europe-west3 (Fráncfort), por ser una región en territorio alemán con catálogo completo y madura. europe-west10 (Berlín) sería otra opción válida en territorio alemán; entre ambas, Fráncfort ofrece mayor disponibilidad de servicios y mejor precio, mientras que Berlín podría interesar por latencia si los clientes se concentraran allí. Dado que el volumen es pequeño y no hay requisitos exóticos, la madurez pesa más.
2. No. Los datos B2B alemanes deben vivir en su propia instancia y su propio proyecto, en europe-west3. Mezclarlos con la base de datos tienda de europe-west1 incumpliría directamente el requisito contractual de residencia, y separarlos después sería mucho más costoso. La estructura natural es un proyecto nuevo, por ejemplo alpinashop-de-prod, dentro de la carpeta produccion.
3. Una política de organización de restricción de ubicaciones (constraints/gcp.resourceLocations) aplicada al proyecto o a una carpeta que lo contenga, permitiendo únicamente in:eu-west3-locations. A diferencia de una norma escrita en un documento, esta política impide técnicamente la creación de recursos fuera de la ubicación permitida, incluso para usuarios con permisos amplios. Se estudia en la lección 07-07.

Solución 3

1. Responsabilidad de AlpinaShop. La configuración de acceso de un bucket es siempre del cliente. Google proporciona los controles; usarlos es tu tarea. Lo habría evitado: activar la prevención de acceso público a nivel de organización, usar acceso uniforme a nivel de bucket, y no subir documentos con datos personales a un bucket destinado a imágenes públicas de catálogo.
2. Responsabilidad de Google en cuanto a la infraestructura: un corte de energía en una zona es un fallo de la nube. Pero la indisponibilidad del servicio es responsabilidad de AlpinaShop, porque desplegó una única VM en una única zona. Google cumple su SLA zonal; AlpinaShop no diseñó para el fallo. Lo habría evitado: un grupo de instancias gestionado regional detrás de un balanceador, con la base de datos en Cloud SQL con HA.
3. Responsabilidad de AlpinaShop. El sistema operativo y sus usuarios son suyos en IaaS. Lo habría evitado: deshabilitar la autenticación por contraseña en SSH, usar el acceso mediante OS Login con identidades de Google, no exponer el puerto 22 a internet y acceder mediante Identity-Aware Proxy.
4. Responsabilidad de Google, y es exactamente el valor que se compra al usar un servicio gestionado: el parcheo del motor de base de datos es suyo. AlpinaShop solo debe encargarse de que la ventana de mantenimiento esté configurada en un horario aceptable y de estar al tanto de los cambios de versión mayor.
5. Responsabilidad de AlpinaShop. El código de la aplicación es siempre del cliente, en todos los modelos de servicio, incluido serverless. Lo habría evitado: consultas parametrizadas, revisión de código, análisis estático en el pipeline de CI/CD y, como capa adicional, reglas de Cloud Armor contra patrones de inyección (lección 03-05).

Ya sabemos dónde van a vivir los recursos de AlpinaShop y quién responde de qué. Hemos recorrido la geografía de Google Cloud —zona, región y multirregión— y hemos clasificado los servicios del curso según sean zonales, regionales, multirregionales o globales, con la particularidad de que en Google Cloud la VPC es global y la ubicación de un bucket o un dataset es inmutable. Hemos visto por qué la red troncal privada de Google y sus puntos de presencia reducen latencia y hacen posibles el balanceador global con IP anycast y Cloud CDN. Hemos aplicado los cinco criterios de elección de región al caso real de AlpinaShop y hemos decidido europe-west1 con zona europe-west1-b, dejando europe-southwest1 como alternativa si aparecen requisitos de residencia en territorio español o si la latencia empieza a costar ventas. Hemos entendido qué protege desplegar en varias zonas frente a lo que exige el multirregión, y hemos repartido la seguridad entre Google y nosotros con la regla que nunca cambia: los datos, los accesos, la configuración y el código son siempre tuyos. Y hemos aprendido a leer un SLA como lo que es: un compromiso económico que depende de tu arquitectura, no una garantía de que nada fallará.

Nos queda una última pieza del módulo, y es la que convierte todo lo anterior en trabajo real. En la próxima lección, Cloud Shell y la CLI de gcloud, dejaremos la teoría y nos pondremos a teclear: veremos qué es Cloud Shell y qué límites tiene, cómo instalar el CLI en local, cómo se estructura un comando gcloud y cómo dominar --format y --filter, cómo funcionan la autenticación y las configuraciones nombradas para alternar entre alpinashop-dev y alpinashop-prod, y cerraremos el módulo con el primer despliegue real del curso: Dani publicará una página de "próximamente" de AlpinaShop en internet, de extremo a extremo, desde el navegador.