ある企業が AWS 上でマイクロサービスアーキテクチャを運用しており、複数の API が Amazon API Gateway 経由で公開されています。最近、一部の API エンドポイントが外部からの過剰なリクエストにより負荷が増大し、他の正常なエンドポイントの性能にも影響を与えるという問題が発生しています。また、特定のユーザーグループへのレート制限も実装したいと考えています。最も適切な解決策はどれですか？
- A. CloudFront を API Gateway の前段に設置し、CloudFront のオリジンシールドでオリジンへのリクエスト数を削減する
- B. API Gateway の使用量プラン（Usage Plan）と API キーを設定し、クライアントまたはユーザーグループごとにスロットリングレート（リクエスト/秒）とクォータ（リクエスト/月）を定義する。API Gateway のデフォルトのスロットリング設定でアカウントおよびステージレベルのレート制限も設定する
- C. Lambda 関数の予約済み同時実行数を増やして過剰なリクエストをさばけるよう処理能力を増強する
- D. API Gateway の WAF を有効化して不正なリクエストをブロックし、Lambda 関数でリクエスト数をカウントして DynamoDB に保存してレート制限を実装する
解答と解説を見る
正解: B
API Gateway の使用量プランは特定の API キー（ユーザーまたはグループに発行）に対して、スロットリング（秒あたりのリクエスト数）とクォータ（月あたりの総リクエスト数）を細かく設定できます。アカウントレベルとステージレベルのデフォルトスロットリングと組み合わせることで、多層的なレート制限が実現できます。設定は AWS マネジメントコンソールから行えます。 D: Lambda を使ったカスタムレート制限の実装は高い開発コストがかかり、DynamoDB への書き込みレイテンシーがリクエスト処理に影響します。API Gateway のネイティブ機能を使う方がはるかに効率的です。 A: CloudFront はキャッシュによるオリジンへのリクエスト削減に有効ですが、ユーザーグループごとの細かいレート制限設定は API Gateway の使用量プランが適しています。 C: 同時実行数の増加は過剰なリクエストをさばく容量を増やしますが、過剰なリクエストそのものを制限するレート制限の要件を解決しておらず、コストも増大します。
📚 関連サービスの解説: Amazon API Gateway