AWS API Gateway 概要 - APIゲートウェイの基本と設計 ​

AWS API Gatewayは、Webアプリケーションやモバイルアプリが必要とするAPIを簡単に作成・管理できるフルマネージドサービスです。従来サーバーで行っていたAPI処理を、AWSが代わりに処理してくれるため、運用負荷を大幅に削減できます。

この記事では、API Gatewayの基本概念から実際の設計パターンまで、初心者にも分かりやすく解説します。

API Gatewayとは ​

基本的な役割 ​

API Gatewayは、Webアプリケーションとバックエンドサービス間の「仲介役」として機能します。クライアントからのリクエストを受け取り、適切なバックエンドサービスに転送し、レスポンスを返す役割を担います。

主な機能

• API管理: APIの作成、公開、バージョン管理
• トラフィック制御: リクエスト数の制限とスロットリング
• 認証・認可: APIアクセスのセキュリティ制御
• データ変換: リクエスト・レスポンスの形式変換
• 監視・ログ: APIの使用状況やエラーの監視

API Gatewayの種類 ​

AWS API Gatewayには3つのタイプがあり、用途に応じて選択できます。

選択の目安

• 複雑なAPI処理が必要 → REST API
• シンプルで高速なAPIが必要 → HTTP API
• リアルタイム通信が必要 → WebSocket API

API Gatewayのアーキテクチャ ​

基本的な構成 ​

API Gatewayは以下の要素で構成されます。

主要コンポーネント

• API Gateway: リクエストの受付とルーティング
• バックエンドサービス: Lambda、EC2、RDS等の実際の処理を行うサービス
• 認証: API キーやIAMロールによるアクセス制御
• ステージ: 開発・テスト・本番等の環境管理

エンドポイントタイプ ​

API Gatewayは3種類のエンドポイントタイプを提供しています(REST APIのみ)。

Edge-optimizedエンドポイント

• CloudFront POPを経由してアクセス
• 地理的に分散したクライアントに最適
• レイテンシの自動最適化

Regionalエンドポイント

• 単一リージョンでホスト
• 独自のCDN戦略を使用する場合に適している
• 低レイテンシのリージョン内通信

Privateエンドポイント

• VPCエンドポイント経由でのみアクセス
• インターネットを経由しない安全な通信
• AWS Direct ConnectやVPN経由の接続をサポート

リクエスト/レスポンスフロー ​

API Gatewayは、クライアントとバックエンド間で5つのステージを経由してリクエスト/レスポンスを処理します。

1. メソッドリクエスト ​

クライアントからのリクエストを受け取り、検証・認可を行います。

主な処理

• リクエスト検証: パラメータやボディの形式チェック
• 認証・認可: API Key、IAM、Cognito等による認証
• APIキーの確認: 使用量プランとの関連付け
• CORSヘッダーの処理: プリフライトリクエストへの対応

注意点

• リクエスト検証を有効にすると、不正なリクエストが統合バックエンドに到達する前に拒否されます
• JSON Schemaを使用してリクエストボディの構造を定義できます（REST APIのみ）
• クエリパラメータ、ヘッダー、パスパラメータの必須チェックが可能
• 認証エラーは401、認可エラーは403を返します

2. 統合リクエスト ​

バックエンドが期待する形式にリクエストを変換します。

主な処理

• データマッピング: マッピングテンプレート（VTL）による変換
• ヘッダーマッピング: 必要なヘッダーの追加・削除・変更
• パラメータマッピング: クエリパラメータやパスパラメータの変換
• リクエストボディの変換: Content-Typeに応じた変換

注意点

• Velocity Template Language（VTL）を使用してカスタム変換が可能
• Lambda Proxy統合では、元のリクエストがそのまま渡されます（変換不要）
• ステージ変数を使用して環境ごとの設定を切り替えられます
• $input、$context変数で元のリクエスト情報にアクセス可能

マッピングテンプレート例

{
  "userId": "$input.params('userId')",
  "body": $input.json('$'),
  "requestId": "$context.requestId",
  "stage": "$context.stage"
}

3. 統合バックエンド ​

実際のバックエンドサービスでビジネスロジックを実行します。

統合タイプ

• Lambda関数: サーバーレス処理
• HTTP/HTTPS: 外部APIやEC2上のアプリケーション
• AWS Service: DynamoDB、S3、SQS等のAWSサービス
• Mock: テスト用の固定レスポンス

