Transición de un entorno de Azure existente a la arquitectura conceptual de la zona de aterrizaje de Azure

  • Artículo

Muchas organizaciones tienen una superficie de Azure existente, una o más suscripciones, y potencialmente una estructura de grupo de administración existente. En función de sus requisitos empresariales y escenarios, es posible que tengan recursos de Azure implementados, como Azure VPN Gateway o Azure ExpressRoute para la conectividad híbrida.

En este artículo se ofrecen recomendaciones para ayudar a su organización a navegar por los cambios basados en su entorno de Azure existente que está realizando la transición a la arquitectura conceptual de la zona de aterrizaje de Azure. En este artículo también se describen las consideraciones para el traslado de recursos de Azure, por ejemplo, el traslado de una suscripción de un grupo de administración existente a otro. Tenga en cuenta estas recomendaciones para ayudarle a evaluar y planear la transición de su entorno de Azure existente.

Trasladar recursos en Azure

Puede trasladar algunos recursos en Azure después de la creación. Hay diferentes enfoques que están sujetos a los permisos de control de acceso basado en roles (RBAC) de Azure de un usuario en y entre los ámbitos. En la tabla siguiente se describen los recursos que puede trasladar, a qué ámbito, y las ventajas y desventajas asociadas a cada recurso.

Ámbito Destination Pro Con
Recursos de grupos de recursos. Puede trasladar a un nuevo grupo de recursos en la misma suscripción o diferente. Puede modificar la composición de los recursos de un grupo de recursos después de la implementación. No admitido por todos los resourceTypes.

Algunos de los resourceTypes tienen limitaciones o requisitos específicos.

Los ResourceIds están actualizados y afectan a las operaciones de supervisión, alertas y plano de control existentes.

Los grupos de recursos están bloqueados durante el período de traslado.

Requiere una evaluación de las directivas y el RBAC antes y después de la operación de traslado.
Suscripciones de un inquilino. Puede trasladarse a diferentes grupos de administración. No hay ningún efecto en los recursos existentes dentro de la suscripción porque los valores resourceId no cambian. Requiere una evaluación de las directivas y el RBAC antes y después de la operación de traslado.

Para determinar qué estrategia de traslado debe usar, tenga en cuenta los ejemplos siguientes.

Movimiento de suscripciones

Normalmente, las suscripciones se mueven para organizarlas en grupos de administración o para transferir suscripciones a un nuevo inquilino de Microsoft Entra ID. El objetivo principal de trasladar una suscripción a un nuevo inquilino es transferir la propiedad de la facturación. Para obtener más información sobre cómo trasladar suscripciones entre grupos de administración del mismo inquilino, consulte Traslado de grupos de administración y suscripciones.

Requisitos de RBAC de Azure

Para evaluar una suscripción antes de un traslado, es importante que el usuario tenga el RBAC de Azure adecuado. El usuario puede ser propietario de la suscripción (asignación directa de roles) y tener permiso de escritura en el grupo de administración de destino. Los roles integrados que admiten el permiso de escritura en el grupo de administración de destino son el rol de propietario, el rol de colaborador y el rol de colaborador de grupo de administración.

Si el usuario tiene un permiso de rol de propietario heredado en la suscripción de un grupo de administración existente, solo puede trasladar la suscripción al grupo de administración en el que el usuario tiene asignado el rol de propietario.

Directivas

Las suscripciones existentes pueden estar sujetas a directivas de Azure que se asignan directamente o se asignan en el grupo de administración donde se encuentran actualmente. Es importante evaluar las directivas actuales y las directivas que pueden existir en el nuevo grupo de administración o jerarquía de grupos de administración.

Azure Resource Graph se puede usar para realizar un inventario de los recursos existentes y comparar su configuración con las directivas existentes en el destino.

Una vez que haya trasladado las suscripciones a un grupo de administración con la configuración de RBAC de Azure y directivas ya existentes, tenga en cuenta los siguientes factores:

  • Para cualquier RBAC de Azure que se herede de las suscripciones trasladadas, los tokens de usuario de la caché del grupo de administración pueden tardar hasta 30 minutos en actualizarse. Para acelerar este proceso, puede actualizar el token cerrando la sesión y volviendo a iniciarla, o solicitando un nuevo token.

  • Una directiva en la que el ámbito de asignación incluye las suscripciones trasladadas efectúa una auditoría solo en los recursos existentes. Un recurso existente en la suscripción que está sujeto a:

    • El efecto de directiva DeployIfNotExists aparece como no conforme y no se corrige automáticamente. Un usuario debe realizar manualmente la corrección.

    • El efecto de directiva Deny aparece como no conforme y no se rechaza. Un usuario debe mitigar manualmente este resultado según corresponda.

    • El efecto de directiva Append y Modify aparece como no conforme y requiere que un usuario lo mitigue.

    • El efecto de directiva Audit y AuditIfNotExist aparece como no conforme y requiere que un usuario lo mitigue.

  • Todas las escrituras nuevas en los recursos de la suscripción trasladada están sujetas a las directivas asignadas en tiempo real de la forma habitual.

Movimiento de recursos

Normalmente, los recursos se trasladan cuando se quieren consolidar los recursos en el mismo grupo de recursos si comparten el mismo ciclo de vida. O bien, si desea trasladar recursos a otra suscripción debido a los requisitos de coste, propiedad o RBAC de Azure.

Al trasladar recursos, el grupo de recursos de origen y el grupo de recursos de destino se bloquean durante la operación de traslado. No puede agregar, actualizar ni eliminar recursos de los grupos de recursos. La operación de traslado de los recursos no cambia la ubicación de estos.

Para obtener más información sobre cómo trasladar recursos entre grupos de recursos y suscripciones del mismo inquilino, consulte Traslado de los recursos a un nuevo grupo de recursos o a una nueva suscripción.

Sugerencia

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.

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.

Antes de trasladar los recursos

Antes de una operación de traslado, debe comprobar que se admiten los recursos y evaluar sus requisitos y dependencias. Por ejemplo, al trasladar una red virtual emparejada, primero debe deshabilitar el emparejamiento de red virtual y volver a habilitar el emparejamiento una vez finalizada la operación de traslado. Planifique con antelación la deshabilitación y la rehabilitación de la dependencia, de modo que comprenda el efecto sobre las cargas de trabajo existentes que podrían estar conectadas a las redes virtuales.

Después de trasladar recursos

Si los recursos se trasladan a un nuevo grupo de recursos de la misma suscripción, se seguirán aplicando las directivas y el RBAC de Azure heredados del grupo de administración o de la suscripción. Esto también se aplica si se traslada a un grupo de recursos en una nueva suscripción en la que la suscripción podría estar sujeta a otra asignación de directiva y RBAC de Azure. Debe validar el cumplimiento del recurso y los controles de acceso.

Escenarios

En los escenarios siguientes se describe cómo migrar y realizar la transición de un entorno existente a la arquitectura conceptual de la zona de aterrizaje de Azure.

Recorrido hacia la arquitectura de destino