AWS Control Towerでランディングゾーンを構築し、ガードレールやSecurity Hubを活用したコンプライアンス体制を整えたら、次は安定的な運用フェーズに入ります。本記事では、Control Towerの日常運用タスク、ドリフト(設定逸脱)の検出と修復、ランディングゾーンのバージョンアップ対応、そしてよくある問題とその解決方法について実践的に解説します。
Control Tower運用の全体像
Control Towerの運用は、日常的な監視・メンテナンスと、イベントドリブンな対応の両面で構成されます。運用チームが把握すべき作業領域を整理します。
運用タスクの分類
flowchart TB
subgraph "日常運用"
D1[コンプライアンス監視]
D2[アカウント管理]
D3[ガードレール管理]
D4[ログ・監査確認]
end
subgraph "定期運用"
P1[ドリフト検出・修復]
P2[バージョンアップ対応]
P3[セキュリティレビュー]
P4[コスト最適化]
end
subgraph "イベント対応"
E1[インシデント対応]
E2[新規アカウント作成]
E3[ガードレール違反対応]
E4[障害復旧]
end
D1 --> P1
D3 --> P2
D2 --> E2
D1 --> E3運用体制の推奨構成
Control Towerの運用を効果的に行うための体制を示します。
| 役割 | 責任範囲 | 必要なアクセス権限 |
|---|---|---|
| クラウドアーキテクト | ランディングゾーン設計、バージョンアップ判断 | 管理アカウントへのフルアクセス |
| セキュリティチーム | コンプライアンス監視、ガードレール管理 | 監査アカウントへのアクセス、Security Hub |
| 運用チーム | 日常監視、インシデント対応 | 読み取り専用+特定操作権限 |
| 開発チーム | アカウント利用、リソース管理 | 割り当てられたアカウントへのアクセス |
日常運用タスク
Control Towerの安定運用に必要な日常タスクを解説します。
コンプライアンスダッシュボードの確認
Control Towerダッシュボードは、組織全体のコンプライアンス状態を一目で把握できる中央管理画面です。
flowchart TB
subgraph "Control Tower ダッシュボード"
SUMMARY[サマリー表示]
OU_STATUS[OU別ステータス]
GR_STATUS[ガードレール違反]
DRIFT_ALERT[ドリフトアラート]
end
SUMMARY --> CHECK{確認項目}
CHECK --> C1[非準拠アカウント数]
CHECK --> C2[違反ガードレール数]
CHECK --> C3[ドリフト検出有無]
C1 --> ACTION1[是正措置]
C2 --> ACTION2[違反内容確認]
C3 --> ACTION3[ドリフト修復]日次確認項目
| 確認項目 | 確認方法 | 異常時のアクション |
|---|---|---|
| 全体コンプライアンス率 | ダッシュボードサマリー | 90%未満なら詳細調査 |
| 非準拠アカウント | OU別ステータス一覧 | 該当アカウントの是正 |
| ガードレール違反 | コントロール画面 | 違反リソースの特定と対応 |
| ドリフト状態 | ランディングゾーン設定 | ドリフト修復の実行 |
AWS CLIによる状態確認
コンソールに加え、CLIを活用した自動監視も推奨します。
|
|
自動監視スクリプト例
|
|
アカウントライフサイクル管理
Account Factoryで作成したアカウントの継続的な管理が必要です。
flowchart LR
subgraph "アカウントライフサイクル"
CREATE[作成]
ACTIVE[稼働中]
SUSPEND[停止]
CLOSE[クローズ]
end
CREATE --> ACTIVE
ACTIVE --> SUSPEND
SUSPEND --> ACTIVE
SUSPEND --> CLOSE
ACTIVE --> CLOSEアカウント管理タスク
| タスク | 頻度 | 手順 |
|---|---|---|
| 未使用アカウントの特定 | 月次 | CloudTrailログでアクティビティ確認 |
| アカウントメタデータ更新 | 随時 | Service Catalogでパラメータ更新 |
| アカウントOU移動 | 随時 | Control Towerコンソールで変更 |
| アカウントクローズ | 随時 | Organizations APIで実行 |
ドリフト検出と修復
ドリフト(Drift)は、Control Towerが管理するリソースが、期待される設定から逸脱した状態を指します。ドリフトの放置はガバナンスの破綻につながるため、適切な検出と修復が重要です。
ドリフトの種類
Control Towerで検出されるドリフトには複数の種類があります。
flowchart TB
subgraph "ドリフトの種類"
MOVED[アカウント移動ドリフト<br/>OUからの移動・削除]
SCP[SCPドリフト<br/>ポリシーの変更・削除]
SHARED[共有アカウントドリフト<br/>設定変更]
CT[CloudTrailドリフト<br/>ログ設定変更]
CONFIG[AWS Configドリフト<br/>設定変更]
end
MOVED --> IMPACT1[ガバナンス適用外]
SCP --> IMPACT2[セキュリティ制御の無効化]
SHARED --> IMPACT3[監査機能の損失]
CT --> IMPACT4[ログ記録の欠落]
CONFIG --> IMPACT5[コンプライアンス監視の停止]ドリフトタイプ別の詳細
| ドリフトタイプ | 原因例 | 影響度 | 検出方法 |
|---|---|---|---|
| アカウント移動 | 手動でOU間移動、登録解除 | 高 | ダッシュボード |
| SCP変更 | SCPの直接編集、削除 | 最高 | Organizations API |
| 共有アカウント設定 | ログアーカイブ/監査アカウントの変更 | 最高 | ダッシュボード |
| CloudTrail設定 | トレイル停止、S3バケット変更 | 高 | ダッシュボード |
| AWS Config設定 | レコーダー停止、配信チャネル変更 | 高 | Config API |
ドリフト検出の仕組み
Control Towerは、EventBridgeとSNSを使用してドリフトを自動検出します。
sequenceDiagram
participant User as ユーザー/管理者
participant Org as Organizations
participant EB as EventBridge
participant CT as Control Tower
participant SNS as SNS
User->>Org: SCP変更操作
Org->>EB: API呼び出しイベント
EB->>CT: ドリフト検出トリガー
CT->>CT: 設定比較
CT->>SNS: ドリフト通知
SNS->>User: アラート送信
CT->>CT: ダッシュボード更新ドリフト検出を強化するEventBridgeルール
|
|
ドリフト修復の手順
ドリフトが検出された場合の修復手順を解説します。
手順1:ドリフト内容の確認
|
|
手順2:影響範囲の評価
flowchart TB
DETECT[ドリフト検出]
DETECT --> ASSESS{影響評価}
ASSESS --> SEV_HIGH[高: セキュリティ制御に影響]
ASSESS --> SEV_MED[中: 監視機能に影響]
ASSESS --> SEV_LOW[低: 表示上の問題]
SEV_HIGH --> IMMEDIATE[即時対応必須]
SEV_MED --> PLANNED[計画的対応]
SEV_LOW --> SCHEDULED[次回メンテナンス]手順3:修復の実行
Control Towerのドリフト修復は、ランディングゾーンの再ベースライン処理で行います。
|
|
コンソールからの修復手順
- Control Towerダッシュボードにアクセス
- 「ランディングゾーン設定」を開く
- ドリフトアラートの「詳細を表示」をクリック
- 「ランディングゾーンを修復」を選択
- 変更内容を確認し「修復」を実行
ドリフト予防策
ドリフトを未然に防ぐための対策を実施します。
flowchart TB
subgraph "予防策"
P1[SCP変更の禁止]
P2[共有アカウント<br/>アクセス制限]
P3[変更検知<br/>アラート設定]
P4[運用ルール<br/>の明文化]
end
P1 --> IMPL1[追加SCPで<br/>Organizations操作を制限]
P2 --> IMPL2[IAMポリシーで<br/>書き込み権限を制限]
P3 --> IMPL3[EventBridgeと<br/>SNSで即時通知]
P4 --> IMPL4[運用手順書に<br/>禁止事項を明記]ドリフト防止用SCP例
|
|
バージョンアップ対応
Control Towerは継続的に機能強化が行われ、ランディングゾーンのバージョンアップが必要になることがあります。
バージョンアップの種類
flowchart TB
subgraph "バージョンアップ種類"
MINOR[マイナーアップデート<br/>機能追加・改善]
MAJOR[メジャーアップデート<br/>アーキテクチャ変更]
SECURITY[セキュリティアップデート<br/>脆弱性対応]
end
MINOR --> OPT_MINOR[推奨だが任意]
MAJOR --> OPT_MAJOR[計画的な実施]
SECURITY --> OPT_SEC[早急な対応必須]アップデート前の確認事項
バージョンアップを実行する前に、以下の項目を確認します。
| 確認項目 | 確認方法 | 対応 |
|---|---|---|
| リリースノート | AWS公式ドキュメント | 変更内容と影響範囲を把握 |
| 既存カスタマイズへの影響 | テスト環境で検証 | 非互換性がないか確認 |
| ダウンタイム | リリースノート | 影響を受ける操作を確認 |
| ドリフト状態 | ダッシュボード | 事前にドリフト修復 |
| 必要な権限 | IAMポリシー | 管理者権限を確認 |
アップデート前チェックリスト
|
|
バージョンアップの実行
手順1:バックアップと準備
|
|
手順2:アップデートの実行
|
|
手順3:アップデート後の確認
sequenceDiagram
participant Admin as 管理者
participant CT as Control Tower
participant OU as 各OU
participant ACC as 各アカウント
Admin->>CT: アップデート実行
CT->>CT: ランディングゾーン更新
CT->>OU: ガードレール再適用
OU->>ACC: Config Rules更新
ACC->>CT: 準拠状態報告
CT->>Admin: 完了通知
Admin->>CT: 動作確認動作確認項目
|
|
よくある問題と解決方法
Control Tower運用で発生しやすい問題と、その解決方法を解説します。
Account Factory関連の問題
問題1:アカウント作成が失敗する
flowchart TB
FAIL[アカウント作成失敗]
FAIL --> CAUSE1{メールアドレス<br/>の問題?}
CAUSE1 -->|はい| FIX1[未使用の<br/>メールアドレスを使用]
CAUSE1 -->|いいえ| CAUSE2{サービス<br/>クォータ?}
CAUSE2 -->|はい| FIX2[上限緩和申請]
CAUSE2 -->|いいえ| CAUSE3{SCPの<br/>制限?}
CAUSE3 -->|はい| FIX3[SCP見直し]
CAUSE3 -->|いいえ| FIX4[AWSサポートへ連絡]| 原因 | 症状 | 解決方法 |
|---|---|---|
| メールアドレス重複 | 「Email already exists」エラー | 未使用のメールアドレスを使用 |
| アカウント数上限 | プロビジョニング失敗 | Service Quotasで上限緩和申請 |
| SCPによる制限 | 特定操作が拒否 | 一時的にSCPを緩和 |
| Service Catalogエラー | プロダクト起動失敗 | ポートフォリオ権限を確認 |
問題2:アカウント登録が完了しない
|
|
ガードレール関連の問題
問題1:ガードレールが有効化できない
flowchart TB
ENABLE_FAIL[ガードレール<br/>有効化失敗]
ENABLE_FAIL --> CHECK1{対象OUは<br/>Control Tower管理下?}
CHECK1 -->|いいえ| FIX1[OUを登録]
CHECK1 -->|はい| CHECK2{前提条件の<br/>ガードレールは有効?}
CHECK2 -->|いいえ| FIX2[依存ガードレール<br/>を先に有効化]
CHECK2 -->|はい| CHECK3{AWS Config<br/>は有効?}
CHECK3 -->|いいえ| FIX3[Config有効化]
CHECK3 -->|はい| FIX4[サポートへ連絡]| 原因 | エラーメッセージ例 | 解決方法 |
|---|---|---|
| OU未登録 | Target OU is not registered | Control TowerでOUを登録 |
| 依存関係 | Prerequisite control not enabled | 依存ガードレールを先に有効化 |
| Config未設定 | AWS Config not enabled | 対象アカウントでConfig有効化 |
| リージョン不整合 | Region not governed | 対象リージョンをガバナンス対象に追加 |
問題2:ガードレール違反が誤検出される
|
|
IAM Identity Center関連の問題
問題1:SSOログインができない
flowchart TB
SSO_FAIL[SSOログイン失敗]
SSO_FAIL --> CHECK1{ユーザーは<br/>存在する?}
CHECK1 -->|いいえ| FIX1[ユーザー作成]
CHECK1 -->|はい| CHECK2{権限セットは<br/>割り当て済み?}
CHECK2 -->|いいえ| FIX2[権限セット割り当て]
CHECK2 -->|はい| CHECK3{アカウントへの<br/>アクセス許可は?}
CHECK3 -->|いいえ| FIX3[アカウント<br/>アクセス許可追加]
CHECK3 -->|はい| CHECK4{外部IdP<br/>連携の問題?}
CHECK4 -->|はい| FIX4[IdP設定確認]
CHECK4 -->|いいえ| FIX5[サポートへ連絡]問題2:権限セットの変更が反映されない
|
|
CloudTrail関連の問題
問題1:ログが配信されない
|
|
| 原因 | 確認方法 | 解決方法 |
|---|---|---|
| トレイル停止 | get-trail-status | トレイルを再開 |
| S3バケットポリシー | get-bucket-policy | ポリシーを修正 |
| KMS権限 | IAMポリシー確認 | KMSキーポリシー修正 |
| リージョン設定 | describe-trails | マルチリージョン有効化 |
パフォーマンスと制限に関する問題
問題1:ガードレール評価が遅い
flowchart TB
SLOW[評価遅延]
SLOW --> CAUSE1[大量のリソース]
SLOW --> CAUSE2[複雑なConfig Rules]
SLOW --> CAUSE3[リージョン数が多い]
CAUSE1 --> FIX1[リソースタグで<br/>スコープを限定]
CAUSE2 --> FIX2[ルール最適化]
CAUSE3 --> FIX3[リージョン見直し]Control Towerの制限事項と回避策
Control Towerには運用上把握すべき制限事項があります。
主要な制限事項
flowchart TB
subgraph "Control Tower 制限事項"
L1[ホームリージョン変更不可]
L2[ネストされたOU制限]
L3[アカウント数上限]
L4[ガードレール適用単位]
end
L1 --> W1[新規ランディングゾーン<br/>作成で対応]
L2 --> W2[フラットなOU構造<br/>を採用]
L3 --> W3[Service Quotas<br/>で上限緩和]
L4 --> W4[OUの細分化]| 制限事項 | 詳細 | 回避策 |
|---|---|---|
| ホームリージョン | 構築後の変更不可 | 事前に慎重に選定 |
| ネストOU | 5階層まで | フラット構造を推奨 |
| アカウント数 | デフォルト5000 | Service Quotasで緩和申請 |
| ガードレール適用 | OU単位のみ | 適切なOU設計 |
| 管理アカウント | ガードレール対象外 | 手動でのセキュリティ設定 |
管理アカウントの保護
管理アカウントはControl Towerのガードレール対象外のため、追加のセキュリティ対策が必要です。
|
|
Organizations機能との共存
Control TowerとOrganizationsの機能を併用する際の注意点を示します。
| Organizations機能 | Control Towerとの互換性 | 注意事項 |
|---|---|---|
| SCP | 共存可能 | Control Tower管理SCPを変更しない |
| タグポリシー | 共存可能 | 競合に注意 |
| バックアップポリシー | 共存可能 | 問題なし |
| 委任管理者 | 一部制限 | Security Hub、GuardDutyは推奨 |
運用自動化のベストプラクティス
Control Tower運用を効率化するための自動化パターンを紹介します。
監視・通知の自動化
flowchart TB
subgraph "イベントソース"
CT_EVENT[Control Tower<br/>イベント]
ORG_EVENT[Organizations<br/>イベント]
CONFIG_EVENT[AWS Config<br/>イベント]
end
subgraph "処理"
EB[EventBridge]
LAMBDA[Lambda]
SNS[SNS]
end
subgraph "通知先"
EMAIL[メール]
SLACK[Slack]
PAGER[PagerDuty]
end
CT_EVENT --> EB
ORG_EVENT --> EB
CONFIG_EVENT --> EB
EB --> LAMBDA
LAMBDA --> SNS
SNS --> EMAIL
SNS --> SLACK
SNS --> PAGERSlack通知Lambda関数例
|
|
定期レポートの自動生成
|
|
Infrastructure as Codeによる管理
Control Towerの設定をコードで管理することで、再現性と変更追跡が可能になります。
|
|
運用メトリクスと継続的改善
Control Tower運用の品質を測定し、継続的に改善するためのメトリクスを定義します。
主要なKPI
| KPI | 目標値 | 測定方法 | 改善アクション |
|---|---|---|---|
| コンプライアンス率 | 95%以上 | Config集約 | 非準拠リソースの是正 |
| ドリフト解決時間 | 4時間以内 | インシデント記録 | 自動修復の導入 |
| アカウント作成時間 | 30分以内 | Service Catalog | テンプレート最適化 |
| セキュリティ検出対応時間 | 24時間以内 | Security Hub | 自動化ワークフロー |
ダッシュボード構築
flowchart TB
subgraph "データソース"
CONFIG[AWS Config]
SH[Security Hub]
CT[Control Tower]
CW[CloudWatch]
end
subgraph "集約"
S3[S3 Data Lake]
ATHENA[Athena]
end
subgraph "可視化"
QS[QuickSight]
GRAFANA[Grafana]
end
CONFIG --> S3
SH --> S3
CT --> CW
S3 --> ATHENA
ATHENA --> QS
CW --> GRAFANAまとめ
AWS Control Towerの運用は、日常的な監視、ドリフト管理、バージョンアップ対応、そして問題解決の4つの柱で構成されます。本記事で解説した内容を実践することで、安定的で持続可能なマルチアカウント環境の運用が実現できます。
運用のポイントを以下にまとめます。
- 日常運用の定型化:ダッシュボード確認、コンプライアンス監視、アカウント管理を定期タスク化
- ドリフトの早期検出と修復:EventBridgeによる自動検出、防止策としてのSCP活用
- 計画的なバージョンアップ:リリースノート確認、テスト環境での検証、影響範囲の事前評価
- 問題解決の体系化:よくある問題と解決パターンの文書化、エスカレーションパスの明確化
- 自動化の推進:監視、通知、レポート生成の自動化による運用負荷軽減
- 継続的改善:KPIの測定とフィードバックループによる運用品質向上
Control Towerは設定して終わりではなく、継続的な運用と改善が求められるサービスです。本記事の内容を参考に、組織の要件に合った運用体制を構築し、セキュアで効率的なマルチアカウント環境を維持してください。