API Gateway の Count と使用量プランの使用状況の値に差がある理由を教えてください
困っていた内容
開発段階で、API Gateway の呼び出し回数について計測をしています。
API Gateway の呼び出し回数について、CloudWatch コンソールで確認できる Count メトリクスと、API Gateway コンソールで確認できる使用量プランの使用状況の値に差がある理由について教えてください。
どう対応すればいいの？
API Gateway の使用量プランでは、有効な API キーの送信を伴うリクエストが正常に受け付けられた場合において、クォータの消費が計上されます。
クォータの枠内として正常に受信され、その後に Lambda などの API バックエンドからエラーが応答された場合も、バックエンドから正常応答が得られた場合と同様に使用量プランのクォータが消費されます。
API GatewayのAPIキーと使用量プランについて調べてみた | DevelopersIOより
API Gatewayから呼び出したLambda関数がエラーを返した場合もAPIキーと使用量プランのアクセス回数には計上されますので注意してください。
API ステージ上に実在しないリソースやメソッドに対するリクエストが受信された場合などのゲートウェイレスポンスによるエラー応答は、クォータの消費に計上されません。
一方で CloudWatch の Count メトリクスは、API キーを必要としないリソースやメソッドに対するリクエストの発生時や、ゲートウェイレスポンスによる使用量プランのクォータ消費を伴わないエラー応答の発生時においても計上されます。
そのため、CloudWatch の Count メトリクスと API Gateway の使用量プランでは、同一のステージを対象とする場合でも、両者の値は一致しない場合があります。
やってみた
実際に API Gateway の呼び出し回数について以下のパターンで検証してみました。
・API キーの送信を伴うリクエストが正常に受け付けられたパターン
・API キーの送信を伴うリクエストが正常に受け付けられたが、Lambda からエラー応答されたパターン
・API ステージ上に実在しないリソースやメソッドに対する API キーを伴うリクエストを送信したパターン
・API キーの送信を伴わないリクエストを送信したパターン
各リクエスト後に、CloudWatch コンソールと API Gateway コンソールから値を確認してみます。
なお、API Gateway リソースや Lambda などは構築済みとします。
API キーの送信を伴うリクエストが正常に受け付けられたパターン
まずは API キーの送信を伴うリクエストが正常に受け付けられたパターンで、Lambda からも成功の応答をするパターンを試してみます。
curl https://t2vjp37vii.execute-api.ap-northeast-1.amazonaws.com/dev \
--header 'x-api-key:{my-api-key}'
CloudWatch コンソールと API Gateway コンソールから値を確認してみます。
※テストとしてリソース構築後に 1 回だけ API キーの送信を伴うリクエストを行っているので、テストで送信したリクエストは呼び出し回数の確認から除外します。
CloudWatch コンソールでは Count が 1 と記録されています。
API Gateway の使用量プランでも使用状況が 1 増えています。
API キーの送信を伴うリクエストが正常に受け付けられたパターンでは、双方に呼び出し回数が記録されることを確認できました。
API キーの送信を伴うリクエストが正常に受け付けられたが、Lambda からエラー応答されたパターン
続いて API キーの送信を伴うリクエストが正常に受け付けられたが、Lambda からエラー応答されたパターンを試してみます。 Lambda からは 503 エラーを返しています。
curl https://t2vjp37vii.execute-api.ap-northeast-1.amazonaws.com/dev \
--header 'x-api-key:{my-api-key}'
CloudWatch コンソールでは Count が 1 と記録されています。
API Gateway の使用量プランでも使用状況が 1 増えています。
API キーの送信を伴うリクエストが正常に受け付けられたが、Lambda からエラー応答されたパターンでは、双方に呼び出し回数が記録されることを確認できました。
※Lambda のタイムアウト、API Gateway のタイムアウトについても試してみたところ、どちらの場合も双方に呼び出し回数が記録されることを確認できました。
API ステージ上に実在しないリソースやメソッドに対する API キーを伴うリクエストを送信したパターン
続いて、API ステージ上に実在しないリソースやメソッドに対する API キーを伴うリクエストを送信したパターンを試してみます。
/test という存在しないリソースパスにリクエストを送信します。
curl https://t2vjp37vii.execute-api.ap-northeast-1.amazonaws.com/dev/test \
--header 'x-api-key:{my-api-key}'
CloudWatch コンソールでは Count が 1 と記録されています。
API Gateway の使用量プランでは使用状況の値が増えていませんでした。
API ステージ上に実在しないリソースやメソッドに対する API キーを伴うリクエストを送信したパターンでは、CloudWatch コンソールの Count のみ増えることが確認できました。
API キーの送信を伴わないリクエストを送信したパターン
最後に API キーの送信を伴わないリクエストを送信したパターンを試してみます。
curl https://t2vjp37vii.execute-api.ap-northeast-1.amazonaws.com/dev
CloudWatch コンソールでは Count が 1 と記録されています。
API Gateway の使用量プランでは使用状況の値が増えていませんでした。
API キーの送信を伴わないリクエストを送信したパターンでは、CloudWatch コンソールの Count のみ増えることが確認できました。
注意点
使用量プランによるクォータの適用はベストエフォートでの動作となります。
そのため、使用量プランで消費されたクォータ数と実際に処理されたリクエスト数で若干の差異が生じる可能性がある点にはご注意ください。
API キーを使用した使用量プランの作成と使用 - Amazon API Gateway より
使用量プランのスロットリングとクォータはハードリミットではなく、ベストエフォートベースで適用されます。場合によっては、クライアントは設定されているクォータを超えることがあります。コストの管理や API へのアクセスのブロックを行う際に使用プランのクォータやスロットリングに依存しないでください。AWS Budgets を使用してコストをモニタリングすること、および AWS WAF を使用して API リクエストを管理することを検討してください。
![2024年版「基本的なウェブアプリケーションを構築する」のチュートリアル手順まとめてみた[Amplify Gen2対応]](https://devio2023-media.developers.io/wp-content/uploads/2024/06/000_basic_web_app.png)
