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を活用した自動監視も推奨します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
# ランディングゾーンの状態確認
aws controltower get-landing-zone-status

# ガードレールの準拠状態確認
aws controltower list-enabled-controls \
    --target-identifier "arn:aws:organizations::123456789012:ou/o-example/ou-1234-5678"

# ドリフト状態の確認
aws controltower get-landing-zone-operation \
    --operation-identifier "op-1234567890abcdef0"

自動監視スクリプト例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
import boto3
import json

def check_control_tower_status():
    """Control Towerの状態を確認し、異常があれば通知"""
    ct_client = boto3.client('controltower')
    
    # ランディングゾーン状態の取得
    response = ct_client.list_landing_zones()
    
    for lz in response.get('landingZones', []):
        lz_arn = lz['arn']
        
        # 詳細情報の取得
        lz_detail = ct_client.get_landing_zone(landingZoneIdentifier=lz_arn)
        status = lz_detail['landingZone']['status']
        drift_status = lz_detail['landingZone'].get('driftStatus', {})
        
        print(f"Landing Zone Status: {status}")
        print(f"Drift Status: {drift_status}")
        
        # ドリフト検出時のアラート
        if drift_status.get('status') == 'DRIFTED':
            send_alert(f"Control Tower drift detected: {lz_arn}")
    
    return response

def send_alert(message):
    """SNSを使用してアラート送信"""
    sns = boto3.client('sns')
    sns.publish(
        TopicArn='arn:aws:sns:ap-northeast-1:123456789012:ControlTowerAlerts',
        Message=message,
        Subject='Control Tower Alert'
    )

アカウントライフサイクル管理

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
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
{
    "source": ["aws.organizations", "aws.cloudtrail", "aws.config"],
    "detail-type": ["AWS API Call via CloudTrail"],
    "detail": {
        "eventSource": ["organizations.amazonaws.com", "cloudtrail.amazonaws.com", "config.amazonaws.com"],
        "eventName": [
            "UpdatePolicy",
            "DeletePolicy",
            "AttachPolicy",
            "DetachPolicy",
            "MoveAccount",
            "StopLogging",
            "DeleteTrail",
            "StopConfigurationRecorder",
            "DeleteConfigurationRecorder"
        ]
    }
}

ドリフト修復の手順

ドリフトが検出された場合の修復手順を解説します。

手順1:ドリフト内容の確認

1
2
3
# ランディングゾーンのドリフト詳細を確認
aws controltower get-landing-zone \
    --landing-zone-identifier "arn:aws:controltower:ap-northeast-1:123456789012:landingzone/ABCD1234"

手順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のドリフト修復は、ランディングゾーンの再ベースライン処理で行います。

1
2
3
# ランディングゾーンのリセット(修復)
aws controltower reset-landing-zone \
    --landing-zone-identifier "arn:aws:controltower:ap-northeast-1:123456789012:landingzone/ABCD1234"

コンソールからの修復手順

  1. Control Towerダッシュボードにアクセス
  2. 「ランディングゾーン設定」を開く
  3. ドリフトアラートの「詳細を表示」をクリック
  4. 「ランディングゾーンを修復」を選択
  5. 変更内容を確認し「修復」を実行

ドリフト予防策

ドリフトを未然に防ぐための対策を実施します。

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例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PreventControlTowerDrift",
            "Effect": "Deny",
            "Action": [
                "organizations:UpdatePolicy",
                "organizations:DeletePolicy",
                "organizations:DetachPolicy",
                "cloudtrail:StopLogging",
                "cloudtrail:DeleteTrail",
                "cloudtrail:UpdateTrail",
                "config:StopConfigurationRecorder",
                "config:DeleteConfigurationRecorder"
            ],
            "Resource": "*",
            "Condition": {
                "ArnNotLike": {
                    "aws:PrincipalARN": [
                        "arn:aws:iam::*:role/AWSControlTowerExecution",
                        "arn:aws:iam::*:role/AWSReservedSSO_AWSAdministratorAccess_*"
                    ]
                }
            }
        }
    ]
}

バージョンアップ対応

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
 4
 5
 6
 7
 8
 9
10
11
12
13
# 1. 現在のバージョン確認
aws controltower get-landing-zone \
    --landing-zone-identifier $LANDING_ZONE_ARN \
    --query 'landingZone.version'

