How to Preserve AWS RAM Shares and Lake Formation Permissions During an AWS Organizations Migration

The Hidden Failure Mode When Accounts Change Organizations

Moving accounts between AWS Organizations looks like an administrative task until a production terraform apply fails with a permission error while traffic keeps flowing. That is the signature of an organization-bound AWS RAM share breaking: the data plane survives, but the control plane goes dark.

This pattern matters for any company going through a merger, divestiture, or multi-org design. The core problem is subtle:

• When a producer account enables sharing with AWS Organizations, AWS RAM trusts each principal through organization membership, even if the share names an account ID.
• The moment the account leaves the source organization, AWS RAM removes that association.
• Existing attachments, DNS paths, and certificates keep working — but engineers can no longer modify shared resources.

A global payment processor hit exactly this during a 382-account migration. The fix was a retained bridge share: a temporary external association created before the move, then removed after the original share is restored. The full write-up, including the validated automation, is documented in the AWS Architecture Blog post.

Affected Resource Types (confirmed in production)

Some services need extra handling: Firewall Manager policies can remove Network Firewall rules (redeploy required), and organization-integrated CloudFormation StackSets can delete stacks unless set to retain.

The Bridge-Share Pattern: Five Steps Per Wave

The key insight is that AWS RAM allows a resource to belong to more than one resource share. A parallel share can exist alongside the original, targeting the same consumer account. When the consumer accepts the invitation before migration, the association becomes external — it no longer depends on organization membership, so it survives the move.

Why the original share must come back

The bridge is a migration-only continuity copy. The original Lake Formation-created share remains the durable, service-managed permission object. If a team adds a grant or changes a shared resource during the migration window, that change lands on the original — not the bridge. Keeping both creates duplicate permission state and drift.

The validated workflow

# 1. Inventory — AWS RAM is Regional, repeat per Region
aws ram list-resource-shares --region us-east-1 --resource-owner SELF

# 2. Create a retained bridge share for the same resource + 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. Consumer accepts the invitation BEFORE migration
aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn <invitation-arn> \
  --region us-east-1

# 4. Move the account (AWS Organizations supports direct transfer between orgs)
# 5. Restore migrated account IDs to the ORIGINAL share as external principals,
#    then validate and delete only bridges fully covered by active originals

The setting that makes it work

On February 27, 2026, AWS released RetainSharingOnAccountLeaveOrganization for new resource shares. It marks principals as external after they accept the invitation. Critically, this setting does not retrofit existing shares — which is why the customer needed a temporary parallel share for every pre-existing share. Testing confirmed that allowExternalPrincipals alone was insufficient; the bridge required both flags.

Automation guardrail

The delete step only fires when the automation finds a non-bridge original whose resources, principals, and permissions cover the bridge and whose associations are all ASSOCIATED. That check confirms the original's associations are active before removing the temporary path.

Caveats and Limitations

This pattern is powerful but not free of sharp edges:

• Non-production testing can lie to you. The customer's non-production accounts already lived in a separate organization, so 14 clean waves validated the process but never crossed the production trust boundary. Each validation environment must cross the same boundary as production.
• Account IDs as principals are not a safety net. Even when a share names an account ID, the organization-bound association is what actually grants trust. Naming the ID does not make it external.
• SCP friction. A service control policy blocking ram:AcceptResourceShareInvitation will silently break the bridge acceptance step — the customer had to temporarily adjust it during migration windows.
• Firewall Manager and StackSets require explicit retain settings or you will redeploy rules / lose stacks.
• Bridge drift risk. If a grant is added to the original during the migration window and the bridge is deleted before the original is verified, you can lose access mid-wave.

Monitoring the control plane

AWS RAM emits resource-share state-change events directly to Amazon EventBridge, and CloudTrail records DisassociateResourceShare API calls for audit. A weekly post-migration sweep acts as a reconciliation check to catch stale shares — this is the cheapest insurance you can buy.

If you are also modernizing the workloads that depend on these shares, the patterns in Beyond Demos: Building Production-Ready AI Agents with Gemini 3 & 6 Open-Source Frameworks show how production-grade agent architectures handle cross-account access and permission boundaries in practice.

Conclusion: Treat Control-Plane Access as a First-Class Migration Risk

The 382-account migration succeeded because the team stopped treating AWS RAM shares as passive configuration and started treating them as production dependencies with a lifecycle. The bridge share is temporary by design — restoring the original keeps Lake Formation permissions aligned with future grants and avoids two sources of truth.

Three takeaways worth stealing for your own migration:

1. Match validation boundaries to production. A test org that never crosses the real boundary proves nothing.
2. Inventory before you wave-plan. The Account Assessment for AWS Organizations tool maps RAM dependencies per Region; do it early.
3. Automate dry-run first. The validated scripts support dry-run and execute modes — run dry, validate every Region and account, then execute.

If you are exploring how autonomous systems and ML experimentation pipelines are being productionized in similar enterprise environments, the Meta REA autonomous agent breakdown is a useful companion read on the same theme of moving from demo to durable infrastructure.

Next learning steps: read the official Transfer AWS accounts between AWS Organizations while preserving AWS Lake Formation permissions guide, review aws-samples/sample-aws-ram-org-migration on GitHub, and engage your AWS account team early whenever Glue Data Catalog or Lake Formation is in scope.