注意点

• Lambda統合では、タイムアウトは最大29秒（API Gatewayの制限）
• HTTP統合では、エンドポイントのヘルスチェックは行われません
• AWS Service統合では、IAMロールで適切な権限を付与する必要があります
• 統合バックエンドのエラーは、統合レスポンスで適切にマッピングする必要があります

4. 統合レスポンス ​

バックエンドからのレスポンスをクライアントが期待する形式に変換します。

主な処理

• ステータスコードマッピング: バックエンドのレスポンスを適切なHTTPステータスコードに変換
• レスポンスボディの変換: マッピングテンプレートによる変換
• ヘッダーマッピング: レスポンスヘッダーの追加・削除・変更
• エラーハンドリング: エラーレスポンスの整形

注意点

• 正規表現を使用してバックエンドのエラーを適切なHTTPステータスコードにマッピング
• Lambda Proxy統合では、Lambdaが直接HTTPレスポンス形式を返す必要があります
• デフォルトレスポンスを設定しておくことで、予期しないエラーにも対応可能
• CORSヘッダーは統合レスポンスで設定できます

ステータスコードマッピング例

// バックエンドのエラーパターンに応じてステータスコードを設定
".*NotFound.*" → 404
".*Unauthorized.*" → 401
".*BadRequest.*" → 400
デフォルト → 200

5. メソッドレスポンス ​

クライアントに返すレスポンスの定義を行います。

主な処理

• レスポンスモデルの定義: 各ステータスコードに対するレスポンスの構造定義
• レスポンスヘッダーの定義: 返却可能なヘッダーの定義
• Content-Typeの設定: レスポンスのメディアタイプ指定

注意点

• メソッドレスポンスはレスポンスの「型定義」であり、実際の変換は統合レスポンスで行います
• CORSを有効にする場合、Access-Control-Allow-Originヘッダーの定義が必要
• APIドキュメント生成時に、ここで定義したモデルが使用されます
• 複数のContent-Typeをサポートする場合、それぞれにレスポンスモデルを定義

統合パターン ​

API Gatewayは様々なAWSサービスと連携できます。

Lambda統合 最も一般的なパターンで、サーバーレスなAPI構築が可能です。

• Lambda Proxy統合: リクエスト/レスポンスの変換が不要で、最も簡単
• Lambda統合（非Proxy）: マッピングテンプレートで細かい制御が可能

# AWSコンソールでの設定手順（概要）
1. API Gatewayでリソース作成
2. メソッド（GET、POST等）を追加
3. 統合タイプでLambdaを選択
4. 対象のLambda関数を指定
5. Proxy統合を有効化（推奨）

Lambda Proxy統合のレスポンス形式

{
  "statusCode": 200,
  "headers": {
    "Content-Type": "application/json",
    "Access-Control-Allow-Origin": "*"
  },
  "body": "{\"message\": \"Success\"}"
}

HTTP統合 既存のWebサービスやEC2上のアプリケーションとの連携に使用します。

• HTTP Proxy統合: リクエストをそのまま転送
• HTTP統合（非Proxy）: マッピングテンプレートで変換可能

プライベート統合 VPC内のリソースとの安全な接続を実現します。

• Network Load Balancer(NLB)経由の接続
• Application Load Balancer(ALB)経由の接続(HTTP APIのみ)
• AWS Cloud Map統合(HTTP APIのみ)

Mock統合 バックエンドを必要とせず、API Gatewayが直接レスポンスを返します。

• プロトタイピングに最適
• APIドキュメントのテスト
• 開発初期段階での利用

認証とセキュリティ ​

認証方法の比較 ​

API Gatewayでは複数の認証方法を選択できます。

JWT Authorizer(HTTP API限定)

• OpenID ConnectやOAuth 2.0をネイティブサポート
• Amazon Cognito、Auth0、Oktaなどと連携
• トークンの検証を自動化
• Lambdaを使わずにコスト削減

Amazon Verified Permissions

• ユーザー属性やグループメンバーシップに基づくきめ細かいアクセス制御
• Cedar言語によるポリシー定義
• OIDC準拠のアイデンティティプロバイダーと統合
• コードレスで権限管理が可能

セキュリティ設定のポイント ​

API Key使用時の注意

• クライアント側でのAPI Key保護
• 定期的なローテーション
• 使用量制限の設定
• REST APIでのみ利用可能(HTTP APIでは未サポート)

