🫨

AWS Control Tower:Organizations間移行で遭遇する「Internal Failure」の真実と解決策

に公開

はじめに

2025年後半、AWS Organizationsに待望のアップデートが舞い込んできました。

(関連情報)AWS Organizations間でのメンバーアカウントの直接移動がサポートされました

2025年11月19日のアップデートにより、Organizations間での直接のアカウント移行が可能になりました。
これまでは、アカウントを別組織へ移動させるには一度「スタンドアロンアカウント」にする必要があり、その過程でクレジットカード等の請求先情報を登録しなければならないなど、コンプライアンスやガバナンスの面で高いハードルがありました。
このアップデートにより、請求先情報の登録なしで組織間移動ができるようになり、アカウントの引っ越しが格段にスムーズになりました。
https://aws.amazon.com/jp/about-aws/whats-new/2025/11/aws-organizations-direct-account-transfers/

Organizationsレベルでの移動は簡単になりましたが、その後の「Control Towerへの登録」には依然として大きな落とし穴が潜んでいます

AWS Control Towerが有効な環境間でメンバーアカウントを移行(Organizationsの引っ越し)した際、移行先での登録に 「Internal Failure」 で失敗する事象に遭遇しました。

単なる「再試行」では解決せず、原因はメンバーアカウント側に残されたCloudFormationスタック にありました。サポートへの問い合わせで判明した詳細なメカニズムと解決策を共有します。

発生した事象

Control Towerの「アカウント自動登録」が有効な環境において、別組織から移入したアカウントをControl Towerでの管理が有効になっているOU(Sandboxなど)に配置したところ、以下のエラーが発生しました。

エラーメッセージキャプチャ画像

  • エラー内容: 次の理由により、AWS Control Tower はアカウントを登録できませんでした:Internal Fallure
  • 状況: AWS Control Tower baseline status が 「失敗」 となり、詳細が不明

移行パターンによる違い

今回の事象は、「移行元でもControl Towerを使っていたか」 が分かれ目になります。

移行元の状態 OUに入れるだけの自動登録
Control Tower未利用 成功
Control Tower利用中 失敗

原因:CloudFormationスタックによる「管理権限のゴースト」

結論から言うと、原因はメンバーアカウント側に残っていた CloudFormationスタック でした。

動作のメカニズム

  1. 移行元での登録時: Control Towerが AWSControlTowerExecution ロールを作成するために、StackSet-AWSControlTowerExecutionRole-* スタックをメンバーアカウントにデプロイします。
  2. 移行元での解除時: 管理を解除すると、ロール自体は削除されますが、スタック(の抜け殻)はメンバーアカウントに残ります。
  3. スタックの「固執」: このスタック内では「 AWSControlTowerExecution ロールはこの私が管理しているリソースである」という記録が残ったままになります。
  4. 移行先での登録失敗: 移行先のControl Towerが新しいスタックで同名のロールを作ろうとしますが、CloudFormationの仕様により 「他のスタックが管理しているリソース(名前)は作成できない」 と拒否され、結果として Internal Failure が発生します。

CloudFormationスタックによるAWSControlTowerExecutionロールの管理競合の図解
※この図解はGoogleのAI「Gemini」を使用して生成しました。

解決手順

別のControl Tower環境へアカウントを移入し、スムーズに自動登録を完了させるには「お掃除」が不可欠です。

  1. 【移行元】 AWS Control Towerの「アカウントの登録解除」を実施する。
  2. 【メンバーアカウント】 移行対象アカウントにログインし、CloudFormationコンソールから StackSet-AWSControlTowerExecutionRole-* スタックを削除する。
    ※このスタックが残っていると、新しい組織での自動登録が100%失敗します。
  3. 【組織移動】 Organizations間でアカウントの移行(招待・承諾)を実施する。
  4. 【移行先】 対象アカウントをControl Tower管理下のOUに移動する。

これにより、新しい組織のControl Towerがクリーンな状態でスタックを再デプロイし、登録が成功します。

まとめ

Control Tower環境への移行は、移行元が「まっさらな状態(Control Tower未経験)」か「過去の利用歴があるか」で挙動が変わります。
Internal Failure が出たら、まずはメンバーアカウントのCloudFormationスタックを確認してみましょう。

関係資料

レスキューナウテックブログ

Discussion