DOP-4.3複雑な環境のモニタリングとイベント管理を自動化する
採点する
2問中 0問が回答されています
質問:
インフォメーション
You have already completed the テスト before. Hence you can not start it again.
問題を読み込んでいます…
You must sign in or sign up to start the テスト.
まず、次の操作を完了する必要があります:
結果
結果
正解数 0/問題数2
回答にかかった時間:
終了時間となりました
回答お疲れ様でした。
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
カテゴリー
- DOP-4.3複雑な環境のモニタリングとイベント管理を自動化する 0%
- 1
- 2
- 選択中
- 後で確認
- 回答済み
- 正解
- 不正解
-
質問 1 of 2
1. 質問
カテゴリ: DOP-4.3複雑な環境のモニタリングとイベント管理を自動化する【DOP-126】企業 X は AWS Organizations 配下に 20 のメンバーアカウントを運用しており、Trusted Advisor Priority を組織全体で有効化済みである。
運用チームはサービス制限の残余が 10 % を切った時点（Trusted Advisor「Service Limits」チェックが WARN または ERROR になるタイミング）で以下の要件を満たす通知機構を構築したい。
1) 検知から 5 分以内にアラートを発報する
2) ルールやコードは 1 か所で保守し、全アカウントに再展開せずに更新できる
3) 通知は組織管理アカウントに存在する既存の Slack 連携用 SNS トピックへ JSON 形式で配信する
4) 将来、同一のイベントバスに他の運用イベントも追加できる拡張性を確保する
上記の要件を最も効率的かつ運用負荷が低い方法で満たすアーキテクチャはどれか。正解不正解ヒントボタン
Trusted Advisor Priority ではステータスが WARN や ERROR になった瞬間に source が aws.trustedadvisor のイベントが EventBridge 組織レベルのデフォルトバスへ自動発行されます。イベント到達は通常数十秒以内で、EventBridge の再試行や DLQ により信頼性も高く、ポーリング型の CloudWatch スケジュール Lambda と比べて検知遅延・実行コストを大幅に削減できます。
AWS Organizations の委任管理者を設定しておけば、EventBridge ルールや Lambda を組織管理アカウントの 1 か所だけに置くだけで 20 のメンバーアカウントすべての Trusted Advisor イベントを収集できます。StackSets でルールを配布したり各アカウントに個別の Lambda を置く方式は更新作業が多くなり、「再展開せずに保守」という要件に合致しません。
EventBridge で条件判定→ターゲットの Lambda で Slack 用 JSON を整形→既存の SNS トピックへ Publish というサーバレス連携にすれば、5 分以内通知・集中管理・拡張性の全要件を満たせます。将来は同じバスに Security Hub や Service Quotas など他イベントも簡単に追加できるため、総合的に最も運用負荷が低いアーキテクチャとなります。
-
質問 2 of 2
2. 質問
カテゴリ: DOP-4.3複雑な環境のモニタリングとイベント管理を自動化する【DOP-127】金融SaaS 企業は 1 リージョンに約 500 台の EC2 を運用している。
運用部門は
1) タグ Environment=Prod かつ AutoStop=Disabled を持つ EC2 が
2) stopped または terminated へ遷移した瞬間のみ Slack 通知したい。
今後インスタンスが倍増しても追加設定を最小に抑え、不要な Lambda 呼出や誤通知を排除できる構成を選べ。正解不正解ヒントボタン
Amazon EventBridge には detail-type=EC2 Instance State-change Notification の標準イベントがあり、detail.state を stopped と terminated、tags.Environment=Prod、tags.AutoStop=Disabled に絞ったイベントパターンを 1 本作るだけで要件を満たせます。フィルタ後に SNS をターゲットにすれば Lambda を挟まず Slack へ届けられ、インスタンスが倍増しても追加設定は不要です。
CloudWatch の StatusCheckFailed_System アラームや Auto Scaling のライフサイクルフック、Systems Manager Run Command は、インスタンス単位の作成やポーリングが必要だったり、停止中はエージェントが働かなかったりと、タグと状態を同時に判定して即時通知する用途では運用負荷や取りこぼしが発生しやすいことを思い出しましょう。
①タグで Prod かつ AutoStop=Disabled を抽出 ②stopped／terminated の瞬間のみ即時通知 ③将来台数が倍になっても設定追加は最小 ④Lambda など不要な呼び出しを排除、という複数要件を俯瞰すると、タグ条件と状態遷移を単一ルールで処理できる Amazon EventBridge と SNS の組み合わせが最もシンプルかつ拡張性に優れると総合判断できます。
改善リクエスト