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

Summary

A global payment processor migrating 382 AWS accounts between AWS Organizations encountered control-plane failures when AWS Resource Access Manager automatically severed organization-bound resource shares. Although data planes continued operating for shared resources such as AWS Transit Gateways, infrastructure automation lost the ability to modify dependencies like AWS Glue Data Catalog databases. The engineering team resolved this by implementing temporary retained bridge shares, establishing external principal associations that survived cross-organization account transfers. Following each account move, automated tooling restored durable original shares, validated Lake Formation permissions, and deleted the bridge copies to prevent configuration drift. This bridge-share workflow enabled the migration of 378 accounts before a Transitional Service Agreement deadline without customer downtime.

Context

A global payment processor needed to migrate 382 AWS accounts out of its former parent company's AWS Organization before a Transitional Service Agreement expired in April 2026. When accounts left the source organization, AWS Resource Access Manager (AWS RAM) automatically dropped organization-bound resource share associations. This caused control-plane failures for shared resources like AWS Transit Gateway and AWS Glue Data Catalog during infrastructure updates, even though data planes remained functional.

Approach / What changed

AWS and the payment processor designed a temporary bridge-share migration pattern. Before moving an account, engineers created a parallel retained AWS RAM share as an external principal association, which survives cross-organization transfers. After transferring the account into the destination organization, automation restored the account to the original durable shares as an external principal, validated permissions, and deleted the temporary bridge shares to prevent permission drift.

Takeaways

• When an AWS account leaves an AWS Organization, AWS RAM severs organization-bound resource shares, breaking control-plane modifications for services like AWS Transit Gateway while data planes typically persist.
• External principal associations created via accepted AWS RAM share invitations survive cross-organization account transfers, enabling temporary bridge shares during migrations.
• Temporary bridge shares must be deleted after restoring migrated accounts to original shares to prevent duplicate permission state and drift in AWS Lake Formation.

Related reading

• Slack · May 5, 2026

  From SSH to REST: A Security-Driven Modernization of Slack’s EMR Data Pipelines

  Slack's data platform accumulated over 700 SSH-based Airflow operators executing jobs directly on AWS Elastic MapReduce clusters, creating broad security surfaces and operational instability. Stateful SSH connections frequently failed when Kubernetes pods restarted, leaving orphaned zombie processes and preventing infrastructure modernization such as migrating EMR clusters to child accounts. To eliminate SSH access, Slack adopted a REST-based architecture using Quarry, a gateway providing unified REST APIs and token authentication across compute engines. For non-Hadoop CLI workloads, Slack leveraged YARN Distributed Shell to execute arbitrary shell scripts stored in Amazon S3 within managed, isolated YARN containers. The phased migration achieved zero downtime across eight data regions, unlocking reliable monitoring, simplified onboarding, and future initiatives like Spark on Kubernetes.

  Mahendran Vasagam

• Slack · May 28, 2026