Se usó la API de Cloud Translation para traducir esta página.

Geografía y regiones

Los productos de Google Cloud se entregan desde dominios con fallas regional específicos y son totalmente compatibles con los Acuerdos de Nivel de Servicio 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.

Pruébalo tú mismo

Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

Comenzar gratis

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. Una región consta de tres o más zonas almacenadas en tres o más centros de datos físicos. Las regiones México, Osaka y Montreal tienen tres zonas alojadas en uno o dos centros de datos físicos. Estas regiones están en proceso de expansión a, al menos, tres centros de datos físicos. Cuando diseñes tus soluciones en Google Cloud, ten en cuenta la orientación que se proporciona en Ubicaciones de Cloud, los ANS de Google Cloud Platform y la documentación del producto de Google Cloud adecuada.

Es posible que estos centros de datos sean propiedad de Google y que aparezcan en la página de ubicaciones de Google Cloud 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. 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 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.

Los servicios y recursos de Google Cloud pueden estar administrados por Google en varias regiones o bien ser zonales o regionales. 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.

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.

Recursos zonales

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. Esto les permite tener una disponibilidad más alta en comparación con los recursos zonales.

Recursos multirregionales

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 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 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. 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 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

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, 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 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
- 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, 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)

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.

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, incluidos los términos específicos del servicio. Google comprende que cada cliente puede tener necesidades de seguridad y cumplimiento únicas. El equipo de ventas de Google Cloud 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, como aplicaciones de App Engine, grupos de instancias regionales administrados o recursos multirregionales administrados, 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.

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.

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

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

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.