Google Cloud Global Infrastructure

Resumen

La infraestructura global de Google Cloud no es un catálogo de centros de datos repartidos por el mundo: es una red que Google diseñó, construyó y opera como una sola pieza, desde los cables submarinos que atraviesan el océano hasta el rack donde corre la instancia que sirve la petición de un usuario en Valparaíso. Entender esa cadena completa es lo que separa a un profesional que sabe desplegar en la nube de uno que sabe decidir dónde desplegar y por qué esa decisión tiene un coste y un riesgo que hay que defender ante el negocio.

Este tema recorre la terminología de red que la guía del examen exige —IP address, internet service provider (ISP), domain name server (DNS), latency, bandwidth, fiber optics, subsea cables, network edge data centers—, porque sin ese vocabulario no se pueden formular las preguntas que de verdad importan en una reunión de diseño: por qué una web para clientes en España debería servirse desde europe-west1 y no desde us-central1, por qué una base de datos transaccional no debe depender de un único centro de datos, o por qué un backup en otra región es una decisión de cumplimiento además de una decisión de supervivencia.

El bloque central son las regiones y las zones: la forma en que Google agrupa centros de datos para definir compromiso de disponibilidad, aislamiento entre zonas y alcance geográfico de los datos. Cada región ofrece un contrato de servicio distinto y cada zona aísla un conjunto de equipos. Elegir región es elegir dónde viven los datos, cuánto cuesta sacarlos y qué normativa les aplica; elegir zona es elegir qué tan cerca está el cómputo de la red y qué nivel de fallo se acepta.

Después se describen los data centers de Google: diseño propio, servidores purpose-built, hardware de seguridad propio como el chip Titan, y una operación de instalaciones gestionada con redundancia a todos los niveles. Y a continuación la red global: un backbone privado que conecta las regiones entre sí con rutas redundantes, cables submarinos que Google posee o cofinancia, puntos de presencia en el edge que dan respuesta en milisegundos y acuerdos de peering que sacan el tráfico de la plataforma hacia el ISP del usuario final.

El tema cierra con dos conexiones que un Digital Leader debe hacer explícitas en cada proyecto: la relación entre latencia y ancho de banda —que no son sinónimos y determinan a la vez la experiencia de usuario y el coste— y la relación entre infraestructura global, residencia de datos y cumplimiento, que es donde la elección de región se convierte en un compromiso legal y no solo en una decisión técnica. En cada bloque, la información técnica se traduce a su consecuencia operativa, económica o regulatoria, que es el idioma que evalúa la certificación.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Definir con precisión los términos de red que aparecen en la guía del examen —IP address, ISP, DNS, regions, zones, fiber optics, subsea cables, network edge data centers, latency y bandwidth— y explicar la función de cada uno dentro de una arquitectura en Google Cloud.
Diferenciar una región de una zona, describir cómo se relacionan y explicar por qué la elección de ambas tiene consecuencias distintas en disponibilidad, latencia, residencia de datos y coste.
Describir los data centers de Google: diseño propio de instalaciones y servidores, hardware purpose-built y componentes de seguridad eigenen como la raíz de confianza de hardware.
Explicar cómo está construida la red global de Google —backbone privado, rutas redundantes, cables submarinos, puntos de presencia en el edge y peering— y qué garantiza cada capa en términos de resiliencia y alcance.
Diferenciar latencia de ancho de banda y deducir sus efectos sobre la experiencia de usuario, el dimensionamiento de la arquitectura y la factura de red.
Relacionar la elección de ubicación con los requisitos de residencia de datos y cumplimiento, e identificar qué servicios y controles de Google Cloud intervienen en cada caso.
Consultar la topología real de la plataforma con gcloud: listar regiones y zonas, describir una zona y sus límites de recursos, localizar las instancias existentes y describir la configuración de los balanceadores globales.
Traducir a lenguaje de negocio los resultados de esa consulta: qué decisión de ubicación sostiene, qué riesgo de disponibilidad cubre y qué coste asumido introduce.

Contenido Principal

Subtema 1: El vocabulario mínimo de red

Antes de hablar de regiones conviene fijar el lenguaje, porque la mayoría de los malentendidos entre el equipo técnico y el negocio nacen de usar la misma palabra para dos cosas distintas.

Una IP address es la dirección lógica que permite que un paquete de datos encuentre su destino en una red. En Google Cloud cada recurso de red tiene dirección IP, y la decisión de si esa dirección es privada o pública tiene consecuencias directas: las direcciones internas no son alcanzables desde internet y son las que debe usar un balanceador interno; las direcciones externas, reservadas o efímeras, son las que aparecerán en los registros del ISP del cliente. Un error frecuente en la conversación de negocio es pedir "una IP pública" sin explicar que eso es una decisión de exposición, no de direccionamiento.

El internet service provider (ISP) es el operador que da acceso a internet al usuario final: una operadora de telecomunicaciones, un proveedor de servicios de correo corporativo con salida a internet, la red de un operador móvil. Para una organización mediana, casi todo el tráfico de usuarios finales entra por un ISP o por un intermediario, y ese salto introduce latencia y puntos de fallo que no están bajo control del proveedor de nube. La lección de arquitectura es que la ruta del usuario hasta la aplicación suele ser la parte menos optimizada del sistema, y que una aplicación global bien diseñada coloca contenido cerca del usuario para acortar precisamente ese tramo.

El domain name server (DNS) resuelve un nombre —tienda.example.com— a una dirección IP. En un contexto de nube, DNS tiene dos capas que conviene no confundir: el DNS público, que resuelve nombres hacia direcciones que pueden ser cualquiercast —una sola dirección que anuncia rutas desde muchos puntos de la red—, y el DNS interno de Google Cloud, que resuelve nombres de máquinas y servicios dentro de una red VPC sin salir de ella. El impacto de negocio del DNS público es que un cambio de dirección IP puede propagarse en minutos u horas según la caché de los resolvers intermedios; por eso los cambios de arquitectura de entrada de tráfico necesitan una ventana de migración, no un cambio instantáneo.

La fiber optics es el medio físico por el que viaja la mayor parte del tráfico de internet y también el backbone privado de Google. La fibra permite distancias mucho mayores que el cobre sin pérdida de señal y inmune a interferencias electromagnéticas, lo que la hace el único medio viable para una red que conecta centros de datos separados por miles de kilómetros. La consecuencia relevante es que la red global de Google es, en el fondo, fibra: cuando se habla de "la nube", la señal física viaja por cables que alguien tendió, conectó y mantiene, y que en el caso de los cables submarinos de Google son inversiones de capital de la propia compañía.

Los subsea cables —cables submarinos— transportan la mayor parte del tráfico internacional de internet. Son el componente que decide la latencia entre continentes y que convierte un corte de cable en un evento de negocio. Google no se limita a comprar capacidad en cables de terceros: ha invertido en consorcios como Unity, JGA, INDIGO o Havfrue, y ha construido cables propios, entre ellos Curie, Dunant, Equiano, Firmina, Grace Hopper, Blue, Raman, Amitié y Sol. El efecto para un cliente de Google Cloud es indirecto pero real: una ruta transatlántica con más cables disponibles significa más rutas de respaldo y mejor tolerancia a la rotura de un enlace individual.

Los network edge data centers son los puntos de presencia que Google tiene cerca de las redes de los ISP, en ciudades de todo el mundo. Ahí termina la caché de Cloud CDN, ahí termina la conexión de los balanceadores globales con anycast, y ahí termina también parte del tráfico de los productos de Google. La cifra publicada por Google es de más de 200 puntos de presencia en el edge [VERIFICAR: la cifra exacta cambia con la expansión de la red]; su consecuencia es que la distancia entre el usuario y un punto de presencia es mucho menor que la distancia entre el usuario y un centro de datos.

Latency es el tiempo que tarda un paquete en ir de un punto a otro. Bandwidth es la cantidad de datos que se pueden mover por unidad de tiempo. Confundirlos lleva a decisiones equivocadas: un enlace de 1 Gbps con 200 ms de retardo puede ser más lento para una transacción web interactiva que un enlace de 100 Mbps a 5 ms, porque el protocolo de aplicación tiene que esperar las confirmaciones. Y al revés: un enlace con muchísima latencia pero mucho ancho de banda es ideal para transferir una copia de seguridad masiva, donde importa el volumen total y no la interactividad.

