- AWS Organizations
- 構成管理
- 運用代行
AWSの管理会社変更や組織再編では、AWSアカウントの移管が必要になることがあります。ただし、管理権限や請求先の変更だけで済むケースもあります。
AWS Organizations間でアカウントを移管する場合と、別のアカウントへリソースを移行する場合では、手順や注意点が異なります。既存システムのアクセス権限や請求・セキュリティ設定にも影響するため、事前の確認が欠かせません。
この記事では、AWSアカウントの移管方法と選び方、具体的な手順、事前準備、注意点を解説します。移管後の確認事項や外部支援の判断基準も紹介します。
AWSアカウントの移管とは、既存のAWSアカウントを別の組織の管理下に移すことです。管理会社や請求先の変更を指す場合もありますが、必要な手続きは異なります。
AWS Organizationsでは、アカウントIDや既存のリソースを維持したまま、メンバーアカウントを別の組織へ移管できます。
AWS Organizationsの基本機能やアカウントの管理方法については、関連記事「AWS Organizations徹底ガイド」で詳しく解説しています。
AWSアカウントの移管や管理体制の変更を検討するケースには、次のようなものがあります。
管理会社・運用委託先の変更:AWSの管理権限や運用体制を別の会社に引き継ぐ
請求代行事業者との契約変更:AWS利用料金の請求・精算を担当する事業者を変更する
企業の統合・分社化・事業譲渡:組織再編に合わせてアカウントの管理主体を変更する
AWS Organizationsの構成見直し:複数の組織に分かれたアカウントを統合したり、事業部門ごとに分離したりする
AWSアカウントの移管では、何を変更したいかによって選ぶ方法が変わります。
変更したいこと | 検討する方法 | 既存アカウントの移動 |
AWSアカウントの所属組織を変えたい | AWS Organizations間の移管 | 必要 |
請求代行事業者を変更したい | 契約の切り替え、必要に応じてOrganizations間の移管 | 契約形態による |
組織を変えずに請求管理を委ねたい | Billing Transfer | 不要 |
別のアカウントにシステムを移したい | リソース移行 | 不要(リソースを移行) |
運用委託先だけを変更したい | IAM権限・運用体制の変更 | 通常不要 |
AWS Organizations間の移管では、移管先からの招待を対象アカウントが承諾することで所属組織を変更できます。現在の組織から事前に脱退する必要はありません。
請求代行事業者の切り替えは、AWSの独立した移管機能ではなく、契約・請求管理上の変更です。契約形態によっては、Organizations間の移管が必要になることもあります。
アカウント移管とリソース移行の違いは、既存のAWSアカウントをそのまま利用するかどうかです。
AWS Organizations間の移管では、アカウントIDやAmazon EC2、Amazon S3、Amazon RDSなどのリソースが維持されるため、別のアカウントへ移し直す必要はありません。
一方、事業譲渡でシステムの一部を切り離す場合や、既存アカウントを引き継げない場合は、リソース移行を検討します。
代表的な移行方法は次のとおりです。
Amazon EC2:AMIやAmazon EBSスナップショットを別アカウントと共有し、移行先でインスタンスを構築する
Amazon S3:クロスアカウントでのオブジェクトコピーやレプリケーションを利用してデータを移す
Amazon RDS:スナップショットの共有・コピーなどを利用して移行先にデータベースを復元する
リソースによって移行方法や制約が異なるため、事前の確認が必要です。
Amazon EC2、Amazon S3、Amazon RDSなどの具体的な移行方法は、関連記事「AWS同士でリソースを移行するには?」で紹介しています。
AWSアカウントの移管前には、権限、システム間の依存関係、請求・契約条件などを確認します。
移管対象のアカウントが直接移管の条件を満たしているか、次の項目を確認します。
アカウントの種類:管理アカウントかメンバーアカウントか
IAM権限:移管先から招待を送信し、対象アカウントで承諾できるか
直接移管の条件:アカウントや移管先組織の作成からの経過日数、販売事業者(Seller of Record:SOR)などの条件を満たしているか
操作を制限する設定:IAMポリシーやサービスコントロールポリシー(SCP)が移管を妨げていないか
ルートユーザーの引き継ぎ:所有者が変わる場合、メールアドレスやMFAを引き継ぐ準備ができているか
AWS Organizationsの直接移管では、移管先組織の作成から7日以上、移管元組織内で作成されたメンバーアカウントは作成から4日以上が経過している必要があります。招待によって組織に加入したアカウントには、4日間の待機条件は適用されません。また、停止・閉鎖されたアカウントは移管できず、移管対象アカウントと移管先組織のSORが一致していることも条件です。
管理アカウントは直接移管できません。元の組織からメンバーアカウントをすべて移動または削除し、組織自体を削除するなどの対応が必要です。
アカウントの所有者も変わる場合は、ルートユーザーのMFAの引き継ぎにも注意が必要です。AWS公式では、移管前に既存のMFAを解除する手順が案内されています。解除する場合は、新しい所有者が速やかにMFAを再設定できるよう準備してください。
移管元の組織に依存する設定や、既存システムとの関係を確認します。
組織のポリシー:SCPや組織IDを条件に使用しているIAMポリシーがないか
組織に依存するサービス:委任管理者、信頼されたアクセス、AWS Control Towerなどを利用していないか
リソース共有:AWS Resource Access Manager(AWS RAM)などによる組織内のリソース共有がないか
システム構成:アカウント間の連携や外部システムとの依存関係を把握できているか
作業スケジュール:作業日時、担当者、移管後の動作確認手順が決まっているか
移管対象アカウントがAWSサービスの委任管理者として登録されている場合は、事前に登録を解除します。
複数アカウントの依存関係を調べる際は、AWS公式の「Account Assessment for AWS Organizations」も活用できます。委任管理者や信頼されたアクセス、組織IDを参照するポリシーなどを検出でき、見落としやすい設定の洗い出しに役立ちます。
このソリューションはAWS環境へのデプロイが必要で、すべての依存関係を検出できるわけではありません。検出結果をもとに、移管先で再設定が必要な項目を確認します。
移管によって請求先や割引の適用条件が変わる場合があるため、次の項目を確認します。
請求・支払い:請求先、支払い方法、税務情報、AWSサポートプラン
割引制度:リザーブドインスタンス(RI)やSavings Plansの購入状況と割引共有設定
AWSクレジット:残高、有効期限、適用条件
AWS Marketplace:利用中のサブスクリプションや契約条件
個別契約:Enterprise Discount Program(EDP)などの契約・割引条件
請求代行事業者:契約の解約・切り替え条件、アカウントの管理権限、移管に必要な手続き
移管前には、Cost and Usage Report(CUR)など、必要な請求・コスト関連レポートもエクスポートしておきます。
請求代行事業者が管理するAWS Organizationsに所属している場合は、自社だけで移管を完了できるとは限りません。契約条件や必要な手続きを事業者に確認してください。
AWS Organizationsでは、2025年11月からメンバーアカウントを別の組織へ直接移管できるようになりました。移管先からの招待を対象アカウントが承諾する方式で、従来のように移管元組織から事前に脱退する必要はありません。
ここでは、直接移管の手順を5つのステップで解説します。請求代行事業者が管理する組織に所属している場合は、事前に事業者へ確認してください。また、管理アカウントの移管には別の手続きが必要です。
移管先のAWS Organizationsを用意します。既存の組織を利用する場合は、その組織の管理アカウントにアクセスできることを確認してください。
招待を送るには、移管先組織の管理アカウントでメールアドレスの確認が完了している必要があります。
移管後に適用する組織単位(OU)やサービスコントロールポリシー(SCP)も確認し、必要な権限を確保します。
招待・承諾に必要な権限と、操作を制限する設定を確認します。
移管先:organizations:InviteAccountToOrganization など、招待の送信に必要な権限がある
移管対象:organizations:ListHandshakesForAccount や organizations:AcceptHandshake など、招待の確認・承諾に必要な権限がある
移管を妨げるIAMポリシーやSCPが設定されていない
移管対象アカウントの委任管理者登録が解除されている
移管先組織の管理アカウントでAWS Organizationsコンソールを開き、次の操作を行います。
「AWS アカウント」を開く
「AWS アカウントを追加する」を選択する
「既存の AWS アカウントを招待する」を選択する
移管対象のAWSアカウントIDまたはメールアドレスを入力する
内容を確認して招待を送信する
招待は対象アカウントの登録メールアドレスに通知されます。送信後の状態はAWS Organizationsコンソールで確認できます。
移管対象のAWSアカウントにサインインし、次の操作を行います。
AWS Organizationsコンソールを開く
「招待」から保留中の招待を確認する
移管先の組織IDなどを確認する
「招待を承諾」を選択する
承諾すると、対象アカウントは移管先組織のルートに追加されます。この時点では、ルートに設定されたSCPが適用され、各OUのSCPは適用されません。
その後、対象アカウントを適切なOUへ移動すると、そのOUのSCPが適用されます。移管直後とOU移動後では権限が変わる場合があるため、それぞれの状態を確認してください。
対象アカウントが移管先組織に所属していることを確認し、次の項目を点検します。
確認項目 | チェック内容 |
IAM権限・SCP | 管理者や利用者の権限、移管先のSCPが適切に設定されているか |
請求・コスト管理 | 請求先、予算、請求アラート、コスト配分タグが適切か |
セキュリティ・監視 | ログ収集、監視、セキュリティサービスの連携が機能しているか |
バックアップ・運用体制 | バックアップの取得状況、障害時の連絡先、運用担当者が整理されているか |
移管元・移管先の関連システムが正常に動作することを確認し、作業結果を関係者に共有します。
AWSアカウントを別の組織へ移管すると、アクセス権限や監視設定、請求・割引条件などが変わる場合があります。移管対象だけでなく、移管元のシステムへの影響も確認が必要です。
AWS Organizations間の移管では、Amazon EC2やAmazon RDS、Amazon S3などのリソースは移動しないため、通常はシステムを停止する必要はありません。ただし、移管先のサービスコントロールポリシー(SCP)によってアクセスが制限されると、アプリケーションや運用作業に支障が出るおそれがあります。
また、AWS Resource Access Manager(AWS RAM)によるリソース共有は、設定によって移管後もアクセスできるかが異なります。組織IDを条件とするアクセス許可も、移管後に機能しなくなる場合があります。
移管元の別アカウントが移管対象アカウントのリソースを利用している場合、組織IDに基づくアクセス制御によって連携が失われることもあります。
移管対象のシステムが正常に動作していても、移管元の別システムに影響が出ることがあるため、双方で動作確認を実施してください。
AWSアカウントを移管しても、既存のIAMユーザーやロールは基本的に維持されます。ただし、移管元の組織に依存する認証・セキュリティ設定は、そのまま利用できるとは限りません。
主な確認項目は次のとおりです。
AWS IAM Identity Center:移管元組織の認証設定やアクセス権限の割り当てが、移管後も利用できるか
信頼されたアクセス・委任管理者:移管元組織との連携が変わるため、移管先で再設定が必要か
AWS CloudTrail:移管元の組織トレイルによるログ収集が継続されるか
AWS Config:組織単位の設定や集約先が変わっても、設定履歴を確認できるか
また、移管元の管理アカウントからアクセスするために作成されたIAMロールは、移管後も自動削除されません。
例えば、OrganizationAccountAccessRole が残っていると、移管元の管理者が引き続き対象アカウントにアクセスできる可能性があります。不要なロールや信頼関係を確認し、削除・変更する必要があります。
AWS Organizations間でアカウントを移管すると、利用料金は原則として移管先組織の一括請求に含まれます。所属組織が変わることで、割引の適用状況やコスト管理にも影響します。
リザーブドインスタンス(RI)やSavings Plansは、購入したアカウントに紐づいたまま移管されます。ただし、組織単位の割引共有範囲が変わるため、移管元・移管先の双方で料金が変動する可能性があります。
移管元の組織単位の請求レポートや履歴は、移管先に引き継がれません。移管対象アカウントでも、旧組織に所属していた期間のコスト・使用量データを参照できなくなるため、必要な情報は事前に保存してください。移管先では、AWS Budgetsやコスト配分タグなどの設定も見直します。
AWSクレジットや個別の割引契約、AWS Marketplaceのサブスクリプションについても、適用条件や請求上の取り扱いが変わる可能性があります。
請求代行事業者を切り替える場合は、既存の割引条件が継続されるとは限りません。移管前に契約内容を確認し、料金への影響を把握しておきます。
外部支援を依頼するかどうかは、アカウント数だけでなく、移管による影響を自社で把握・検証できるかで判断します。
次のような場合は、外部支援が有効です。
アカウント間の依存関係を把握できていない:移管元・移管先のアクセス権限やリソース共有に不明点があり、影響を判断できない
複数のAWSアカウントをまとめて移管する:アカウントごとに権限や請求設定が異なり、作業の調整に手間がかかる
システム停止が業務に大きな影響を与える:移管前の影響調査と移管後の動作検証を十分に行う必要がある
社内にAWSの専門知識が不足している:移管方法の選定やSCP、セキュリティ設定の確認が難しい
移管後の運用体制も見直したい:監視、障害対応、コスト管理などを含めて運用を再設計する
一方、権限やシステム間の依存関係を把握し、移管後の動作確認まで実施できるなら、自社での対応も可能です。
サーバーワークスでは、AWS環境の構築・移行支援、AWS Organizationsを活用した統合管理基盤の設計・構築、監視・運用支援などを提供しています。
AWSアカウントの統合管理や移管後の監視・運用体制の見直しについては、サーバーワークスにご相談ください。