API Gateway

1. TLS終端: クライアントからのHTTPS接続をAPI Gatewayで終端し、証明書の検証・暗号化処理を行う
2. 認証・認可: APIキー、JWT、OAuth 2.0トークンなどを検証し、リクエスト元の身元とアクセス権限を確認する
3. レート制限・スロットリング: クライアントごと・APIキーごとの呼び出し回数を確認し、上限を超えていれば429エラーで拒否する
4. リクエスト変換: ヘッダーの付け替え、パスの書き換え、クエリパラメータの正規化、必要に応じたペイロード変換を行う
5. ルーティング: パス・ホスト名・ヘッダー・HTTPメソッドなどの条件に基づいて、対応するバックエンドサービスへ転送する
6. キャッシュ確認: 同一条件のレスポンスがキャッシュされていれば、バックエンドを呼び出さずにそのまま返却する
7. バックエンド呼び出し: Lambda関数、ECS/EKS上のコンテナ、オンプレミスサーバーなど実際の処理系を呼び出す
8. レスポンス変換・返却: バックエンドの応答を必要に応じて整形し、ログを記録した上でクライアントに返す

# リクエスト（クライアント → API Gateway）
GET /v1/products/1234 HTTP/1.1
Host: api.example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
x-api-key: ak_live_9f8c2e1b

# レスポンス（API Gateway → クライアント）
HTTP/1.1 200 OK
Content-Type: application/json
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 998
X-Cache-Status: MISS

{
  "id": "1234",
  "name": "ワイヤレスキーボード",
  "price": 4980,
  "currency": "JPY",
  "in_stock": true
}

# AWS CLIを使用したAPI Gateway作成例
aws apigateway create-rest-api --name "MyAPI"

# リソース作成（/users パスの追加）
aws apigateway create-resource \
  --rest-api-id "api-id" \
  --parent-id "root-resource-id" \
  --path-part "users"

# メソッド作成（GETメソッドの追加、IAM認証を有効化）
aws apigateway put-method \
  --rest-api-id "api-id" \
  --resource-id "resource-id" \
  --http-method GET \
  --authorization-type "AWS_IAM"

# Lambda統合設定（Lambdaプロキシ統合）
aws apigateway put-integration \
  --rest-api-id "api-id" \
  --resource-id "resource-id" \
  --http-method GET \
  --type AWS_PROXY \
  --integration-http-method POST \
  --uri "arn:aws:apigateway:region:lambda:path/functions/function-arn/invocations"

# ステージへのデプロイ（変更を反映）
aws apigateway create-deployment \
  --rest-api-id "api-id" \
  --stage-name "prod"

重要な設計ポイント

• 単一障害点への対策: API Gateway自体が落ちると全APIがアクセス不能になる。マルチAZ・オートスケーリング構成にし、ヘルスチェックとフェイルオーバーを組み込む
• レイテンシの把握: 追加のネットワークホップにより数ms〜数十ms程度のオーバーヘッドが乗る。エッジ最適化（AWSのエッジ最適化API Gatewayなど）やキャッシュ活用で緩和する
• 運用の複雑性: ルーティングルール、認証ポリシー、プラグイン設定が増えるほど設定管理が煩雑になる。Infrastructure as Code（Terraform、AWS SAM、CDKなど）で定義をバージョン管理するのが定石
• コスト試算: 従量課金モデルではリクエスト数・データ転送量に応じて費用が変動する。トラフィック予測に基づいた事前の試算と、キャッシュによる呼び出し削減が有効
• APIバージョニング: /v1/、/v2/のようにパスでバージョンを分離するか、ヘッダーでバージョン指定を受け付けるかを設計初期に決めておく
• タイムアウト・リトライ設計: バックエンドが遅延・停止した際にAPI Gatewayが延々と待ち続けないよう、適切なタイムアウト値とサーキットブレーカーパターンの導入を検討する

セキュリティ上の注意点

• 最小権限の原則: バックエンドを直接インターネットに公開せず、API Gateway経由のみアクセス可能にする（AWSであればVPCリンクやプライベート統合を利用）
• WAFとの併用: SQLインジェクション・XSSなどのパターンはWAFで検知・遮断し、API Gateway単体の認証機能だけに依存しない多層防御にする
• APIキーの取り扱い: APIキーは認可のためでなく識別・利用量計測のために使うものと位置づけ、機微なアクセス制御にはJWTやOAuth 2.0スコープを使う
• ログのマスキング: アクセスログや監視ツールに個人情報・トークンなどの機微情報が平文で出力されないよう、ログ出力フォーマットを事前に設計する
• mTLS（相互TLS認証）: パートナー企業とのB2B API連携など高い信頼性が求められる場面では、クライアント証明書による相互認証を検討する

• AIゲートウェイ（AI Gateway）の登場: OpenAI・Anthropicなど複数のLLMプロバイダーへのリクエストを一元的にルーティング・フェイルオーバーする「AI Gateway」機能を提供するプロダクトが増加。トークン使用量ベースのコスト管理やモデル単位のレート制限が一般的な要件になりつつある
• eBPFベースの高性能ゲートウェイ: LinuxカーネルのeBPF技術を活用し、ユーザー空間を経由せずにレイヤー4/7の処理を行う高性能なプロキシ・ゲートウェイ実装（Ciliumなど）への関心が高まっている
• Kubernetes Gateway APIへの移行: 従来のKubernetes Ingressに代わり、より表現力の高いルーティング定義が可能な「Gateway API」への移行が進み、Envoy GatewayやKongなどが対応を進めている
• OpenAPI／AsyncAPI仕様との統合強化: API仕様書からゲートウェイ設定やモックサーバーを自動生成する「API-first」なワークフローが定着し、開発者ポータルとの連携が強化されている