SOAモニタリング、ロギング、分析、修復、およびパフォーマンスの最適化
ある企業は本番環境のEC2インスタンス群に対してCloudWatchアラームを個別に設定しています（CPU使用率・ネットワークエラー率・アプリケーションレイテンシ・ディスク使用率など）。大規模障害発生時に数十件のアラームが同時に通知され、運用チームがアラート疲れを起こしています。運用チームは以下の要望を持っています。
・CPUとエラー率が同時に閾値を超えた場合のみ重大インシデントとして1件の通知を送りたい
・個別アラームはダッシュボードで引き続き確認したい
最も運用負荷の低い構成で要件を満たすにはどれが最適ですか？
AAmazon EventBridgeルールでCloudWatchアラームの状態変化を検知し、AWS Step Functionsで複数アラームの論理評価を実行し、条件一致時のみSNSへ通知するワークフローを構成する
EventBridgeとStep Functionsの組み合わせでも複数アラームの相関評価は技術的に可能だが、状態管理・タイムアウト処理・エラーハンドリングを自前で実装する必要があり、Composite Alarmsと比べて構成が複雑で運用負荷が高くなる。
BCloudWatchメトリクスのMath式を使って複数の指標を数式で合成した単一メトリクスを定義し、その合成値が閾値を超えたときのみアラームがトリガーされるよう設定する
CloudWatch Metrics Mathは複数メトリクスを数式で合成できるが、異なる単位のメトリクスへのAND論理評価には適しておらず、個別アラームのSNSアクションを抑制する機能がないため重複通知を防げない。
CCloudWatch Composite Alarmsを使用し、CPUアラームとエラー率アラームをAND条件で組み合わせたうえでアクションサプレッションを設定し、複合アラームのみがSNS通知を発火するよう構成する
✓ 正解
CloudWatch Composite Alarmsはアクションサプレッション機能により、複合アラームがALARM時に子アラームのSNSアクションを自動抑制して通知を1件に集約できる。AND条件で複合条件を定義でき、追加コンポーネント不要でCloudWatch単体で要件をすべて満たせる。
DAWS Lambda関数がAmazon DynamoDBでアラーム状態を管理し、複数アラームが同時にALARM状態になったことを検出した場合のみSNS通知を送信する独自の相関評価エンジンを構築する
Lambda + DynamoDBによる独自エンジンは開発・テスト・保守コストが最も高く、CloudWatch Composite Alarmsがネイティブに提供するアクションサプレッション機能を自前実装することになり、最も運用負荷の高い選択肢となる。
解説
CloudWatch Composite Alarms（複合アラーム）は、既存のCloudWatchアラームをAND・OR・NOTのブール論理で組み合わせて1つの親アラームとして管理できる機能です。特に重要な機能が「アクションサプレッション」で、複合アラームがALARM状態になった際に子アラームのSNSアクションを自動的に抑制し、複合アラームのアクションのみを発火させます。これにより「CPUとエラー率が同時に閾値を超えた場合のみ通知する」という要件をCloudWatch単体で実現でき、個別アラームはダッシュボードで引き続き参照できます。追加コンポーネントが不要なため、運用負荷が最も低い選択肢です。
選択肢AのAmazon EventBridge + AWS Step Functionsは、複数アラームの状態追跡・論理評価ロジックを自前で実装する必要があり、構成が複雑で運用負荷が高くなる。
選択肢BのCloudWatch Metrics Mathは異なる単位・スケールの複数メトリクスをAND/OR条件で論理評価するには適しておらず、個別アラームのSNSアクションを抑制する機能も持たない。
選択肢DのAWS Lambda + Amazon DynamoDBによる独自の相関評価エンジンは、開発・テスト・保守コストが最も高く、Composite Alarmsがネイティブに提供する機能を車輪の再発明することになる。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →