制限
一般的な CloudWatch クォータ
アラームに適用される一般的な CloudWatch サービスクォータについては、「CloudWatch サービスクォータ」を参照してください。
Metrics Insights クエリに基づいてアラームに適用される制限
CloudWatch Metrics Insights アラームを使用する場合は、以下の機能制限に注意してください。
-
リージョン別でアカウントごとに Metrics Insights クエリを使用するアラームのデフォルトの数 200
-
アラームの状態の評価に使用できるのは、直近 3 時間のデータのみです。ただし、アラームの詳細ページグラフでは最大 2 週間のデータを視覚化できます
-
複数の時系列を評価するアラームは、同時移行のレートを 100 に制限します
-
クエリが 150 個の時系列を取得すると仮定すると、次のようになります。
-
ALARM のコントリビューター数が 100 未満 (95 など) の場合、
StateReasonは「ALARM に対して評価された時系列は 150 件中 95 件」になります -
ALARM のコントリビューター数が 100 以上 (105 など) の場合、
StateReasonは「ALARM に対して評価された時系列は 100 件以上」になります
-
-
さらに、アラームコントリビューターデータのサイズに基づいて、
StateReasonを切り捨てて時系列データの表示を減らすことができます。コントリビューターを 85 に切り捨てると、StateReasonは次のようになります。-
ALARM のコントリビューター数が 100 未満 (95 など) の場合、85 に切り詰められ、
StateReasonは「ALARM に対して評価された時系列は 150 件中 85 件以上」になります。 -
ALARM のコントリビューター数が 100 以上 (105 など) の場合、85に切り詰められ、
StateReasonは「ALARM に対して評価された時系列は 85 件以上」になります。
-
-
-
分析または返される時系列の最大数に関する Metrics Insights の制限が適用されます
-
アラームの評価中、次の制限のために
EvaluationStateはPARTIAL_DATAに設定されます。-
Metrics Insights クエリが 500 を超える時系列を返した場合。
-
Metrics Insights クエリが 10,000 を超えるメトリクスと一致する場合。
-
CloudWatch サービスクォータ と制限の詳細については、「CloudWatch Metrics Insights サービスクォータ」を参照してください。
接続されたデータソースに基づくアラームに適用される制限
-
CloudWatch はアラームを評価するとき、アラームの期間が 1 分を超えていても、1 分ごとにアラームを評価します。アラームが機能するためには、Lambda 関数が期間の長さの倍数だけでなく、任意の分から始まるタイムスタンプのリストを返すことができなければなりません。これらのタイムスタンプは、1 つの期間の長さの間隔を空ける必要があります。
したがって、Lambda によってクエリされたデータソースが期間の長さの倍数のタイムスタンプしか返せない場合、関数は取得したデータを「再サンプリング」して、
GetMetricDataリクエストで期待されるタイムスタンプと一致させる必要があります。例えば、5 分間隔のアラームは、毎回 1 分ずつシフトする 5 分のウィンドウを使用して 1 分ごとに評価されます。この場合は以下のようになります。
-
12:15:00 のアラーム評価では、CloudWatch は
12:00:00、12:05:00、12:10:00のタイムスタンプを持つデータポイントを予想します。 -
次に、12:16:00 のアラーム評価では、CloudWatch は
12:01:00、12:06:00、12:11:00のタイムスタンプを持つデータポイントを予想します。
-
-
CloudWatch がアラームを評価すると、Lambda 関数によって返されるデータポイントのうち、予想されるタイムスタンプと一致しないものはすべて削除され、残りの予想されるデータポイントを使用してアラームが評価されます。例えば、
12:15:00でアラームが評価されると、12:00:00、12:05:00、12:10:00のタイムスタンプを持つデータを予想します。12:00:00、12:05:00、12:06:00、12:10:00のタイムスタンプを持つデータを受信すると、12:06:00からのデータは削除され、CloudWatch は他のタイムスタンプを使用してアラームを評価します。次の
12:16:00での評価では、12:01:00、12:06:00、12:11:00のタイムスタンプを持つデータを予想します。タイムスタンプが12:00:00、12:05:00、12:10:00のデータしかない場合、これらのデータポイントはすべて 12:16:00 で無視され、アラームは、指定されている欠落データの処理方法に従って状態に遷移します。詳細については、「アラーム評価」を参照してください。 -
いくつかの Lambda 関数の失敗ユースケースでは、設定されているアラームによる欠落データの処理方法に関係なく、アラームが
INSUFFICIENT_DATAに遷移するため、これらのアラームを作成して、INSUFFICIENT_DATA状態に遷移したときにアクションを実行することをお勧めします。 -
Lambda 関数がエラーを返した場合:
-
Lambda 関数の呼び出しでアクセス権限の問題が発生した場合、アラームの作成時に欠落データを処理するように指定した方法に従って、アラームは欠落データの遷移を開始します。
-
Lambda 関数から発生するその他のエラーにより、アラームは
INSUFFICIENT_DATAに遷移します。
-
-
Lambda 関数によってリクエストされたメトリクスに遅延があり、最後のデータポイントが常に欠落している場合は、回避策を使用する必要があります。N 個中 M 個のアラームを作成するか、アラームの評価期間を長くすることができます。N 個中 M 個のアラームについては、「アラーム評価」を参照してください。