![[アップデート] AWS Organizations にアカウント直接転送機能が追加されました！](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-2eddd7f989fa67416ea2d27b4223cc32/8f5b157eb82ee11cc288225119e0c290/aws-organizations?w=3840&fm=webp)
[アップデート] AWS Organizations にアカウント直接転送機能が追加されました！
はじめに
2025年11月19日、AWS Organizations にアカウント直接転送機能が追加されました!
この機能により、組織間でアカウントを移動する際のプロセスが大幅に簡素化されます。
AWS Organizations を使用したアカウント移動における課題
AWS Organizations を使用してマルチアカウント環境を管理している組織では、M&A や組織再編などの理由で、アカウントを別の Organizations に移動させることがあります。
従来、組織 A から組織 B にアカウントを移動する際には、以下の手順が必要でした。
従来の手順
- 組織 A からアカウントを削除してスタンドアロン状態にする
- スタンドアロン状態のアカウントで支払い方法や連絡先情報を手動で設定する
- 組織 B からアカウントに招待を送信する
- アカウントで招待を承諾する
従来の課題
- アカウントが一時的にスタンドアロン状態になり、統合請求が途切れる
- ガバナンス機能(SCP など)へのアクセスが一時的に失われる
- スタンドアロン状態の間、支払い方法や連絡先情報を手動で設定する必要がある
- 複数アカウントを移動する場合、手動作業が膨大になる
今回リリースされた直接アカウント転送機能は、この「一時的なスタンドアロン状態」を経由せずに、組織間で直接アカウントを転送できるようになるというアップデートになります。
主な機能
直接アカウント転送機能を使用すると、以下のように動作が変わります。
転送プロセスの簡素化
従来と同じく、組織がアカウントを招待し、対象アカウントが受け入れるという手順で完了します。
ただし、アカウントが既に別の組織に所属している場合でも、直接招待を承諾することで自動的に転送されます。
自動的に処理される内容
アカウント転送時に、AWS Organizations が以下の処理を自動的に実行します。
-
統合請求の継続
アカウントがスタンドアロン状態にならないため、統合請求が途切れません。 -
支払い情報の維持
支払い方法や連絡先情報の再設定が不要です。 -
転送元組織からの自動削除
招待を承諾すると、転送元の組織から自動的に削除されます。 -
転送先組織への自動追加
転送先組織の Root 直下に自動的に追加されます。
主なメリット
- アカウントの移動プロセスが簡素化され、運用負荷が軽減される
- スタンドアロン状態を経由しないため、統合請求とガバナンス機能が途切れない
- 支払い情報の再設定が不要になり、設定ミスのリスクが低減される
- M&A プロジェクトなど大規模なアカウント転送作業が効率化される
アカウント直接転送機能を試してみた
検証環境の準備
今回の検証には、以下の環境を用意しました。
- 組織 A (転送元): itkr_mem02 が現在所属している組織 (AWS Control Tower 利用中)
- 組織 B (転送先): itkr_mem02 を受け入れる組織 (AWS Control Tower 利用中)
- itkr_mem02: 組織 A の SandboxOU に所属しているメンバーアカウント
組織 A と組織 B の両方で AWS Control Tower を利用しています。
itkr_mem02 は組織 A の SandboxOU に所属しており、24 個の Control Tower コントロールが有効になっている状態です。
組織 B から招待を送信する
組織 B の管理アカウントにログインし、AWS Organizations コンソールを開きます。
「AWS アカウント」>「招待」の順にクリックします。
「AWS アカウントを招待」をクリックします。
「既存の AWS アカウントを招待」を選択し、「itkr_mem02 のアカウント ID（もしくは AWS アカウントの E メールアドレス）」と「招待 E メールメッセージに含めるメッセージ（オプション）」を入力し、「招待を送信」をクリックします。
招待が送信されたことを確認します。
「すべての招待を表示」をクリックすると、招待したアカウント ID が表示されます。
itkr_mem02 で招待を承諾する
itkr_mem02 (現在は組織 A のメンバー)にログインし、AWS Organizations コンソールを開きます。
現在は組織 A （管理アカウントの E メールアドレスが @gmail.com）に所属していることを確認します。
「招待」を確認すると、組織 B（管理アカウントの E メールアドレスが ～classmethod.jp）からの招待が表示されています。
内容を確認して「招待を承認する」をクリックします。
確認ダイアログが表示されるので、内容を確認して「招待を承認する」をクリックします。
従来のように組織 A からの削除作業は不要です。
秒で切り替わりました。もっと時間かかるかと思っていたのにびっくり。。。
転送完了を確認する
組織 B の管理アカウントで itkr_mem02 が組織 B に所属していることを確認します。
先ほどの招待はステータスが「ACCEPTED」に変わっていました。
itkr_mem02 が Root 直下に追加されていることも確認できます。
組織 A の管理アカウントで確認すると、itkr_mem02 が自動的に削除されています。
従来であれば、組織 A からの手動削除→スタンドアロン状態での設定→組織 B への招待承諾という 3 ステップが必要でしたが、直接転送機能により招待承諾の 1 ステップのみで完了するようになりました。
AWS Control Tower コントロールの状態確認
今回の検証では、AWS Control Tower を利用している組織間でアカウントを転送しました。
転送前後でのコントロールの状態変化を確認してみます。
■ 転送前(組織 A の SandboxOU 所属時)
itkr_mem02 には、SandboxOU に設定されている 24 個のコントロールが有効になっていました。
有効だったコントロール一覧 (クリックで展開)
[CT.KMS.PV.1]Require an AWS KMS key policy to have a statement that limits creation of AWS KMS grants to AWS services[AWS-GR_AUDIT_BUCKET_RETENTION_POLICY]Set a retention policy for log archive[CT.KMS.PV.4]Require that an AWS KMS customer-managed key (CMK) is configured with key material originating from AWS CloudHSM[CT.KMS.PV.2]Require that an AWS KMS asymmetric key with RSA key material used for encryption does not have a key length of 2048 bits[CT.EC2.PV.5]Disallow the use of Amazon EC2 VM import and export[AWS-GR_AUDIT_BUCKET_LOGGING_ENABLED]Disallow modification of server access logging for an Amazon S3 bucket[CT.KMS.PV.3]Require that an AWS KMS key is configured with the bypass policy lockout safety check enabled[AWS-GR_RESTRICT_S3_CROSS_REGION_REPLICATION]Disallow cross region replication for S3 buckets[AWS-GR_DISALLOW_CROSS_REGION_NETWORKING]Disallow cross-region networking for Amazon EC2, Amazon CloudFront, and AWS Global Accelerator[CT.LAMBDA.PV.1]Require an AWS Lambda function URL to use AWS IAM-based authentication[AWS-GR_DISALLOW_VPN_CONNECTIONS]Disallow Amazon Virtual Private Network (VPN) connections[CT.KMS.PV.6]Require that an AWS KMS customer-managed key (CMK) is configured with key material originating from an external key store (XKS)[CT.APPSYNC.PV.1]Require an AWS AppSync GraphQL API to be configured with private visibility[AWS-GR_DISALLOW_VPC_INTERNET_ACCESS]Disallow internet access for an Amazon VPC instance managed by a customer[CT.MULTISERVICE.PV.1]Deny access to AWS based on the requested AWS Region for an organizational unit[AWS-GR_AUDIT_BUCKET_POLICY_CHANGES_PROHIBITED]Disallow policy changes to an Amazon S3 bucket[CT.EC2.PV.4]Require that Amazon EBS direct APIs are not called[CT.EC2.PV.2]Require that an attached Amazon EBS volume is configured to encrypt data at rest[AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED]Disallow modification of an Amazon S3 bucket default encryption[CT.EC2.PV.6]Disallow the use of deprecated Amazon EC2 RequestSpotFleet and RequestSpotInstances API actions[CT.EC2.PV.1]Require an Amazon EBS snapshot to be created from an encrypted EC2 volume[AWS-GR_REGION_DENY]Deny access to AWS based on the requested AWS Region for the landing zone[CT.EC2.PV.3]Require that an Amazon EBS snapshot cannot be publicly restorable[CT.KMS.PV.5]Require that an AWS KMS customer-managed key (CMK) is configured with imported key material
■ 転送後(組織 B の Root 直下に配置)
転送後、itkr_mem02 は組織 B の Root 直下に配置されました。
組織 A の SandboxOU に設定されていた Control Tower コントロールは自動的に解除されます。
■ 重要なポイント
直接転送機能により、以下の処理が自動的に実行されます。
- 転送元 OU (組織 A の SandboxOU) に設定されていた Control Tower コントロールの自動解除
- スタンドアロン状態を経由しないため、AWS Organizations レベルのガバナンス (SCP など) は常に適用されている状態を維持
なお、AWS Control Tower のコントロールは OU レベルで適用されるため、Root 直下に配置されたアカウントには Control Tower コントロールは適用されません。
組織移動後、itkr_mem02 に Control Tower のガバナンスを適用したい場合は、組織 B で Control Tower 登録済みの OU へ速やかに移動する必要があります。
■ 補足
AWS Organizations の SCP (Service Control Policy) や宣言型ポリシーは Root を含むどの OU にもアタッチ可能ですが、Control Tower コントロールは登録された OU に対してのみ適用可能です。
これにより、従来のようにスタンドアロン状態でガバナンス機能が一時的に失われることがなくなりました。
注意点
直接アカウント転送機能を使用する際には、以下の点に注意が必要です。
アカウント作成後の待機期間
組織内で作成したアカウントを移動する場合、アカウント作成から最低 4 日間待つ必要があります。
招待されたアカウントには、この待機期間は適用されません。
クローズまたはサスペンド状態のアカウント
クローズまたはサスペンド状態のアカウントは移動できません。
アカウントを再アクティブ化するには、AWS サポートに連絡する必要があります。
委任管理者権限の事前削除
アカウントが委任管理者として登録されている場合、移動前に委任管理者権限を削除する必要があります。
IAM ポリシーと SCP の確認
アカウント移動を妨げる IAM ポリシーや SCP がないことを事前に確認する必要があります。
また、組織 ID を指定している IAM ポリシー(aws:PrincipalOrgID など)は、移動後に更新が必要です。
転送先組織の OU に移動する前に、適切なポリシーとアクセス許可を確認することを推奨します。
さいごに
AWS Organizations の直接アカウント転送機能を実際に試してみました。
従来はアカウントを組織間で移動する際、一時的なスタンドアロン状態を経由する必要がありましたが、この機能により招待承諾のみで直接転送できるようになりました。
一見すると小さな改善に見えるかもしれませんが、M&A プロジェクトや組織再編などで複数のアカウントを定期的に移動する運用を行っている環境では、この自動化は大きな運用負荷の軽減につながると感じました。
また、スタンドアロン状態を経由しないため、統合請求とガバナンス機能が途切れることなく、支払い情報の再設定も不要になった点も良いアップデート内容だと感じました。
AWS Organizations を使ってマルチアカウント環境を運用していて、組織間でのアカウント移動が発生する可能性がある方は、ぜひこの機能を活用してみてください。
この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら(@itkr2305)でした!