# 2. ドリフト状態の確認
aws controltower get-landing-zone \
    --landing-zone-identifier $LANDING_ZONE_ARN \
    --query 'landingZone.driftStatus'

# 3. 進行中のオペレーションがないか確認
aws controltower list-landing-zone-operations \
    --query 'landingZoneOperations[?status==`IN_PROGRESS`]'

バージョンアップの実行

手順1:バックアップと準備

1
2
3
4
5
6
7
8
# CloudFormation StackSetsの状態を記録
aws cloudformation list-stack-sets \
    --status ACTIVE \
    > stacksets-backup.json

# Service Catalogポートフォリオの状態を記録
aws servicecatalog search-products-as-admin \
    > service-catalog-backup.json

手順2:アップデートの実行

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# CLIでのアップデート実行
aws controltower update-landing-zone \
    --landing-zone-identifier $LANDING_ZONE_ARN \
    --version "3.3"  # 新しいバージョンを指定

# オペレーションIDを取得
OPERATION_ID=$(aws controltower update-landing-zone \
    --landing-zone-identifier $LANDING_ZONE_ARN \
    --version "3.3" \
    --query 'operationIdentifier' \
    --output text)

# 進行状況の監視
aws controltower get-landing-zone-operation \
    --operation-identifier $OPERATION_ID

手順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: 動作確認

動作確認項目

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 1. バージョン確認
aws controltower get-landing-zone \
    --landing-zone-identifier $LANDING_ZONE_ARN \
    --query 'landingZone.version'

# 2. ガードレール状態確認
aws controltower list-enabled-controls \
    --target-identifier $PRODUCTION_OU_ARN

# 3. Account Factory動作確認
aws servicecatalog search-provisioned-products

# 4. コンプライアンス状態確認
aws configservice get-compliance-summary-by-config-rule

よくある問題と解決方法

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
2
3
4
5
6
7
# プロビジョニング状態の確認
aws servicecatalog describe-provisioned-product \
    --id pp-1234567890

# エラー詳細の確認
aws servicecatalog describe-record \
    --id rec-1234567890

ガードレール関連の問題

問題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:ガードレール違反が誤検出される

1
2
3
4
5
6
7
8
9
# Config Ruleの評価結果詳細を確認
aws configservice get-compliance-details-by-config-rule \
    --config-rule-name "AWSControlTower_AWS-GR_ENCRYPTED_VOLUMES" \
    --compliance-types NON_COMPLIANT

# リソースの実際の設定を確認
aws ec2 describe-volumes \
    --volume-ids vol-0123456789abcdef0 \
    --query 'Volumes[].Encrypted'

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:権限セットの変更が反映されない

1
2
3
4
5
6
# 権限セットの再プロビジョニング
aws sso-admin provision-permission-set \
    --instance-arn arn:aws:sso:::instance/ssoins-1234567890 \
    --permission-set-arn arn:aws:sso:::permissionSet/ssoins-1234567890/ps-1234567890 \
    --target-type AWS_ACCOUNT \
    --target-id 123456789012

CloudTrail関連の問題

問題1:ログが配信されない

1
2
3
4
5
6
7
# CloudTrailの状態確認
aws cloudtrail get-trail-status \
    --name aws-controltower-BaselineCloudTrail

# S3バケットポリシーの確認
aws s3api get-bucket-policy \
    --bucket aws-controltower-logs-123456789012-ap-northeast-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のガードレール対象外のため、追加のセキュリティ対策が必要です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 管理アカウント用のカスタムガードレール実装

# 1. AWS Configルールの手動設定
aws configservice put-config-rule \
    --config-rule '{
        "ConfigRuleName": "management-account-mfa-enabled",
        "Source": {
            "Owner": "AWS",
            "SourceIdentifier": "MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS"
        }
    }'

# 2. CloudWatch Alarmsの設定
aws cloudwatch put-metric-alarm \
    --alarm-name "RootAccountUsage" \
    --metric-name "RootAccountUsageCount" \
    --namespace "CloudTrailMetrics" \
    --statistic Sum \
    --period 300 \
    --threshold 1 \
    --comparison-operator GreaterThanOrEqualToThreshold \
    --evaluation-periods 1 \
    --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:SecurityAlerts

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 --> PAGER

Slack通知Lambda関数例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
import json
import urllib.request
import os

SLACK_WEBHOOK_URL = os.environ['SLACK_WEBHOOK_URL']

