# 制限
<a name="alarm-limits"></a>

## 一般的な CloudWatch クォータ
<a name="general-cloudwatch-quotas"></a>

アラームに適用される一般的な CloudWatch サービスクォータについては、「[CloudWatch サービスクォータ](cloudwatch_limits.md)」を参照してください。

## メトリクス数式に基づくアラームに適用される制限
<a name="metric-math-alarm-limits"></a>

メトリクスの数式に基づくアラームには、最大 10 個のメトリクスを参照することができます。これは増やすことのできない厳格な上限です。1 つのアラームで 10 個を超えるメトリクスをモニタリングする必要がある場合は、次のいずれかのアプローチを検討してください。
+ メトリクスが同じ名前空間にある場合は、アラームでメトリクス数式ではなく、Metrics Insights クエリを使用します。Metrics Insights は、単一のクエリで多くのメトリクスを集約できます。
+ Lambda 関数を使用してメトリクスを事前集計してカスタムメトリクスを発行し、アラーム式でその集計済みメトリクスを参照します。
+ ロジックを複数のアラームに分割し、複合アラームを使用して結合します。

## Metrics Insights クエリに基づいてアラームに適用される制限
<a name="metrics-insights-alarm-limits"></a>

CloudWatch Metrics Insights アラームを使用する場合は、以下の機能制限に注意してください。
+ リージョン別でアカウントごとに Metrics Insights クエリを使用するアラームのデフォルトの数 200
+ アラームの状態の評価に使用できるのは、直近 3 時間のデータのみです。ただし、アラームの詳細ページグラフでは最大 2 週間のデータを視覚化できます
+ 複数の時系列を評価するアラームは、ALARM のコントリビューターの数を 100 に制限します
  + クエリが 150 個の時系列を取得すると仮定すると、次のようになります。
    +  ALARM のコントリビューター数が 100 未満 (95 など) の場合、`StateReason` は「ALARM に対して評価された時系列は 150 件中 95 件」になります 
    +  ALARM のコントリビューター数が 100 以上 (105 など) の場合、`StateReason` は「ALARM に対して評価された時系列は 100 件以上」になります 
  + さらに、属性の量が多すぎる場合、ALARM のコントリビューターの数は 100 未満に制限できます。
+ 分析または返される時系列の最大数に関する Metrics Insights の制限が適用されます
+ アラームの評価中、次の制限のために `EvaluationState` は `PARTIAL_DATA` に設定されます。
  +  Metrics Insights クエリが 500 を超える時系列を返した場合。
  +  Metrics Insights クエリが 10,000 を超えるメトリクスと一致する場合。

CloudWatch サービスクォータ と制限の詳細については、「[CloudWatch Metrics Insights サービスクォータ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-metrics-insights-limits.html)」を参照してください。

## PromQL クエリに基づいてアラームに適用される制限
<a name="promql-limits"></a>

CloudWatch PromQL アラームを使用する場合は、以下の機能制限に注意してください。
+ 複数の時系列を評価するアラームは、ALARM のコントリビューターの数を 100 に制限します
  +  ALARM のコントリビューター数が 100 未満 (95 など) の場合、`StateReason` は「ALARM に対して評価された時系列は 95 件」になります 
  +  ALARM のコントリビューター数が 100 以上 (105 など) の場合、`StateReason` は「ALARM に対して評価された時系列は 100 件以上」になります 
  + さらに、属性の量が多すぎる場合、ALARM のコントリビューターの数は 100 未満に制限できます。
+ 分析または返される時系列の最大数に関する PromQL の制限が適用されます
+ アラーム評価中に、PromQL クエリが 500 件を超える時系列を返す場合、`EvaluationState` は `PARTIAL_DATA` に設定されます。

## 接続されたデータソースに基づくアラームに適用される制限
<a name="MultiSource_Alarm_Details"></a>
+ 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 で無視され、アラームは、指定されている欠落データの処理方法に従って状態に遷移します。詳細については、「[アラーム評価](alarm-evaluation.md)」を参照してください。
+ いくつかの Lambda 関数の失敗ユースケースでは、設定されているアラームによる欠落データの処理方法に関係なく、アラームが `INSUFFICIENT_DATA` に遷移するため、これらのアラームを作成して、`INSUFFICIENT_DATA` 状態に遷移したときにアクションを実行することをお勧めします。
+ Lambda 関数がエラーを返した場合：
  + Lambda 関数の呼び出しでアクセス権限の問題が発生した場合、アラームの作成時に欠落データを処理するように指定した方法に従って、アラームは欠落データの遷移を開始します。
  + Lambda 関数から発生するその他のエラーにより、アラームは `INSUFFICIENT_DATA` に遷移します。
+ Lambda 関数によってリクエストされたメトリクスに遅延があり、最後のデータポイントが常に欠落している場合は、回避策を使用する必要があります。N 個中 M 個のアラームを作成するか、アラームの評価期間を長くすることができます。N 個中 M 個のアラームについては、「[アラーム評価](alarm-evaluation.md)」を参照してください。