【re:Invent 2025】AWSアカウントのOrganizations移行における“Direct Transfers”を使ってみる

記事タイトルとURLをコピーする

re:Invent 2025 参加レポート:AWS Organizations 間のアカウント移行について、“直接移行”が提供。

re:Invent 2025 に参加してきました!CC1課の森井です。

今回の re:Invent 周辺では、マルチアカウント運用に関わる重要なアップデートが複数発表されました。その中でも特にインパクトが大きいのが、AWS Organizations(A) から Organizations(B) へ、アカウントを “直接移行 (Direct Account Transfers)” できるようになった という点です。

これまでは「招待 → 承認 → 移行準備 → 各種設定のやり直し…」と、多くのステップと調整が必要でしたが、今回の新機能によって作業は大幅に簡素化されています。

アップデート自体は、11月19日にリリースされていましたが、re:Inventセッション [NEW LAUNCH] New capabilities for achieving effective governance at scale (COP365) を参考に、従来の流れと最新アップデートの比較をわかりやすく整理していきます。


⚠️ 注意事項

サーバーワークスの 請求代行サービスをご利用中のお客様は、本機能を使用しないようお願いいたします。 複数 Organizations の統合やアカウント移行をご希望の場合は、弊社担当までご相談ください。


Organizations 移行の主なユースケース

AWS アカウントを別 Organizations に移行したいシーンは数多くあります。代表的なものは次のとおりです。

  • M&A による企業グループ再編 企業買収や統合に伴い、複数の AWS Organizations を集約したいケース。
  • ホールディングス体制でのアカウント統合 グループ企業ごとの AWS 管理が散在し、セキュリティガバナンスの標準化が必要な場合。
  • 管理主体の切り替え 運用委託先や事業部間の管理権限を変更したい場合。

こうした場面で、必要になるのが、AWSのマルチアカウント運用及びガードレールの構築ですが、 その対応を行うためのファーストステップとして、Organizations 間のアカウント移行は避けて通れません。


今回のアップデート:Direct Account Transfers による移行簡略化

AWS は 2025 年 11 月、AWS Organizations Direct Account Transfers を発表しました。 これにより、アカウント移行に必要なステップは劇的に簡素化されています。

re:Invent 2025 Choke talk スライド

1.従来のOrganizations間の移行ステップ

  1. メンバーアカウントの脱退(多くの場合、以下2~4の前提条件不足で失敗)
  2. 支払い情報の登録(カード登録など、請求書払いの場合は、別途AWSサポートへの依頼が必要)
  3. アカウント管理者の情報確認(管理者情報の住所・会社名・所在地など)
  4. サポートプランの選択(Basic、Developper、Enterpriseなど)
  5. メンバーアカウントの脱退を行い、スタンドアロンアカウント化する(※これが、大きな手間)
  6. 新しい Organizations から招待
  7. スタンドアロンアカウントで招待を承認

(補足)スタンドアロン化によって発生する課題

一次的にスタンドアロン化することにより、従来のOrganizationsのメンバーとして加入していたことによって受けられていた恩恵が受けられなくなります。 例えば、以下のような問題が発生します。

〇請求書が増えます。 Organizations移行において、請求書が以下のような単位で分かれます。 ・請求書①:前Organizations加入時に発生していた利用料 ・請求書②:スタンドアロンアカウント時に発生した利用料 ・請求書③:新Organizations加入によって発生した利用料 ※あくまで、各状態にて、利用料が発生する事由があった場合に、請求書が分かれてしまします。

〇ReservedInstanceやSavingsPlansなどの共有を受けられなくなる時間が増えます、 ReservedInstanceやSavingsPlansなどは、Organizations内のアカウントで共有設定をすることができます。 ※弊社佐竹が詳しく解説しているブログを参考にしていただけたらと思います。

blog.serverworks.co.jp

blog.serverworks.co.jp

Organizationsの移行ステップが増えれば増えるほど、従来RISPを購入していた共有アカウントと同居しない(共有された状態にならない)時間が増え、RISPを無駄に消費する時間が増えてしまいます。(アカウント数が多いほどより顕著になります。)

2.直接移行に対応した後の移行ステップ

以下の通り、ステップが2ステップに簡素化されました、

  1. 新しい Organizations から招待
  2. 移行したいアカウントで招待を承認

※アカウントのスタンドアロン化をせず移行が行える。

これにより、各メンバーアカウントで個別の設定などを行わずとも、新Organizationsへの移行を行うことができます。

実際の手順

このシナリオでは、以下のようにアカウント移行を実施してみます。

