![[アップデート]AWS Control Towerがサービスリンクされた AWS Config マネージド Config ルールをサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-fff4d7e7c3509d1ffcc67578673c5f00/056494cb8aea27071cd8ed8a870bda83/aws-control-tower)
[アップデート]AWS Control Towerがサービスリンクされた AWS Config マネージド Config ルールをサポートしました
2025.06.13お疲れさまです。とーちです。
AWS Control Towerがサービスリンクされた AWS Config マネージド Config ルールをサポートするようになったというアップデートがあったので、早速触ってみました。
サービスリンクされた AWS Config ルールとは
まず、今回のアップデートを理解するために「サービスリンクされた AWS Config ルール」について整理してみましょう。
以下のURLにサービスリンクされた AWS Config ルールに関する詳細な説明があります。
ドキュメントによると、通常のAWS Config ルールと比べ以下のような特徴を持っているようです。
- AWS側が所有・管理: SecurityHubなどの他のAWSサービスが自動的に作成する
- 読み取り専用: ユーザーは内容の確認のみ可能、編集や削除は不可
- 事前設定済み: 必要な権限やパラメータがすべて事前に設定済み
私は最初、ある特定のAWS Config マネージドルールがサービスリンクされたConfig ルールという属性を持つのかと誤解していたのですが、そうではありませんでした。あくまでも実装方法の違いを指しているようです。
つまり、同じAWS Config のマネージドルールでも「ユーザーが設定する方法」と「サービスリンクConfig ルールによりAWSが実装する方法」があるということですね。
どういうアップデート？
では、具体的に今回のアップデートがどのようなアップデートなのかを見ていきます。
従来の実装方式
従来から、Control TowerでConfig ルールを展開することは可能でした。従来の方法はControl TowerがCloudFormation StackSetsを使ってConfig ルールを展開するという手法を取っていました。
この方法で設定されたConfig ルールを実際に見てみましょう。
CloudFormationスタックの確認
まず、メンバーアカウントでConfig ルールを作っているCloudFormationスタックを確認してみます。
初めて知ったのですが、どうやら1スタックにつき、一つのConfig ルールを作っているようです。Control Towerで多くのConfig ルールのコントロールを有効化すると、スタック数が大変なことになりそうですね。
AWS Configでの表示確認
次に、AWS Configの画面からConfig ルールを確認してみましょう。
一番下のSecurityHubにより展開されたルールは左のラジオボタンがグレーアウトされているのに対して、ControlTowerにより展開されたConfigルールは選択が可能になっています。
編集機能の確認
従来方式のConfig ルールを選択して編集ボタンを押すと、以下のように編集画面が表示されます。
ただし、実際に編集しようとすると以下のようにSCPにより拒否されます。
新しい実装方式の確認
続いて、新しい実装方式を実際に試してみました。
コントロールの有効化
Control Towerから適当なConfig ルールを有効化してみます。
今回はSecurity OUで有効化してみました。
デプロイ時間の比較
約1分程度で、コントロール有効化が完了しました。What's Newの記載によると、このコントロールのデプロイ速度が大幅に向上したことが今回のアップデートの最大のメリットのようです。
参考までに、以前の方式での有効化時間を確認してみましょう。StackSetsの実行履歴を見ると以下のようになっており、1分以内には完了しているようです。
ただし、これは一つのConfig ルールを有効化するのにかかった時間です。複数のConfig ルールを一括で有効化する場面では、その分StackSetsが増えるので時間がかなり変わってきそうな気がします。
新方式のConfig ルール確認
Security OU内のAWSアカウント内で再度Config ルールを確認してみると、以下のように追加したConfig ルールのラジオボタンはグレーアウトとなっているのがわかります。
また、対象のルールをクリックしてみると以下のような画面が出て、Control Towerが作成したことや、編集・更新・削除は不可であるという説明がされています。
CloudFormationスタックの状況確認
ちょっと分かりづらいのですが、以下のコマンドで確認すると、CloudFormationスタックも作成されていないことがわかります。
aws cloudformation list-stacks \
--stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE \
--query 'StackSummaries[?contains(StackName, `StackSet-AWSControlTower`) || contains(StackName, `AWSControlTower`)].{Name:StackName,CreationTime:CreationTime}' \
--output table
実行結果：
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
| ListStacks |
+----------------------------------+------------------------------------------------------------------------------------------------------------------------------+
| CreationTime | Name |
+----------------------------------+------------------------------------------------------------------------------------------------------------------------------+
| 2025-03-26T22:14:08.595000+00:00| StackSet-AWSControlTowerGuardrailAWS-GR-DETECT-CLOUDTRAIL-ENABLED-ON-SHARED-ACCOUNTS-1e927f51-c8ee-4389-af06-1d321f3fd6a0 |
| 2025-03-26T22:13:19.345000+00:00| StackSet-AWSControlTowerGuardrailAWS-GR-AUDIT-BUCKET-PUBLIC-READ-PROHIBITED-2dd868e9-3807-4bf2-98fd-bcea4548e7ac |
| 2025-03-26T22:12:30.341000+00:00| StackSet-AWSControlTowerGuardrailAWS-GR-AUDIT-BUCKET-PUBLIC-WRITE-PROHIBITED-e00f352a-61f3-4895-9347-9dc19b22f6a8 |
| 2025-03-26T22:04:07.842000+00:00| StackSet-AWSControlTowerBP-BASELINE-CONFIG-1558e4b0-d0b2-4078-8d09-cfb6a1b6ac |
| 2025-03-26T22:04:07.712000+00:00| StackSet-AWSControlTowerBP-BASELINE-CLOUDWATCH-2c8199b4-3b8d-422b-8e05-b87881ef1c25 |
| 2025-03-26T22:02:35.415000+00:00| StackSet-AWSControlTowerBP-BASELINE-SERVICE-LINKED-ROLE-7e71f879-dfc3-4c29-98e5-27a92a02a6f1 |
| 2025-03-26T22:02:34.068000+00:00| StackSet-AWSControlTowerBP-BASELINE-SERVICE-ROLES-f305ea22-4c07-431e-8c80-e660bd402302 |
| 2025-03-26T22:02:33.538000+00:00| StackSet-AWSControlTowerBP-BASELINE-ROLES-34d80653-f6c0-4915-9779-757196cc6e81 |
| 2025-03-26T22:00:59.208000+00:00| StackSet-AWSControlTowerLoggingResources-c0e2cb13-8693-44c6-9d9b-ed5c0717277b |
| 2025-03-26T21:25:36.408000+00:00| StackSet-AWSControlTowerExecutionRole-5a8d82d8-bfbf-4c7c-8ba6-8ad8f45fd925 |
+----------------------------------+------------------------------------------------------------------------------------------------------------------------------+
ご覧の通り、新しくControl Towerのコントロールを有効化しましたが、新たなCloudFormationスタックは作成されていません。
このアップデートで何が嬉しいのか
主に以下の２点が嬉しいポイントかなと思います。
セキュリティとガバナンス強化
上記でも示したとおり、従来の方法でControlTowerにより作成されたConfigルールでもSCPにより編集は不可能となっていましたが、これがより強化されたことで、抜け道的にControlTowerにより作成されたConfigルールを変更・削除するといったことは完全に不可能となりました。（従来の方法でもメンバーアカウントからSCPを変更することは基本的には難しかったと思うので、どういった抜け道があったかはわかりませんが）
デプロイ速度の向上
その他のメリットとしては、コントロールを有効化した際のConfig ルールのデプロイ速度が向上したという部分が一番のメリットになりそうです。
特に、多数のコントロールを一括で有効化する場合において、従来のStackSets方式と比較してかなりの時間短縮が期待できるのではないでしょうか。
まとめ
ということで、AWS Control Towerがサービスリンクされた AWS Config マネージド Config ルールをサポートするようになったというアップデートでした。
個人的にはサービスリンクされた AWS Config マネージド Config ルールという概念を初めて知ったので、そこが勉強になりました。
またCloudFormationスタックを作らなくなったということでよりシンプルに管理できるようになったのが良いですね。
以上、とーちでした。
![[アップデート] AWS WAF がアプリケーションレイヤー（L7）層の DDoS 保護機能をサポートしました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-8cc2be5d32f2b7e78f85a99d463f3690/6213c0b16f198b77794266f22dc8eb5c/aws-waf)
![[アップデート] Amazon Q Developer IDE からも MCP サーバーが使えるようになりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-5dd35cec6954843cd98f8fe0f8bf3afe/08b840eb79b1e885b48a9fad3081ce0a/amazon-q)
