Control Tower LZ 4.0 環境で見えた CT 作成管理 SNS と EventBridge のいま

JAWS-UG東京 ランチタイムLT会 #34
https://jawsug.connpass.com/event/388571/

Transcript

1. 2026/04/23 JAWS-UG東京 ランチタイムLT会 #34 Control Tower LZ 4.0 環境で⾒えた CT 作成管理 SNS と EventBridge のいま
2. AWS Control Tower とは 2 • AWS 上でマルチアカウント環境を安全かつ効率的に構築‧管理するための マネージドサービス • 主な機能 ◦ ベースライン適⽤（アカウント作成時の設定⾃動化） ◦ コントロール （SCP / Config Rules / CFn hook 等による予防‧検知‧プロアクティブ） ◦ ドリフト検知 （CT が管理する設定が意図せず変更されたことを検出） • 2025 年に LZ 4.0 がリリース。ひとつ前は LZ 3.3 ※AWS Black Belt Online Seminar AWS Control Tower 基礎編 より引用
3. なぜ今⽇は SNS と EventBridge の話？ 3 • CT の「ドリフト検知」は 検知するだけ でなく 通知を送る仕組み とセット • LZ 3.3 までの通知経路 ◦ CT → SNS トピック（CT ⾃動作成）→ サブスクライバー（購読は⼿動設 定） • LZ 4.0 からの通知経路 ◦ CT → EventBridge にシフト（公式） • アップグレード後、既存の SNS はどうなる？EventBridge に流れるドリフ ト通知はどこで受け取る？ → これを検証環境で確かめたのが今⽇の話
4. 前提: LZ 4.0 移⾏ガイドによる主な変更点 4 公式ドキュメント Key changes in landing zone v4.0 からの引⽤ AWS Control Tower will stop sending drift notifications to SNS topic for all customers on landing zone 4.0 without the AWSControlTowerBaseline enabled, and will start sending drift notifications to EventBridge in the management account instead. 機械翻訳 ドリフト通知: AWS Control Tower は、AWSControlTowerBaseline が有効になっていな いランディングゾーン 4.0 上のすべてのお客様に対して、SNS トピックへのドリフト通知 の送信を停⽌し、代わりに管理アカウントの EventBridge にドリフト通知の送信を開始 します。 • 要約すると「ドリフト通知は SNS → EventBridge（管理アカウント） に移 る」ってことか？🤔 • 「SNS はもう使わないのかな？」「管理アカウントに EventBridge 関連のリ ソースができるってことかな？」と思いませんか？
5. 検証環境で⾒てみた 5 LZ 3.3 から LZ 4.0 へアップグレードした結果、 実際の挙動は⾃分が考えていたのと少し違った
6. 発⾒ ① : SNS トピックは消えていない 6 アップグレード後の Audit アカウント • aws-controltower-SecurityNotifications → 残存 • aws-controltower-AggregateSecurityNotifications → 残存 • aws-controltower-AllConfigNotifications → 残存 アップグレード後の Log Archive アカウント • aws-controltower-SecurityNotifications → 残存 • aws-controltower-CentralizedLoggingNotifications → 新規追加 Audit Topic × 3 Log Archive Topic Topic NEW
7. 発⾒ ② : EventBridge は SNS の 前段 に⼊る 7 Before (LZ 3.3): Config イベント → SNS → 既存サブスクライバー After (LZ 4.0): Config イベント → EventBridge ルール → SNS → 既存サブスクライバー • EventBridge が SNS を 置き換えた のではなく ルーティング層として前段に挟まった • 既存の SNS サブスクライバー（メール通知、Lambda 等）は 引き続き動作する • アップグレード後の既存運⽤への影響が⼩さい設計 Topic Rule Event Email Lambda function Config NEW
8. 発⾒ ③ : EventBridge ルールは統合アカウントに置かれる 8 Audit / Log Archive に同じ 2 種のルールが作成される • AWSControlTowerManagedRule • aws-controltower-ConfigComplianceChangeEventRule 管理アカウントには CT 関連 EventBridge ルールは追加されない • 公式⽂章の「EventBridge in the management account」は ドリフト通知の送 信先 を指しているのであって、ルールが管理アカウントに作られる という意味 ではない • ドリフト通知を受け取りたい場合、管理アカウントにルールを ⾃分で作成する
9. 発⾒ ④ : ルールを作るまで誰も拾ってくれない 9 アップグレード直後の管理アカウント • CT 関連の⾃動作成 EventBridge ルール: なし • でも、CT のドリフトは発⽣しうる • じゃあ、そのドリフト通知はどこへ？ Control Tower ドリフト発⽣ Event Rule ドリフト通知はどこへ…？
10. EventBridge の基本挙動 10 • EventBridge 対応の AWS サービスがイベントを発⽣させると、動作してい るアカウントの default event bus に配信される • ルールがマッチしなければ、イベントは 拾われずに消える • 「通知が来ない」≠「イベントが発⾏されていない」 つまり イベントは流れているが、拾うルールがない という状況があり得る Control Tower ドリフト発⽣ Event ルールが無いので拾われずに消える！
11. 検証: 管理アカウントにルールを⾃作 11 作成したルール • 配置先: 管理アカウント / default event bus • ターゲット: CloudWatch Logs（イベントの中⾝を確認するため） イベントパターン { "source": ["aws.controltower"], "detail-type": ["Drift Detected"] }
12. 検証: 管理アカウントにルールを⾃作 12 届いたイベント（抜粋） { "detail-type": "Drift Detected", "source": "aws.controltower", "account": "111122223333", "time": "2026-04-22T14:30:12Z", "region": "ap-northeast-1", "detail": { "driftType": "ACCOUNT_MOVED_BETWEEN_OUS", "accountId": "444455556666", "sourceId": "ou-xxxx-workload", "destinationId": "ou-xxxx-default", "remediationStep": "..." } } → default event bus にドリフトイベントが流れていた証拠
13. 統合アカウントの⾃動作成ルールは別物 13 発⾒③で確認した 2 つの⾃動作成ルール • AWSControlTowerManagedRule: Security Hub Findings を CT サービスへルーティング • aws-controltower-ConfigComplianceChangeEventRule: Config Rule のコンプライアンス変化を SNS へルーティング いずれも CT ドリフト⽤ではない。 ⽤途が違うだけで、CT ドリフトが「来ていない」わけではない → ドリフト通知を拾う仕組みは ユーザー側で⽤意する必要がある
14. おまけ: OU 移動でもドリフトにならないケース 14 検証中に気づいた点 • CT 登録済み OU 間の移動は ドリフトにならない • CT 登録済み OU → CT 未登録 OUへの移動 ドリフトになる ◦ ドリフト種別 ACCOUNT_MOVED_BETWEEN_OUS は 「CT 管理階層を跨いだ移動」で検出される
15. なぜ EventBridge を挟んだのか（考察） 15 ① AWS 各サービスのイベント発⾏パターンとの⼀貫性 • GuardDuty / Security Hub / Config は 2019 年頃には EventBridge 対応済み • CT は LZ 4.0（2025 年）で 対応 • 横断的な⾃動化がやりやすくなり、他サービスと同じ要領で扱えるようになった ② ルーティング‧フィルタリングの柔軟性 • SNS: サブスクライバーは全部受け取る（細かいフィルタは購読側で実装） • EventBridge: イベントパターンで送信前に絞れる、複数ターゲットに分岐可能 • 例: ドリフトは Lambda、コンプラ違反は SNS、他は CloudWatch Logs …と使い 分けできる ※ AWS の公式⾒解ではなく、検証環境での観察からの考察です
16. まとめ: LZ 4.0 の CT 作成管理 SNS と EventBridge のいま 16 • 「SNS → EventBridge」は単純な置換ではなく、SNS はそのまま、前段に EventBridge が追加された • 既存の SNS サブスクライバーは そのまま動き続ける • CT ⾃動作成 EventBridge ルールは Audit / Log Archive にある • 管理アカウントでドリフト通知を拾うには ルールをユーザー側で作成する 必要がある ◦ CT に限らず、管理アカウントのあらゆる AWS サービスのイベントが同じ