SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は本番EC2インスタンスに対してCloudWatchで「CPU使用率90%超」「メモリ使用率85%超」「ディスク使用率80%超」の3つの個別アラームを設定しています。夜間バッチ処理中にこれら3つのアラームが頻繁に発報し、担当者が不要な対応を強いられる「アラート疲れ」が発生しています。夜間バッチの特性上、いずれか1指標が高くなるのは正常であるため、「3指標すべてが同時に閾値超過した場合のみ」通知を受け取りたいという要件を、既存アラームを変更せずに最小構成で実現するには何をすればよいですか。
A3つの個別アラームをすべて廃止した上で、CPU・メモリ・ディスク使用率を統合したカスタム複合メトリクスをCloudWatchエージェントで再定義し、単一の閾値アラームとSNS通知を新たに構築する
既存アラームを廃止してカスタム複合メトリクスから再構築するアプローチは、CloudWatchエージェントの設定変更・既存モニタリングの全面見直しが必要で、「既存アラームを変更せず最小構成」という要件に反し、かえって運用負荷が増加します。
BCloudWatch Composite Alarmを作成し、3つの既存アラームをAlarm Ruleの「ALARM(cpu) AND ALARM(mem) AND ALARM(disk)」形式で組み合わせ、この複合アラームのみをSNSトピックに接続する
✓ 正解
CloudWatch Composite Alarmは既存の個別アラームを変更せず、AND/OR/NOT演算子によるAlarm Ruleで複合アラームを作成するだけで実現できます。複合アラームのみSNS通知に接続することで、3指標同時閾値超過時のみ通知するロジックを最小構成で設定できます。
CAmazon EventBridgeルールで3つのアラームの状態変化イベントを受信するAWS Lambdaを設定し、3つすべてがALARM状態かどうかをDescribeAlarmsで確認して条件一致時のみSNS通知を送信する
EventBridge+Lambdaでも3アラームの状態を条件付きで評価できますが、Lambda関数の実装・デプロイ・IAMロール設定・テストなど複数の構成手順が必要です。Composite Alarmに比べ構成が複雑で運用負荷も高くなります。
DCloudWatch Dashboardに3つのアラームのステータスウィジェットを追加してオンコール担当者が定期的に目視確認し、3つが同時にALARM状態になったときのみ手動でインシデント対応を開始する
CloudWatch Dashboardによる目視確認は自動アラートではなく人的な監視作業です。担当者がダッシュボードを常時監視する必要があり、「アラート疲れ」を解消するどころか24時間監視の負担が新たに発生します。
解説
CloudWatch Composite Alarm（複合アラーム）は、複数の既存アラームをAND・OR・NOTの論理演算子で組み合わせて「上位アラーム」を作成する機能です。既存の個別アラームを変更・廃止せずに複合アラームを追加するだけで実現できます。SNS通知を複合アラームのみに接続し、個別アラームのSNSアクションを削除することで「3つすべてがALARM状態のときだけ通知」というロジックを最小構成で実装できます。
選択肢AのカスタムCloudWatchエージェント複合メトリクスは、既存アラームの廃止・エージェント設定変更・アラーム再設定が必要で「既存アラームを変更せずに最小構成」の要件に反します。
選択肢CのEventBridge+Lambdaは機能的には実現可能ですが、Lambda関数の実装・デプロイ・IAMロール設定・管理など複数の構成手順が必要でComposite Alarmより大幅に複雑になります。
選択肢DのCloudWatch Dashboardによる目視確認は自動アラートではなく、担当者が常時監視する必要があるため運用負荷が増大し、自動通知の要件を満たしていません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →