Regiones de la zona de aterrizaje

La propia arquitectura de zona de aterrizaje de Azure es independiente de la región. Sin embargo, se le pedirá que especifique las regiones de Azure para implementar la arquitectura de zona de aterrizaje de Azure. En este artículo se explica cómo las zonas de aterrizaje usan regiones de Azure. También se explica cómo agregar una región a una zona de aterrizaje existente y algunas consideraciones al migrar sus activos de Azure a otra región.

Para obtener más instrucciones sobre cómo elegir regiones de Azure, consulte Selección de regiones de Azure.

Uso de las zonas de aterrizaje en regiones de Azure

Las zonas de aterrizaje de Azure constan de un conjunto de recursos y configuraciones. Algunos de estos elementos, como grupos de administración, directivas y asignaciones de roles, se almacenan en un nivel de inquilino o grupo de administración dentro de la arquitectura de la zona de aterrizaje de Azure, por lo que estos recursos no se "implementan" en una región determinada, sino que se implementan globalmente. Aun así, debe especificar una región de implementación, porque Azure realiza un seguimiento de algunos de los metadatos de recursos en un almacén de metadatos regionales.

Otros recursos se implementan regionalmente. En función de su propia configuración de zona de aterrizaje, es posible que tenga algunos o todos los siguientes recursos implementados regionalmente:

• Área de trabajo de Log Analytics (incluidas las soluciones seleccionadas)
• Cuenta de Automation
• Grupos de recursos (para los demás recursos)

Si implementa una topología de redes, también deberá seleccionar una región de Azure en la que implementar los recursos de redes. Esta región puede ser diferente de la región que se usa para los recursos enumerados en la lista anterior. Según la topología que seleccione, los recursos de redes que implemente pueden incluir:

• Azure Virtual WAN (incluido el centro de Virtual WAN)
• Redes virtuales de Azure
• VPN Gateway
• Puerta de enlace de ExpressRoute
• Azure Firewall
• Planes de Azure DDoS Protection
• Zonas DNS privadas de Azure, incluidas para Azure Private Link
• Grupos de recursos, para contener los recursos enumerados anteriormente

Nota:

Para reducir el efecto de las interrupciones regionales, se recomienda ubicar 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.

Añadir una nueva región a una zona de aterrizaje existente

Debe considerar una estrategia de varias regiones, ya sea desde el inicio del recorrido de la nube o expandiéndose a más regiones de Azure una vez que haya completado la implementación inicial de la arquitectura de la zona de aterrizaje de Azure. Por ejemplo, si habilita la recuperación ante desastres para las máquinas virtuales mediante Azure Site Recovery, es posible que desee replicarlas en otra región de Azure. Para agregar regiones de Azure en la arquitectura de zona de aterrizaje de Azure, tenga en cuenta las siguientes áreas y recomendaciones:

Área	Recomendación
Grupos de administración	No es necesaria ninguna acción. Los grupos de administración no están vinculados a una región y no es recomendable crear una estructura de grupo de administración basada en regiones.
Suscripciones	Las suscripciones no están vinculadas a una región.
Azure Policy	Realice cambios aquí si asignó directivas para denegar la implementación de recursos en todas las regiones mediante la especificación de una lista de regiones de Azure "permitidas". Estas asignaciones deben actualizarse para permitir implementaciones de recursos en la nueva región que desea habilitar.
Control de acceso basado en rol	No es necesaria ninguna acción. RBAC de Azure no está asociado a ninguna región.
Supervisión y registro	Decida si va a usar un único área de trabajo de Log Analytics para todas las regiones o crear varias áreas de trabajo para cubrir diferentes regiones geográficas. Ambos tienen sus ventajas y desventajas, incluidos posibles cargos de red entre regiones. Para saber más, consulte Diseño de una arquitectura de área de trabajo de Log Analytics.
Redes	Si implementó una topología de redes, Virtual WAN o en estrella tipo hub-and-spoke, expanda las redes a la nueva región de Azure. Cree otro centro de redes mediante la implementación de los recursos de red necesarios en la suscripción de conectividad existente en la nueva región de Azure. Azure Virtual Network Manager puede facilitar la expansión y administración de redes virtuales a escala en varias regiones. Desde una perspectiva de DNS, es posible que también quiera implementar reenviadores, si se usan, en la nueva región de Azure. Use reenviadores para las redes virtuales de tipo spoke en la nueva región con fines de resolución. Las zonas de Azure DNS son recursos globales que no están vinculados a una sola región de Azure, por lo que no es necesario hacer nada en ellas.
Identidad	Si implementó Active Directory Domain Services o Microsoft Entra Domain Services en la suscripción o radio de identidad, expanda el servicio en la nueva región de Azure.

Nota:

También puede usar zonas de disponibilidad para lograr una alta disponibilidad dentro de una región. Compruebe si se admiten las zonas de disponibilidad en las regiones elegidas y para los servicios que desea usar.

Microsoft Cloud for Sovereignty tiene directrices para restringir los servicios y las regiones. Puede utilizar estas directrices para imponer la configuración del servicio y ayudar a los clientes a satisfacer sus necesidades de residencia de datos.

Enfoque de alto nivel

Al expandir una zona de aterrizaje de Azure a una nueva región, considere la posibilidad de seguir los pasos descritos en estas secciones. Antes de empezar, debe decidir en una nueva región de Azure o en varias regiones de Azure para expandirse.

Redes

Arquitectura tradicional en estrella tipo hub-and-spoke

Sugerencia

Revise el área de diseño de la zona de aterrizaje de Azure para la arquitectura tradicional en estrella tipo hub-and-spoke.

1. Decidir si se necesita una nueva suscripción de zona de aterrizaje de la plataforma. Se recomienda que la mayoría de los clientes usen sus suscripciones de conectividad existentes, incluso cuando usan varias regiones.
2. En la suscripción, cree un nuevo grupo de recursos en la nueva región de destino.
3. Cree un centro de conectividad Virtual Network en la nueva región de destino.
4. Si procede, implemente Azure Firewall o aplicaciones virtuales de red (NVA) en el nuevo centro de conectividad Virtual Network.
5. Si procede, implemente puertas de enlace de Virtual Network para la conectividad VPN o ExpressRoute y establecimiento de conexiones. Asegúrese de que los circuitos ExpressRoute y las ubicaciones locales siguen las recomendaciones de resistencia de Microsoft. Para obtener más información, consulte Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute.
6. Establezca el emparejamiento de red virtual entre el nuevo centro de conectividad de red virtual y los demás centros de conectividad de redes virtuales.
7. Cree y configure cualquier enrutamiento necesario, como Azure Route Server o rutas definidas por el usuario.
8. Si procede, habilite la resolución de nombres mediante la implementación de reenviadores DNS para la nueva región de destino y la vinculación a cualquier zona DNS privada.
   • Algunos clientes pueden configurar su resolución de nombres en sus controladores de Dominio de Active Directory en la suscripción de la zona de aterrizaje de la plataforma de identidad.

Para hospedar las cargas de trabajo puede conectar radios de zona de aterrizaje de aplicaciones a través del emparejamiento de red virtual con el nuevo centro de conectividad Virtual Network en la nueva región a través del emparejamiento de red virtual.

Sugerencia

Azure Virtual Network Manager puede facilitar la expansión y administración de redes virtuales a escala en varias regiones.

Arquitectura de Virtual WAN

Sugerencia

Revisión del área de diseño de la zona de aterrizaje de Azure para la arquitectura de Virtual WAN.

1. En el Virtual WAN existente, cree un nuevo centro virtual en la nueva región de destino.
2. Implemente Azure Firewall u otras aplicaciones virtuales de red (NVA) admitidas en el nuevo centro virtual. Configure directivas de intención y enrutamiento de Azure Virtual WAN para enrutar el tráfico a través del nuevo centro virtual protegido.
3. Si procede, implemente puertas de enlace de Virtual Network para la conectividad VPN o ExpressRoute en el nuevo centro virtual y establecimiento de conexiones. Asegúrese de que los circuitos ExpressRoute y las ubicaciones locales siguen las recomendaciones de resistencia de Microsoft. Para obtener más información, consulte Diseño para la recuperación ante desastres con el emparejamiento privado de ExpressRoute.
4. Si procede, cree y configure cualquier otro enrutamiento que necesite, como las rutas estáticas del centro virtual.
5. Si procede, implemente reenviadores DNS para la nueva región de destino y vínculo a cualquier zona DNS privada para habilitar la resolución.
   • Algunos clientes pueden configurar su resolución de nombres en sus controladores de Dominio de Active Directory en la suscripción de la zona de aterrizaje de la plataforma de identidad.
   • En implementaciones de Virtual WAN, esto debe estar en una red virtual de radios conectada al centro virtual a través de una conexión de red virtual, según el patrón de extensión de centro de conectividad virtual.