Término	Qué significa	Dónde aparece en Google Cloud	Implicación de negocio
IP address	Dirección lógica que identifica un punto en una red	Direcciones internas y externas de VMs, reglas de firewall, direcciones de balanceadores	Define exposición y es la base del aislamiento de red
ISP	Proveedor de acceso a internet del usuario final	Ruta de entrada del tráfico de clientes; relevante en el tramo usuario-aplicación	La latencia del tramo final depende del ISP, no del proveedor de nube
DNS	Sistema que resuelve nombres a direcciones IP	DNS público de los servicios de Google; DNS interno dentro de la VPC	Los cambios de dirección tienen ventana de propagación: planificarlos
Fiber optics	Medio de transmisión por luz a través de fibra de vidrio	Backbone privado de Google y cables submarinos	Permite conexiones intercontinentales de alta capacidad
Subsea cables	Cables submarinos que transportan tráfico entre continentes	Inversiones y consorcios de Google: Curie, Dunant, Equiano, Firmina, Grace Hopper, Blue, Raman, Amitié	Determina la latencia transatlántica y la resiliencia de la ruta
Network edge data centers	Puntos de presencia del proveedor cerca de las redes de los ISP	Puntos de presencia cerca de las redes de los ISP; origen de la caché de Cloud CDN	Acerca el contenido al usuario sin mover el backend
Latency	Tiempo de ida y vuelta de un paquete	Se mide entre zonas, regiones y usuarios	Limita la experiencia interactiva y el número de saltos de diseño
Bandwidth	Volumen de datos por unidad de tiempo	Capacidad de la red y del balanceador; prepago de Premium Tier	Sostiene descargas y cargas, y es una partida de coste medible
Region	Área geográfica con al menos tres zonas y disponibilidad de producto	`us-central1`, `europe-west1`, `southamerica-west1`, etc.	Ancla de la residencia de datos, del coste y del cumplimiento
Zone	Área de despliegue aislada dentro de una región	`europe-west1-b`, `us-east1-c`, etc.	Unidad de aislamiento de hardware y de fallo

Ejemplo Práctico

Antes de discutir regiones y zonas conviene poder ver, con comandos reales, cómo está construida la red lógica del proyecto: qué direcciones existen, si son internas o externas, en qué red virtual están y cómo se enruta el tráfico. Esa lectura es la que convierte la terminología del Subtema 1 en hechos auditables.

Listar las redes virtuales del proyecto y ver si usan subredes automáticas o mode manual:

gcloud compute networks list \
  --format="table(name, autoCreateSubnetworks, subnetworks[0].region.basename(), mtu)"

Lectura de negocio: cada fila es una red VPC. El valor autoCreateSubnetworks en True indica que las subredes se crean y se borran con la red, lo que es cómodo para prototipos pero frágil en producción, porque una subred con un rango de IP mal dimensionado deja de crecer sin recrear la red. La columna region.basename() muestra dónde vive la subred principal y es ya una primera verificación de residencia.

Ver las direcciones IP reservadas y su tipo, que es donde se ve la exposición de cada servicio:

gcloud compute addresses list \
  --format="table(name, address, region.basename(), addressType, purpose, networkTier, status)"

La columna addressType distingue una dirección interna de una externa, y la columna purpose distingue una dirección de un balanceador de una dirección efímera asignada a una instancia. La columna networkTier indica si el tráfico entra por la red global de Google o por internet público. Lectura de negocio: un inventario de direcciones con addressType en EXTERNAL y purpose en GLOBAL es la lista de los puntos de entrada públicos de la organización, y por tanto la superficie que debe estar detrás de Cloud Armor, de reglas de firewall y de certificados válidos. Una dirección externa de una instancia, en cambio, es una exposición innecesaria y candidato natural a eliminarse.

Comprobar el nombre DNS interno de una red y su modo de enrutamiento:

gcloud compute networks describe VPC_NAME \
  --format="value(name, dnsSuffix, routingConfig.routingMode, mtu)"

El dnsSuffix es el dominio con el que Google publica los nombres internos de las máquinas de esa red, y el routingMode indica si el enrutamiento es global o regional. Lectura de negocio: el enrutamiento global permite que una instancia en europe-west1 alcance recursos en us-central1 por la red interna sin salir a internet, con lo que la latencia y la consistencia del tráfico entre servicios mejoran y el camino deja de depender de la ruta pública. El enrutamiento regional es más restrictivo y requiere rutas estáticas o un Cloud Router para hablar con otras redes; es una decisión de contención que conviene justificar por separado.

Ver las rutas de la red, que es donde se observa el camino real hacia los destinos externos:

gcloud compute routes list \
  --format="table(name, network, destRange, nextHopGateway, nextHopInstance, priority)"

Cada fila es una ruta: un prefijo de destino y un siguiente salto. Un nextHopGateway que referencia un Cloud Router indica que la salida hacia ese destino se negocia por BGP, que es el patrón típico de la conexión híbrida con la red corporativa. Un nextHopInstance indica que el tráfico se encamina a una instancia concreta, patrón que conviene revisar con detenimiento porque envejece mal y suele esconder reglas de salida que nadie recuerda haber creado. En términos de negocio, estas tablas son el inventario de "por dónde sale el tráfico de la empresa", un inventario que aparece en la auditoría de seguridad y que casi nunca está escrito en ningún documento.

Subtema 2: Regiones y zonas: qué son y cómo se eligen

Una region es un área geográfica independiente que agrupa varias zones. Cada región se ubica en una ubicación física concreta, tiene identificador estable del tipo us-central1 o europe-west1, y ofrece un conjunto de servicios soportados con sus propios acuerdos de nivel de servicio. Google publica más de 40 regiones y más de 120 zonas [VERIFICAR: las cifras exactas se actualizan con la expansión de la plataforma; consúltese la página de ubicaciones de Google Cloud], distribuidas en América, Europa, Asia-Pacífico, Oriente Medio y África.

Una zone es un área de despliegue aislada dentro de una región. El aislamiento es real, no lógico: las zonas son agrupaciones de centros de datos con sistemas de energía, refrigeración y red independientes. Cuando se corta la alimentación de una zona, la otra zona de la misma región no se ve afectada, y por eso una aplicación tolerante a fallos se despliega en varias zonas de la misma región. La comunicación entre zonas de una misma región es de alto ancho de banda y baja latencia por diseño, lo que permite replicar bases de datos entre zonas sin penalizar la experiencia.

Las zonas se nombran con el identificador de región seguido de una letra: europe-west1-a, europe-west1-b, europe-west1-c. Las zonas -a, -b y -c son las tres disponibles habitualmente en la mayoría de regiones; Google no garantiza que las tres estén presentes en cada región y algunas regiones tienen número distinto de zonas. Ese detalle importa cuando se diseña un despliegue con tres zonas: hay que comprobar la disponibilidad real antes de comprometer una arquitectura.

La relación entre región y zona puede entenderse como una matriz de compromiso: la región define el alcance geográfico y la residencia de los datos, la zona define el aislamiento de hardware. Multi-zona dentro de una región protege frente a fallos de una instalación concreta. Multi-región protege frente a fallos regionales y permite servir cerca de cada mercado. Son dos cosas distintas y confundirlas lleva a pagar de más o a asumir riesgo de más.

La elección tiene cuatro ejes, y en orden de peso suelen ser: requisitos regulatorios (dónde pueden vivir los datos), proximidad a los usuarios (latencia de la experiencia), disponibilidad de los servicios que la aplicación necesita (no todos los productos están en todas las regiones), y coste (las tarifas de red y de cómputo varían entre regiones y los descuentos por compromiso tienen disponibilidad desigual).

Criterio de selección	Pregunta de negocio	Decisión resultante	Riesgo si se ignora
Residencia de datos	¿En qué países pueden residir los datos personales?	Fijar la región y, con ella, las ubicaciones de buckets y copias de seguridad	Incumplimiento regulatorio y pérdida de confianza del cliente
Proximidad al usuario	¿Dónde están nuestros usuarios principales?	Región cercana, con edge y CDN para el contenido estático	Abandono por lentitud, especialmente en checkout
Disponibilidad de producto	¿El servicio que usamos existe en esa región?	Verificar con `gcloud compute regions describe` y con la matriz de productos	Bloqueo de la migración o reconstrucción en PaaS
Capacidad y tipos de máquina	¿Hay CPU, GPU o TPU disponible donde lo necesitamos?	Filtrar zonas por tipo de máquina antes de comprometer	Sobreaprovisionamiento o esperas de capacidad
Coste de red	¿Cuánto cuesta el egreso desde esa región?	Estimar con etiquetas y presupuestos por región	Sorpresas en la factura de salida de datos
Continuidad	¿Qué hacemos si se cae la región entera?	Réplica en una segunda región, con enrutamiento y failover definidos	RTO de días en vez de horas
Sostenibilidad	¿Hay requisitos de huella de carbono?	Region Picker y datos de intensidad de carbono por región	Incumplimiento de un compromiso ambiental publicado

