はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Amazon API Gateway 関連の知識をまとめました。
REST API と HTTP API の違い、アクセス制御の方法、Usage Plans によるレート制限、キャッシュによるコスト削減など、試験で問われるポイントを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
API Gateway の種類
| REST API | HTTP API | WebSocket API | |
|---|---|---|---|
| JWT Authorizer | ❌ | ✅ ネイティブ | ❌ |
| コスト | 高い | 安い（最大71%オフ） | 中 |
| レイテンシー | 標準 | 低い | 低い |
| 機能 | フル機能（API Key、Usage Plans） | 軽量 | 双方向通信 |
| Lambda Authorizer | ✅ | ✅ | ✅ |
| Cognito Authorizer | ✅ | ❌（JWT で代替） | ✅ |
判断のポイントです。
- JWT ネイティブ + コスト重視 → HTTP API
- フル機能（API Key、Usage Plans） → REST API
- 双方向通信（チャット等） → WebSocket API
API Gateway の重要な特性
- フルマネージドサービス → ユーザーの VPC 内にデプロイされない
- セキュリティグループはアタッチできない（VPC リソースではない）
- サブネットにも配置されない
アクセス制御方法
| 方法 | 用途 |
|---|---|
| リソースポリシー | IP アドレス、VPC エンドポイント、AWS アカウント |
| IAM オーソライザー | IAM 認証情報 |
| Lambda オーソライザー | カスタム認証ロジック |
| Cognito オーソライザー | ユーザープール認証 |
| WAF | 地理的制限、レート制限、SQLi 防止 |
Usage Plans + API Keys
- クライアントごとにレート（req/s）とクォータ（期間あたりの総リクエスト数）を定義
- ALB / NLB / GWLB にはレート制限機能がない → API Gateway のみネイティブ対応
API Gateway Caching
- API レイヤーでレスポンスをキャッシュ
- TTL 設定可能（デフォルト300秒、最大3600秒）
- キャッシュヒット時は Lambda / DB を呼び出さない → コスト大幅削減
試験で問われる設計パターン
アクセス制御系
API Gateway の IP ベースアクセス制御 → リソースポリシー
シナリオ: 特定の IP アドレスからのみ API Gateway へのアクセスを許可したいです。どの方法が適切でしょうか？
正解: API Gateway のリソースポリシー
- API Gateway には SG をアタッチできない
- パブリックサブネットにデプロイされるわけではない
API レート制限 + クライアント別クォータ → Usage Plans + API Keys
シナリオ: API のレート制限をクライアントごとに設定し、月間のリクエスト数にもクォータを設けたいです。
正解: API Gateway + Usage Plans + API Keys
- ALB / NLB / GWLB にはネイティブなレート制限機能がない
- API Gateway のみ対応
認証系
JWT 検証 + OIDC + コスト効率 → HTTP API + JWT Authorizer
シナリオ: API の認証で JWT トークンを検証したいです。ネイティブ対応でコスト効率の良い方法はどれでしょうか？
正解: HTTP API + JWT Authorizer
- REST API では Lambda Authorizer が必要
- HTTP API は REST API より最大71%安い
- WebSocket API は双方向通信用
コスト最適化系
API Gateway + Lambda + Aurora の読み取り負荷軽減 → API Gateway Caching
シナリオ: API Gateway → Lambda → Aurora の構成で、同じリクエストが繰り返し来ています。Lambda と Aurora の呼び出しコストを削減するにはどうすべきでしょうか？
正解: API Gateway Caching を有効化
- キャッシュヒット時は Lambda / DB を呼び出さない → コスト大幅削減
- Aurora Read Replica の追加はコストが増える
- Lambda にネイティブのインメモリキャッシュはない
統合パターン系
フィードバック収集 + 感情分析 + 1年保持
シナリオ: ユーザーのフィードバックを API で収集し、感情分析して1年間保持したいです。
正解: API Gateway → SQS → Lambda → Comprehend → DynamoDB（TTL 365日）
Python マイクロサービス + 自動スケール + 運用最小
シナリオ: Python で書かれたマイクロサービスを、自動スケール対応で運用負荷を最小にしたいです。
正解: Lambda + API Gateway + Provisioned Concurrency
おわりに
API Gateway は「REST vs HTTP API の違い」「SG がアタッチできない」「Usage Plans でレート制限」「Caching でコスト削減」の4つを押さえておけば、ほとんどの問題に対応できます。特に「JWT ネイティブ + 安い → HTTP API」は反射的に判断できるようにしておきましょう。
間違いや補足があればぜひコメントで教えてください。