Mutual TLS認証 クライアント証明書による双方向認証をサポートします。

• REST APIとHTTP APIの両方で利用可能
• カスタムドメイン名での設定が必要
• より強固なセキュリティを実現

AWS WAF統合(REST APIのみ)

• SQLインジェクション対策
• クロスサイトスクリプティング(XSS)対策
• レート制限ルールの設定
• IPアドレスベースのアクセス制御

リソースポリシー(REST APIのみ)

• 特定のVPCエンドポイントからのみアクセス許可
• ソースIPアドレスによるアクセス制御
• AWSアカウント間のアクセス制御

HTTPS強制 API Gatewayは標準でHTTPS通信をサポートします。

# CLIでHTTPS強制設定確認
aws apigateway get-rest-api --rest-api-id your-api-id

パフォーマンス最適化 ​

キャッシュの活用 ​

API Gatewayはレスポンスキャッシュ機能を提供しています。

キャッシュの効果

• レスポンス時間短縮
• バックエンドサーバー負荷軽減
• コスト削減（Lambda実行回数減）

キャッシュ設定の考慮事項

• キャッシュキーの設計
• TTL（Time To Live）の適切な設定
• キャッシュ無効化のタイミング

スロットリング設定 ​

Usage Plans APIの使用量を制御し、サービス品質を保つ仕組みです。

• バーストリミット: 短期間での大量リクエスト制御
• レートリミット: 持続的なリクエスト数制御
• クォータ: 月間・日間の使用量制限

運用と監視 ​

CloudWatch統合 ​

API Gatewayは自動的に以下のメトリクスを収集します。

主要メトリクス

• リクエスト数(Count)
• レスポンス時間(Latency、IntegrationLatency)
• エラー率(4xxError、5xxError)
• キャッシュヒット率(CacheHitCount、CacheMissCount)

CloudWatch Logsへのログ出力

• アクセスログ:リクエスト/レスポンスの詳細
• 実行ログ:API Gatewayの内部処理詳細(REST APIのみ)
• カスタムフォーマット:JSON形式でのログ出力が可能

AWS X-Ray統合 ​

API Gatewayは分散トレーシングをサポートします。

X-Ray統合のメリット

• エンドツーエンドのリクエストトレーシング
• パフォーマンスボトルネックの特定
• エラー発生箇所の可視化
• Lambda統合時の詳細な実行トレース

# X-Rayトレーシングの有効化
aws apigateway update-stage \
  --rest-api-id your-api-id \
  --stage-name prod \
  --patch-operations op=replace,path=/tracingEnabled,value=true

ログ設定 ​

アクセスログ リクエストの詳細情報を記録できます。

# CloudWatch Logsでアクセスログ確認例
aws logs describe-log-groups --log-group-name-prefix API-Gateway-Execution-Logs

実際の設計パターン ​

サーバーレスWebアプリケーション ​

このパターンでは、フロントエンドはS3、APIはAPI Gateway + Lambda、データベースはDynamoDBの組み合わせで構成します。

マイクロサービス統合 ​

複数のマイクロサービスを単一のAPIエンドポイントとして公開できます。

メリット

• クライアント側の複雑性軽減
• 統一されたAPI仕様
• 横断的な関心事（認証、ログ等）の一元管理

コスト最適化 ​

料金体系の理解 ​

無料利用枠(最初の12ヶ月)

• REST API: 100万回のAPI呼び出し/月
• HTTP API: 100万回のAPI呼び出し/月
• WebSocket API: 100万メッセージ + 75万接続分

REST API料金(無料枠超過後)

• API呼び出し: 1百万回あたり$3.50～$3.70
• データ転送: 1GBあたり$0.09～(リージョンにより異なる)
• キャッシュ: 0.5GB～237GBで$0.020～$3.80/時間

HTTP API料金(無料枠超過後)

• API呼び出し: 1百万回あたり$1.00～$1.17
• データ転送: REST APIと同等
• REST APIより約70%安価

WebSocket API料金

• メッセージ送受信: 100万メッセージあたり$1.00
• 接続時間: 100万分あたり$0.25

最適化手法 ​

1. HTTP APIの活用 シンプルなユースケースではHTTP APIを選択することでコストを約70%削減できます。

HTTP APIとREST APIの比較

• HTTP API: 低レイテンシ、低コスト、基本機能
• REST API: 豊富な機能、API Key、WAF統合、リクエスト検証

