Amazon API Gateway

解決する課題

• API用のサーバーを自前で運用したくない
• 認証・レート制限・キャッシュを共通の玄関で処理したい
• バックエンド（Lambda等）を安全に公開したい

主要概念と用語

• REST API / HTTP API / WebSocket API
• ステージ: dev/prod などのデプロイ環境
• オーソライザー: Cognito / Lambda による認証認可
• スロットリング / 使用量プラン / APIキー: 流量制御
• キャッシュ: レスポンスをキャッシュして高速化・コスト減

仕様・制限・クォータ

• フルマネージドで自動スケール
• Lambdaプロキシ統合でシンプルに接続
• スロットリング上限（アカウント/メソッド単位）

内部の仕組み

クライアント → API Gateway → バックエンドの流れで、玄関で認証（オーソライザー）・流量制限（スロットリング）・必要なら変換やキャッシュを挟みます。HTTP APIは軽量・安価・低レイテンシでLambda/HTTP統合向け、REST APIは詳細な変換・APIキー・リクエスト検証など高機能。用途で選びます。

設計パターン / ベストプラクティス

• API Gateway + Lambda でサーバーレスAPI
• Cognitoオーソライザーで認証を玄関に集約
• スロットリング/使用量プランで保護・課金管理
• 前段にWAF、配信はCloudFront併用も

運用・監視・トラブルシュート

• メトリクス: Count 4XXError 5XXError Latency IntegrationLatency
• 429（Too Many Requests）はスロットリング上限を確認
• アクセスログ/実行ログをCloudWatchへ

コスト

• リクエスト数課金。HTTP APIはREST APIより安価。キャッシュは別課金

セキュリティ

• オーソライザー（Cognito/Lambda）、IAM認証
• スロットリングで乱用防止、WAF併用
• TLS、必要ならプライベートAPI（VPC内公開）

Well-Architected の観点

• セキュリティ: 認証・流量制御を玄関で統一
• パフォーマンス効率: キャッシュ・自動スケール
• コスト最適化: HTTP API・キャッシュ
• 運用上の優秀性: ステージ管理・IaC

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# HTTP API を作成し Lambda 統合で公開（最短）
aws apigatewayv2 create-api \
  --name orders-api --protocol-type HTTP \
  --target arn:aws:lambda:ap-northeast-1:123456789012:function:orders

# 既存APIのステージを確認
aws apigatewayv2 get-stages --api-id abcde12345