全球支付处理商在AWS Organizations迁移中如何保留AWS RAM共享和Lake Formation权限
内容提要
一家全球支付处理商在382个AWS账户迁移中，通过临时AWS RAM桥接共享保留Lake Formation权限。迁移时原组织共享失效，桥接共享维持访问，迁移后恢复原共享并删除桥接。此模式两周内验证，确保服务不中断，最终378个账户成功迁移，无客户影响。
延伸解读
控制面与数据面的分离是迁移风险的关键
文章指出，当AWS RAM共享关系因账户迁移而断开时，多数服务的数据面（如已运行的EC2实例、已建立的网络连接）仍能正常工作，但控制面（如通过Terraform修改共享资源）会立即失效。这种隐蔽性导致问题在2月的一次生产环境中才暴露，此前非生产环境测试均未发现。迁移前应重点检查依赖控制面的基础设施即代码（IaC）操作，并针对每个生产风险建立能复现该边界条件的测试环境。
桥接共享的临时性与恢复原共享的必要性
桥接共享（bridge share）是迁移期间临时保留访问权限的手段，但并非最终状态。文章强调，原共享是AWS Lake Formation管理的持久权限对象，迁移期间新增的授权或资源变更只会附加到原共享，而不会自动同步到桥接共享。因此，迁移后必须将账户恢复至原共享，并验证其关联状态为ASSOCIATED后，才能删除桥接共享，否则会形成两套权限路径，导致权限漂移和审计困难。
迁移验证需跨越真实组织边界
该支付处理商的非生产账户原本就位于独立组织中，从未跨越生产环境所面临的组织边界，因此14个非生产波次均未触发权限失效问题。这提示，任何迁移验证环境都必须模拟与生产相同的信任边界条件，否则无法暴露组织绑定共享在账户迁出时的行为差异。AWS在测试中确认，仅设置allowExternalPrincipals不够，还必须启用retainSharingOnAccountLeaveOrganization，才能让桥接共享在迁移后继续生效。
Q&A
AWS Organizations迁移时，为什么原有的AWS RAM资源共享会失效？
因为组织绑定的资源共享通过账户的组织成员身份来信任账户，当账户离开组织时，AWS RAM会移除该关联。
桥接共享（bridge share）是如何在账户迁移期间保持访问的？
在迁移前创建一个保留的桥接共享，作为外部关联，账户接受邀请后，即使原组织绑定共享失效，桥接共享仍能保持访问。
迁移后为什么必须恢复原始共享并删除桥接共享？
原始共享是AWS Lake Formation管理的持久权限对象，新授权和资源变更都附加到它。保留桥接会导致重复权限状态和漂移，因此迁移后需恢复原始共享并删除桥接。
在AWS Organizations迁移中，哪些资源类型会受到影响？
AWS Transit Gateway、Amazon Route 53 Resolver规则、AWS Private CA、EC2前缀列表、AWS Glue Data Catalog数据库和表等。它们可能失去控制平面访问或面临DNS中断风险。
为什么非生产测试没有发现资源共享失效的问题？
因为非生产账户已经在单独的组织中，没有跨越导致生产关联失效的组织边界，所以测试未暴露该问题。
应用桥接共享模式的五个步骤是什么？
1. 清单：映射每个原始共享、资源、主体、权限和区域；2. 创建并接受桥接：创建保留共享并接受邀请；3. 迁移账户；4. 恢复原始共享：将账户ID添加回原始共享；5. 验证并删除桥接：确认覆盖后删除。
AWS RAM的RetainSharingOnAccountLeaveOrganization设置有什么作用？
该设置使新资源共享在账户接受邀请后将主体标记为外部，从而在账户离开组织时保留共享。但它不适用于现有共享，因此需要临时并行共享。
这次迁移的最终结果如何？
382个账户中378个成功迁移，剩余4个等待外部批准。TSA按时结束，没有客户工作负载中断，也没有网络中断。