Temas relacionados: Transformación con tecnología cloud, Modelos de nube y responsabilidad compartida, Controles de red y VPC.

Ejemplo Práctico

El primer paso de cualquier decisión de ubicación es ver la realidad de la plataforma en el proyecto, no lo que dice un diagrama. Todo lo siguiente son comandos reales del gcloud CLI.

Listar las regiones disponibles y su estado:

gcloud compute regions list

La salida tiene columnas NAME, CPUS, DISKS_GB, ADDRESSES, RESERVED_ADDRESSES y STATUS:

NAME              CPUS    DISKS_GB   ADDRESSES   RESERVED_ADDRESSES   STATUS
asia-east1        0/24    0/10240    0/23        0/7                  UP
europe-west1      0/24    0/10240    2/23        0/7                  UP
europe-west2      0/24    0/10240    0/23        0/7                  UP
us-central1       0/24    0/10240    0/23        0/7                  UP

Lectura de negocio: cada fila es una región y las cuatro columnas de recursos son cuota consumida frente a cuota disponible —CPUs, discos, direcciones IP y direcciones reservadas— para ese proyecto en esa región. El STATUS con valor UP indica que la región está operativa. Esta tabla resuelve de inmediato dos preguntas que en las reuniones se respondían con suposiciones: qué regiones están realmente disponibles para ese proyecto, y si alguna de ellas está cerca de agotar la cuota de direcciones IP, que es un límite silencioso que bloquea despliegues por ritmo de crecimiento, no por falta de capacidad de cómputo.

Listar las zonas de una región concreta y ver cuántas hay:

gcloud compute zones list --filter="region:europe-west1"
gcloud compute zones describe europe-west1-b --format="table(name, region, status)"

El describe de una zona devuelve su region, su status y, en la respuesta completa, los límites de recursos de esa zona: maximumPersistentDisks, maximumPersistentDisksSizeGb, maximumAddresses y los límites de CPU. Lectura de negocio: una zona con menos direcciones disponibles que la región no es un problema de diseño de la región sino de cuota consumida; y conocer los límites por zona evita el clásico incidente de despliegue que falla en la zona prevista por haber superado un límite local, y que se resuelve moviendo el tráfico a otra zona en lugar de resolver el problema de fondo.

Para localizar las cargas ya desplegadas y verificar que la infraestructura real coincide con la documentada:

gcloud compute instances list \
  --format="table(name, zone.basename(), machineType.basename(), status, networkInterfaces[0].networkIP)"

La salida indica, para cada instancia, su zona (zone.basename()), su tipo de máquina, su estado y su IP interna. Esta es la tabla que reconcilia arquitectura y realidad: si el documento dice que la aplicación es tolerante a fallos y aquí solo aparece una instancia en una zona, la alta disponibilidad es una intención, no un hecho. Y el inverso también importa: si aparecen instancias en tres zonas distintas, la organización ya tiene resiliencia zonal y su siguiente decisión debe ser la multi-región, no la que se gasta en añadir otra zona en la misma región.

Para el despliegue en curso, el balanceo global y las reglas de reenvío, que son los objetos que materializan el alcance global:

gcloud compute url-maps list --format="table(name, defaultService.basename())"
gcloud compute backend-services list --format="table(name, loadBalancingScheme, backends[0].group.basename())"
gcloud compute forwarding-rules list --format="table(name, region.basename(), IPAddress, IPProtocol, loadBalancingScheme)"
gcloud compute health-checks list --format="table(name, type, checkIntervalSec, timeoutSec)"

Las cuatro consultas, leídas en conjunto, dicen si la aplicación es global o regional: una url-map con backend services en más de una región indica una entrada global con enrutamiento anycast; un forwarding-rule con region informada indica un balanceador regional o interno. Y un health check con checkIntervalSec alto o timeoutSec corto es un hallazgo de resiliencia: el intervalo determina el tiempo de detección de fallo y, por tanto, cuánto tiempo el usuario ve errores tras la caída de una zona. Este detalle es el puente entre infraestructura global y experiencia de negocio.

Subtema 3: Los data centers de Google

Google no alquila centros de datos genéricos: diseña sus propias instalaciones y sus propios servidores. Esa decisión tiene consecuencias directas en lo que un cliente puede prometer a su negocio.

En el diseño de las instalaciones, cada centro de datos se planifica con redundancia en todos los niveles: varias alimentarías, generadores de respaldo que arrancan de forma automática, baterías de reserva que mantienen los servidores en marcha durante el arranque del generador, y sistemas de refrigeración redundantes. La consecuencia práctica es que un fallo de suministro eléctrico no se traduce en una caída del servicio, y que una operación de mantenimiento en una zona no obliga a pausar el negocio. Google opera además con una estrategia de continuidad y recuperación ante desastres que contempla el acceso automático a otro centro de datos ante una disrupción.

En el diseño del hardware, los servidores son purpose-built: placas base, fuentes de alimentación, tren de refrigeración y equipos de red diseñados para el objetivo concreto de Google, no ensamblados a partir de componentes genéricos de servidor. El argumento de negocio es doble. Por un lado, la eficiencia: un diseño propio optimiza la densidad, el consumo y el rendimiento, lo que reduce el coste unitario de cómputo que paga el cliente. Por otro, la seguridad: al diseñar el componente, se evita incluir componentes innecesarios que introduzcan vectores de ataque, y se puede integrar seguridad en el silicio en lugar de añadirla después.

El hardware de seguridad propio es el ejemplo más visible de esa filosofía. El chip Titan es un microcontrolador de bajo consumo que se despliega en servidores, equipos de red y otros periféricos de los centros de datos, y que constituye una raíz de confianza de hardware: verifica de forma criptográfica la integridad del firmware y del arranque de la máquina antes de que esta pueda participar en la carga de trabajo. Si un servidor arranca con software que se desvía del estado esperado, no obtiene las credenciales que necesita y queda fuera de la programación hasta que la infraestructura de gestión lo repare. El mismo principio aparece en las claves de seguridad Titan y en el diseño de acceso físico al centro de datos, donde el hardware permite distinguir un dispositivo legítimo de Google de uno introducido de forma maliciosa.

La lectura de negocio de todo esto es que la seguridad física y de la plataforma es responsabilidad del proveedor —como se discutió en el tema de modelos de servicio— y que el cliente puede dar por cubiertos, con respaldo contractual y técnico, el control físico de acceso, la energía, la refrigeración y la integridad del hardware. Lo que el cliente sigue teniendo que hacer es lo de siempre: los datos, las identidades, la configuración y el uso. El diseño propio del datacenter es, en el fondo, la razón por la que esa frontera es creíble.

Elemento del data center	Qué aporta	Consecuencia para el cliente	Impacto en el coste
Instalaciones de diseño propio	Control del diseño, energía y refrigeración	Alta disponibilidad sostenida sin que el cliente lo opere	Eficiencia operativa que se traduce en precio unitario
Servidores purpose-built	Optimización de rendimiento y consumo	Mayor densidad y mejor rendimiento por vCPU	Menos capacidad pagada por el mismo resultado
Hardware de seguridad propio (Titan)	Raíz de confianza de hardware y arranque verificado	Confianza en la integridad de la plataforma	Sin coste directo para el cliente
Energía y refrigeración redundantes	Continuidad ante fallo y mantenimiento	Los incidentes de instalación no se traducen en caída	Evita pérdida de ingresos por indisponibilidad
Aislamiento físico y lógico entre tenants	Separación de clientes dentro del mismo edificio	Datos de un cliente no expuestos a otro	Requisito previo para sector regulado
Operación de instalaciones por parte de Google	El cliente no necesita personal de centro de datos	Reducción del equipo de operaciones	Menos horas de operación en el TCO

Ejemplo Práctico

El diseño purpose-built del hardware de Google y la operación con mantenimiento continuos se pueden comprobar desde el CLI. No es una inspección física del centro de datos, pero sí es la forma de verificar qué plataformas y qué políticas de mantenimiento aplican a las cargas que el negocio paga.

