¡Hola Devs! El problema que nadie ve hasta que rompe el terraform apply
Fíjate en esto: mover cuentas entre AWS Organizations parece tarea administrativa… hasta que un terraform apply en producción falla con error de permisos mientras el tráfico sigue fluyendo sin problema. Ese es el síntoma clásico de un share de AWS RAM atado a la organización que se rompe: el data plane aguanta, pero el control plane se apaga.
Esto le pega a cualquier empresa que pase por fusión, escisión o diseño multi-org. El detalle es sutil:
- Cuando la cuenta productora activa el sharing con AWS Organizations, AWS RAM confía en cada principal a través del membership de la organización, aunque el share mencione un account ID.
- En el momento en que la cuenta sale de la organización origen, AWS RAM elimina esa asociación.
- Los attachments, rutas DNS y certificados siguen funcionando — pero nadie puede ya modificar los recursos compartidos.
Un procesador global de pagos vivió exactamente esto en una migración de 382 cuentas. La solución fue un bridge share retenido: una asociación externa temporal creada antes del movimiento y eliminada después de restaurar el share original. El caso completo, con automatización validada, está en el post del AWS Architecture Blog.
Tipos de recurso afectados (confirmados en producción)
| Recurso | Servicio | Efecto de perder el share |
|---|---|---|
| AWS Transit Gateway | ec2:TransitGateway | Pierde control plane, mantiene data plane |
| Route 53 Resolver rules | route53resolver:ResolverRule | Riesgo de interrupción en resolución DNS |
| AWS Private CA | acm-pca:CertificateAuthority | Share perdido, certificados emitidos siguen válidos |
| EC2 prefix lists | ec2:PrefixList | Data plane ok, creación de nuevos recursos bloqueada |
| Glue Data Catalog DBs/tables | Glue + Lake Formation | Requiere validación de bridge share antes de migrar |
Algunos servicios piden cuidado extra: las políticas de Firewall Manager pueden borrar reglas de Network Firewall (hay que redeploy), y los StackSets integrados con la organización pueden eliminar stacks si no están configurados para retención.
El patrón bridge-share: cinco pasos por wave
El insight central es que AWS RAM permite que un recurso pertenezca a más de un resource share. Un share paralelo puede coexistir con el original, apuntando a la misma cuenta consumidora. Cuando la consumidora acepta la invitación antes de la migración, la asociación se vuelve externa — ya no depende del membership de la organización, así que sobrevive al movimiento.
¿Por qué restaurar el share original?
El bridge es una copia de continuidad solo para la migración. El share original creado por Lake Formation sigue siendo el objeto durable y gestionado por el servicio. Si alguien agrega un grant o cambia un recurso compartido durante la ventana de migración, ese cambio va al original — no al bridge. Mantener los dos genera estado duplicado de permisos y drift.
Workflow validado
# 1. Inventario — AWS RAM es regional, repite por Region
aws ram list-resource-shares --region us-east-1 --resource-owner SELF
# 2. Crea un bridge share retenido para el mismo recurso + principals
aws ram create-resource-share \
--name "bridge-tgw-prod" \
--resource-arns arn:aws:ec2:us-east-1:111122223333:transit-gateway/tgw-xxxx \
--principals 444455556666 \
--allow-external-principals \
--region us-east-1
# 3. La cuenta consumidora acepta la invitación ANTES de migrar
aws ram accept-resource-share-invitation \
--resource-share-invitation-arn <invitation-arn> \
--region us-east-1
# 4. Mueve la cuenta (AWS Organizations soporta transferencia directa entre orgs)
# 5. Restaura los account IDs migrados en el share ORIGINAL como principals externos,
# valida y solo entonces borra los bridges totalmente cubiertos por originales activos
La flag que hace que todo funcione
El 27 de febrero de 2026, AWS lanzó RetainSharingOnAccountLeaveOrganization para resource shares nuevos. Marca los principals como externos después de que aceptan la invitación. Dato clave: esa flag no aplica retroactivamente a shares existentes — por eso el cliente necesitó un share paralelo temporal para cada share pre-existente. En las pruebas, allowExternalPrincipals solo no alcanzó; el bridge necesitó las dos flags.
Guardrail de automatización
El paso de delete solo dispara cuando la automatización encuentra un original (no-bridge) cuyos recursos, principals y permisos cubren el bridge y cuyas asociaciones están todas en ASSOCIATED. Eso confirma que el original está activo antes de quitar el camino temporal.
Límites y advertencias
Este patrón es poderoso, pero tiene filos:
- Testear en non-prod te puede mentir. Las cuentas non-prod del cliente ya estaban en otra organización, así que 14 waves limpias validaron el proceso, pero nunca cruzaron la frontera de confianza de producción. Cada ambiente de validación debe cruzar la misma frontera que producción.
- Account ID como principal no es red de seguridad. Aunque el share mencione un account ID, lo que realmente concede confianza es el membership de la organización. Poner el ID no vuelve externa la asociación.
- Fricción con SCP. Una service control policy que bloquee
ram:AcceptResourceShareInvitationrompe en silencio el paso de aceptación del bridge — el cliente tuvo que ajustarla temporalmente durante las ventanas de migración. - Firewall Manager y StackSets requieren configuración explícita de retención, o redeployas reglas / pierdes stacks.
- Riesgo de drift del bridge. Si se agrega un grant al original durante la ventana y se borra el bridge antes de verificar, pierdes acceso a media wave.
Monitoreando el control plane
AWS RAM emite eventos de cambio de estado de resource share directo a Amazon EventBridge, y CloudTrail registra llamadas DisassociateResourceShare para auditoría. Un barrido semanal post-migración funciona como reconciliación para detectar shares obsoletos — es el seguro más barato que puedes contratar.
Si también estás modernizando las cargas que dependen de estos shares, los patrones en Beyond Demos: Building Production-Ready AI Agents with Gemini 3 & 6 Open-Source Frameworks muestran cómo las arquitecturas de agentes en producción manejan acceso cross-account y fronteras de permisos en la práctica.
Conclusión: trata el acceso al control plane como riesgo de migración de primera clase
La migración de las 382 cuentas salió bien porque el equipo dejó de tratar los shares de AWS RAM como configuración pasiva y empezó a tratarlos como dependencias de producción con ciclo de vida. El bridge share es temporal por diseño — restaurar el original mantiene los permisos de Lake Formation alineados con grants futuros y evita dos fuentes de verdad.
Tres lecciones para tu propia migración:
- Alinea las fronteras de validación con producción. Una org de test que nunca cruza la frontera real no prueba nada.
- Inventaria antes de planear waves. La herramienta Account Assessment for AWS Organizations mapea dependencias de RAM por Region; hazlo temprano.
- Automatiza con dry-run primero. Los scripts validados soportan dry-run y ejecución — corre dry, valida cada Region y cuenta, luego ejecuta.
Si andas explorando cómo los sistemas autónomos y pipelines de experimentación en ML se están llevando a producción en entornos corporativos parecidos, el breakdown del agente autónomo Meta REA es una lectura complementaria útil sobre el mismo tema de pasar del demo a la infraestructura durable.
Siguientes pasos de estudio: lee la guía oficial Transfer AWS accounts between AWS Organizations while preserving AWS Lake Formation permissions, revisa el aws-samples/sample-aws-ram-org-migration en GitHub y contacta a tu equipo de cuenta AWS temprano siempre que Glue Data Catalog o Lake Formation estén en el alcance.