def lambda_handler(event, context):
    # イベント内容の解析
    detail = event.get('detail', {})
    event_name = detail.get('eventName', 'Unknown')
    event_source = detail.get('eventSource', 'Unknown')
    
    # Slackメッセージの構築
    message = {
        "blocks": [
            {
                "type": "header",
                "text": {
                    "type": "plain_text",
                    "text": "Control Tower Alert"
                }
            },
            {
                "type": "section",
                "fields": [
                    {"type": "mrkdwn", "text": f"*Event:* {event_name}"},
                    {"type": "mrkdwn", "text": f"*Source:* {event_source}"}
                ]
            }
        ]
    }
    
    # Slack送信
    req = urllib.request.Request(
        SLACK_WEBHOOK_URL,
        data=json.dumps(message).encode('utf-8'),
        headers={'Content-Type': 'application/json'}
    )
    urllib.request.urlopen(req)
    
    return {'statusCode': 200}

定期レポートの自動生成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
import boto3
from datetime import datetime

def generate_compliance_report():
    """コンプライアンス状態の定期レポートを生成"""
    config = boto3.client('config')
    ct = boto3.client('controltower')
    
    report = {
        'generated_at': datetime.utcnow().isoformat(),
        'compliance_summary': {},
        'non_compliant_resources': []
    }
    
    # コンプライアンスサマリーの取得
    summary = config.get_compliance_summary_by_config_rule()
    report['compliance_summary'] = {
        'compliant': summary['ComplianceSummary']['CompliantResourceCount']['CappedCount'],
        'non_compliant': summary['ComplianceSummary']['NonCompliantResourceCount']['CappedCount']
    }
    
    # 非準拠リソースの詳細取得
    non_compliant = config.describe_compliance_by_config_rule(
        ComplianceTypes=['NON_COMPLIANT']
    )
    
    for rule in non_compliant['ComplianceByConfigRules']:
        details = config.get_compliance_details_by_config_rule(
            ConfigRuleName=rule['ConfigRuleName'],
            ComplianceTypes=['NON_COMPLIANT'],
            Limit=10
        )
        for result in details['EvaluationResults']:
            report['non_compliant_resources'].append({
                'rule': rule['ConfigRuleName'],
                'resource_type': result['EvaluationResultIdentifier']['EvaluationResultQualifier']['ResourceType'],
                'resource_id': result['EvaluationResultIdentifier']['EvaluationResultQualifier']['ResourceId']
            })
    
    return report

Infrastructure as Codeによる管理

Control Towerの設定をコードで管理することで、再現性と変更追跡が可能になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# control-tower-config.yaml
# Customizations for Control Tower (CfCT) 設定例

region: ap-northeast-1
version: 2021-03-15

organizational_units:
  - name: Security
    accounts:
      - name: Log Archive
        email: log-archive@example.com
      - name: Audit
        email: audit@example.com
  
  - name: Production
    core_ou: true
    guardrails:
      - identifier: AWS-GR_ENCRYPTED_VOLUMES
        enable: true
      - identifier: AWS-GR_RDS_INSTANCE_PUBLIC_ACCESS_CHECK
        enable: true

  - name: Development
    guardrails:
      - identifier: AWS-GR_ENCRYPTED_VOLUMES
        enable: true

service_control_policies:
  - name: DenyRootUser
    policy_file: policies/deny-root-user.json
    targets:
      - Production
      - Development

運用メトリクスと継続的改善

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つの柱で構成されます。本記事で解説した内容を実践することで、安定的で持続可能なマルチアカウント環境の運用が実現できます。

運用のポイントを以下にまとめます。

  1. 日常運用の定型化:ダッシュボード確認、コンプライアンス監視、アカウント管理を定期タスク化
  2. ドリフトの早期検出と修復:EventBridgeによる自動検出、防止策としてのSCP活用
  3. 計画的なバージョンアップ:リリースノート確認、テスト環境での検証、影響範囲の事前評価
  4. 問題解決の体系化:よくある問題と解決パターンの文書化、エスカレーションパスの明確化
  5. 自動化の推進:監視、通知、レポート生成の自動化による運用負荷軽減
  6. 継続的改善:KPIの測定とフィードバックループによる運用品質向上

Control Towerは設定して終わりではなく、継続的な運用と改善が求められるサービスです。本記事の内容を参考に、組織の要件に合った運用体制を構築し、セキュアで効率的なマルチアカウント環境を維持してください。

参考リンク