Ver la plataforma de CPU disponible para un tipo de máquina en una zona concreta:

gcloud compute machine-types describe n2-standard-8 \
  --zone=europe-west1-b \
  --format="table(name, zone.basename(), guestCpus, memoryMb, architecture, deprecated.disclosureTime)"

La respuesta incluye la arquitectura del procesador y, en las versiones más recientes, la plataforma de CPU concreta —por ejemplo, generaciones sucesivas de Intel o las CPU Axion propias de Google—, y la fecha a partir de la cual el tipo de máquina queda marcado como obsoleto. Lectura de negocio: la fecha de obsolescencia es una fecha de renovación que debe estar en el plan de capacidad, porque un tipo de máquina que se retira obliga a migrar la carga antes de que se agote el plazo. Y la plataforma de CPU es un argumento de rendimiento y de coste: dos máquinas con el mismo número de vCPU no rinden igual si el procesador de fondo no es el mismo.

Ver la política de mantenimiento del host y el modelo de aprovisionamiento de una instancia en marcha:

gcloud compute instances describe INSTANCE_NAME \
  --zone=europe-west1-b \
  --format="value(scheduling.onHostMaintenance, scheduling.provisioningModel, status, lastStartTimestamp)"

El campo onHostMaintenance con valor MIGRATE indica que la instancia se migra en caliente cuando el servidor que la hospeda entra en mantenimiento, es decir, sin que la aplicación se detenga. Con valor TERMINATE, el comportamiento por defecto es detener la instancia, lo que se traduce en una interrupción visible para el usuario. Lectura de negocio directa: con TERMINATE, cada ventana de mantenimiento del centro de datos es una ventana de caída del servicio, y esa decisión tiene que estar en el acuerdo de nivel de servicio que se firma con el negocio. Con MIGRATE, el mantenimiento deja de ser un evento de disponibilidad y pasa a ser un evento operativo invisible, y la organización puede comprometer un porcentaje de disponibilidad más alto.

Comprobar los eventos de mantenimiento realmente ejecutados sobre el proyecto:

gcloud compute operations list \
  --filter="operationType=compute.instances.migrateOnHostMaintenance" \
  --limit=20 \
  --format="table(name, zone.basename(), status, creationTimestamp)"

Esta consulta devuelve las migraciones en caliente ejecutadas, con su fecha. Es la evidencia que permite responder a la pregunta que siempre aparece en la revisión de disponibilidad: "¿cuántas veces se ha interrumpido el servicio por mantenimiento de la plataforma en el último trimestre?". Si la lista está vacía, la respuesta es que no hubo interrupciones de ese tipo. Y si hay eventos con estado distinto de DONE, hay migraciones fallidas, lo que es un hallazgo que debe ir al comité de riesgos con su impacto económico estimado.

Subtema 4: La red global: backbone, redundancia, cables submarinos, edge y peering

La red global de Google es lo que convierte un conjunto de centros de datos en una plataforma. Se apoya en cuatro capas que conviene distinguir.

El backbone privado es la red troncal que interconecta las regiones y los centros de datos de Google entre sí, sobre infraestructura de fibra propia. Para un cliente, esto significa que el tráfico entre dos recursos dentro de Google no sale a internet: viaja por la red interna del proveedor. La diferencia no es teórica. Un paquete que sale a internet pierde las garantías del camino del proveedor, atraviesa equipos de terceros y hereda sus políticas; un paquete que viaja por el backbone llega con una ruta conocida, instrumentada y con una latencia más predecible. Por eso las cargas que se comunican entre sí —replicación de base de datos, llamadas entre microservicios, tráfico de datos entre regiones—disfruta de una latencia y una consistencia muy distintas a las de una llamada que sale a internet y vuelve.

La redundancia de rutas es el principio que hace que esa red sea resiliente. Google opera múltiples rutas entre los mismos puntos de destino para que un corte individual —una zanja, un cable, un enlace de un operador— no se convierta en una interrupción. En las aplicaciones globales esto se materializa en dos niveles: el balanceador global, que enruta al origen sano más cercano cuando uno falla, y las réplicas de datos en varias zonas o regiones, que permiten reconstruir el servicio en otro punto. La reducción del riesgo de un solo cable se traduce en el negocio como reducción del riesgo de la aplicación, y por tanto como mayor disponibilidad contractual y menor exposición a ingresos perduidos.

Los cables submarinos conectan los continentes y son el eslabón más difícil de sustituir: reparar un cable en el fondo del océano puede tardar semanas o meses. Google ha combinado inversión en consorcios —Unity, JGA, INDIGO, Havfrue, entre otros— con cables propios como Curie (el primer cable intercontinental privado construido por una empresa no perteneciente a las telecomunicaciones), Dunant, Equiano, Firmina, Grace Hopper, Blue, Raman, Amitié o Sol. Invertir en cables propios no es un capricho: aumenta la capacidad disponible, reduce la dependencia de terceros en las rutas más demandadas y permite diseñar rutas con puntos de aterrizaje más resilientes. Para un cliente de nube, el beneficio es indirecto pero medible en dos términos: menor latencia en rutas intercontinentales frecuentes y mayor probabilidad de que exista una ruta alternativa cuando ocurre un corte.

Los network edge data centers son los puntos de presencia en más de 200 ciudades [VERIFICAR: cifra actualizada por Google; consultar la página de ubicaciones de Google Cloud]. Ahí es donde Google termina la conexión con el ISP del usuario final y donde se aloja la capa de caché de Cloud CDN y la terminación de las direcciones anycast de los balanceadores globales. El efecto para el negocio es que el contenido estático —imágenes, vídeo, JavaScript, CSS— se sirve sin llegar al centro de datos, lo que reduce la latencia percibida, alivia la carga del backend y disminuye el coste de salida de datos.

El peering es el conjunto de acuerdos por los que el tráfico de Google se intercambia directamente con las redes de operadores y proveedores, sin pasar por un tercero que cobra por transportar. La consecuencia para un cliente es que el tramo final del camino, el que va del ISP del usuario al punto de presencia, es más corto y más rápido de lo que sería si el tráfico tuviera que atravesar redes intermedias.

Capa de la red global	Qué resuelve	Herramienta o servicio asociado	Lectura de negocio
Backbone privado	Tráfico interno sin salir a internet	Red de Google, Premium Tier	Menos latencia y más consistencia entre servicios
Rutas redundantes	Tolerancia a cortes individuales	Diseño de red de Google, distribución de carga	Disponibilidad real, no solo contractual
Cables submarinos	Capacidad y latencia intercontinental	Curie, Dunant, Equiano, Firmina, Grace Hopper, Blue, Raman, Amitié, Sol	Menos dependencia de terceros en rutas críticas
Network edge locations	Distancia mínima entre usuario y contenido	Cloud CDN, balanceadores globales anycast	Mejor experiencia y menor carga en el backend
Peering	Entrada directa desde las redes de los ISP	Premium Tier	Menor latencia en el tramo final hacia el usuario
Premium Tier vs Standard Tier	Enrutamiento por la red de Google o por internet público	Premium Tier en Cloud Load Balancing y Cloud CDN	Coste mayor a cambio de rendimiento y rutas garantizadas

Subtema 5: Latencia y ancho de banda: dos cosas distintas, dos costes distintos

El error conceptual más común —y el que más caro sale— es tratar la latencia y el ancho de banda como sinónimos. Son propiedades independientes y cada una responde a un problema distinto.

La latencia es una restricción de la interactividad. Determina cuánto tarda el usuario en ver el efecto de su acción. Se mide en milisegundos y depende de la distancia física, del número de saltos y del trabajo de procesamiento en cada uno. El caso de negocio puro: una sesión interactiva tolera alrededor de 100 ms de ida y vuelta por debajo de la percepción del usuario como inmediata; a partir de unos 200 ms empieza a percibirse la espera; más allá de 1 segundo la aplicación se siente rota aunque el servidor responda correctamente.

El ancho de banda es una restricción de volumen. Determina cuántos datos se pueden mover por segundo. Se mide en megabits o gigabits por segundo y suele ser el límite cuando se transfiere un archivo grande, se replica un dataset o se sirve una descarga masiva.

