SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業では、EC2インスタンスごとにCPU使用率・ネットワーク受信量・ステータスチェックの3つのCloudWatchアラームをそれぞれ設定しています。しかし個別アラームが頻繁に誤発報してオペレーターが疲弊しています。「CPUとネットワーク受信量が同時に閾値超過し、かつステータスチェックが失敗したとき」のみSNS通知を受け取りたい場合、最も運用負荷が低い実装方法はどれですか？
A既存の3つのアラームをトリガーとするLambda関数を作成し、すべてがALARM状態のときだけSNS通知を送信するロジックを実装する
Lambdaでアラーム状態を評価する構成は、EventBridgeからの状態変化イベント受信・複数アラーム状態の追跡・SNS通知のカスタムロジック実装が必要です。設計・実装・テストに手間がかかり、コンポジットアラームと比べて運用負荷が格段に高くなります。
BCloudWatchコンポジットアラームを作成し、3つの既存アラームをすべてAND条件で組み合わせるルール式を定義する
✓ 正解
CloudWatchコンポジットアラームは複数の既存アラームをAND・OR・NOT条件で組み合わせるAWS標準機能です。追加のコード実装や外部サービス不要で、3つすべてのアラームがALARM状態のときだけSNS通知できるルールを最小限の設定で実現できます。
CCloudWatch Dashboardに全アラームを集約し、運用チームが定期的に手動確認して対応する
CloudWatch Dashboardはアラームや各種メトリクスを可視化するためのツールです。条件に応じた自動通知機能はなく、運用チームが定期的に手動確認する方式では即時対応が困難で、自動的に通知を受け取るという要件を満たしていません。
DEventBridgeルールを3つ作成し、各アラームの状態変化をStep Functionsに送り、すべてALARMになったときだけSNSに通知する
EventBridgeとStep Functionsを組み合わせた構成は、各アラームのEventBridgeルール・ステートマシンの設計・全アラームのALARM状態管理・SNS連携と複数サービスにわたる複雑な実装が必要です。コンポジットアラームで容易に実現できることを過度に複雑化しています。
解説
CloudWatchコンポジットアラームを作成し、3つの既存アラームをすべてAND条件で組み合わせるルール式を定義する。
CloudWatchコンポジットアラーム（Composite Alarm）は、複数の既存アラームをAND・OR・NOT条件で組み合わせる機能です。個別アラームがALARM状態になっても通知せず、ルール式が満たされたときのみ通知できるため、アラームノイズ（誤発報の多発による疲弊）を大幅に削減できます。
選択肢AはLambdaを使う構成は設計・実装コストが高くなります。
選択肢CはDashboardの手動確認は自動化と言えません。
選択肢DはStep Functionsを使う方法も設計・実装コストが高くなります。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →