Compartir a través de

Selección de regiones de Azure

  • Artículo

Al diseñar la estrategia para usar Microsoft Azure, puede elegir entre muchas regiones de Azure de todo el mundo. La selección de la región es una parte clave de la estrategia general de adopción de la nube. Cada región de Azure tiene características específicas, por lo que es esencial elegir las mejores regiones para los recursos de Azure.

Descripción de las arquitecturas y la resistencia de la región de Azure

Las distintas regiones de Azure tienen características diferentes. Dos formas comunes de que las regiones de Azure varían implican zonas de disponibilidad y regiones emparejadas. Además, algunas regiones están operadas por entidades soberanas en determinados países. La arquitectura de la región hace referencia a cómo se diseña una región específica y a las funcionalidades regionales generales que proporciona.

Para más información sobre cómo funcionan las regiones de Azure, consulte ¿Qué son las regiones de Azure y las zonas de disponibilidad?.

Zonas de disponibilidad

Muchas regiones de Azure incluyen zonas de disponibilidad, que son ubicaciones físicamente independientes dentro de una región. Mediante el uso de zonas de disponibilidad, puede lograr una mayor disponibilidad y resistencia en las implementaciones. Para obtener más información sobre las zonas de disponibilidad, consulte Compatibilidad con el servicio de zona de disponibilidad y Compatibilidad con regiones de zona de disponibilidad.

Regiones emparejadas

Algunas regiones se emparejan con otra región, con ambas regiones ubicadas normalmente en la misma área geopolítica. El emparejamiento de regiones proporciona resistencia durante errores catastróficos en la región. El emparejamiento de regiones se usa principalmente para el almacenamiento con redundancia geográfica (GRS) y otros servicios de Azure que dependen de Azure Storage para la replicación.

Las regiones más recientes no están emparejadas. En su lugar, usan zonas de disponibilidad para lograr alta disponibilidad y resistencia. Más adelante en este artículo, obtendrá más información sobre cómo usar estos tipos de región.

Sugerencia

Para obtener información sobre cómo diseñar una carga de trabajo que use regiones y zonas de disponibilidad, consulte Recomendaciones para usar zonas de disponibilidad y regiones.

Regiones soberanas

Algunas regiones están dedicadas a entidades soberanas concretas. Aunque todas las regiones son regiones de Azure, estas regiones soberanas están aisladas del resto de Azure. Microsoft no los administra necesariamente y se pueden restringir a determinados tipos de clientes. Estas regiones soberanas son Azure China 21Vianet y Azure Government - EE. UU. Las regiones soberanas se crean en los mismos estándares de resistencia que otras regiones de Azure.

Considere la disponibilidad y la capacidad del servicio de la región

Azure ofrece dos tipos de regiones:

  • Las regiones recomendadas son adecuadas para la mayoría de las cargas de trabajo.
  • Las regiones alternativas no están optimizadas para cargas de trabajo principales. En su lugar, las regiones alternativas solo están disponibles para la copia de seguridad o la conmutación por error, o solo para los clientes con presencia de empresa dentro de un país o región definido.

Al decidir qué región usar, es una buena idea seleccionar una región recomendada si es posible, debido a las siguientes ventajas:

  • Las regiones recomendadas suelen tener una mayor capacidad. Debido a la mayor capacidad, las regiones recomendadas a menudo pueden respaldar el crecimiento a largo plazo mejor que las regiones alternativas.
  • Menor costo. Muchas regiones recomendadas ofrecen costos más bajos para una gama de servicios de Azure. Mediante el uso de regiones recomendadas, puede reducir el importe de la factura general de Azure.
  • Obtenga acceso anticipado a las ofertas más recientes. Por ejemplo, las funcionalidades de inteligencia artificial y los recursos de GPU suelen estar disponibles en regiones recomendadas antes que en otras regiones. 

Microsoft vuelve a evaluar periódicamente las regiones que se recomiendan. Para aprovechar las ventajas de las regiones recién recomendadas, considere la posibilidad de adoptar una estrategia de varias regiones. Esta estrategia ayuda a garantizar que esté listo para usar más regiones para sus propias cargas de trabajo.

Los servicios que puede implementar en una región dependen del tipo de la región, entre otros factores. Para obtener más información, consulte los siguientes recursos:

Algunas regiones están reservadas para los clientes que necesitan recuperación ante desastres dentro de su país o región. Para solicitar acceso a estas regiones de acceso reservadas, cree una nueva solicitudde soporte técnico.

Azure es una plataforma escalable de forma masiva, pero cada región tiene una capacidad máxima. La capacidad máxima de una región puede influir en qué tipos de suscripciones pueden implementar qué tipos de servicios y en qué circunstancias. La capacidad regional es diferente de una cuota de suscripción. Si va a planear una implementación o migración a Azure, es recomendable hablar con el equipo de campo local de Azure o con el administrador de cuentas de Azure. Pida confirmación de que puede implementar a la escala que necesita.

Cuando use regiones con fines de recuperación ante desastres, considere si la región de destino proporciona la capacidad que necesita para admitir las cargas de trabajo. En el caso de las cargas de trabajo basadas en máquinas virtuales (VM), considere la posibilidad de usar reservas de capacidad para garantizar la disponibilidad de la capacidad en las regiones que use.

Descripción de la residencia de datos

En todo el mundo, las organizaciones gubernamentales han empezado a establecer la soberanía de los datos y las regulaciones de privacidad de los datos. Estos tipos de requisitos de cumplimiento suelen requerir la localización en un país o región específicos para proteger a los ciudadanos que residen en esa ubicación. En algunos casos, los datos que pertenecen a clientes, empleados o asociados se deben almacenar en una plataforma en la nube en la misma región que el usuario.

Asegúrese de que comprende sus propios requisitos de residencia de datos. Además, compruebe que las regiones de Azure que seleccione estén en ubicaciones geográficas que cumplan sus requisitos. Para obtener más información, consulte Habilitar la residencia de datos y la protección de datos en las regiones de Microsoft Azure.

Abordar los desafíos de residencia de datos es una motivación significativa para las organizaciones que operan a escala global para migrar a la nube. Para mantener el cumplimiento con la soberanía de datos, algunas organizaciones han optado por implementar recursos de TI duplicados en los proveedores de nube de la región.

Microsoft Cloud for Sovereignty es una solución que permite a los gobiernos implementar cargas de trabajo en Microsoft Cloud a la vez que ayudan a satisfacer sus requisitos específicos de soberanía, cumplimiento, seguridad y directivas. Microsoft Cloud for Sovereignty crea límites de software en la nube para establecer la protección adicional que requieren los gobiernos, mediante controles de cifrado y confidencialidad basados en hardware. Para obtener más información, consulte Funcionalidades de Microsoft Cloud for Sovereignty.

Considere la posibilidad de tener en cuenta la proximidad de la

Los usuarios o servicios que necesitan acceder a los servicios de Azure pueden residir en varias zonas geográficas globalmente. Del mismo modo, es posible que los servicios de Azure necesiten consumir servicios de orígenes externos que se encuentran en varias zonas geográficas. O bien, es posible que los servicios necesiten conectarse a los sistemas locales.

La proximidad es un factor importante que se debe tener en cuenta al seleccionar una región de Azure. Si usa Azure ExpressRoute para conectarse a los sistemas locales, puede optimizar la conectividad de red y reducir la latencia mediante una región cercana a los sistemas locales. Las conexiones posteriores entre regiones de Azure usan la red global de Microsoft de alta velocidad.

Para más información sobre la latencia entre regiones de Azure y otras áreas geográficas, consulte Estadísticasde latencia de ida y vuelta de red de Azure.

Funcionamiento en varias regiones geográficas

Es habitual que una organización funcione en varias regiones geográficas. Una organización puede obtener las siguientes ventajas con el uso de varias regiones de Azure:

  • Ejecute diferentes cargas de trabajo en regiones diferentes. Este motivo se aplica cuando desea estar cerca de una base de clientes específica o de un asociado empresarial. También es relevante cuando desea usar los servicios de Azure que no están disponibles en una región de Azure específica.
  • Admite una basede usuarios dispersa geográficamente. Si opera en varios países o si los clientes usan los servicios de varios países, puede tener sentido tener recursos de Azure en cada ubicación. Como alternativa, puede considerar el uso de una sola región y, a continuación, usar Azure Front Door para acelerar el tráfico global a esa región.
  • Cumplir los requisitosde soberanía de datos. Su organización puede estar sujeta a límites en las áreas geográficas donde puede almacenar determinados datos.
  • Lograr una alta resistencia, especialmente para cargas de trabajo críticas para la empresa. Las cargas de trabajo críticas para la empresa requieren las ventajas que proporcionan las zonas de disponibilidad, como la alta disponibilidad y la protección frente a interrupciones y desastres en toda la región.
  • Mejorar la conectividad y el rendimientode la red. En un escenario híbrido o multinube, el uso de varias regiones de Azure puede ayudar a mejorar el rendimiento de la red. El tráfico puede entrar y salir de la red troncal de Microsoft de alta velocidad en ubicaciones cercanas a los sistemas locales o a las ubicaciones de otro proveedor de nube. Para más información sobre las soluciones multinube, consulte Conectividad con otros proveedoresde nube.
  • Optimización de costes. Los distintos tipos de recursos de Azure pueden tener precios diferentes en regiones diferentes. Al usar herramientas como la calculadora de precios y la información de precios del servicio de Azure, asegúrese de seleccionar la región correcta para ver información de precios precisa. A veces, puede reducir los costos mediante la implementación de entornos de desarrollo y pruebas en una región diferente. Pero debe asegurarse de que la región proporciona las funcionalidades y los servicios que usa en la región de producción.
  • Escale más allá de las cuotas de recursos. Algunos recursos de Azure tienen cuotas y límites que restringen el número de instancias de un recurso que puede crear en cada región de cada suscripción. Para escalar más allá de estos límites, es posible que tenga que usar suscripciones adicionales o varias regiones.
  • Evitar restricciones de capacidad. En ocasiones, las regiones tienen restricciones de capacidad aplicadas. Si usa varias regiones, probablemente será más fácil encontrar y usar una región que admita los servicios que quiere implementar. Si usa una sola región y necesita expandirse a una segunda región solo para evitar restricciones de capacidad, podría tardar más tiempo en preparar e implementar los recursos.
  • Reducir la complejidad en comparación con las implementaciones de nube múltiple. La complejidad de la administración de implementaciones de varias regiones suele ser menor que las implementaciones de nube múltiple y, a menudo, puede obtener ventajas similares de disponibilidad y resistencia. Sin embargo, la elección entre los dos enfoques depende de los objetivos específicos de la organización.

Al operar un entorno de nube distribuido en varias regiones geográficas, tenga en cuenta los siguientes factores:

  • Complejidad operativa. Cuando tiene varios recursos en regiones diferentes, es posible que haya una carga operativa adicional. Es posible que también tenga que pagar costos adicionales al duplicar los recursos entre regiones.
  • Sincronización de datos. Comprenda si necesita sincronizar o replicar datos entre regiones. Si lo hace, comprenda si hacerlo de forma asincrónica o sincrónica. La configuración de una capa de almacenamiento de datos de varias regiones puede ser compleja. Debe tener en cuenta las compensaciones entre resistencia, rendimiento y costo.
  • Topología de red global. Azure proporciona muchos servicios de red diferentes. Azure también admite la implementación de varias topologías de redes globales para cumplir distintos requisitos y proporcionar diferentes ventajas. Por ejemplo, puede expandir las redes de Azure a varias regiones mediante Azure Virtual WAN, o puede usar un modelo tradicional en estrella tipo hub-and-spoke con un esfuerzo adicional.
  • Perfiles de acceso de los usuarios. Si un solo usuario trabaja con componentes en varias regiones, comprenda cómo administrar sus identidades y acceder a perfiles entre regiones.
  • Requisitos de cumplimiento. Compruebe que cada región cumple los requisitos de cumplimiento, incluidos los requisitos de soberanía de datos.
  • Resistencia regional. Aunque el uso de una arquitectura de varias regiones ayuda a aumentar la resistencia, también debe diseñar la solución para que esté altamente disponible en cada región. Use zonas de disponibilidad en las que pueda y asegúrese de considerar cómo lograr una alta resistencia dentro de cada región.
  • Conmutación por error. Cuando se usan varias regiones con fines de resistencia, puede diseñar la solución para usar un enfoque activo-pasivo. Este enfoque requiere que detecte interrupciones regionales y conmute por error el tráfico entre regiones. Puede tardar tiempo en un proceso de conmutación por error para detectar una interrupción y un enrutamiento de tráfico completo, lo que puede provocar tiempo de inactividad para los servicios. En su lugar, algunas organizaciones eligen implementar en un patrón activo-activo para evitar confiar en la conmutación por error. Las ventajas de usar un patrón activo-activo incluyen equilibrio de carga global, mayor tolerancia a errores y aumentos del rendimiento de la red. Para sacar el máximo partido a este patrón, las aplicaciones deben admitir la ejecución activa-activa en varias regiones.

