アラーム（データポイント数「M out of N」によるノイズ抑制）難易度 高無料
あるアラームは「1分間隔で評価し、直近1回のデータポイントがしきい値を超えたら即ALARM」という設定になっているが、ネットワークの瞬間的な揺らぎで単発スパイクが発生するたびに誤発報（false positive）が多発している。実際に障害として扱いたいのは「継続的にしきい値を超え続けている状態」のみである。オンコール対応の負荷を減らすための最も適切な変更を選べ。（単一選択）
- Aアラームのしきい値を現在より大幅に高い値へ引き上げ、多少のスパイクでは超えないようにする
- B評価期間（Evaluation Periods）を5、データポイント数（Datapoints to Alarm）を3に設定し、「直近5回の評価のうち3回以上しきい値を超えた場合」にALARMへ遷移するよう変更する
- Cアラームのアクション設定でSNS通知先を減らし、通知を受け取るオンコール担当者の人数を減らして負荷を分散させる
- Dアラームの比較演算子を
GreaterThanThresholdからGreaterThanOrEqualToThresholdに変更する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・独立検証済
解説
CloudWatchアラームには、「直近何回中、何回しきい値を超えたらALARMにするか」を指定する 「データポイント数（Datapoints to Alarm）＝M out of N」という設定がある。
- 例えば「評価期間（Evaluation Periods）5回のうち3回」（3 out of 5）と設定すると、 直近5つのデータポイントのうち3つ以上がしきい値を超えて初めてALARMになり、単発の1回だけのスパイクでは発報しなくなる。
- これは、しきい値そのものを変えずに「継続性・頻度」でノイズを抑制する手法であり、 本問のように「一時的な揺らぎは無視し、持続的な異常だけを検知したい」という要件に直接対応する。
- これに対し、しきい値自体を緩める対応は、本来検知したい持続的な異常の検知感度まで一律に下げてしまう副作用があり、根本対応として適切でない。
- Aしきい値を緩めると、本来検知したい持続的な高負荷そのものの検知感度まで下がってしまう。単発ノイズの抑制と持続的異常の検知は別軸で解決すべき。
- C誤発報の根本原因（単発スパイクへの過敏な反応）を解消しておらず、単に通知を受け取る人を減らすだけでは同じ回数だけ誤発報が発生し続ける。
- D比較演算子の変更は「しきい値と等しい場合も含めるか」を左右するだけで、単発スパイクによる誤発報を抑制する仕組みではない。
ひっかけ： 「しきい値の数値を上げる（誤答）」でも一時的にノイズは減るが、本当に深刻な持続的高負荷の検知感度まで一緒に下げてしまうという副作用がある。
「単発のノイズを無視し、継続性のあるものだけ拾いたい」という要件はDatapoints to Alarm（M out of N）で解決するのが定石。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）