← AWSサービスの内部原理 コース
37. API Gatewayの正体 — マネージドなリバースプロキシ
API Gatewayの正体を「マネージドなリバースプロキシ」という一本の軸で捉え、3タイプの違い・WebSocketの仕組み・スロットリングの原理を図で追っていきます。
① 正体はマネージドな「リバースプロキシ」
クライアントHTTPSで接続
代理でリクエストを転送(RFC 9110のゲートウェイ)
API Gatewayマネージドなリバースプロキシ
認証・スロットリング・変換をここで処理Lambda関数
HTTPエンドポイント
他のAWSサービス
- RFC 9110: プロキシ/ゲートウェイ=クライアントの代わりに別サーバへ転送し応答を代理で返す中継役
- 自前でNginx/Envoyを立ててTLS終端・ルーティング・レート制限を運用する代わりに、一式をマネージドで肩代わり
API GatewayはクライアントとバックエンドのあいだでTLSを終端し、認証・スロットリング・変換を済ませてから代理でリクエストを転送する中継役。クライアントには単一エンドポイントに見え、裏側を隠す「ファサード」として働く。
② REST API — 全部入りの4段パイプライン
リクエスト到着
レスポンス返却
メソッドリクエストリクエスト検証
統合リクエストマッピングテンプレートで変換
統合レスポンスバックエンド応答を変換
メソッドレスポンスレスポンス整形
クライアントへ応答
- 各段にパラメータ・ボディの変換、キャッシュ、レスポンス整形などを差し込める
REST APIはリクエストが来てから4つの段を順に通し、各段で検証・変換・整形を差し込める「全部入り」タイプ。
③ HTTP API — 機能を削ること自体が安さと速さの源泉
REST専用機能キャッシュ / APIキー(使用量プラン) / リソースポリシー / WAF など
処理する工程が少ない
HTTP API最小限の機能で設計
JWTオーソライザーだけはHTTP API専用低価格
高速
- REST専用: キャッシュ / APIキー(使用量プラン) / リソースポリシー / リクエストボディ検証 / WAF / エッジ最適化・プライベートエンドポイント / 実行ログ・X-Ray / レスポンスストリーミング
- HTTP API専用のJWTオーソライザーはOIDC/OAuth2のJWT検証をゲートウェイ内で完結(RESTではLambdaオーソライザーで代替)
HTTP APIは重いパイプラインを意図的に削ぎ落とした低機能・低価格版。公式も「最小限の機能で設計され、より低い価格で提供できる」と明言しており、機能差分表はこの因果で読める。
④ WebSocket API — 接続を張りっぱなしにするステートフル型
クライアントHTTP Upgradeハンドシェイク
式の評価値をルートキーと突き合わせ
API Gateway接続ごとにconnectionIdを割り当て管理
route selection expression 例: ${request.body.action}$connect接続確立時
$disconnect切断時
$default評価不能・一致なし
カスタムルート一致した統合を呼ぶ
- 定番パターン: $connectでconnectionIdを登録し、$disconnectで後始末
- 接続は10分アイドルまたは最大2時間の接続寿命で閉じられる(クローズコード1001)
HTTPのUpgradeハンドシェイクで始まり、確立後はTCP接続を保持して双方向に通信。ゲートウェイが各接続にconnectionIdを割り当て、route selection expressionでメッセージの行き先を決める。
⑤ @connections API — サーバから押し出すプッシュ経路
DynamoDB Streams
SQS
connectionIdを指定してPOST
Lambdaステートレスなまま
該当ユーザーの接続だけに配信
@connections API接続状態はゲートウェイが保持
クライアントプッシュ通知を受信
- 通常のリバースプロキシは要求に応えるだけだが、WebSocketは接続を保持しているぶんバックエンドの都合でメッセージを押し出せる
「誰が今つながっているか」をゲートウェイが肩代わりして持つため、ステートレスなLambdaからでもconnectionId指定のPOSTでリアルタイム配信ができる。
⑥ スロットリング — トークンバケットと4階層の入れ子
リクエスト
この判定を4階層で評価(内側は外側を超えられない)
あり → 通過トークンを1つ消費
なし → 429Too Many Requests
使用量プランAPIキー単位(最も内側)
ステージ / メソッド
アカウント×リージョン
AWSリージョナル上限最も外側
- rate=1秒あたりバケットへ補充するトークン数、burst=バケットの最大容量
- いずれもベストエフォート(厳密な上限保証ではなく分散環境での近似)
- APIキーは認証ではなく識別(使用量プランに紐づける目印)
- リソースポリシーはオーソライザー呼び出しの前に評価され、明示Denyが先行して効く(REST APIならではの挙動)
rate(毎秒の補充数=定常速度)とburst(バケット容量=一時的な超過許容)の2つで流量を制御し、トークンがなければ429を返す。上限は内側から外側へ4階層の入れ子で評価される。