Reubicación entre regiones

En ocasiones, es posible que tenga que reubicar recursos o cargas de trabajo de una región de Azure a otra. Los cambios en los requisitos empresariales, las adquisiciones de la empresa, las leyes de residencia de datos y otros factores son motivos para tener que reubicarse.

Sugerencia

La reasignación de recursos entre regiones puede ser compleja. Cuando sea posible, intente implementar los recursos en la región correcta desde el principio.

Azure proporciona varias herramientas y varias funcionalidades de reubicación, pero los detalles varían para cada servicio de Azure. Algunos tipos de recursos se pueden mover directamente entre regionesy otros se pueden mover mediante Azure Resource Mover. Algunos tipos de recursos no se pueden mover y deben volver a implementarse.

Para más información sobre cómo reubicar entre regiones, consulte Reubicación de cargas de trabajo en la nube.

Alta disponibilidad y recuperación ante desastres entre regiones

Las regiones de Azure son de alta disponibilidad. Los contratos de nivel de servicio de Azure se aplican a los servicios que se ejecutan en regiones específicas. En esta sección se proporcionan algunas consideraciones que se aplican si decide implementar en varias regiones para aumentar la resistencia.

Advertencia

Al diseñar cargas de trabajo críticas para la empresa, planee siempre errores regionales y evite la implementación dentro de una sola región. También debe practicar los pasos de recuperación y mitigación. Para más información, consulte Cargas de trabajo críticas.

Descripción de las características de resistencia del servicio de Azure

Muchos servicios de plataforma como servicio (PaaS) dependen de sus propias soluciones de resistencia regional. Por ejemplo, al implementar Azure SQL Database y Azure Cosmos DB, puede replicar fácilmente los datos en más regiones. Otros servicios se implementan en una sola región y debe implementarlos manualmente en otras regiones. Además, algunos servicios de Azure, como Azure DNS y Azure Front Door, se implementan globalmente y no tienen dependencias regionales.

Para cada servicio de Azure que considere para el proceso de adopción de la nube, comprenda las funcionalidades de conmutación por error y los pasos de recuperación necesarios.

Planeamiento de implementaciones de grupos de recursos de Azure

Para obtener el escenario más fiable y minimizar el efecto de las interrupciones regionales, se recomienda colocar recursos en la misma región que el grupo de recursos. Para obtener más información, consulte Alineación de la ubicación del grupo de recursos.

Si tiene recursos en regiones diferentes dentro del mismo grupo de recursos, considere la posibilidad de mover los recursos a un nuevo grupo de recursos o suscripción.

Para determinar si el recurso admite el traslado a otro grupo de recursos, realice un inventario de los recursos haciendo referencia cruzada a ellos. Asegúrese de que cumple los requisitos previos adecuados.

Sugerencia

Siempre que sea posible, implemente grupos de recursos en una región que tenga varias zonas de disponibilidad. Las zonas de disponibilidad ayudan a minimizar el riesgo de interrupciones regionales que reducen la disponibilidad del recurso y también hacen que las operaciones de administración no estén disponibles.

