使用量プラン・APIキー難易度 標準無料
複数の外部パートナー企業に同じREST APIを提供する。パートナーごとに「1秒あたりのリクエスト数上限」と「1か月あたりの総リクエスト数上限（クォータ）」を個別に設定し、パートナーを識別できるようにしたい。この要件を満たす最も適切な設計を選べ。（単一選択）
- AパートナーごとにAPIキーを発行し、使用量プランでパートナーごとのレート・バースト・クォータを設定してAPIキーを紐付ける
- BAPI Gatewayのアカウントレベルのスロットリング設定を1つだけ変更し、全パートナー共通の上限を1つ適用する
- CLambdaオーソライザー内でDynamoDBにリクエスト回数を記録し、閾値を超えたら拒否するカウンターを自前実装する
- Dパートナーごとに完全に別のAWSアカウントでAPIをホストし、アカウント単位のサービスクォータで制御する
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：AAI作成・独立検証済
解説
パートナーごとに異なるレート制限・クォータを課しつつ識別可能にする標準的な仕組みは、APIキー＋使用量プラン（usage plan）である。
- パートナーごとにAPIキーを発行し、リクエストヘッダー（
x-api-key）で送らせることでクライアントを識別する。 - 使用量プランで、レート（steady-state のリクエスト/秒）・バースト（トークンバケットの容量）・クォータ（日/週/月あたりの総リクエスト数）を設定し、 各APIキーを該当のプランに関連付ける。
- 使用量プランはステージ単位で紐付けるため、パートナーA用プラン・パートナーB用プランのようにパートナーごとに異なる上限を個別設定できる。
なお、使用量プランのスロットリング/クォータはAPI全体の既定のアカウントレベル・ステージレベルのスロットリングとは別レイヤーで、APIキー単位にきめ細かく制御する点が特長である。
- Bアカウントレベル/ステージレベルのスロットリングはAPI全体（または特定メソッド）に対する一律の上限であり、パートナーごとに個別の上限を設定する仕組みではない。
- C実現は可能だが、車輪の再発明でありレース条件やスケーリングの考慮が必要になる。APIキー＋使用量プランという標準機能で同じ要件を満たせる。
- D運用が煩雑でコストも増大する。サービスクォータはAWSサービス自体の上限管理であり、パートナー向けAPIのレート制限・クォータ設計には使わない。
ひっかけ： 「Lambdaオーソライザーでリクエスト数をカウントして自前で制限する」という自作発想（C）は車輪の再発明であり運用負荷が高い。
クライアント（パートナー）ごとのレート制限・クォータはAPIキー＋使用量プランが標準機能として提供されていることを押さえる。
AIが作成し、独立した検証を経た解説です（有資格者による監修は経ていません）