1.1標準
注文数をCloudWatchカスタムメトリクスへ継続送信している。1分間のSumは時間帯・曜日に応じて変動し、正常時の履歴がある。
通常より多すぎる場合も少なすぎる場合もSNSへ通知したい。正常な週次ピークを毎回異常扱いする固定しきい値は避けたい。
最も適切な監視構成はどれか。
× 不正解
注文数の1分Sumに異常検出モデルを作り、期待帯の上側・下側への逸脱をSNSへ通知する。
詳細解説
誤りEC2のCPUUtilizationにだけ異常検出を設定する
CPU使用率は注文数の増減そのものではない。注文数メトリクスを指定する要件を満たさない。
誤り注文数グラフに期待帯を表示するだけでアラームを作らない
画面で逸脱を確認できても、期待帯の表示だけではSNSへの通知にならない。
誤り注文数に単一の固定上限だけを設定する
曜日・時間帯で変わる正常範囲を表しにくく、注文数の異常な減少も検出条件に入らない。
正しい注文数のSumにanomaly detectionを設定し、期待帯の上下への逸脱をSNS通知する
当該メトリクスと統計値の履歴から期待範囲を作り、上側と下側の両方をアラームの判定に使える。
公式資料で確認する
以下の項目を公式資料の記述と照合して確認します。
公式資料でモデルのメトリクス・統計値、帯の幅、上下の判定条件、SNS通知を確認する。
参考にした公式資料
確認できる内容
期待帯の表示と通知アラームを区別し、学習データの選択と帯の幅による検知感度を説明できる。
理解のポイント
- anomaly detection
- 期待範囲
- 季節変動
確認時の注意
- 確認環境: AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
- AWS公式SOA-C03試験ガイドと各サービスの公式ドキュメントを確認する。
基礎のおさらい
モデルはメトリクスと統計値に対応する
異常検出は時間帯・日次・週次のパターンを考慮する。注文数のSumのモデルを、CPUや注文数のAverageのモデルと混同しない。グラフへ帯を表示するだけでは通知されず、逸脱条件とSNSアクションを設定する。
学習範囲と感度を調整する
最大2週間の履歴を学習に使うが、開始に必ず2週間分が必要なわけではない。障害やデプロイ期間は学習対象から除外できる。帯を広くすると逸脱が少なくなるため、履歴で検知結果を確かめ、正常と異常を完全に判別できると考えない。
問題IDAWS-SOA-017
確認環境AWS公式SOA-C03試験ガイドとAWS公式ドキュメントの確認
最終技術確認2026-10-04
誤り・権利侵害を報告