En algunos casos, los recursos de un grupo de recursos suelen abarcar varias regiones. Si toda una región no está disponible, se pueden producir errores en todas las operaciones de administración que implican recursos dentro de los grupos de recursos de la región no disponible. Sin embargo, los recursos que se implementan en otra región pueden seguir estando disponibles aunque no se puedan administrar. En algunos escenarios, para asegurarse de que los recursos siempre permanecen disponibles, puede colocar un grupo de recursos en varias regiones. Este enfoque tiene limitaciones, pero mantiene la disponibilidad de los recursos durante una interrupción temporal.

Uso de GRS en regiones emparejadas

Si implementa en una región que tiene una región emparejada asociada, puede usar la región emparejada como parte de la estrategia de resistencia de varias regiones. Las regiones emparejadas permiten usar regiones primarias y secundarias.

Azure Storage admite GRS. En el GRS de Azure Storage se almacenan tres copias de los datos en la región primaria y otras tres copias en la región emparejada. En el almacenamiento con redundancia geográfica no se puede cambiar el emparejamiento del almacenamiento. Otros servicios de Azure que dependen de Azure Storage suelen aprovechar esta capacidad de regiones emparejadas. Las aplicaciones y la red deben configurarse para admitir regiones emparejadas y usar el almacenamiento GRS de forma adecuada.

No intente usar Storage con replicación GRS para las copias de seguridad de máquinas virtuales. En vez de eso, use Azure Backup, Azure Site Recovery y Azure Managed Disks, para respaldar la resistencia de las cargas de trabajo de infraestructura como servicio (IaaS).

Sugerencia

Las soluciones de varias regiones no tienen que usar GRS de almacenamiento. En su lugar, hay disponibles otras opciones:

En estos escenarios, al seleccionar una región secundaria, considere la posibilidad de usar una región que no sea la región emparejada. Si se produce un error regional en la región primaria, la presión intensa se pone en los recursos de la región emparejada cuando se migran los recursos y se produce la conmutación por error entre regiones. Para evitarlo, se puede realizar la recuperación en un sitio alternativo y conseguir una mayor velocidad durante la recuperación.

Implementación en regiones sin un par

Las regiones más recientes de Azure no tienen ningún par regional. Logran una alta disponibilidad mediante zonas de disponibilidad. Estas regiones siguen las directrices de residencia de datos que proporcionan la opción de almacenar datos en la región.

Al usar estas regiones, puede usar almacenamiento con redundancia local (LRS) o almacenamiento con redundancia de zona (ZRS). Las regiones sin un par no admiten GRS. Los servicios como Backup que tienen una dependencia de Storage también pueden requerir que use el almacenamiento ZRS o LRS. Siempre que sea posible, se recomienda usar ZRS para mejorar la resistencia dentro de su región.

Para prepararse para el evento poco frecuente que una región completa de Azure no está disponible, debe planear la recuperación ante desastres entre regiones. Como mínimo, es recomendable implementar la infraestructura mediante enfoques de automatización y realizar copias de seguridad de los datos entre regiones. Si se produce una interrupción de toda la región, puede volver a implementar manualmente los recursos y restaurar las copias de seguridad. En algunos escenarios, es posible que tenga que tener en cuenta otras alternativas para reducir el tiempo de recuperación potencial y la pérdida de datos. Para más información, consulte Compatibilidad del servicio de zona de disponibilidad, Compatibilidad con regiones de zona de disponibilidad y Resistencia de Azure: continuidad empresarial y recuperación ante desastres.

Tenga en cuenta las necesidades de resistencia de los datos. Independientemente de dónde se encuentren los datos, puede mover, copiar o acceder a los datos desde cualquier ubicación globalmente.

Algunos servicios de Azure proporcionan una manera de almacenar o replicar los datos en varias regiones sin que se emparejan las regiones. Por ejemplo:

Pasos siguientes

Al migrar cargas de trabajo existentes desde un centro de datos local a Azure, hay otras consideraciones de selección de regiones que también debe tener en cuenta. Para más información, consulte Selección de regiones de Azure para una migración.