La actualización de IAM Identity Center elimina la necesidad de recrear asignaciones al migrar desde AD, un cambio que reduce el riesgo operativo en transiciones de infraestructura de identidad.
AWS modificó el comportamiento de IAM Identity Center para que las migraciones desde Active Directory hacia un proveedor de identidad externo o hacia el directorio propio de Identity Center ya no eliminen usuarios, grupos ni asignaciones de permisos durante el cambio. La actualización, disponible desde octubre de 2026, invierte la lógica que hasta ahora obligaba a los equipos de infraestructura a recrear manualmente todos los accesos después de cada migración desde AD.
El cambio afecta a organizaciones que están consolidando infraestructura de identidad, migrando sistemas legacy on-premises o adoptando capacidades de single sign-on basadas en proveedores SAML 2.0 como Okta Universal Directory, Microsoft Entra ID o Ping Identity. Antes de esta actualización, el momento del cutover desde Active Directory borraba de forma permanente todos los usuarios, grupos, membresías y asignaciones de la instancia de IAM Identity Center, lo que convertía cada migración en un evento de alto riesgo operativo que requería scripts de respaldo y restauración manual de permisos.
Cómo Identity Center mantiene la continuidad de acceso durante el cambio
IAM Identity Center ahora preserva los mismos IDs de usuario y grupo durante la migración desde Active Directory, actualizando únicamente el identificador externo (externalId) para reflejar la nueva fuente. Esto significa que las asignaciones de permission sets en cuentas AWS y las asignaciones de aplicaciones gestionadas por AWS (como SageMaker Studio u OpenSearch Service) permanecen intactas después del cambio de fuente de identidad.
El mecanismo funciona porque Identity Center mantiene su propio identity store interno como capa de abstracción entre la fuente de identidad y las asignaciones de acceso. Cuando la fuente cambia de Active Directory a un proveedor externo, el sistema actualiza la referencia de origen pero no destruye los objetos de identidad ya existentes en el store. Los roles IAM que respaldan los permission sets (nombrados con el prefijo AWSReservedSSO_) se mantienen sin cambios en cada cuenta, lo que evita interrupciones en el acceso de usuarios y grupos.
La única dirección de migración que todavía elimina usuarios, grupos y asignaciones es el cambio hacia Active Directory desde cualquier otra fuente. En ese escenario, el comportamiento destructivo se mantiene porque AD asume el rol de fuente autoritativa y requiere reprovisionar todas las identidades desde cero.
Por qué AWS recomienda validación de pruebas antes del cambio
El cambio de fuente de identidad se aplica a toda la instancia de Identity Center de una vez, sin posibilidad de rollback gradual por cuenta o por grupo de usuarios. AWS recomienda explícitamente validación de pruebas y un ensayo general antes del cutover en producción, porque cualquier inconsistencia en la configuración del proveedor externo (como diferencias en atributos SAML, mapeos de grupos o políticas de aprovisionamiento SCIM) puede dejar usuarios sin acceso después del cambio.
El riesgo operativo se concentra en dos puntos: la sincronización inicial de identidades desde el nuevo proveedor y la validación de que los externalId actualizados coinciden correctamente con los usuarios y grupos en el sistema de origen. Si el proveedor externo no provisiona un usuario con el mismo identificador único que tenía en Active Directory, ese usuario queda desconectado de sus asignaciones previas aunque Identity Center haya preservado el objeto de identidad interno.
Impacto en organizaciones latinoamericanas con infraestructura híbrida
El cambio tiene implicancias directas para organizaciones en México, Brasil, Argentina y Chile que todavía operan infraestructura de identidad híbrida con Active Directory on-premises y están evaluando migración a proveedores cloud. Según el patrón de adopción de AWS en la región, muchas empresas de servicios financieros y retail mantienen AD como fuente autoritativa por requisitos de auditoría local, pero enfrentan presión para adoptar capacidades de single sign-on que no dependen de conectividad VPN hacia datacenters propios.
La preservación de asignaciones durante la migración reduce el riesgo de ventanas de mantenimiento extendidas que afecten operaciones críticas. En sectores como banca y gobierno, donde los equipos de seguridad deben mantener trazabilidad de accesos durante todo el proceso de cambio, la capacidad de migrar sin recrear permisos manualmente disminuye la superficie de error humano en la reconfiguración de roles y políticas.
Qué sigue sin resolverse en el modelo de migración actual
La actualización no elimina la necesidad de inventariar asignaciones que viven dentro de las aplicaciones mismas, fuera del control de IAM Identity Center. AWS advierte que cada aplicación debe probarse en un ambiente no productivo antes de la migración, porque algunas aplicaciones gestionadas por el cliente pueden tener lógica de autorización propia que no se sincroniza automáticamente con el cambio de fuente de identidad.
Tampoco resuelve el caso de organizaciones que necesitan migrar hacia Active Directory desde un proveedor externo o desde el directorio de Identity Center. En esa dirección, el comportamiento destructivo se mantiene sin cambios: el cutover elimina todos los usuarios, grupos y asignaciones, lo que obliga a los equipos a implementar scripts de respaldo y restauración manual de permisos. AWS no ha indicado si planea extender la lógica de preservación a ese escenario en futuras actualizaciones.
Nuestro análisis
Este cambio refleja un patrón más amplio en la evolución de servicios de identidad en cloud: la transición desde modelos que asumen una única fuente autoritativa inmutable hacia arquitecturas que permiten cambiar de proveedor sin destruir el estado operativo. La decisión de AWS de preservar usuarios y asignaciones durante migraciones desde Active Directory responde a un problema real que enfrentaban equipos de infraestructura en organizaciones medianas y grandes: el riesgo de ventanas de mantenimiento extendidas y la complejidad de recrear manualmente cientos o miles de asignaciones de permisos después de cada cambio de fuente.
Lo que sigue sin resolverse es la asimetría en el comportamiento de migraciones: cambiar hacia Active Directory todavía elimina todo, mientras que cambiar desde AD ahora preserva todo. Esa asimetría sugiere que AWS considera a Active Directory como un caso especial que requiere reprovisionar identidades desde cero, probablemente porque AD asume control total sobre atributos de usuario y políticas de grupo que no tienen equivalente directo en otros proveedores. Pero esa lógica deja a organizaciones que necesitan volver a AD (por ejemplo, después de una adquisición que consolida infraestructura) sin una ruta de migración de bajo riesgo. ¿Cuánto tiempo más AWS mantendrá esa asimetría antes de que la presión operativa de clientes empresariales fuerce una solución simétrica para todas las direcciones de migración?