①新しい Organizations から招待

・招待元のOrganizations管理アカウントから、招待したいアカウントを招待します。

・招待が送信できると、以下の様に、ステータスOPENとして、表示されます

②移行したいアカウントで招待を承認

・招待されたアカウントに以下のようなメールが飛びます。Accept Invitationを押下します

・招待を承諾すると、以下のように移行先OrganizationsのRootOU配下にアカウントが配置されます。

・招待を行ったOrganizationsアカウントでも、招待ステータスが、ACCEPTEDに変わっています。

尚、当件は、以下OrganizationsFullAccessが付与されているユーザーにて操作を行っております。

  
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSOrganizationsFullAccess",
            "Effect": "Allow",
            "Action": "organizations:*",
            "Resource": "*"
        },
        {
            "Sid": "AWSOrganizationsFullAccessAccount",
            "Effect": "Allow",
            "Action": [
                "account:PutAlternateContact",
                "account:DeleteAlternateContact",
                "account:GetAlternateContact",
                "account:GetContactInformation",
                "account:PutContactInformation",
                "account:ListRegions",
                "account:EnableRegion",
                "account:DisableRegion",
                "account:PutAccountName",
                "account:GetAccountInformation"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AWSOrganizationsFullAccessCreateSLR",
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": "organizations.amazonaws.com"
                }
            }
        }
    ]
}
  

アカウント移行に関する注意点

re:Inventセッション [NEW LAUNCH] New capabilities for achieving effective governance at scale (COP365)にて、アカウント移行についての注意点が紹介されていました。こちらも併せてアカウント移行について対応いただくのがよろしいかと思います。

re:Invent 2025 Choke talk スライド

① Account Quotas(アカウント上限)

・Organizations には「管理できるアカウント数の上限(クォータ)」がある ・招待(Invite)を送るには、その上限に空きが必要 ・未承認(Pending)の招待も、すでに1アカウント分としてカウントされる ➡Organizations配下に登録可能なアカウント数はデフォルト10になります。事前に移行計画を踏まえて、拡張が必要な場合は、拡張しておくことを推奨いたします。

docs.aws.amazon.com

② Permissions(権限)

・管理アカウント側:アカウント招待を送信するための IAM 権限が必要 ・メンバーアカウント側:招待を「承認(Accept)」するための IAM 権限が必要 ➡こちらは、先にご説明した通り、OrganizationFullAccessなど、Organizationに対して、操作を実行できるIAMを有したユーザーにて対処いただくことを推奨いたします。

docs.aws.amazon.com

③Time to Accept(承認期限)

・招待を受け取ってから 14日以内 に承認が必要 ➡Organizationの招待を送信したら、その招待の有効期限は2週間(14日)となります。期限が切れた場合は、再招待する必要があります。

④ Cancel Invites(招待のキャンセル)

・まだ承認されていない招待はキャンセル可能 ➡招待はキャンセルすることが可能です。誤ったアカウントIDに招待をしてしまった(招待後、招待メールが飛んでいなかった)場合などにおいては、招待を取り消すことを推奨いたします。 ※Organizationでは、一括請求(メンバーアカウントの請求が親アカウントに集約)されるため、自社と関係のないアカウントの利用料を支払うといったリスクが生まれてしまいます。アカウントIDは正確に確認いただくことを推奨いたします。

⑤ Delegated Admins(委任管理者)

AWS Organizations と連携するサービス(例) ・Security Hub ・GuardDuty ・AWS Config など これらで Delegated Administrator(委任管理者) を設定している場合 組織を抜ける前 or 別組織に参加する前に解除(deregister)が必要 ➡移行しようと思っているアカウントが、Organizations内で何らかの委任管理者に設定されている場合は、以下のようなエラーが出ます。 招待を承認する前に、当該アカウントの委任管理者の設定を除外してから、移行を承諾を押下する必要があります。


まとめ:マルチアカウント戦略の再設計がしやすい時代へ

今回の Direct Account Transfers により、Organizations の枠組みを超えたアカウント移行がはるかに実行しやすくなりました。

特に M&A やグループ再編が多い企業、またはマルチアカウント運用におけるAWSのガバナンスにおいて、全体最適を目指そうとしているタイミングにとって、AWSアカウントにおける横断的な管理への変更の柔軟性が飛躍的に向上 します。

サーバーワークスとしても、企業のクラウドガバナンス強化やマルチアカウント最適化を引き続き支援していきます。 アカウントが点在・全体像が見えていない・管理ができていない などなど、お悩みがありましたら、お声がけをいただけますと幸いでございます。