Skip to content

How a global payment processor preserved AWS RAM shares and Lake Formation permissions during an AWS Organizations migration

Summary

A worldwide payment-technology provider separated 382 AWS accounts from a former parent company before a Transitional Service Agreement (TSA) expired in April 2026. The estate depended on AWS RAM resource shares to preserve AWS Lake Formation permissions and other shared resources. The core hazard: an organization-bound resource share trusts a consumer account through its organization membership, so the moment an account leaves the source AWS Organization, AWS RAM removes that association — silently breaking the control plane while the data plane keeps running. AWS and the customer designed, validated, and rolled out a retained bridge-share migration pattern in two weeks: create a parallel external share that survives the move, migrate, restore the original Lake-Formation-managed share as the durable source of truth, then delete the bridge. 378 of 382 accounts migrated with no customer-facing downtime and no recorded network drops.

Key takeaways

  1. Organization-bound shares break on account move; data plane survives, control plane does not. Because "sharing with AWS Organizations" was enabled on the producer, RAM trusted each in-org principal through org membership — even when a share named a bare account ID. On leaving, RAM removed the org-bound association. A terraform apply against a shared Transit Gateway failed with a permission error in a February 2026 production wave while traffic kept flowing and no alarm fired — the defining control-plane / data-plane signature. (Source: this page)

  2. External principal associations survive the move. A share created for a principal outside the organization uses an invitation/accept flow; the accepted association is external and does not depend on org membership, so it survives the account transfer. The whole bridge-share pattern rides on this behavior. (Source: this page)

  3. allowExternalPrincipals alone is not enough — you also need retainSharingOnAccountLeaveOrganization. AWS released RetainSharingOnAccountLeaveOrganization for new RAM shares on February 27, 2026; it marks principals external after they accept. Testing across three test accounts and two organizations confirmed both settings are required on the bridge. Critically, the setting does not retrofit existing shares — hence the need for a temporary parallel share. (Source: this page)

  4. Restore the original share, then delete the bridge. The bridge is a point-in-time migration-only copy; the original Lake-Formation-created share stays the durable, service-managed permission object. New grants during the migration window attach to the original, not the bridge. Keeping both would create two divergent permission paths — audit ambiguity and drift. Automation deletes a bridge only after finding a non-bridge original whose resources, principals, and permissions cover the bridge and whose associations are all ASSOCIATED. (restore-original-share-then-delete-bridge) (Source: this page)

  5. Match validation boundaries to production. 14 clean non-production waves validated the process but never crossed an organization boundary — so they could not reproduce the production-only failure. The non-prod accounts were already in a separate org. Lesson: every validation environment must cross the same trust boundary as production. (patterns/shadow-migration boundary caveat) (Source: this page)

  6. Five-step per-wave workflow. Each production wave ran: (1) Inventory — map every share, resource, principal, permission, and Region (RAM is Regional → repeat per Region); (2) Create + accept bridges before migration; (3) Migrate the account (RAM drops the org-bound association, the accepted bridge keeps access live); (4) Restore originals by re-adding migrated account IDs as external principals (reactivates durable shares + captures in-window grants); (5) Validate + remove bridges only when fully covered by active originals. (inventory-dryrun-validate-migration-workflow) (Source: this page)

  7. Monitor the control plane you can't see failing. RAM emits resource-share state-change events to EventBridge; CloudTrail records DisassociateResourceShare API calls for audit. A weekly post-migration sweep provided periodic reconciliation to catch stale shares. (Source: this page)

  8. Inventory dependencies and destination guardrails first. The Account Assessment for AWS Organizations tool inventories RAM dependencies before wave planning. A service control policy that blocked ram:AcceptResourceShareInvitation during migration windows had to be temporarily relaxed at the destination. (Source: this page)

Affected resource types (customer-confirmed)

Resource AWS service / API Effect of losing the share
Transit Gateway ec2:TransitGateway Loses control plane; keeps data plane
Route 53 Resolver rules route53resolver:ResolverRule Risk of DNS resolution disruption
AWS Private CA acm-pca:CertificateAuthority Loses share; issued certs keep working
EC2 prefix lists ec2:PrefixList Keeps data plane; blocks new resource creation
Glue Data Catalog DBs / tables AWS Glue + Lake Formation Requires bridge-share validation before migrating

Additional handling: an AWS Firewall Manager policy can remove Network Firewall rules on cleanup (must redeploy); org-integrated CloudFormation StackSets can delete stacks unless set to retain.

Operational numbers

  • 382 accounts in scope; 378 migrated into the landing zone (final 4 awaited external-stakeholder approvals).
  • 14 non-production waves (8 months) + 1 production pilot + 12 weekly production waves + 3 contingency waves.
  • 21 accounts handled via a manual recovery path first, while automation was built.
  • 10 accounts in the embedded-payments-platform Glue/Lake-Formation share group (account IDs as principals); its production migration completed July 21, 2026.
  • Discovery → validated pattern in 2 weeks. TSA ended on schedule April 2026; TSA expiry fell inside the contingency window, leaving ~1 week of usable slack.
  • Validation: 3 test accounts across 2 organizations.
  • RetainSharingOnAccountLeaveOrganization released 2026-02-27.

Caveats

  • Vendor (AWS Architecture Blog) + customer reference-architecture framing; company names anonymized in the post.
  • No throughput/latency/cost internals for RAM itself; the "numbers" are wave counts, account counts, and dates.
  • Automation specifics (dry-run/execute modes, coverage check) are described qualitatively; command-level detail lives in the linked AWS Cloud Operations blog and aws-samples/sample-aws-ram-org-migration.

Source

  • systems/aws-resource-access-manager-ram — the share primitive at the center of the migration.
  • systems/aws-lake-formation — the service-managed source-of-truth permission object the bridge protects.
  • systems/aws-organizations — the trust boundary whose crossing triggers the failure.
  • organization-bound-resource-share — the failing association type.
  • external-principal-association — the surviving association type the bridge relies on.
  • retained-bridge-share-migration — the core pattern.
  • restore-original-share-then-delete-bridge — the cleanup discipline.
  • inventory-dryrun-validate-migration-workflow — the five-step per-wave workflow.
  • concepts/control-plane-data-plane-separation — why the failure stayed hidden.
Last updated · 766 distilled / 2,225 read