2. キャッシュ活用(REST APIのみ) 頻繁にアクセスされるデータはキャッシュすることで、バックエンド処理コストを削減できます。

• キャッシュTTL: 0秒～3600秒で設定可能
• キャッシュサイズ: 0.5GB～237GBまで選択可能
• コスト削減効果: Lambda実行回数を大幅に削減

3. プライベート統合の最適化

• 低頻度のリクエスト: VPC Lambda関数を検討
• 高頻度のリクエスト: NLBによるプライベート統合
• NLBコスト: 時間課金 + データ処理量課金

4. リージョナルエンドポイントの活用

• 同一リージョン内通信でレイテンシ削減
• CloudFrontコストを回避
• 独自のCDN戦略を使用可能

動的ルーティングルール ​

API Gatewayは、カスタムドメイン名に対する動的ルーティングルールをサポートしています。

ルーティング条件 ​

ヘッダーベースルーティング

• HTTPリクエストヘッダーの値に基づいてルーティング
• APIバージョニングやA/Bテストに最適

Conditions:
  - Type: Header
    Key: X-API-Version
    Value: v2
Action:
  TargetApi: api-v2-id
  TargetStage: production

パスベースルーティング

• リクエストパスに基づいて異なるAPIにルーティング
• マイクロサービスアーキテクチャに適している

優先度制御

• 複数のルールが一致する場合、優先度に基づいて評価
• 柔軟なルーティング戦略を実現

ユースケース ​

1. APIバージョニング: ヘッダーによるバージョン切り替え
2. A/Bテスト: トラフィックを複数のAPIに分散
3. カナリアリリース: 段階的な新バージョンへの移行
4. マルチテナント: テナントごとに異なるAPIへルーティング

ベストプラクティス ​

セキュリティ ​

1. すべてのルートに認証を設定

   • WebSocket APIの$connectルートに認証を必須化
   • HTTP APIでもすべてのルートに認証を推奨
   • コンプライアンス要件を満たす

2. 最小権限の原則を適用

   • IAMポリシーで必要最小限の権限のみ付与
   • リソースポリシーでアクセス元を制限

3. CloudTrailとConfigの有効化

   • API操作の監査証跡を記録
   • リソース設定の変更を追跡

パフォーマンス ​

1. 適切な統合タイプの選択

   • Lambda Proxy統合: 最も簡単、柔軟性が高い
   • Lambda統合: データ変換が必要な場合
   • HTTP Proxy統合: 既存のHTTPエンドポイント

2. リージョン配置の最適化

   • クライアントに近いリージョンを選択
   • マルチリージョン展開で冗長性を確保

3. キャッシュの効果的な活用

   • 静的コンテンツや変更頻度の低いデータをキャッシュ
   • キャッシュキーの適切な設計
   • TTLの最適化

コスト最適化 ​

1. APIタイプの適切な選択

   • シンプルなAPI: HTTP API(70%コスト削減)
   • 高度な機能が必要: REST API

2. 使用量プランの活用

   • APIキーによるクライアント識別
   • レート制限とクォータで過剰な使用を防止

3. 不要なログの削減

   • 実行ログは開発環境のみに制限
   • アクセスログは必要な情報のみを記録

まとめ ​

API Gatewayは、現代のWebアプリケーション開発において重要な役割を果たすサービスです。適切な設計により、セキュアで高性能なAPI基盤を短期間で構築できます。

導入時の重要ポイント ​

1. 要件に応じたAPIタイプの選択

   • REST API: 豊富な機能が必要な場合
   • HTTP API: コストとパフォーマンスを重視
   • WebSocket API: リアルタイム双方向通信

2. 適切な認証方式の設定

   • JWT Authorizer: 標準トークン認証(HTTP API)
   • Lambda Authorizer: カスタムロジック
   • Verified Permissions: 属性ベースアクセス制御

3. パフォーマンスとコストのバランス

   • HTTP APIで70%のコスト削減
   • キャッシュでバックエンド負荷軽減
   • X-Rayでパフォーマンス可視化

4. 監視・運用体制の確立

   • CloudWatchメトリクスの監視
   • アクセスログの分析
   • CloudTrailによる監査

これらの要素を総合的に検討することで、スケーラブルで運用しやすいAPI環境を実現できます。

関連リソース ​

• AWS API Gateway公式ドキュメント
• API Gateway料金
• API Gatewayベストプラクティス