Compartir a través de

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

Muchas organizaciones tienen una presencia de Azure existente, una o varias suscripciones, y posiblemente 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 proporcionan recomendaciones para ayudar a su organización a navegar por los cambios en función de su entorno de Azure existente que realiza la transición a la arquitectura de referencia de la zona de aterrizaje de Azure. En este artículo también se describen las consideraciones para mover recursos en Azure, por ejemplo, mover una suscripción de un grupo de administración existente a otro grupo de administración. Tenga en cuenta estas recomendaciones para ayudarle a evaluar y planear la transición de su entorno de Azure existente.

Traslado de recursos en Azure

Puede mover 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 rol (RBAC) de un usuario en un único ámbito o entre múltiples ámbitos. En la tabla siguiente se describen los recursos que puede mover, en qué ámbito, y las ventajas y desventajas asociadas a cada recurso.

Ámbito Destino Pro Con
Recursos en grupos de recursos. Puede pasar a un nuevo grupo de recursos en la misma suscripción o diferente. Puede modificar la composición de recursos en un grupo de recursos después de la implementación. No es compatible con todos los resourceTypes.

Algunos resourceTypes tienen limitaciones o requisitos específicos.

Los ResourceId se actualizan y afectan a las operaciones existentes de supervisión, alertas y plano de control.

Los grupos de recursos se bloquean durante el período de traslado.

Requiere una evaluación de las directivas y de las operaciones de RBAC antes y después del movimiento.
Suscripciones en un inquilino. Puede pasar 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 de las operaciones de RBAC antes y después del movimiento.

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

Traslado 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. Mover una suscripción a un nuevo inquilino es principalmente para transferir la propiedad de facturación. Para obtener más información sobre cómo mover suscripciones entre grupos de administración en el 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 predeterminados que admiten el permiso de escritura en el grupo de administración objetivo son el rol de propietario, el rol de colaborador y el rol de colaborador del 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 mover la suscripción al grupo de administración en el que el usuario tiene asignado el rol de propietario.

Policies

Las suscripciones existentes pueden estar condicionadas por directivas de Azure que se asignan directamente o están asignadas al grupo de administración en el que se encuentran actualmente. Es importante evaluar las directivas actuales y las directivas que pueden existir en el nuevo grupo de administración o en la jerarquía de grupos de administración.

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

Después de mover las suscripciones a un grupo de administración con el RBAC y las directivas de Azure existentes, tenga en cuenta los siguientes factores:

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

  • Directiva en la que el ámbito de asignación incluye las suscripciones movidas realiza una auditoría solo en los recursos existentes. Un recurso existente en la suscripción que está sujeto a:

    • DeployIfNotExists el efecto de la política aparece como no cumplido y no se corrige automáticamente. Un usuario debe realizar manualmente la corrección.

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

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

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

  • Todas las nuevas operaciones de escritura en los recursos de la suscripción trasladada quedan sujetas a las políticas asignadas en tiempo real, como de costumbre.

Traslado de recursos

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

Al mover 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 en los grupos de recursos. Una operación de traslado de recursos no cambia la ubicación de los recursos.

Para obtener más información sobre cómo mover recursos entre grupos de recursos y suscripciones en el mismo inquilino, consulte Traslado de recursos a un nuevo grupo de recursos o 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 cumplir los requisitos previos adecuados.

Antes de mover recursos

Antes de una operación de traslado, debe comprobar que los recursos son compatibles y evaluar sus requisitos y dependencias. Por ejemplo, al mover 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. Planee con anticipación la dependencia de deshabilitar y volver a habilitar para comprender el efecto en las cargas de trabajo existentes que podrían estar conectadas a sus redes virtuales.

Después de mover recursos

Al mover los recursos a un nuevo grupo de recursos en la misma suscripción, se siguen aplicando todas las directivas y RBAC de Azure heredadas del grupo de administración o la suscripción. Esto también se aplica si se mueve 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 verificar el cumplimiento normativo de los recursos 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 de referencia de la zona de aterrizaje de Azure.

Recorrido hacia la arquitectura de destino

  • Last updated on