La aritmética que hay que tener en la cabeza es la siguiente: con un enlace de 100 Mbps y una latencia de ida y vuelta de 200 ms, cada conexión puede tener en vuelo unos 2,5 MB de datos antes de que la primera respuesta llegue. Ese es el motivo por el que una descarga de 100 MB desde un servidor lejano, con una sola conexión, tarda lo mismo que si el ancho de banda fuese diez veces mayor: el cuello de botella no es el ancho de banda, es el tiempo de espera. La solución arquitectónica no es comprar más ancho de banda, sino abrir más conexiones en paralelo, usar un CDN, o acercar el backend al usuario. Saber distinguir ambos problemas es lo que permite gastar el dinero en la parte correcta.

En Google Cloud, la elección de ubicación ataca la latencia y el ancho de banda con herramientas distintas. La región y la zona determinan la distancia al usuario. Cloud CDN y los balanceadores globales atacan la distancia al contenido. Premium Tier mejora el enrutamiento. Y el dimensionamiento de la instancia y del balanceador determina el ancho de banda disponible en el origen. Un diseño correcto usa la combinación: servir el contenido estático desde el edge, dejar el tráfico dinámico en la región más cercana al usuario y dimensionar el backend para el pico, no para la media.

El impacto en el coste es directo y suele ser ignorado en la fase de construcción del caso de negocio. El egreso de datos se factura por gigabyte y su tarifa varía según el destino y la región de origen [VERIFICAR: tarifas exactas en la página de precios de Google Cloud]. Enrutar un tráfico de retorno pesado desde una región lejana al usuario final no solo cuesta más en latencia: cuesta más en egreso. Poner Cloud CDN delante de un bucket reduce el egreso repetido, porque el contenido se sirve desde el edge y el origen solo responde una vez. Ese es un argumento financiero que funciona bien: la misma arquitectura que mejora la experiencia de usuario reduce la factura de red.

Dimensión	Latencia	Ancho de banda
Qué mide	Tiempo de ida y vuelta de un paquete	Volumen de datos por segundo
Qué limita	La interactividad de la aplicación	El volumen y la velocidad de las transferencias
Se mejora con	Región más cercana, edge, CDN, menos saltos	Más capacidad de instancia, más conexiones en paralelo, mejor enrutamiento
Síntoma típico	La interfaz "se queda pensando" con carga correcta	La carga es correcta pero tarda en completarse
Coste asociado	Egreso por repetidas travelled rutas largas	Egreso por gigabytes transferidos
Relación	Multiplicativa con el número de viajes de ida y vuelta	Independiente: más ancho de banda no arregla la latencia

Temas relacionados: Agilidad de negocio e innovación, Estrategia de migración de negocio, Controles de red y VPC.

Ejemplo Práctico

Para elegir la zona y la región hay que medir, no suponer. Los comandos de gcloud no devuelven la latencia entre zonas —esa información no viene en la API—, pero sí permiten acotar el problema con precisión: enumerar candidatas, filtrar por disponibilidad real de recursos y medir después desde una instancia en marcha.

Enumerar las zonas candidatas para una carga que va dirigida al mercado europeo, filtrando solo las que están en servicio:

gcloud compute zones list \
  --filter="region:europe-west1 AND status:UP" \
  --format="table(name, region.basename(), status)"

Comprobar qué tipos de máquina están realmente disponibles en cada zona candidata, antes de comprometer la arquitectura:

gcloud compute machine-types list \
  --filter="zone:europe-west1-b AND name:c3-standard-4" \
  --format="table(name, zone.basename(), guestCpus, memoryMb)"

Estos dos comandos resuelven el error más común de la fase de diseño: asumir que todo tipo de máquina existe en todas las zonas. La disponibilidad de aceleradores y de familias nuevas de CPU es desigual entre zonas, y una arquitectura que promete GPUs en tres zonas puede encontrarse con que solo dos los ofrecen. La comprobación previa convierte un incidente de producción en una línea de un plan de despliegue.

Medir la latencia real desde una instancia existente hacia el público objetivo, que es la única forma fiable de ordenar las candidatas:

gcloud compute instances create latency-probe \
  --zone=europe-west1-b \
  --machine-type=e2-micro \
  --tags=latency-probe

gcloud compute ssh latency-probe --zone=europe-west1-b \
  --command="ping -c 20 es.example.com"

El ping desde la instancia mide el tiempo de ida y vuelta hacia un punto de negocio real, atravesando la red pública y no la red privada. Comparar la misma medición desde instancias en dos regiones candidatas produce una tabla de decisión honesta:

gcloud compute instances list \
  --filter="name:latency-probe" \
  --format="table(name, zone.basename(), networkInterfaces[0].networkIP)"

Y para completar la lectura de coste, el consumo de red por instancia, que es el dato que convierte la decisión de ubicación en una decisión de factura:

gcloud compute instances describe latency-probe \
  --zone=europe-west1-b \
  --format="table(name, zone.basename(), networkInterfaces[0].accessConfigs[0].natIP, status)"

Lectura de negocio del conjunto: la latencia medida desde la región candidata cuantifica la experiencia mínima que el usuario europeo tendrá; un resultado de decenas de milisegundos justifica una arquitectura con backend en europe-west1 y contenido estático en el edge, mientras que un resultado de más de 150 milisegundos indica que la región elegida no sirve y que hay que mover el backend o aceptar un rediseño del frontend. Y el hecho de que el sondeo se haga con una e2-micro de un solo minuto de vida muestra el principio: la decisión de ubicación se toma con una medición barata y reproducible, no con una intuición que alguien defenderá tres años después.

Ejemplo Práctico

Las capas de la red global se materializan en objetos concretos que se pueden listar y describir. Verificarlas es la forma de saber si la aplicación es realmente global o solo está descrita como global.

Describir un backend service global para ver su esquema de balanceo, sus health checks y si tiene CDN:

gcloud compute backend-services describe BACKEND_NAME --global \
  --format="yaml(loadBalancingScheme, healthChecks, backends[].group, enableCDN, cdnPolicy)"

Lectura de negocio: un loadBalancingScheme con valor EXTERNAL_MANAGED indica un balanceador global administrado por Google, que reparte tráfico entre los backends de distintas regiones y enruta al origen sano más cercano al usuario mediante una dirección anycast. Un valor EXTERNAL corresponde a un balanceador regional. La diferencia no es de matiz: el global reparte de forma automática ante la caída de una región, mientras que el regional obliga al cliente a construir la conmutación. El campo enableCDN en true confirma que el contenido estático se sirve desde los puntos de presencia del edge, lo que reduce tanto la latencia percibida como el egreso desde la región de origen. Y la lista de healthChecks es el mecanismo que decide a qué ritmo se detecta un fallo: un health check muy lento multiplica por el mismo factor el tiempo de indisponibilidad tras la caída de una zona.

Ver la dirección global y el nivel de red del punto de entrada:

gcloud compute forwarding-rules describe FORWARDING_RULE --global \
  --format="value(name, IPAddress, loadBalancingScheme, networkTier, portRange)"

gcloud compute addresses list \
  --filter="networkTier=PREMIUM" \
  --format="table(name, address, region.basename(), purpose, usage)"

La dirección global es la que resuelven los usuarios y la que anuncian los puntos de presencia: una única dirección anycast que el usuario alcanza por el camino más corto hacia la red de Google. La columna networkTier con valor PREMIUM indica que el tráfico se enruta por la red global de Google, con el backbone privado y los acuerdos de peering, en lugar de por internet público. Lectura de negocio: la diferencia de coste entre Premium y Standard Tier es real y medible, y se justifica cuando la latencia del tramo final hacia el usuario o la fiabilidad de la ruta son requisitos del contrato de servicio con el cliente final, no cuando se trata de tráfico interno entre microservicios.

Comprobar la conectividad híbrida y el enrutamiento dinámico:

gcloud compute routers list \
  --format="table(name, region.basename(), network, enableBgp, bgp.asn)"

gcloud compute interconnects list \
  --format="table(name, location, networkTier, operationalStatus)"

gcloud compute vpn-tunnels list \
  --format="table(name, region.basename(), status, router)"

La lista de Cloud Routers con enableBgp activo indica que la conexión con la red corporativa se negocia dinámicamente, que es el patrón que permite que las rutas cambien sin intervención manual cuando el centro de datos cambia de estado. Los Dedicated Interconnects son los enlaces físicos con la red de Google, y su operationalStatus es el indicador que hay que vigilar: un enlace en estado degradado reduce la capacidad y puede provocar que el tráfico se desplace al otro camino, con lo que la latencia sube sin que ninguna aplicación falle. En términos de negocio, esta consulta es la que alimenta el informe de riesgo de la conexión con el datacenter principal y justifica, cuando corresponde, una segunda conexión en una ubicación distinta.

Para la distribución global del contenido, la configuración de Cloud CDN y de sus reglas de caché:

gcloud compute backend-services describe BACKEND_NAME --global \
  --format="yaml(cdnPolicy, enableCDN)"

gcloud compute url-maps list \
  --format="table(name, defaultService.basename(), defaultUrlRedirect.hostRule)"

El cdnPolicy muestra el modo de caché —con clave por ruta, por query string o por cabeceras— y el tiempo de vida en caché. Lectura de negocio: una caché mal configurada produce el síntoma clásico de "la aplicación está actualizada para unos usuarios y no para otros", que en un equipo comercial se traduce en pérdida de oportunidades de venta y en un equipo de soporte en incidencias difíciles de reproducir. Revisar la política de caché es, por tanto, una tarea de producto y no solo de plataforma.

Subtema 6: Infraestructura global, residencia de datos y cumplimiento

La última conexión es la que convierte la infraestructura global en un asunto de gobierno. Elegir región es, por encima de todo, decidir dónde están físicamente los datos, y esa decisión tiene consecuencias legales, contractuales y de reputación.

La residencia de datos en Google Cloud se materializa en varios niveles. Los recursos zonales viven en la zona donde se crean. Los recursos regionales, como un balanceador regional o un clúster de Cloud SQL, viven en la región. Los buckets de Cloud Storage pueden tener residencia regional, dual-region o multi-region, y cada modalidad tiene una implicación distinta: una dual-region ofrece mayor resiliencia dentro de un mismo país o área, mientras que una multi-region distribuye los datos entre continents y tiene implicaciones de cumplimiento más amplias. Las réplicas de BigQuery, las copias de Cloud SQL y las snapshots heredan estas políticas según cómo se configuran.

El punto que un Digital Leader debe poder explicar es que la residencia no es solo dónde está el dato en reposo, sino también dónde se procesa y por dónde viaja. Un conjunto de datos almacenado en europe-west1 pero procesado por un job de BigQuery en us-central1 sale de la residencia declarada. Por eso existen controles como VPC Service Controls, que permiten definir perimetros de datos que restringen por dónde puede moverse la información y desde qué identidades se accede a ella, y como Assured Workloads, que ofrece controles de gestión de datos y de acceso que configuran el estándar de un marco regulatorio concreto en entornos dedicados. Google también ofrece en algunos países servicios soberanos, en los que el cliente puede operar con control sobre el acceso del personal del proveedor a la infraestructura [VERIFICAR: países y características exactas de las ofertas soberanas].

El cumplimiento se apoya en un conjunto de certificaciones y marcos —ISO 27001, ISO 27017 e ISO 27018, SOC 1, SOC 2, SOC 3, HIPAA, PCI DSS, FedRAMP en entornos dedicados— y en un centro de cumplimiento donde se puede consultar, por servicio y por región, qué certificaciones aplican [VERIFICAR: cobertura de certificaciones por región y por producto; consultar el Cloud Compliance Center]. La consecuencia de negocio es que no todas las regiones ofrecen el mismo paquete de cumplimiento, y un proyecto que se dirige a un sector regulado debe validar la región antes de comprometerse, no después.

Hay un coste de complejidad asociado que conviene declarar. Distribuir una carga en varias regiones multiplica la superficie de datos que hay que clasificar, los permisos que hay que revisar y los procesos de datos que hay que mantener. La decisión correcta no es "más regiones es mejor", sino "tantas regiones como exijan la latencia, la resiliencia y el cumplimiento, y ni una más". Cada distribución adicional es un multiplicador de coste operativo, de superficie de datos y de esfuerzo de cumplimiento.

Palanca de ubicación	Opciones	Requisito o necesidad que satisface	Consideración de coste
Región	Una región elegida por residencia, latencia y disponibilidad de producto	Localización física de los datos y servicios	La réplica y la conmutación por fallo en una segunda región duplican parte del gasto
Multi-zona dentro de la región	Backend distribuido en dos o tres zonas	Tolerancia a fallo de instalación sin salir del país	Sobrecostes de licencia y de red en la réplica
Dual-region	Bucket con residencia en dos regiones de un área	Resiliencia sin salir del marco regulatorio	Egreso entre zonas de la dual-region
Multi-region	Bucket distribuido entre continentes	Máximo alcance y resiliencia	Egreso intercontinental, el más caro por gigabyte
Premium Tier	Enrutamiento por la red de Google	Latencia y rutas garantizadas	Mayor precio por gigabyte que Standard Tier
Cloud CDN	Caché en el edge	Contenido estático cercano al usuario	Reduce egreso y carga de origen
VPC Service Controls	Perímetro de datos sobre servicios de Google	Prevención de exfiltración y acceso fuera del perímetro	Sin coste directo; coste de configuración y proceso
Assured Workloads	Controles de gestión y acceso sobre un marco	Requisitos regulatorios con controles dedicados	Escenario dedicado: coste unitario mayor
Servicios soberanos	Operación con control sobre el acceso del proveedor	Requisitos de soberanía más estrictos	Disponibilidad limitada a determinadas regiones y controles

Temas relacionados: Estrategia de migración de negocio, Transformación con tecnología cloud, Controles de red y VPC.

Ejemplo Práctico

La residencia de datos se demuestra con un inventario, no con una declaración. Estos comandos permiten construir la evidencia que un auditor pide: dónde está cada tipo de dato y qué copias existen.

Listar los buckets y su ubicación de residencia:

gcloud storage buckets list \
  --format="table(name, location, storageClass, versioningEnabled, retentionPolicy.retentionPeriod)"

La columna location es la declaración de residencia: un bucket en EU se replica dentro de la Unión Europea, un bucket en europe-west1 tiene residencia en esa región y uno en US en Estados Unidos. La columna versioningEnabled y la política de retención importan porque cada versión adicional es una copia más de los datos que hereda la misma residencia. Lectura de negocio: un bucket sin location explícita, o creado con el valor por defecto de la organización, puede tener una residencia que nadie revisó, y ese es el tipo de hallazgo que aparece en una auditoría de protección de datos.

Inventariar todos los recursos del proyecto agrupados por ubicación, para ver dónde vive realmente cada cosa:

gcloud asset search-all-resources \
  --scope="projects/PROJECT_ID" \
  --format="table(assetType, location, name)" \
  --limit=200

Cada fila es un recurso con su location. Los recursos zonales aparecen con la zona, los regionales con la región y los globales sin ubicación, lo que permite construir el mapa de residencia completo: qué recursos son globales, cuáles son regionales y si existe algún recurso en una región que el equipo de cumplimiento no tiene registrada. La revisión de esa tabla antes de cada auditoría es el equivalente a la preparación de un inventario de datos, y su resultado típico es descubrir réplicas, copias de seguridad o logs en ubicaciones que nadie había considerado.

Cruzar la ubicación de los recursos con las etiquetas, que es donde se documenta el propósito de negocio de cada carga:

gcloud compute instances list \
  --filter="labels.environment=production" \
  --format="table(name, zone.basename(), machineType.basename(), labels.application, labels.data_classification)"

gcloud compute disks list \
  --filter="labels.data_classification:public OR labels.data_classification:confidential" \
  --format="table(name, zone.basename(), sizeGb, labels.data_classification)"

Las etiquetas de clasificación de datos son el mecanismo que convierte la residencia en un control operable: permiten generar un informe de "dónde están los datos de cada clasificación", automatizar la verificación de que ningún recurso sensible vive fuera de las regiones permitidas y alimentar la evidencia de cumplimiento. Lectura de negocio: sin etiquetas, la respuesta a "dónde están los datos confidenciales" depende de la memoria de las personas; con etiquetas, la respuesta es una consulta de inventario reproducible, y la diferencia entre ambas es exactamente la diferencia entre una declaración y un control.

Para verificar la cobertura de los productos y de las certificaciones en la región elegida:

gcloud compute regions describe europe-west1 \
  --format="yaml(name, status, zones, quotas)"

gcloud services list --enabled --project="PROJECT_ID" \
  --format="table(name, config.title)"

