Control Tower の自動アカウント登録機能が Config アグリゲータに与える影響を調べてみた
こんにちは、クラウド事業本部 コンサルティング部のいたくらです。
はじめに
先日、AWS Control Tower に自動アカウント登録機能が追加されたというブログを公開しました。
この機能を有効にすると、Audit アカウントに作成される Config アグリゲータ「aws-controltower-GuardrailsComplianceAggregator」の集約対象が変化するようでした。
ということで調べた内容をまとめてみました。
三行まとめ
- Automatic account enrollment を有効化すると、Config アグリゲータ（aws-controltower-GuardrailsComplianceAggregator）の集約対象に管理アカウントが自動追加される
- 管理アカウント側に Audit アカウントからの認証リクエストが作成される（有効期限 7 日間）
- 認証を承認しない場合、集約対象には含まれるが実際には Audit アカウントから管理アカウントの Config データにアクセスできない状態となる
調査してみた
前提
- Control Tower ランディングゾーン設定済みの Organizations 環境
- 管理アカウントA（アカウント ID が 9 から始まる）は Automatic account enrollment を有効化済み
- 管理アカウントB（アカウント ID が 6 から始まる）は Automatic account enrollment が無効
そもそもなぜ気付いたの？
管理アカウントA の Config を偶然開いた際に、見覚えのない「認証」が作成されていました。
アカウント ID が 7 から始まるアカウントは Audit アカウントです。
直近、Control Tower が作る Config アグリゲータをテーマに登壇していたので、aws-controltower-GuardrailsComplianceAggregator のソースアカウントに管理アカウントが含まれないことは確認していました。
そのため、あれ？？？？どうして？？？？と気付きました。
まずは Audit アカウントを見てみる
管理アカウントA 配下の Audit アカウントにログインし、aws-controltower-GuardrailsComplianceAggregator のソースアカウントを確認します。
ソースアカウントに管理アカウントA（アカウント番号が 9 から始まる）が含まれていることが確認できます。
管理アカウントB 配下の Audit アカウントにログインし、aws-controltower-GuardrailsComplianceAggregator のソースアカウントを確認します。
ソースアカウントに管理アカウントB（アカウント番号が 6 から始まる）が含まれていません。
次に管理アカウントを見てみる
管理アカウントA にログインし、Config の認証を確認します。
・・・認証、消えていますね？？？？？？
ちなみに「そもそもなぜ気付いたの？」に貼った認証のキャプチャは 2025/10/23 に取得しました。
このブログを執筆している 2025/10/29 に確認したら消えていました。
おそらく、認証リクエストの有効期限が 7 日間であるため、期限切れとなって消えてしまったようです（認証リクエストが作成されたのは Automatic account enrollment を有効にした 2025/10/20 なので・・・）。
管理アカウントB にログインし、Config の認証を確認します。
こちらは Audit アカウントで確認した際にソースアカウントに含まれていなかったので、認証が無くても問題ないです。
もう一回 Audit アカウントを見てみる
認証は確認できませんでしたが、痕跡はあるはずなので 管理アカウントA 配下の Audit アカウントにログインし、CloudTrail のイベント履歴を確認します。
イベント名：PutConfigurationAggregator で検索すると10月 20, 2025, 11:55:42 (UTC+09:00) に、このイベントが発生していました。
以下、イベントレコードの一部抜粋です。
管理アカウントA（アカウント番号が 9 から始まる）が集約対象に含まれるように設定が更新されたことが確認できます。
{
"userIdentity": {
"type": "AssumedRole",
"invokedBy": "controltower.amazonaws.com"
},
"eventTime": "2025-10-20T02:55:42Z",
"eventSource": "config.amazonaws.com",
"eventName": "PutConfigurationAggregator",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "controltower.amazonaws.com",
"userAgent": "controltower.amazonaws.com",
"requestParameters": {
"accountAggregationSources": [
{
"accountIds": [
"9XXXXXXXXXXX",
"7XXXXXXXXXXX",
"3XXXXXXXXXXX",
"0XXXXXXXXXXX",
"5XXXXXXXXXXX"
],
"allAwsRegions": true
}
],
"configurationAggregatorName": "aws-controltower-GuardrailsComplianceAggregator"
}
}
管理アカウントA で Automatic account enrollment を有効化したのは 10月 20, 2025, 11:53:24 (UTC+09:00) なので、このランディングゾーン設定更新によってaws-controltower-GuardrailsComplianceAggregator のソースアカウントが更新されたと考えて良さそうです。
認証リクエストは承認も削除もしなかったので、Audit アカウントから管理アカウントの Config データにアクセスできないはず。
ということで確認してみます。
AWS Config > アグリゲータ > aws-controltower-GuardrailsComplianceAggregator と移動して、認証のステータス：Failed でフィルタした結果です。
管理アカウントA（アカウント ID が 9 から始まる）の認証は失敗していることが確認できます。
また、アグリゲータのコンプライアンスダッシュボードでも、上位 10 件のアカウントが出るはずのグラフに管理アカウントA（アカウント ID が 9 から始まる）は表示されないことが確認できます。
認証が失敗している＝Audit アカウントから管理アカウントの Config データにアクセスできない状態であることも確認できました。
まとめ
Control Tower の Automatic account enrollment を有効化すると、Audit アカウントの Config アグリゲータ「aws-controltower-GuardrailsComplianceAggregator」のソースアカウントに管理アカウントが追加されることが確認できました。
具体的には、ランディングゾーン設定の更新時に Control Tower が PutConfigurationAggregator API を実行し、管理アカウントを集約対象に含める変更を行います。
同時に、管理アカウント側には Audit アカウントからの認証リクエストが作成されます。
ただし、この認証リクエストには 7 日間の有効期限があり、期限内に承認しないと自動的に削除されます。
認証リクエストを承認しない場合、Audit アカウントの Config アグリゲータは管理アカウントを集約対象として保持しますが、認証失敗により実際には管理アカウントの Config データにアクセスできない状態となります。
Automatic account enrollment を有効化した環境で管理アカウントの Config データも Audit アカウントの Config アグリゲータで集約したい場合は、7 日間以内に管理アカウント側で認証リクエストを承認する必要があります。
この記事がどなたかのお役に立てれば幸いです。
以上、クラウド事業本部 コンサルティング部のいたくら（＠itkr2305）でした！