Para hospedar las cargas de trabajo, puede conectar radios de zona de aterrizaje de aplicaciones con el nuevo centro virtual de Virtual WAN en la nueva región a través de las conexiones de Virtual Network.

identidad

Sugerencia

Revise el área de diseño de la zona de aterrizaje de Azure para la administración de identidades y acceso.

1. Decida si necesita una nueva suscripción de zona de aterrizaje de la plataforma. Se recomienda que la mayoría de los clientes usen sus suscripciones de identidad existentes, incluso cuando usan varias regiones.
2. Creación de un nuevo grupo de recursos en la nueva región de destino.
3. Creación de un Virtual Network en la nueva región de destino.
4. Establecimiento del emparejamiento de red virtual con el centro de conectividad regional de red virtual recién creado en la suscripción de conectividad.
5. Implementación de cargas de trabajo de identidad, como máquinas virtuales del controlador de dominio de Active Directory en nuevas redes virtuales.
   • Es posible que tenga que realizar una configuración adicional de las cargas de trabajo una vez aprovisionadas, como los siguiente pasos de configuración:
     • Promocionar las máquinas virtuales del controlador de dominio de Active Directory al dominio de Active Directory existente.
     • Crear nuevos sitios y subredes de Active Directory.
     • Configurar las opciones del servidor DNS, como reenviadores condicionales.

Trasladar sus activos de Azure a una nueva región

En ocasiones, puede que tenga que mover todos sus activos de Azure a otra región. Pongamos un ejemplo: ha implementado la zona de aterrizaje y las cargas de trabajo en una región de Azure en un país o región vecinos y, a continuación, se establece una nueva región de Azure en su país o región principal. En ese caso, podría mover todas las cargas de trabajo a la nueva región para mejorar la latencia de comunicación o cumplir los requisitos de residencia de datos.

Nota

En este documento solo se proporciona información sobre cómo migrar los componentes de la zona de aterrizaje de sus activos. Para más información sobre cómo reubicar los componentes de carga de trabajo, consulte Reubicación de cargas de trabajo en la nube.

Configuración de la zona de aterrizaje global

Cuando se mueven regiones, no suele ser necesario modificar la mayoría de las configuraciones de la zona de aterrizaje implementadas globalmente. De todas formas, compruebe si hay asignaciones de directiva que restrinjan las implementaciones de regiones y actualice la directiva para permitir las implementaciones en la nueva región.

Recursos de la zona de aterrizaje regional

Los recursos de zona de aterrizaje específicos de la región suelen requerir más reflexión, ya que algunos recursos de Azure no se pueden mover entre regiones. Este es un planteamiento a tener en cuenta:

1. Agregue la región de destino como una región adicional a la zona de aterrizaje. Siga las instrucciones de Incorporación de una nueva región a una zona de aterrizaje existente.
2. Implemente componentes centralizados en la región de destino. Por ejemplo, implemente un área de trabajo de Log Analytics nueva en la región de destino para que las cargas de trabajo puedan empezar a usar el nuevo componente cuando se migren.
3. Migre las cargas de trabajo de la región de origen a la región de destino. Durante el proceso de migración de la carga de trabajo, vuelva a configurar los recursos para usar los componentes de red de la región de destino, los componentes de identidad, el área de trabajo de Log Analytics y otros recursos regionales.
4. Retire los recursos de la región de origen una vez completada la migración.

Tenga en cuenta estas recomendaciones al migrar recursos de zona de aterrizaje entre regiones:

• Use una infraestructura como código: las configuraciones más complejas (como las reglas para Azure Firewall) se pueden exportar y volver a importar mediante Bicep, plantillas de ARM, Terraform, scripts o un enfoque similar.
• Azure Automation: Azure Automation proporciona instrucciones y scripts para ayudar con la migración entre regiones de los recursos de Azure Automation.
• ExpressRoute: plantéese si puede usar ExpressRoute Local en la región de destino. Si los entornos locales están dentro del mismo área metropolitana que la región de Azure, ExpressRoute Local puede proporcionar una opción de menor coste que otras SKU de ExpressRoute.

Pasos siguientes

Mejora de la gobernanza de la zona de aterrizaje