SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業はEC2インスタンス（Webサーバー）に対して以下の3つのCloudWatchアラームを独立して設定しています。
・CPU使用率90%超
・メモリ使用率85%超
・ディスク使用率95%超
現在いずれか1つが閾値を超えるたびにSNS通知が送られるため、アラームノイズが多くオンコールエンジニアが疲弊しています。「3つすべてのアラームが同時にALARM状態になった場合のみ通知する」仕組みを追加コードなし・最小の運用負荷で実現するには？
ACloudWatch Composite Alarmを作成し、ALARM(CPU) AND ALARM(Memory) AND ALARM(Disk)のルール式で3つを結合する。このComposite AlarmにのみSNSアクションを設定し、既存の個別アラームからSNSアクションを削除する
✓ 正解
Composite AlarmはAND/ORロジックで複数アラームを結合するネイティブ機能です。追加コード不要で、コンソールからルール式を設定するだけで3つ同時ALARM状態時のみSNS通知が実現します。
B既存3つのアラームのSNSアクションを同一トピックに向け、そのトピックをトリガーとするLambda関数でDescribeAlarmsを呼び出して全アラームの状態を確認し、3つともALARM状態の場合のみ管理者へ通知する
Lambda関数でDescribeAlarmsを呼び出す方法は機能しますが、コードの実装・デプロイ・保守が必要です。Composite Alarmに比べて運用負荷が高く、最小運用負荷の要件を満たしません。
CEventBridgeルールで各CloudWatchアラームのStateChangeイベントをキャプチャし、Lambda関数がParameter Storeに各アラームの状態を書き込みながら3つが同時にALARMになった時点でSNS通知を送る
Parameter Storeを使った状態管理は複数の非同期イベントを整合させる仕組みが複雑で、タイミング依存の不具合が発生しやすく、構成の信頼性・保守性ともにComposite Alarmより劣ります。
DCloudWatch Dashboardに3つのアラームをまとめ、各メトリクスにCloudWatch Anomaly Detectionを追加することで統計的バンド外検出に置き換え、誤検知を削減してノイズを抑制する
CloudWatch Anomaly Detectionは過去パターンから期待値バンドを生成する異常検出機能であり、複数アラームのAND条件結合によるノイズ削減とは目的が異なり、要件を満たしません。
解説
CloudWatch Composite Alarm（複合アラーム）は、複数のCloudWatchアラームをAND/ORのロジック式で結合する機能です。ALARM(CPU) AND ALARM(Memory) AND ALARM(Disk)のルール式を設定することで、3つすべてが同時にALARM状態になったときのみアクションを実行できます。追加のLambdaや外部コードは不要で、コンソールまたはCloudFormationから数ステップで設定できます。個別アラームはデータ収集・評価を続けながらも通知を抑制し、Composite Alarmが一元的に通知を管理します。
選択肢BのLambdaはDescribeAlarms APIで全アラームの状態を確認する設計で機能しますが、コードの実装・デプロイ・保守が必要で運用負荷がComposite Alarmより大きくなります。
選択肢CのEventBridge＋Parameter Storeによる状態管理は複数の非同期イベントを整合させる仕組みが複雑で、信頼性の確保が難しく最小構成とは言えません。
選択肢DのAnomaly Detectionは過去のメトリクスパターンから期待値バンドを生成する異常検出機能であり、複数アラームのAND条件結合でノイズを削減する要件とは目的が異なります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →