グローバルメディア配信企業が、5,000万人以上のデイリーアクティブユーザーを持つ動画ストリーミングプラットフォームを3リージョン（us-east-1、eu-west-1、ap-northeast-1）で運用しています。 【アラート疲弊（Alert Fatigue）の問題】 ・SREチーム（Site Reliability Engineering：サービス信頼性を担当するエンジニアリング組織）が1日600件以上のCloudWatchアラームを受信しており、対応が困難 ・アラームの80%以上が以下の理由による誤報（False Positive）： - 深夜の定期バッチ処理による一時的なCPUスパイク - 週次コンテンツリリース時の正常なトラフィック急増 - タイムゾーンによる地域別の時間帯差分トラフィック変動 ・静的閾値のため曜日・時間帯のパターンが反映されていない ・重大インシデントが誤報に埋もれ、MTTD（Mean Time to Detect：インシデント平均検知時間）が45分に達している ・独立したサービスのアラームが文脈なしに発砲される（例：定期レポート処理中にDBのCPUアラームが単独で通知される） 【要件】 ・誤報率を80%以上削減する ・真のインシデントを100%検知する（見逃しゼロ） ・追加の外部ツール導入コストを最小化する ・計画メンテナンス時間帯のアラーム抑制を実現する 最小の運用オーバーヘッドで要件を満たすアーキテクチャはどれですか？
CloudWatch Anomaly DetectionはMLを使用して日次・週次の周期パターンを自動学習し、正常なビジネス変動による誤報を大幅に削減します。Composite Alarmは複数の独立したアラームをAND/OR条件で組み合わせ、文脈なしの単発アラームを防ぎます。Alarm Action Suppressorはメンテナンスウィンドウ中のアクション実行を抑制でき、これらはすべてAWSネイティブサービスで追加コスト最小化の要件を満たします。 選択肢BのAmazon Managed Grafana はCloudWatchメトリクスの可視化・アラートには有効ですが、CloudWatch Anomaly Detectionのような組み込みMLによる季節性学習機能がなく、Prometheusへの移行が必要なため構築コストが高くなります。 選択肢CのAmazon EventBridge ルールとLambda カスタムアルゴリズムは、AnomalyDetection・Composite Alarmで標準提供される機能を自前で再実装することになり、開発・テスト・運用コストが大幅に増加します。 選択肢DのAWS Fault Injection Simulator はカオスエンジニアリングツールであり誤報削減には使用しません。AWS Health APIはAWSサービス自体の障害イベントを提供するものであり、アプリケーションメトリクスの異常検知には使用できません。