21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Geografía y regiones
Los productos de Google Cloud se entregan desde dominios con fallas regional específicos
(https://cloud.google.com/about/locations?hl=es-419) y son totalmente compatibles con los
Acuerdos de Nivel de Servicio (https://cloud.google.com/terms/sla?hl=es-419) para garantizar que
diseñes la arquitectura de tu aplicación en la estructura de Google Cloud.

Los servicios de infraestructura de Google Cloud están disponibles en diferentes ubicaciones

de América del Norte, América del Sur, Europa, Asia, Oriente Medio y Australia. Estas
ubicaciones se dividen en regiones y zonas. Para satisfacer los requisitos de latencia,
disponibilidad y durabilidad, puede elegir la ubicación de las aplicaciones.

Regiones y zonas
Las regiones son áreas geográficas independientes que constan de zonas. Las zonas y las
regiones son abstracciones lógicas de los recursos físicos subyacentes que se proporcionan
en uno o más centros de datos físicos. Es posible que estos centros de datos sean propiedad
de Google y que aparezcan en la página de ubicaciones de Google Cloud
(https://cloud.google.com/about/locations?hl=es-419) o que puedan alquilarse a proveedores de
centros de datos externos. Para obtener la lista completa de las ubicaciones de los centros de
datos de Google Cloud, consulta nuestro certificado ISO/IEC 27001
(https://cloud.google.com/security/compliance/iso-27001?hl=es-419). Google Cloud selecciona los
centros de datos y diseña su infraestructura para proporcionar un nivel uniforme de
rendimiento, seguridad y confiabilidad, sin importar si el centro de datos es propio o alquilado.

Una zona es un área de implementación para los recursos de Google Cloud dentro de una
región. Las zonas se deben considerar como dominios con fallas únicos dentro de una región.
Para implementar aplicaciones tolerantes a errores con alta disponibilidad y ayudar a proteger
contra fallas inesperadas, implementa las aplicaciones en varias zonas de una región.

Para protegerte contra la pérdida de una región entera debido a un desastre natural, debes
tener un plan de recuperación ante desastres y saber cómo abrir la aplicación en el caso de
que se pierda la región principal. Consulta las consideraciones para implementar una
aplicación (#application_deployment_considerations) a fin de obtener más información.

Si deseas obtener más información acerca de los recursos específicos disponibles dentro de
cada opción de ubicación, consulta nuestras ubicaciones de Cloud

https://cloud.google.com/docs/geography-and-regions?hl=es-419 1/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

(https://cloud.google.com/about/locations?hl=es-419).

Los servicios y recursos de Google Cloud pueden estar administrados por Google en varias
regiones (#multiregional_resources) o bien ser zonales (#zonal_resources) o regionales
(#regional_resources). Si quieres obtener más información sobre lo que implican estas opciones
para los datos, consulta la administración geográfica de los datos
(#geographic_management_of_data).

Google Cloud pretende ofrecer un mínimo de tres zonas de disponibilidad (zonas distintas de
manera física y lógica) en cada región de uso general.

Documentos sobre las ubicaciones relacionados

Zonas y regiones de Compute Engine

(https://cloud.google.com/compute/docs/regions-zones?hl=es-419)

Ubicaciones de los buckets de Cloud Storage

(https://cloud.google.com/storage/docs/bucket-locations?hl=es-419)

Ubicaciones de App Engine

(https://cloud.google.com/appengine/docs/locations?hl=es-419)

Los recursos zonales operan dentro de una sola zona. Las interrupciones zonales pueden
afectar a algunos o a todos los recursos de esa zona. Un ejemplo de un recurso zonal es una
instancia de máquina virtual (VM) de Compute Engine que reside dentro de una zona
específica.

Recursos regionales
Los recursos regionales son recursos que se implementan de manera redundante en varias
zonas dentro de una región, por ejemplo, las aplicaciones de App Engine o los grupos de
instancias regionales administrados
(https://cloud.google.com/compute/docs/instance-groups?hl=es-
419#types_of_managed_instance_groups)
. Esto les permite tener una disponibilidad más alta en comparación con los recursos zonales.

Recursos multirregionales

https://cloud.google.com/docs/geography-and-regions?hl=es-419 2/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Google administra varios servicios de Google Cloud para que sean redundantes y se
distribuyan dentro de las regiones y entre ellas. Estos servicios permiten optimizar la
disponibilidad, el rendimiento y la eficiencia de los recursos. Como resultado, estos servicios
requieren una compensación entre la latencia o el modelo de coherencia. Y se documentan
específicamente para cada producto.

Los siguientes servicios tienen una o más ubicaciones multirregionales

(https://cloud.google.com/about/locations?hl=es-419#multi-region) además de las ubicaciones
regionales:

Artifact Registry

Bigtable

Protección de datos sensibles

API de Cloud Healthcare

Cloud KMS

Container Registry

Spanner

Cloud Storage

Database Migration Service

Datastore

Firestore

Estos servicios multirregión están diseñados para poder funcionar después de la pérdida de
una sola región.

Para obtener más información, consulta Productos disponibles por ubicación

(https://cloud.google.com/about/locations?hl=es-419#products-available-by-location) y la
documentación de cada producto.

Servicios globales
Google Cloud se diseñó para operar a nivel global desde cero y realizar mantenimiento y
actualizaciones de forma continua las 24 horas, todos los días del año, sin interrumpirte.

https://cloud.google.com/docs/geography-and-regions?hl=es-419 3/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Nuestra red troncal global proporciona flexibilidad enorme para el balanceo de cargas y reduce
la latencia del usuario final mediante interconexiones cercanas. Nuestro plano de
administración de la nube global simplifica la administración de desarrollos multirregionales.

Servicios internos
Los servicios de Google Cloud que respaldan y respaldan a muchos de ellos son un conjunto
de servicios internos comprobados, como Spanner, Colossus, Borg y Chubby.

Estos servicios internos tienen balanceo de cargas global en varias regiones o están
dedicados a cada región en la que están disponibles. Cuando los servicios tienen balanceo de
cargas en varias regiones, implementamos actualizaciones de forma progresiva por región, lo
que nos permite detectar y abordar problemas sin afectar tu uso de los servicios. Ninguno de
estos servicios internos está limitado a un único centro de datos lógico o a una sola región.

Los servicios internos globales se pueden ejecutar o replicar en las siguientes regiones
(https://cloud.google.com/compute/docs/regions-zones?hl=es-419#available) de la nube:

América

southamerica-west1

us-central1

us-east1

us-east4

us-west1

us-west4

Europa

europe-north1

europe-west1

europe-west4

Asia

https://cloud.google.com/docs/geography-and-regions?hl=es-419 4/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

asia-east1

asia-southeast1

Dependencias de servicios
En general, para los servicios de Google Cloud, si una sola región falla, solo los clientes de esa
región se ven afectados. Los clientes que tienen productos multirregionales no se ven
afectados. Google Cloud tiene una arquitectura significativa con el objetivo de evitar fallas
correlacionadas en todas las regiones.

Todos los servicios de Google Cloud se basan en herramientas internas principales para
proporcionar servicios fundamentales, como herramientas de redes (dentro y fuera de los
centros de datos), acceso a centros de datos y sistemas de autorización de identidad. Estas
herramientas son resistentes a las interrupciones regionales con el objetivo de que una región
no se vea afectada si otras regiones no están disponibles.

Google Cloud proporciona instrucciones claras sobre cómo los clientes pueden diseñar sus
aplicaciones para el nivel deseado de resiliencia en nuestrositio web público
(https://cloud.google.com/solutions/disaster-recovery/architecture?hl=es-419#common_themes), en
especial para productos de Google Cloud más utilizados, como Compute Engine, BigQuery,
Pub/Sub y otros servicios.

Nuestras dependencias principales se enumeran a continuación, comenzando con

dependencias comunes a todos los servicios, con la condición de que los detalles de la
implementación de nivel inferior estén sujetos a cambios.

Dependencias comunes para todos los servicios

Plano de datos de identidad para la autenticación y la autorización

Servicios internos que proporcionan registros, almacenamiento de metadatos y

administración de flujos de trabajo

El acceso a las API de Google Cloud depende de los balanceadores de cargas de DNS
distribuidos en todo el mundo y de los puntos de presencia (PoP).

La configuración de los recursos globales: por ejemplo, las políticas de IAM, las reglas de
firewall globales, las configuraciones globales del balanceador de cargas y los temas de

https://cloud.google.com/docs/geography-and-regions?hl=es-419 5/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Pub/Sub se almacenan en bases de datos replicadas.

Cuando los servicios de Google Cloud realizan solicitudes a extremos controlados por el
cliente, por ejemplo, Cloud EKM recupera las claves del cliente o Pub/Sub envía
mensajes, esas solicitudes dependen de nuestra infraestructura de red global para
acceder a esos extremos de cleintes controlados.

Servicios con dependencias adicionales

Servicios de Compute Engine

Los planos de datos de VM de Google Cloud y de Persistent Disk dependen de los

servicios de Compute Engine y Cloud Storage de nivel inferior, como Borg y
Colossus.

Los servicios de almacenamiento de infraestructura y Google Cloud, como Spanner,

Bigtable y Cloud Storage dependen de lo siguiente:

Infraestructura de encriptación y administración de claves para el cliente (Cloud

KMS/Cloud EKM) e infraestructura interna para claves de Google

Servicios internos para proporcionar registros y auditorías de acceso a los datos

Servicios de replicación de datos internos, en los que se espera que los datos estén
disponibles en varias regiones

Las copias de seguridad y la replicación configuradas de manera explícita en otras

regiones dependen de las redes entre regiones

Servicios de mensajes

Pub/Sub depende de nuestra infraestructura de red global para acceder a los

extremos controlados por el cliente

Servicios de Herramientas de redes

El balanceo de cargas global, el DNS y la conmutación por error entre regiones

dependen de la infraestructura de red física.

La prevención de ataques de DSD, entre otros, depende de la infraestructura de

nivel inferior de Compute Engine.

Servicios administrados y alojados, como GKE y Cloud SQL

https://cloud.google.com/docs/geography-and-regions?hl=es-419 6/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Depende de Compute Engine y Container Registry o Artifact Registry para las

imágenes de VM.

Infraestructura de nivel inferior autónoma

Nuestro plano de control interno del clúster, incluido Borg y las estructuras de red

Almacenamiento a nivel de clúster, como Colossus

Infraestructura de encriptación y administración de claves

Mantén y mejora la disponibilidad y la resiliencia

La ingeniería de confiabilidad de sitios (SRE) es la organización interna de Google dedicada a
trabajar en la disponibilidad, la latencia, el rendimiento y la capacidad. Las interrupciones y la
falta de disponibilidad del servicio se correlacionan con la implementación de código nuevo o
cambios en el entorno. Mediante las prácticas recomendadas de la industria, SRE equilibra la
necesidad de lanzar software nuevo y mantiene el entorno seguro con la comprensión de que
esos cambios necesarios pueden causar tiempo de inactividad.

Asóciate con clientes para desarrollar servicios resilientes

Si tienes necesidades esenciales y necesitas diseñar para la resiliencia y la recuperación ante
desastres (https://cloud.google.com/architecture/disaster-recovery?hl=es-419), nuestros equipos de
SRE/CRE y PSO pueden trabajar contigo a fin de diseñar tus aplicaciones para que se conecten
varias regiones y zonas, y te pueden ayudar aún más a diseñar sistemas de alta disponibilidad
(HA).

Si aumentas los requisitos de disponibilidad en fechas específicas, como el Black Friday o el

Cyber Monday, Google Cloud tiene un programa que te permitirá asociarte con el fin de
verificar y validar tu aplicación específica que se ejecuta en Google Cloud y que identifica las
dependencias de servicio inesperadas entre tu aplicación y nuestros servicios.

Puntos de presencia (POP)

https://cloud.google.com/docs/geography-and-regions?hl=es-419 7/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Google opera una red global de puntos de presencia de intercambio de tráfico, lo que significa
que el tráfico del cliente puede viajar dentro de la red de Google hasta que se encuentre cerca
de su destino, lo que brinda una mejor experiencia y seguridad a los usuarios. Para obtener
más información, consulta Ubicaciones de la red perimetral
(https://cloud.google.com/vpc/docs/edge-locations?hl=es-419).

Administración geográfica de los datos

La ubicación de los datos de los servicios de Google Cloud se rige por las Condiciones del
Servicio (https://cloud.google.com/terms?hl=es-419), incluidos los términos específicos del servicio
(https://cloud.google.com/terms/service-terms?hl=es-419). Google comprende que cada cliente
puede tener necesidades de seguridad y cumplimiento únicas. El equipo de ventas de
Google Cloud (https://cloud.google.com/contact?hl=es-419) puede ayudarte a satisfacer tus
requisitos.

Cuando uses recursos de almacenamiento regionales o zonales, te recomendamos que

repliques los datos en otra región o guardes instantáneas en un recurso de almacenamiento
multirregional para la recuperación ante desastres.

Consideraciones para implementar aplicaciones

Puedes compilar servicios y aplicaciones con alta disponibilidad capaces de resistir las fallas
de las zonas.

Para ello, usa los siguientes recursos:

Recursos regionales (#regional_resources), como aplicaciones de App Engine, grupos

de instancias regionales administrados
(https://cloud.google.com/compute/docs/instance-groups?hl=es-
419#managed_instance_groups)
o recursos multirregionales administrados (#multiregional_resources), como
Cloud Storage, Datastore, Firestore o Spanner.

Recursos zonales, como las máquinas virtuales de Compute Engine, pero debes
administrar la redundancia del procesamiento y almacenamiento entre las zonas o
las regiones.

https://cloud.google.com/docs/geography-and-regions?hl=es-419 8/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Puedes compilar aplicaciones preparadas para la recuperación ante desastres y que puedan
resistir la pérdida prolongada de regiones completas.

Para los datos, usa una o más de las siguientes estrategias:

Usa servicios de almacenamiento multirregionales administrados, como

Cloud Storage, Datastore, Firestore o Spanner.

Usa recursos zonales o regionales, pero guarda instantáneas de los datos en

recursos multirregionales, como Cloud Storage, Datastore, Firestore o Spanner.

Usa recursos regionales o zonales, pero administra la replicación de tus datos en

una o más regiones adicionales.

Para el procesamiento, usa la siguiente estrategia:

Usa recursos zonales o regionales, como Compute Engine o App Engine, pero
activa la aplicación, de forma manual o automática, en otra región (en caso de
fallas regionales) mediante referencias a copias de los datos principales, si es que
estos no se encuentran en un recurso multirregional administrado.

Para obtener más información sobre las dependencias del servicio, comunícate con Ventas
(https://cloud.google.com/contact/?hl=es-419).

Instructivos y soluciones adicionales

Los siguientes instructivos y soluciones sirven de guía para garantizar que tu aplicación pueda
resistir las fallas y ofrecer alta disponibilidad:

Patrones de apps escalables y resilientes

(https://cloud.google.com/solutions/scalable-and-resilient-apps?hl=es-419)

Aprende a usar Google Cloud para compilar arquitecturas de aplicaciones escalables y

resilientes mediante patrones y prácticas que se suelen usar en cualquier aplicación web.

Crea un balanceador de cargas de HTTPS

(https://cloud.google.com/load-balancing/docs/https/cross-region-example?hl=es-419)

https://cloud.google.com/docs/geography-and-regions?hl=es-419 9/10
21/4/24, 03:31 Geografía y regiones | Documentación | Google Cloud

Configura las instancias de Compute Engine en regiones distintas y usa el balanceo de cargas
de HTTP para distribuir el tráfico entre regiones y aumentar la disponibilidad entre estas,
además de brindar conmutación por error en caso de que falle un servicio.

Diseña sistemas sólidos (https://cloud.google.com/compute/docs/tutorials/robustsystems?hl=es-419)

Diseña la aplicación en el servicio de Compute Engine para que pueda resistir fallas,
interrupciones de red y desastres inesperados.

Copia de seguridad y restablecimiento de Cassandra con Cloud Storage

(https://github.com/GoogleCloudPlatform/cassandra-cloud-backup)

Obtén información para agregar la recuperación ante desastres básica a la instalación de

Cassandra mediante la creación de una copia de seguridad de los datos y su restablecimiento
desde Cloud Storage.

Guía de planificación para la recuperación ante desastres

(https://cloud.google.com/architecture/dr-scenarios-planning-guide?hl=es-419)

Principios generales para diseñar y probar un plan de recuperación ante desastres con
Google Cloud.

Salvo que se indique lo contrario, el contenido de esta página está sujeto a la licencia Atribución 4.0 de
Creative Commons (https://creativecommons.org/licenses/by/4.0/), y los ejemplos de código están sujetos a la
licencia Apache 2.0 (https://www.apache.org/licenses/LICENSE-2.0). Para obtener más información, consulta
las políticas del sitio de Google Developers (https://developers.google.com/site-policies?hl=es-419). Java es
una marca registrada de Oracle o sus afiliados.

Última actualización: 2024-03-15 (UTC)

https://cloud.google.com/docs/geography-and-regions?hl=es-419 10/10