AWS Architecture Blog·August 24, 2026Preserving AWS Resource Shares During AWS Organizations Migrations
This article details a critical architectural challenge faced by a global payment processor during a large-scale AWS Organizations migration: preserving AWS Resource Access Manager (RAM) shares and Lake Formation permissions. It introduces a 'bridge share' pattern to maintain data plane and control plane access across 382 accounts, highlighting the importance of understanding AWS RAM's behavior with organization-bound vs. external shares and the need for robust testing in environments that mimic production trust boundaries.
Read original on AWS Architecture BlogWhen accounts are moved between AWS Organizations, AWS Resource Access Manager (AWS RAM) automatically removes organization-bound resource share associations. This can lead to significant outages, especially for critical shared resources like Transit Gateways, Route 53 Resolvers, and Glue Data Catalogs. While the data plane often remains active (e.g., existing EC2 instances keep running in a shared VPC), the control plane access is lost, preventing any modifications or new resource creation. This issue is particularly problematic for infrastructure-as-code deployments that require control plane access.
The Challenge: Loss of Control Plane Access
A global payment processor encountered this challenge when migrating 382 AWS accounts. Their non-production testing, performed in a separate organization, failed to expose the issue because those accounts never crossed the organization boundary that caused production associations to break. This highlights a crucial lesson: validation environments must accurately replicate the trust boundaries and architectural conditions of production systems.
| Resource | AWS Service | Effect of losing the share |
|---|
The Bridge Share Pattern for Migration
The solution, developed in partnership with AWS, is a 'retained bridge share' pattern. This pattern leverages the fact that AWS RAM treats shares with principals outside the organization differently, sending an invitation and creating an external, durable association that survives account moves. The process involves:
- Creating Parallel Bridge Shares: For each original organization-bound share, a second parallel 'bridge share' is created, targeting the same consumer account.
- Accepting Invitation: The consumer account accepts the invitation *before* migration, establishing an external association.
- Migration: During the account move, the original organization-bound association is removed, but the bridge share continues to grant access.
- Restoration: After the move, the migrated principals are restored to the original share, and the temporary bridge share is deleted. This is critical because the original share is the source of truth for permissions; changes made during the migration window would only apply to the original share, not the bridge.
Key Principle for System Design
When designing for multi-account or multi-organizational AWS environments, understand the implications of different resource sharing mechanisms (e.g., organization-bound vs. external shares) and plan for their behavior during account lifecycle events like mergers, acquisitions, or divestitures. Always validate migration paths in environments that faithfully replicate the target trust boundaries.