El describe de la región devuelve sus zonas y sus cuotas, y la lista de APIs habilitadas dice qué servicios están activos realmente en ese proyecto. En conjunto, ambas consultas contestan a las dos preguntas previas al compromiso: dónde se puede desplegar y qué queda realmente en uso. Y una tercera pregunta, que no debe olvidarse: si la región seleccionada no ofrece un producto o una certificación que el negocio necesita, la decisión no se resuelve cuadrando el calendario, se resuelve buscando una región alternativa antes de migrar.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Region	Área geográfica independiente que agrupa varias zonas y define la residencia del dato	Para fijar dónde viven los datos y el marco regulatorio aplicable
Zone	Área de despliegue aislada dentro de una región, con energía y red independientes	Para desplegar componentes tolerantes a fallos de instalación
Multi-zona	Distribución de una carga entre zonas de la misma región	Para alta disponibilidad sin abandonar el país o la región regulatoria
Multi-región	Distribución de una carga entre regiones distintas	Para resiliencia regional y para servir a mercados en continentes diferentes
Global anycast	Anunciado desde múltiples puntos de presencia con una única dirección IP	En la entrada de tráfico global de una aplicación pública
Backbone privado	Red troncal de Google que interconecta regiones sin salir a internet	Para explicar por qué el tráfico interno es más rápido y consistente
Redundancia de rutas	Múltiples caminos disponibles entre los mismos destinos	En el análisis de riesgo de un enlace o de una región
Subsea cable	Cable submarino que transporta tráfico entre continentes	Al evaluar latencia intercontinental y riesgo de corte
Network edge location	Punto de presencia del proveedor cerca de las redes de los ISP	Para servir contenido estático con mínima latencia
Peering	Intercambio directo de tráfico con redes de operadores	Para explicar la calidad del tramo final hacia el usuario
Premium Tier	Enrutamiento del tráfico por la red global de Google	Cuando la latencia y la previsibilidad del camino justifican el coste
Standard Tier	Enrutamiento del tráfico por internet público	Para cargas tolerantes donde prima el coste unitario
Latency	Tiempo de ida y vuelta de un paquete entre dos puntos	Al dimensionar la experiencia interactiva de una aplicación
Bandwidth	Volumen de datos que se puede mover por unidad de tiempo	Al dimensionar transferencias masivas y ancho de banda del origen
Propagación de DNS	Tiempo que tarda un cambio de dirección en reflejarse en las cachés	Al planificar cambios de entrada de tráfico sin interrupciones
IP address	Dirección lógica que identifica un recurso en la red	Para decidir exposición pública o privada de un servicio
ISP	Proveedor de acceso a internet del usuario final	Al analizar por dónde entra el tráfico y qué dependencia existe
DNS	Resolución de nombres a direcciones, con capa pública y capa interna de VPC	Para el diseño de nombres, health checks y conmutación de tráfico
Fiber optics	Transmisión de datos por luz a través de fibra de vidrio	Base física del backbone y de los cables submarinos
Data center purpose-built	Centro de datos e instalación diseñados y construidos por el proveedor	Para explicar la eficiencia y la resiliencia del hardware
Hardware root of trust	Componente de hardware que verifica la integridad del arranque del servidor	Para argumentar la integridad de la plataforma frente a auditorías
Residencia de datos	Ubicación física y lógica donde se almacenan y procesan los datos	En el diseño de cualquier carga con requisitos regulatorios
VPC Service Controls	Perímetro que restringe por dónde y por quién se mueven los datos	Para prevenir exfiltración y proteger datos sensibles
Assured Workloads	Controles de acceso y gestión para un marco regulatorio concreto	Para cargas sujetas a marcos como FedRAMP o marcos regulatorios sectoriales

Comparaciones

Dimensión	Región	Zona	Edge location	Data center
Qué es	Área geográfica con servicios y SLA	Subdivisión aislada de una región	Punto de presencia junto a redes de ISP	Instalación física con energía y refrigeración propias
Unidad de aislamiento	Lógica y geográfica	Física, por equipos y energía	Física, por presencia	Física, por sala y suministro
Qué decide	Residencia del dato, cumplimiento, coste base	Tolerancia a fallo, cercanía al usuario	Latencia del contenido estático	Confianza en la plataforma y resiliencia
Equivalente en on-premises	On-premises: no existe equivalente	On-premises: racks en un edificio	On-premises: no existe	On-premises: sala propia con control de acceso
Ventaja principal	Cumplimiento y alcance global	Alta disponibilidad sin salir de la región	Respuesta en milisegundos cerca del usuario	Eficiencia y seguridad de hardware propias
Coste principal	Tarifas de región y egreso	Sobrecostes de replicación y licencias	Coste de Premium Tier y de caché	Se traslada a la tarifa de consumo
Relación con la redundancia	Multi-región cubre fallo regional	Multi-zona cubre fallo de instalación	El edge absorbe el tráfico estático	El datacenter es la unidad de fallo física
Relación con el coste	Determina la tarifa base	Multiplica la capacidad para alta disponibilidad	Puede reducir el egreso	Optimiza el coste por vCPU
Relación con la latencia	Define la distancia al usuario	Afina la distancia intraregional	Reduce la distancia del contenido estático	No es visible para el usuario final

Errores Comunes

Error: Elegir la región por su descuento de precio o por costumbre, sin mirar la latencia real ni la disponibilidad de los servicios que la aplicación necesita, y descubrir a mitad del proyecto que la familia de máquinas o el servicio elegido no existe en esa región. → Solución: Fijar primero las restricciones no negociables —residencia de datos y requisitos regulatorios— y después validar con gcloud compute regions describe, gcloud compute zones list y gcloud compute machine-types list --filter="zone=..." que todo lo que la arquitectura necesita existe en la ubicación candidata. Medir después con un sondeo desde una instancia en marcha y documentar el resultado como evidencia de la decisión.
Error: Confundir latencia con ancho de banda y resolver un problema de interactividad comprando más capacidad, o resolver un problema de volumen ignorando el tiempo de espera. → Solución: Clasificar el síntoma antes de gastar. Si la interfaz responde tarde con la carga correcta, el problema es de latencia: acercar el backend, servir lo estático en el edge, reducir viajes de ida y vuelta. Si la transferencia tarda en completarse con volumen bajo de CPU, el problema es de ancho de banda o de egreso: dimensionar la instancia, paralelizar conexiones y evaluar la caché. En ambos casos, medir con ping desde una instancia real antes de abrir la compra.
Error: Declarar alta disponibilidad en la documentación y desplegar en una sola zona, o desplegar en varias zonas de la misma región y creer que eso cubre un fallo regional. → Solución: Reconciliar la arquitectura con la realidad mediante gcloud compute instances list --format="table(name, zone.basename(), ...)" y comprobar la dispersión real de las instancias. Multi-zona cubre fallo de una instalación; multi-región cubre fallo regional; son objetivos distintos con requisitos de prueba de conmutación distintos.
Error: Elegir la región por el centro de datos y olvidar que algunos productos no tienen la misma cobertura regional, o que la certificación regulatoria necesaria no está disponible en todas las ubicaciones. → Solución: Validar el producto y el cumplimiento antes de comprometer: comprobar la matriz de productos por región, revisar las certificaciones aplicables en el Cloud Compliance Center para la región concreta y, si el caso lo requiere, considerar entornos dedicados con Assured Workloads o las ofertas soberanas disponibles. La validación de cumplimiento se hace con el área legal y de riesgo, no solo con ingeniería.
Error: Distribuir la carga en muchas regiones "porque el mundo es global", multiplicando coste de datos, superficie de cumplimiento y complejidad operativa, sin un requisito que lo justifique. → Solución: Fijar el número de regiones a partir de tres ejes —latencia aceptable para el mercado, tolerancia al fallo regional requerida y residencia obligatoria— y justificar cada región adicional con un criterio. Usar el edge y la CDN para el alcance geográfico del contenido estático en lugar de multiplicar despliegues de backend, y revisar el gasto de egreso intercontinental, que es la partida más cara y la que más rápido invalida un diseño elegante.

Puntos para el Examen

🎯 Punto clave 1: Región y zona responden a preguntas distintas. La región define la residencia del dato, el marco regulatorio aplicable, la disponibilidad de producto y la tarifa base; la zona define el aislamiento físico y por tanto la tolerancia a fallo de instalación. La respuesta esperada ante un escenario de alta disponibilidad es: multi-zona dentro de una región para alta disponibilidad, multi-región para resiliencia regional, y el naming region-letra como evidencia de que se entiende la jerarquía.

