AWS Organizations間のアカウント移行でRAM共有とLake Formation権限を失わない方法

なぜこの話が実務で重要なのか

AWS Organizations内のアカウントを別のOrganizationsへ移す作業は、M&Aや分社化（divestiture）、グループ再編などで思った以上に頻繁に発生します。問題はAWS RAM（Resource Access Manager）のリソース共有が絡んでいる場合です。

組織に紐づく共有（organization-bound share）は、アカウントが組織を離れた瞬間にAWS RAMがその関連付けを自動的に削除します。データプレーンは生きているのにコントロールプレーンだけが死ぬという奇妙な障害がここで発生します。Terraformのapplyが突然permission errorで落ちるのに、トラフィックは正常に流れている、という状況です。

本記事では、グローバル決済処理企業が382アカウントをOrganizations間で移行する際に、**ブリッジ共有（bridge share）**パターンでLake Formation権限を保持した事例を扱います。単なる要約ではなく、なぜこのパターンが必要なのか、どんな落とし穴があるのかを実務視点で解説します。原文の流れは根拠資料で確認できます。

核心となる原理：組織バウンド共有 vs 外部共有

AWS RAMは2つの方法でprincipalを信頼します。

1. 組織メンバーシップベース（organization-bound）： 同じOrganizations内にいれば自動信頼。アカウントIDを指定しても組織メンバーシップで信頼されます。
2. 外部招待ベース（external）： Organizations外のprincipalには招待（invitation）を送り、承諾されれば外部関連付けとして維持されます。

重要なのは外部関連付けは組織メンバーシップに依存しないため、アカウントが移動しても生き残るという点です。ブリッジ共有パターンはこの性質を利用します。

ブリッジ共有ワークフロー（5ステップ）

# 1) インベントリ：リージョンごとに元の共有/リソース/principal/権限をマッピング
# AWS RAMはリージョンサービスなので、スコープ内の全リージョンで繰り返す必要があります。
aws ram list-resource-shares --region ap-northeast-1 --resource-owner SELF

# 2) ブリッジ作成 + 承諾（移行前に必ず承諾）
aws ram create-resource-share \
  --name bridge-share-for-migration \
  --resource-arns arn:aws:glue:ap-northeast-1:111122223333:catalog \
  --principals 444455556666 \
  --allow-external-principals \
  --retain-sharing-on-account-leave-organization \
  --region ap-northeast-1

# コンシューマアカウントで招待を承諾（移行前に完了）
aws ram accept-resource-share-invitation \
  --resource-share-invitation-arn <invitation-arn> \
  --region ap-northeast-1

# 3) アカウント移動（Organizations間の直接移動が可能、中間のstandalone期間は不要）

# 4) 元の共有にマイグレーション済みアカウントIDを外部principalとして再登録
aws ram associate-resource-share \
  --resource-share-arn <original-share-arn> \
  --principals 444455556666 \
  --region ap-northeast-1

# 5) 検証後にブリッジ削除（元の共有が完全にカバーしている場合のみ）
aws ram delete-resource-share --resource-share-arn <bridge-share-arn> --region ap-northeast-1

⚠️ allowExternalPrincipalsだけでは不十分です。2026年2月に追加されたretainSharingOnAccountLeaveOrganization設定も併せて有効化する必要があります。この設定は新規作成した共有にのみ適用され、既存の共有には遡及適用されません。そのため既存の共有には一時的な並列共有（ブリッジ）が必要なのです。

注意事項：データプレーンが生きていても油断は禁物

この事例で最も危険だったポイントは、非本番テストでは絶対に再現できないという事実でした。非本番アカウントはすでに別のOrganizationsに属しており、本番で壊れる信頼境界を越えていなかったのです。14回のクリーンなウェーブはプロセスを検証しましたが、本番固有の条件は捉えられませんでした。

リソースタイプ別の影響まとめ

追加で壊れるもの

• AWS Firewall Managerポリシー：リソースクリーンアップ設定によってはNetwork Firewallルールが削除され、再デプロイが必要
• CloudFormation StackSets（組織統合型）：retain設定をしないとスタックが削除される
• SCP：マイグレーションウィンドウ中にram:AcceptResourceShareInvitationをブロックするSCPがある場合は一時調整が必要

なぜ元の共有を必ず復元すべきか

ブリッジはマイグレーション専用の一時コピーです。Lake Formationが作成した元の共有がdurableな権限オブジェクトです。マイグレーションウィンドウ中に追加されたgrantは元の共有にのみ付き、ブリッジには自動反映されません。両方を残すと権限状態が二股に分岐（drift）し、監査（audit）が複雑化し、どちらが真の権限か分からなくなります。そのため自動化は、元の共有がブリッジのリソース/principal/権限を完全にカバーし、すべてのassociationがASSOCIATED状態である場合にのみブリッジを削除するよう設計されています。

💡 日本の金融・SI環境ではSCPと監査ログ（CloudTrail）要件が厳しいため、ブリッジ共有を作成する瞬間から変更履歴が残るようタグ戦略を事前に設計することを推奨します。ram:ResourceShareInvitationArnイベントをEventBridgeで受け取りSlack通知を仕込めば、stale shareを早期に検出できます。

まとめ：実務適用のためのチェックリスト

この事例から抽出できる教訓は3つです。

1. 検証境界を本番と一致させよ。 テスト用Organizationsが本番と同じ信頼境界を越えなければ、この失敗は絶対に再現されません。最初のウェーブ前に、各本番リスクを再現可能な環境にマッピングしてください。
2. コントロールプレーンの変化を監視せよ。 AWS RAMはリソース共有状態変更イベントをEventBridgeへ直接エクスポートし、CloudTrailがDisassociateResourceShare API呼び出しを記録します。週次post-migration sweepでstale shareを整理する習慣が大きな事故を防ぎます。
3. 依存関係と移行先ガードレールを同時にインベントリ化せよ。 Account Assessment for AWS OrganizationsツールでRAM依存関係を事前抽出し、移行先OrganizationsのSCPも同時点でレビューしてください。

ブリッジ共有は一時的である点が核心です。元の共有を復元してこそLake Formation権限が将来のgrantと整合し、権限状態が二つに分岐する事態を避けられます。

次のステップ学習方向

• aws-samples/sample-aws-ram-org-migrationスクリプトをdry-runモードで先に実行してください。リージョン別・アカウント別の検証が必須です。
• Glue Data CatalogやLake Formationがスコープに入る場合はAWS account teamを早期に招集してください。2週間でパターンが検証されたのもこの協業の賜物です。

あわせて読みたい記事

• PMTUDブラックホール、Cloudflare Oneがリアルタイムで解決します — ネットワーク経路問題をリアルタイムで捉えるアプローチに興味があれば。
• CSS Gridでジグザグ（滝）レイアウトを作る translateY(%)の隠れた魔法 — フロントエンドレイアウトに少し目を向けたいときに。