はじめに
こんにちは。
マルチアカウント環境のベストプラクティスを迅速に展開できるAWS Control Towerは、非常に魅力的ですよね。組織のセキュリティとガバナンスを高いレベルで維持してくれる、まさに"ガードレール"のような存在です。
しかしその一方で、「ここを少しだけ変更したいのに…」といった 細かなカスタマイズが難しい 場面に直面したことはありませんか？
私自身、実際にそうした壁にぶつかり、試行錯誤した経験があります。
今回は、Control Towerで“変更できなかったポイント”について実例を交えてご紹介します。
同じような悩みをお持ちの方にとって、少しでも参考になれば幸いです
Control Towerでできなかったこと
1. OU構成が固定されている
Control Towerでは、ランディングゾーンのセットアップ時に Security OUが第一階層に必ず作成 され、変更できません。
そのため、すでに自社内でOU構成の方針があったとしても、それに合わせた自由な設計はできません。
OU名や階層を柔軟に変えたい場合、Control Towerの使用自体を見直す必要があります。
2. AWS Configのカスタマイズができない
Control Tower配下で新規アカウントを作成すると、AWS Configが自動で有効化されます。
しかしこのConfigについては、以下のように設定の変更が基本的にできません。
デフォルト設定（Control Towerによる自動適用）
| 項目 | 設定内容 |
|---|---|
| 有効化リージョン | Control Towerで有効になっているすべてのリージョン |
| 記録対象リソースタイプ | すべてのリソース |
| データ保持期間 | 7年間（※S3バケットの保存期間を変更することは可能） |
| スナップショットの取得頻度 | 毎日（24時間ごと） |
設定変更はできる？AWSサポートに確認してみた
実際にAWSサポートに問い合わせたところ、以下のような回答がありました：
Control Towerによって自動作成されたConfigリソースは、手動での変更・削除は非推奨。
AWSリソースの手動変更により、Control Towerの動作が保証されなくなることがあるため、Configの設定（例：保持期間を5年に変更、スナップショットの無効化など）は原則として変更不可とのことです。
一部には、以下のようなソリューションも紹介されていますが、
これは高度なカスタマイズを前提としたもので、保持期間やスナップショット設定の変更は対象外とされています。
また、AWS公式のガイダンスでも次のように記載されています：
「AWS Control Tower によって作成されたリソースを変更または削除しないでください。これらの変更により、ランディングゾーンの更新やOUの再登録が必要になる場合があります。」
Control Towerの自動設定は変更前提で設計されていないため、Configのカスタマイズが必要な場合は、Control Towerの使用そのものを見直す必要があるかもしれません。
3. CloudTrailの設定に制限あり
Control Towerによって自動作成されるCloudTrailの証跡では、管理イベントの記録が有効になっています。
しかし、以下のイベントは対象外で、必要に応じて別途設定が必要です。
データイベント
S3オブジェクトの操作やLambda関数の呼び出しなど、リソース内の詳細なデータ操作の記録です。インサイトイベント
異常検知や不正アクセスのパターン分析に用いられる追加のログ情報です。
Control TowerのCloudTrailではこれらは自動で記録されないため、データイベントやインサイトイベントの取得が必要な場合は、別途証跡を作成して設定する必要があります。
補足：Control TowerにおけるCloudTrail証跡の仕様
Control Towerで管理されるCloudTrail証跡は、ランディングゾーンの設定で有効／無効を選択できます。
ただし、この証跡はControl Towerのガバナンス機能の一部のため、いくつか仕様上の特徴があります。
- ランディングゾーン設定で無効化しても、証跡自体は削除されず「無効な状態」として残り続けます。
- 証跡の編集・削除はできません。
もし完全に独自の証跡設定で運用したい場合は、Control Towerの証跡を無効化した上で、ご自身で管理する証跡を別途作成することも検討してください。
無理に変更しようとすると？
Control Towerの設定を無理やり変更すると、「ドラフト状態」 になることがあります。
これは、Control Towerの管理対象から外れてしまった状態で、将来の更新に支障が出る可能性も。
一度ドラフト状態になると、修復や再適用にも手間がかかるため要注意です。
まとめ：Control Towerは「受け入れる」前提で使う
Control Towerは「自由なカスタマイズ」ができない代わりに、強力なベストプラクティスと自動化の恩恵を受けられるサービスです。 思い通りにいかない部分があっても、「あえて受け入れる」ことが一番うまく付き合うコツだと感じています。 私と同じように、「Control Tower、いいんだけど、思い通りにいかない…」と感じている方の参考になれば幸いです！