🎯 Punto clave 2: La infraestructura global de Google es fibra y redundancia: un backbone privado que interconecta las regiones, rutas redundantes entre destinos, cables submarinos propios y en consorcio para la conexión intercontinental, más de 200 puntos de presencia en el edge y acuerdos de peering con los ISP. La consecuencia defendible es que la ruta del usuario a la aplicación no es la parte optimizada del sistema, y por eso el edge y la CDN importan tanto como la elección del backend.

🎯 Punto clave 3: Latencia y ancho de banda no son sinónimos. La latencia limita la interactividad y se combate acercando el backend o moviendo el contenido al edge; el ancho de banda limita el volumen y se combate dimensionando capacidad o paralelizando conexiones. Un examinador que plantee "la aplicación va lenta" espera que se distinga entre ambos y que la solución propuesta apunte a la zona de la respuesta, no a comprar más cómputo.

🎯 Punto clave 4: Elegir región es un acto de gobierno, no solo de arquitectura. La residencia del dato se aplica también al procesamiento y al tránsito, no solo al almacenamiento en reposo, y por eso existen VPC Service Controls, Assured Workloads y las ofertas soberanas. La cobertura de certificaciones varía entre regiones y productos, y validarla antes de comprometer es parte del trabajo de un Digital Leader.

🎯 Punto clave 5: El conocimiento verificable es el que sale de la consola. gcloud compute regions list y gcloud compute zones list dan la topología disponible y las cuotas consumidas; gcloud compute zones describe da los límites por zona; gcloud compute instances list reconcilia la arquitectura documentada con la desplegada; gcloud compute forwarding-rules list y gcloud compute backend-services list dicen si la entrada de tráfico es global o regional. Saber leer esa salida y traducirla a disponibilidad, latencia y coste es exactamente lo que se evalúa.

Recursos Externos

Ubicaciones globales de Google Cloud: regiones y zonas — Inventario actualizado de regiones, zonas, ubicaciones de edge y disponibilidad de productos por región.
Regions and zones de Compute Engine — Definición de región y zona, reglas de nomenclatura, recursos globales, regionales y zonales.
View available regions and zones — Referencia de los comandos gcloud compute regions list y gcloud compute zones list, con ejemplos de salida.
Google infrastructure security design overview — Diseño propio de centros de datos, servidores, hardware de seguridad y raíz de confianza de hardware.
Titan hardware chip — Documentación del chip de raíz de confianza en hardware y su papel en el arranque verificado.
VPC Service Controls — Perímetros de datos para proteger la información frente a exfiltración y accesos no autorizados.
Precios de red de Google Cloud — Tarifas de egreso y condiciones de Premium Tier y Standard Tier.

Autoevaluación Rápida

Pregunta: Una empresa europea con clientes en España, Francia y Alemania necesita una aplicación web de alto tráfico, y su auditor exige que los datos personales no salgan de la Unión Europea. ¿Qué decisiones de infraestructura global hay que tomar y con qué argumentos se defienden? Respuesta: Hay que decidir región y, dentro de ella, zona. La región debe estar en la Unión Europea —europe-west1, europe-west2, europe-west3, europe-west4, europe-west6, europe-west8 o europe-west9 son las candidatas europeas disponibles— porque es lo que da soporte a la exigencia de residencia y a las certificaciones europeas. Dentro de ella, la carga debe desplegarse en varias zonas para que un fallo de instalación no elimine el servicio, y conviene validar con gcloud compute zones list que las tres zonas están disponibles. El contenido estático debería servirse con Cloud CDN desde el edge, lo que mejora la latencia percibida sin mover datos fuera del perímetro. Y hay que comprobar que los productos que la aplicación usa están disponibles en esa región, porque no todos lo están, y que los buckets, las réplicas y las copias de seguridad heredan la misma residencia. La defensa ante el auditor es un documento que declare región, zona, productos, certificaciones aplicables y mecanismo de failover.
Pregunta: El equipo de producto se queja de que "la web va lenta" en usuarios de Latinoamérica, pero los datos están correctamente alojados en us-central1. Explique el razonamiento técnico y las opciones, con sus costes. Respuesta: El síntoma es compatible con latencia, no necesariamente con falta de cómputo, y hay que medirlo antes de comprar capacidad. Si el backend está en us-central1, la distancia entre el usuario y la aplicación impone una latencia de ida y vuelta mínima, del orden de cien o más milisegundos [VERIFICAR: valor real según ruta y ISP], y por encima de unos 200 ms la interacción se percibe como lenta. La primera opción de bajo coste es la CDN y el edge para todo lo estático, que saca la mayor parte del tráfico de la ruta larga sin mover datos de negocio. La segunda es un backend en una región latinoamericana, que resuelve la latencia pero crea el problema de duplicar los datos fuera de la residencia que ya se declaró, y por tanto un coste de egreso intercontinental y una obligación de cumplir también en esa región. La tercera, si el problema es en realidad volumen, es dimensionar capacidad o el balanceador, sin tocar la ubicación. La clave del razonamiento es separar latencia de ancho de banda antes de gastar.
Pregunta: Un arquitecto afirma que "Google Cloud tiene más de 40 regiones, así que podemos distribuir la aplicación y ser resilientes sin problema adicional". ¿Qué le corregiría usted? Respuesta: Que el número de regiones disponibles no es un argumento de diseño. Hay cuatro correcciones. Primera: la resiliencia no se obtiene por tener más regiones, sino por tener una estrategia de conmutación definida y probada; una segunda región sin un mecanismo de failover es un coste duplicado, no una mejora de disponibilidad. Segunda: distribuir más aumenta el coste de egreso, el de licencias y el de operación, y cada distribución adicional multiplica la superficie de datos que hay que clasificar y los permisos que hay que revisar. Tercera: no todas las regiones ofrecen todos los productos ni las mismas certificaciones, de modo que el número de candidatas reales es menor que el número de regiones de la plataforma; conviene verificarlo con gcloud compute regions describe y con el catálogo de productos por región. Cuarta: el examen de resiliencia debe hacerse con una zona caída o una región caída, no con un diagrama. La respuesta defendible es "tantas regiones como exijan la latencia, la tolerancia al fallo y el cumplimiento, y cada una justificada".
Pregunta: ¿Por qué el cable submarino no puede tratarse como un detalle de la infraestructura de Google, y qué implicaciones tiene para un cliente que opera en dos continentes? Respuesta: Porque es el componente con la tasa de reparación más lenta de toda la infraestructura: un corte en un cable en el fondo del océano puede tardar semanas o meses en resolverse, y afecta a rutas completas, no a un servicio individual. Google mitiga el riesgo con redundancia de rutas y con inversión en cables propios, como Curie, Dunant, Equiano, Firmina, Grace Hopper, Blue, Raman, Amitié o Sol, además de su participación en consorcios como Unity, JGA, INDIGO y Havfrue. Para un cliente que opera en dos continentes, la implicación práctica es que el diseño no puede asumir una sola ruta: la aplicación debe funcionar si el tráfico entre regiones se degrada, los datos deben tener copias en más de un punto y la conmutación debe estar probada. La consecuencia de negocio es que el incidente de infraestructura más caro no es la caída de una zona, sino la pérdida de una ruta intercontinental completa sin plan de contingencia, y por eso esa contingencia es un entregable del diseño, no un extra.
Pregunta: Explique la diferencia entre red lógica dentro de una VPC y red física de Google, y por qué esa diferencia importa en la frontera de responsabilidad del cliente. Respuesta: La red física —fibra, centros de datos, hardware de red, energía, aislamiento entre tenants, raíz de confianza en el hardware— es responsabilidad de Google y viene cubierta por los acuerdos de nivel de servicio. La red lógica dentro de una VPC —subredes, reglas de firewall, rutas, balanceo privado, NAT, políticas de rutas, VPC Service Controls, permisos de acceso a red— es responsabilidad del cliente, incluso cuando la aplicación corre en PaaS. La diferencia importa porque define dónde se concentra el esfuerzo del cliente: en el modelo de responsabilidad compartida, esa frontera es el mapa de trabajo del equipo. Concretamente, una regla de firewall mal definida en una subred de una VPC de una aplicación en Cloud Run es un incidente del cliente, y lo mismo ocurre con un peering hacia una red corporativa mal planificado. La consecuencia organizativa es que un equipo que migra a PaaS debe reasignar horas que antes dedicaba a la red física hacia la red lógica y hacia los controles perimetrales, porque esa carga no desaparece: cambia de naturaleza.