この記事について
2 つの AWS Organizations を 1 つにまとめます。
どちらの組織でも IAM Identity Center（以下 IdC）を使っている前提です。
管理アカウントは OU に入れても SCP が効きません。
管理アカウントにはワークロードを置かないことが推奨されています（管理アカウントのベストプラクティス）。
この記事では管理アカウントをルート直下に置いて説明します。
3 行でわかる結論
| ポイント | |
|---|---|
| 1 | 組織をまとめてマージする機能はない → アカウントを 1 つずつ移す |
| 2 | メンバー（004）は 直接転送 で移せる。 → 管理（003）は 組織 B を削除してから 移す |
| 3 |
IdC の権限・組織 ID 条件・RAM 共有は引き継がれない。 → ここで業務影響が出る |
全体像
アカウントの種類で移し方が変わる
直接転送は 2025 年 11 月に追加された機能です。
以前のように一度スタンドアロンにして、支払い方法やサポートプランを登録し直す必要はありません（What's New）。
全体の流れ
①② の準備に一番時間をかけます。
④ は元に戻せないので、③ の動作確認が全部終わってから実施します。
要注意：「004 は A、003 は B」の中間期間
この構成では、③〜⑤ のあいだ 004 と 003 が別の組織にいる期間 が必ずできます。
中間期間には、次のようなことが起きる可能性があります。この期間はなるべく短くし、④⑤ は同じ作業枠で続けて行います。
- 003⇔004 の共有 VPC（サブネット共有）が切れ、Auto Scaling などで新しいリソースを作れない（VPC 共有）
- 組織 ID で絞った設定があると、003 と 004 の間のアクセスが拒否される
- 003 は、組織 B の削除から A に入るまでの間、組織の CloudTrail 証跡に記録されない（Part 3 ブログ）
- 004 が GuardDuty などの委任管理者だと、解除後は組織全体の検出結果をまとめて見る場所がなくなる（各アカウントの中では見られる）
- 003 の RI / Savings Plans の割引を 004 が受けられなくなる
移行手順
① 棚卸し
前提条件を確認する
移行できる条件を満たしているかを、最初に確認します（公式）。
| 項目 | 条件 | 確認・対処 |
|---|---|---|
| 📅 アカウントの経過日数 | 組織内で作成したアカウントは、作成から 4 日以上たっていること | 招待で組織に入ったアカウントは対象外 |
| 🏢 請求元の会社（Seller of Record） | 移すアカウント（003・004）と A の管理アカウント（001）で、請求書を出す AWS の会社が同じこと | 請求コンソールの「支払い設定」→「サービスプロバイダー」で確認（公式） |
| 🚫 組織から抜ける権限 | 004 が組織 B から抜けられること（organizations:LeaveOrganization） |
B の SCP で禁止していたら、移行の間だけ 004 を対象から外す |
| 🔢 アカウント数の上限 | 移行後のアカウント数が A の上限に収まること（既定は 10。送った招待も数に含まれる） | 足りなければ A の管理アカウントから Service Quotas で引き上げを申請（公式） |
| 🏗️ Control Tower | B で使っている場合は、移す前にアカウントを Control Tower から登録解除すること | A で使っている場合は、移行後に登録（Auto Enroll なら自動）。アカウントを別の組織に転送する |
組織 B に何が依存しているか
赤い 4 つは、アクセス拒否・通信断・リソース削除に直結 します。
| 依存先 | 抜けると起きること | 先にやる対策案 |
|---|---|---|
| 組織 ID 条件 | S3 / KMS / 信頼ポリシーでアクセス拒否 | 移行期間だけ A・B 両方の組織 ID を許可する |
| RAM 組織共有 | 共有が外れて通信断 | 組織を抜けても共有が残る設定で共有を作り直す（2026-02 追加）。VPC サブネット共有は対象外 |
| IdC が作るロール | KMS キーポリシーやバケットポリシーで、IdC のロール名（AWSReservedSSO_権限セット名_ランダム文字列）を指定して許可していると、移行でロールが作り直されて末尾が変わり、拒否される |
そのポリシーの指定を、末尾を * にした書き方（例：AWSReservedSSO_Admin_*）に直す |
| StackSets | 設定によっては、組織を抜けた時点でスタックのリソースが削除される | 「アカウント削除時にスタックを残す」設定（RetainStacksOnAccountRemoval）を true にする |
組織 B の設定を CLI で洗い出す（ACCOUNT_003 で実行）
「委任管理者」「組織ポリシー」などが、組織 B で実際にどう設定されているかを調べます。
組織全体の設定は、組織 B の管理アカウント(すべて ACCOUNT_003 で実行)で確認します。
| 調べること | コマンド |
|---|---|
| 委任管理者になっているアカウント | aws organizations list-delegated-administrators |
| 委任管理者のアカウントごとに、任されているサービス（GuardDuty など） | aws organizations list-delegated-services-for-account --account-id <委任管理者のアカウントID> |
| 組織と連携しているサービスの候補（使っていなくても出るので、出たサービスは各サービス側で使っているか確認する） | aws organizations list-aws-service-access-for-organization |
| 組織にある SCP | aws organizations list-policies --filter SERVICE_CONTROL_POLICY |
| SCP ごとに、どの OU・アカウントに付いているか | aws organizations list-targets-for-policy --policy-id <SCP のポリシーID> |
組織 ID 条件や IdC のロール名を書いたポリシーは、上のコマンドでは見つかりません。AWS が公開している Account Assessment for AWS Organizations（英語） をデプロイすると、全アカウントのポリシーを組織 ID などで検索できます（スキャンは1日1回）。
② 受け入れ準備
IdC の「空白時間」をなくす
何も準備しないと、次のようにアクセスできない時間が生まれます。
アカウントが組織を抜けると、IdC はそのアカウントのメタデータとリソースを片付けます（Part 3 ブログ）。
空白時間を最短にするために、次を 事前に 用意します。
| 項目 | ポイント |
|---|---|
| ユーザー / グループ | B の利用者を A の IdC に用意する（同じ IdP なら、A の連携対象に B のグループを足すだけ） |
| 権限セット | B と同じ内容の権限セットを A に作る（IaC で管理していればコードを使い回す） |
| 割り当て | 「誰に・どのアカウントで・どの権限セットを使わせるか」を決めておく(アカウントが A に入ってからでないと設定できない) |
| 緊急用ロール | IdC が使えない間に備え、A の管理アカウントから入れる IAM ロールを各アカウントに作る |
| ルートユーザー | 最後の手段として、ルートユーザーのパスワードと MFA を使える状態にしておく（公式） |
移行用 OU を作る
承諾したアカウントは A のルート直下 に入り、ルートに付いている全ポリシー（SCP、RCP など）がすぐ適用されます。そのため、移行用 OU を経由して段階的に移します（Transitional OU（英語））。
A の組織単位の設定が自動で当たる
アカウントが A に入ると、A の組織証跡には自動で入ります。
GuardDuty / Config / Security Hub は、A の自動有効化の設定次第で有効になります。
- アカウント側にも CloudTrail 証跡があると、ログが二重になり課金が増える → 移行後に、アカウント側の証跡を消すか検討する
- 今まで無効だったサービスが有効になると、そのアカウントで課金が始まる
③ ACCOUNT_004 を移す（直接転送）
# ACCOUNT_001：招待（招待は 15 日で失効）
aws organizations invite-account-to-organization --target Id=<ACCOUNT_004>,Type=ACCOUNT
# ACCOUNT_004：承諾（応答待ちの招待の State は OPEN または REQUESTED）
HS=$(aws organizations list-handshakes-for-account --filter ActionType=INVITE \
--query 'Handshakes[?State==`OPEN` || State==`REQUESTED`].Id | [0]' --output text)
echo "Handshake ID: $HS"
aws organizations accept-handshake --handshake-id "$HS"
- 承諾する IAM プリンシパル（004 で承諾に使うユーザーやロール）には、次の権限が必要です（re:Post）。
organizations:ListHandshakesForAccountorganizations:AcceptHandshakeorganizations:LeaveOrganizationiam:CreateServiceLinkedRole
- 委任管理者の解除は、まずサービス側（GuardDuty ならリージョンごとに、管理者とメンバーの紐付けを外す → 管理者の指定を取り消す）で行い、最後に Organizations 側（
deregister-delegated-administrator）で行います。（例：GuardDuty）。
ロールバック：組織 B が残っている間であれば、B から再招待すれば 004 を戻せます。
④ 組織 B を解体する（元に戻せない）
# 組織 B の管理アカウントで実行
aws organizations delete-organization
⑤ ACCOUNT_003 を移す
③ と同じ流れ（招待 → 承諾 → 移行用 OU → IdC の割り当て → 動作確認 → 本番 OU）です。
中間期間を短くするため、④ に続けて同じ作業枠で実施します。
元管理アカウントは、A では ただのメンバー になり、A のガードレールがかかります。
ワークロードが載っていることが多いので、移行用 OU でじっくり確認します。
⑥ 移行後の見直し
アカウントが A に入ったら、A 側で次を見直します（公式）。
| ✅ | やること |
|---|---|
| ☐ | 税設定、サポートプラン、予算、コスト配分タグ、Marketplace のライセンスを見直す（RI / SP はアカウントと一緒に移る） |
| ☐ | アカウントと OU のタグを作り直す |
⑦ 後片付け
移行のために一時的に入れたものを消します。
| ✅ | やること |
|---|---|
| ☐ | 旧 OrganizationAccountAccessRole（003 を信頼）と、移行用の緊急ロールを削除 |
| ☐ | 組織 ID 条件から B の組織 ID を消す |
当日までのチェックリスト
① 棚卸し
- 前提条件（経過日数、請求元の会社、組織から抜ける権限、アカウント数の上限、Control Tower）を確認した
- 組織 ID 条件に A・B 両方の組織 ID を入れた
-
IdC のロール名を指定したポリシーを、末尾を
*にした書き方に直した - RAM 共有の扱いを決めた
- StackSets の「アカウント削除時にスタックを残す」設定を確認した
② 受け入れ準備
- 移行用 OU を作った
- A の IdC に、ユーザー / グループと権限セットを用意し、割り当て内容を決めた
- 緊急用のアクセス経路（IAM ロール、ルートユーザー）を用意した
④ 組織 B の削除前
- B のポリシー、IdC の割り当て、請求レポートを保存した
当日の前
- 検証用アカウントでリハーサルした
-
利用者に、作業日時と新しいアクセスポータル URL（
~/.aws/configのsso_start_url/sso_regionも変わる）を周知した
おわりに
組織の統合は、アカウントを 1 つずつ移す作業の積み重ねです。
直接転送でメンバーの移行は楽になりましたが、業務影響は「引き継がれないもの」と「組織をまたぐ中間期間」から出ます。
棚卸しで赤い項目をつぶし、リハーサルをしてから本番に臨むのが確実です。
参考
- AWS Organizations でアカウントを別の組織に移行する
- AWS Organizations が組織間の直接アカウント移行を導入
- AWS Organizations の組織間でアカウントを移動する
- AWS ブログ「AWS Organizations のメンバーアカウントを他の組織へ移行する」Part 1 / Part 2 / Part 3
- Migrating accounts between AWS Organizations from a network perspective（英語）