Control Tower 環境に既存の AWS アカウントを追加する
2025.03.24コーヒーが好きな emi です。
既存の AWS アカウントを Control Tower に参加させたいシーンがありました。
過去何回も擦られたネタかもしれませんが、読むのと自分でやるのとでは理解に差があると思うので改めて記事に手順を残しておきます。
今回の検証イメージ
以下のように、右の Organizations 組織の管理アカウントを、左の Control Tower 環境に登録したいと考えています。
Control Tower に登録するには、事前に以下を確認し準備しておく必要があります。
1. AWS Config を無効化
2. 既存の CloudTrail が必要か確認し不要であれば削除
3. ガードレールの SCP で影響が出るものがないか確認する
4. STS エンドポイントが有効化されているか
5. Control Tower 用の IAM Role（AWSControlTowerExecution）を作成
6. 既存の Organizations 組織を削除（メンバーアカウントであれば旧組織を離れておく）
7. Control Tower 管理アカウントと同じ Organizations 組織に所属させる
上記事前準備が終わったら、最後に Control Tower への登録を行います。
事前準備
1. AWS Config を無効化
以下ブログのスクリプトで確認しました。
2. 既存の CloudTrail が必要か確認し不要であれば削除
以下ブログのスクリプトで確認しました。
3. ガードレールの SCP で影響が出るものがないか確認する
Control Tower では全アカウントで準拠すべき設定を強制するために「コントロール」というものを有効化できます。
このコントロールを有効にしておくと、例えば「Amazon API Gateway ステージのすべてのメソッドでキャッシュが有効になっていて、キャッシュが暗号化されているかどうかを確認します」とか、「Amazon S3 でバッキングされたオリジンを使用する Amazon CloudFront ディストリビューションでオリジンアクセス制御を設定するよう要求する」とか、そういった設定を強制することができます。
実態は裏で AWS Config が動いています。
つまり上記の例で言うと、これから Control Tower 環境に参加させたいアカウントで CloudFront ディストリビューションで Origin Access Control (OAC) が有効になっていない場合、Control Tower のコントロールが有効になっていることが原因で何かしらのエラーが発生する可能性があるわけです。
ガードレールに限らず、SCP で例えばオレゴンリージョンの利用を禁止しているにも関わらず CloudFront がオレゴンリージョンにある！みたいなケースでエラーが発生したり既存のリソースに影響が発生する可能性があります。
そういった不具合が発生しないかどうかをここで確認します。
今回 Control Tower 環境に参加させたいアカウントが別の Organizations の管理アカウントだったため、Control Tower 環境に参加させたいアカウント側でも SCP を確認しておきます。
組織の構造は以下のようになっています。青枠で「これから Control Tower に参加させたいアカウント」を表現します。
SCP を確認すると、リージョン制限の SCP を設定していました。これは今後 Control Tower 側に移植することにしましょう。
参考：limit-region の中身
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideRequestedRegions",
"Effect": "Deny",
"NotAction": [
"cloudfront:*",
"iam:*",
"route53:*",
"support:*",
"aws-portal:*",
"budgets:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"us-east-1",
"us-west-2",
"ap-northeast-1",
"ap-northeast-3"
]
}
}
}
]
}
続いて Control Tower 側の SCP を確認します。Control Tower 側の管理アカウントはピンクの枠で表現します。
まずは Root 直下に何か SCP が無いか確認しましたが、FullAWSAccess だけなので大丈夫そうですね。
続いてこれからアカウントを追加させる予定の workload OU に SCP があたっていないか確認します。直接 Organizations 側から SCP を設定していなかったので、存在していたのは「aws-guardrails-」で始まる SCP だけでした。
「aws-guardrails-」で始まる SCP に関しては以下のブログも参照ください。
Control Tower コンソールから workload OU でコントロールが何か有効になっていないか確認します。
[組織] - [workload] から有効なコントロールを確認します。
見たところ、Control Tower 側で作成されるリソース（Config や CloudWatch Logs など）の変更を拒否するコントロールが有効になっているようでした。これなら既存のワークロードに影響はなさそうです。
4. STS エンドポイントが有効化されているか
これから Control Tower 環境に追加登録するアカウントで、IAMコンソールの [アカウント設定] → [Security Token Service(STS)] から STS エンドポイントが有効になっているか確認しておきます。
良さそうです。
5. Control Tower 用の IAM Role（AWSControlTowerExecution）を作成
Control Tower がアカウントを管理するために、AWSControlTowerExecution というロールを使用します。そのため、Control Tower へ登録する前に以下の設定で IAM ロールを手動で作成しておく必要があります。
設定内容は Control Tower用のIAM Role(AWSControlTowerExecution)を作成しているか も参考にしてください。
今回は IAM コンソールから手動で作ってみます。
信頼されたエンティティタイプは AWS アカウントで、Control Tower の管理アカウント ID を入力します。
設定する許可は AdministratorAccess (AWS管理ポリシー) です。
できた IAM ロールはこんな感じです。
6. 既存の Organizations 組織を削除（メンバーアカウントであれば旧組織を離れておく）
対象アカウントが Organizations 組織のメンバーアカウントである場合、別の Organizations 組織配下に入ることはできません。事前に Organizations 組織を離れておく必要があります。
今回 Control Tower 環境に追加登録したいアカウントが別の Organizations 組織の管理アカウントであったため、組織を離れることができず、組織を削除しました。
7. Control Tower 管理アカウントと同じ Organizations 組織に所属させる
Control Tower 管理アカウント側から Organizations 組織へ招待を送信します。Organizations コンソールで「招待」を開き、「AWS アカウントを招待」をクリックします。
「既存の AWS アカウントを招待」を選択し、登録する AWS アカウントのアカウント ID を入力して招待を送信します。
招待が送信されます。
登録する AWS アカウントのメールボックスに、招待メールが届いています。これから Control Tower 環境に参加する AWS アカウントを開いているブラウザで招待を Accept します。
1 件の招待が届いています。
「招待を承諾する」で承諾します。
Control Tower 環境の Organizations に参加できました。
※まだ Control Tower には登録されていません。
ついでに workload OU にアカウントを移動しておきましょう。Conrol Tower の管理アカウントで Organizations コンソールを開き、登録したアカウントにチェックしてアクションから「移動」をクリックします。
workload をチェックして「AWS アカウントを移動」をクリックします。
今、Control Tower 環境の Organizations に参加しましたが、Control Tower にはまだ登録されていない状態です。
Control Tower への登録
Organizations 組織まで参加できていればもうほぼ終わったような感じですが、最後に Control Tower 環境に登録します。
Control Tower コンソールを見ると、今回追加登録したいアカウントが表示されていますが、まだ「未登録」となっています。アクションから「登録」をクリックします。
参加する組織単位で workload OU が選択されていることを確認し「アカウントの登録」を「クリックします。
確認画面で再度「アカウントの登録」をクリックします。
「登録リクエストが送信されました」と表示されています。リクエストの詳細については Service Catalog を確認するように書かれているので、リンクをクリックして Service Catalog を開きます。
Service Catalog を開くと以下のようにステータスが「変更中」になっています。
10 分ほど待って再度確認すると、ステータスが「使用可能」になっていました。
Control Tower 組織から確認すると、新規登録したアカウントが「登録済み」になっていることが確認できました。
おわりに
Control Tower 環境に既存の AWS アカウントを追加する手順をまとめました。事前準備が肝でしたね。
本記事への質問やご要望については画面下部のお問い合わせ「DevelopersIO について」からご連絡ください。記事に関してお問い合わせいただけます。
参考
![[登壇レポート] JAWS DAYS 2025「DevelopersIO流！アマゾンの奥地で技術の限界に挑戦：LT7人衆、熱き戦い」で「実装先SCPのコントロールを全部有効化してみた！～2025年 ver.～」という内容で登壇しました #jawsdays2025 #jawsug #jawsdays2025_c](https://images.ctfassets.net/ct0aopd36mqt/5lqlZrUocbMciBtGGxa1rM/981f1c9eec7e5d5e2ea89fd0d7d655ba/jaws-days-2025_1200x630.png)
