API Gateway統合・デプロイメント・セキュリティ
API Gatewayの統合タイプ(Lambda・HTTP・Mock・プライベート)、デプロイメント戦略、キャッシング、スロットリング、認証・認可の実装方法を詳解します。
API Gateway統合・デプロイメント・セキュリティ
API Gatewayはサーバーレスアーキテクチャの玄関口として機能し、クライアントリクエストを受け付けてバックエンド処理に転送します。このトピックでは、統合の設計からセキュリティ・運用まで、実装の全体像を整理します。
API利用の必要事項
APIを活用するには、以下の4つの側面をバランスよく構築・運用・保守する必要があります:
APIの作成
APIの定義とバックエンド統合の設計です。要件に応じて適切な統合タイプを選択し、ビジネスロジックと接続します。
APIの利用状況監視
CloudWatch、CloudTrail、X-Rayなどのサービスを使用して、API の呼び出し履歴、エラー率、レイテンシーを可視化します。
APIのバージョン管理
デプロイステージ(開発・ステージング・本番)を用いて、複数バージョンのAPIを並行管理できます。
APIの認証・アクセス管理
リソースポリシー、IAM、Lambda認可、Cognito認可など複数の認証方式をメソッド単位で適用できます。
AWSにおけるAPI提供
一般的なアプリケーション開発パターン
従来のサーバーサイド開発では、Elastic Load Balancer(ELB)経由でAPIを提供してきました:
- フロントエンド: Flask、Ruby on Rails、iOS/Flutterなどで実装
- サーバーサイド: ELBの背後にアプリケーションサーバーをホスト
- バックエンド: RDS、キャッシュなどのデータベース
この構成ではELB配下のサーバーが常時起動し、サーバー管理のオーバーヘッドが大きくなります。
API Gatewayによるサーバーレス化
API Gatewayはこのパターンをサーバーレスに置き換えます:
クライアント → API Gateway → Lambda(ビジネスロジック)→ 必要に応じてAWSサービスへ
利点:
- インフラ管理が不要
- 使用量ベースの課金
- 自動スケーリング
- CloudFront、キャッシュ連携で高速化
APIのタイプ選択
実装したい通信方式に応じてAPIタイプを選択します。
HTTP API
REST APIよりもレイテンシーとコストが低い軽量APIです。
特徴:
- AWS Lambda関数またはルーティング可能なHTTPエンドポイントにリクエストを送信できる
- REST APIよりも低いレイテンシー(典型的には50%短い)と低いコスト(典型的には70%削減)
- OAuth 2.0とOpenID Connect(OIDC)による認証機能
- CORS、自動デプロイメント対応
用途:
- シンプルなマイクロサービス
- 軽量なLambda関数の公開
- リアルタイム系Webアプリケーション
Restful API
AWS Lambda、ルーティング可能なHTTPエンドポイント、Lambda非プロキシ(カスタム)統合を使用して、API メソッドをHTTPエンドポイントに統合します。
特徴:
- RESTアーキテクチャスタイルの完全な実装
- クライアントがサービスにリクエストを送信し、サービスが同期的に応答するリクエスト・レスポンスモデル
- 複雑な変換・ルーティング・アグリゲーションが可能
- OpenAPI (Swagger) 仕様によるAPIドキュメント自動生成
用途:
- 複雑なビジネスロジック
- 複数リソースの関連付け
- 細かいアクセス制御が必要な場合
WebSocket API
双方向通信の方式でクライアントはサービスにメッセージを送信し、サービスは個別にクライアントにメッセージを送信することで堅牢なクライアント/サービスの対話を実現します。
特徴:
- 双方向リアルタイム通信
- チャットアプリケーション、コラボレーションプラットフォーム、ファイナンシャルトレーディングプラットフォーム、マルチプレイヤーゲームなどのリアルタイムアプリケーションに利用
用途:
- チャットシステム
- ライブダッシュボード
- 金融取引プラットフォーム
- マルチプレイゲーム
API Gateway統合タイプ
API Gatewayはメソッドを複数の統合先に接続できます。統合タイプごとに、リクエスト/レスポンスの変換方法が異なります。
Lambda統合
Lambda関数との統合式を選択します。
Lambda プロキシ統合
- API Gatewayがクライアントリクエスト全体をバックエンド Lambda 関数にマッピングして、Lambda関数と統合
- APIゲートウェイに許可ロール設定して統合設定するだけで自動的にマッピングして統合できる
- クライアントが API リクエストを送信すると、API Gateway は、統合されたLambda 関数に raw リクエストをそのままます。リクエストパラメータの順序は保持されない
- このリクエストデータには、リクエストヘッダー、クエリ文字列パラメータ、URL パス変数、ペイロード、および API 設定データが含まれる
- 設定データには、現在のデプロイステージ名、ステージ変数、ユーザー ID、または承認コンテキスト(存在する場合)を含める
メリット:
- リクエスト/レスポンスの変換が自動化される
- Lambda側で全情報にアクセス可能
- 開発効率が高い
Lambda 非プロキシ統合(カスタム統合)
- プロキシ統合のセットアップステップに加えて、受信リクエストデータがどのように統合リクエストにマッピングされるか、統合レスポンスデータの結果がメソッドレスポンスにマッピングされるかを指定する
用途:
- リクエスト/レスポンスの細かい制御が必要な場合
- APIゲートウェイ側で前処理・後処理を実施
HTTP統合
バックエンドのHTTPエンドポイントを公開します。
HTTP プロキシ統合またはHTT カスタム統合を使用して、API メソッドを
HTTP エンドポイントに統合します。
- 80、443、および 1024-65535のエンドポイントボートをサポート
プライベート統合
VPC外のクライアントからVPC内にあるHTTP/HTTPSリリースにアクセスするために利用する統合方式です。
機能:
- API Gateway がサポートする認証方法より API へのアクセスを制御できる
- リソースポリシーを利用してアクセスを制御できる
Mock統合
バックエンドを統合することなく、API Gateway から直接 API レスポンスを生成できる統合方式です。
用途:
- API を操作する必要がある他の依存チームのブロックを解除できる
- また、API の概要や API へのナビゲーションを提供できる API ラウンディングページをプロジェクションすることが可能になる
API Gatewayのバージョン管理
API Gatewayはメソッド単位のバージョン管理でデプロイを柔軟に管理します。
デプロイステージ
APIは複数のステージでデプロイできます。各ステージは独立した設定を持ちます:
- 開発環境(dev):開発チームが開発・テスト
- ステージング環境(staging):本番前のテスト・検証
- 本番環境(prod):ユーザー向けサービス
各ステージ間でエンドポイント、リソース制限、キャッシング、認証設定を独立して管理できます。
ステージ変数
ステージ間で設定を切り替えるための変数です。Lambda関数の呼び出し引数やエンドポイントURLをステージ変数で動的に変更できます。
キャッシュ機能の利用
キャッシュを有効にすると、エンドポイントへの呼び出しの数を減らし、API へのリクエストのレイテンシーを短くできます。
キャッシュの設定
- デフォルトTTL:300秒(5分)
- 最大TTL:3600秒(1時間)
- TTL=0:キャッシュを無効化
キャッシュはレスポンスをAPI Gateway側で保持し、同一リクエストに対して保存済みのレスポンスを返すため、バックエンド呼び出しの頻度が低下します。
キャッシュの最適化
API Gatewayはクライアント分散を検出し、キャッシュの効率を判定します。クライアントの地理的分布に応じて:
- CloudFront連携でグローバルに最適ルーティング
- Cookie名を使ってHTTP Cookie を統一してHTTP Cookie で区別
スロットリング・制限
サーバー側のスロットリング
全てのクライアントに対するリクエストを制限します。全体のリクエストが多すぎるために、バックエンドサービスが処理しきれなくなることを防ぐことができます。
クライアントあたりのスロットリング
クライアントごとに「使用量プラン」に応じて制限を行います。特定のユーザーからのリクエストが多い場合に有効です。
使用量プランの設定:
- リクエストレート:1秒あたりのリクエスト数
- バースト:一時的に許可する最大リクエスト数
- 月間クォータ:1ヶ月間の総リクエスト数
API Gatewayの認証方式
複数の認証方式をメソッド単位で適用できます。
リソースポリシー(REST APIのみ)
JSON形式のリソースポリシーを定義することで、他のリソースからのAPI Gateway へのアクション(許可または拒否)を設定します。
用途:
- 特定のIAMロール・ユーザーのみアクセス許可
- VPC内からのアクセスのみ許可
IAM認証
APIのアクセス権限を設定したIAMポリシーを作成し、IAM ユーザーやIAMロールに付与してAPIへのアクセスを制御します。
設定方法:
- API メソッドでIAM認証を有効化
Lambda オーソライザー
Lambda関数を作成することで、認証プロバイダーでの認証結果を元に、APIへのアクセス制御をメソッド単位で実施します。
用途:
- カスタム認証ロジック
- 外部システムと連携した認可
Cognito オーソライザー
認証プロバイダーとしてCognitoユーザープールを用いて、APIへのアクセス制御をメソッド単位で実施します。
用途:
- ユーザー認証の一元化
- ソーシャルログイン連携
使用量プランとAPIキー
使用量プランとAPIキーを利用して、アクセスするユーザーやアクセス回数などを制御できます。
使用量プランの機能
- リクエストレート制限:1秒あたりのリクエスト数をクォータ設定できます。アクセス可能回数となるレート、バースト、月間クォータを設定できます
- APIキーの取得:使用量プランを使用して、ユーザーエンティティを識別し、APIキーを持つユーザーのみアクセス可能なAPIを作成できます
- ユーザー識別:API キー識別子で特定ユーザーを認識し、そのユーザーのみアクセス可能なAPIを作成できます
- 複合制御:API キーと Lambda オーソライザー、IAM ロール、または Amazon Cognito を一緒に使用して API へのアクセスを制御できます
APIキーの役割
APIキーは各ユーザーに割り当てられ、APIへのアクセスを識別・制限するための一意の識別子です。APIゲートウェイはAPIキーを使用してユーザーを追跡し、使用量制限の適用やコスト配分を実施します。
API Gateway統合の実装例:EC2中心のWebアプリケーションのサーバーレス化
従来のEC2ベースのWebアプリケーション構成を、API Gatewayを使ってサーバーレス化する典型例です。
元の構成
- フロントエンド:Webブラウザ、モバイルアプリケーション
- CDN:CloudFront で静的コンテンツを配信
- ロードバランサー:Elastic Load Balancer(ELB)でトラフィック分散
- アプリケーション層:EC2インスタンスでビジネスロジック実行
- データベース:RDS で永続化、キャッシング機能を備えたデータベース
サーバーレス化後
- フロントエンド:変更なし
- CDN:CloudFront で静的コンテンツを配信
- API層:API Gateway で受け付け
- ビジネスロジック:Lambda で実行
- データベース:RDS(またはDynamoDB)で永続化
利点:
- サーバー管理が不要
- 使用量ベースの課金
- 自動スケーリング
- Lambda + API Gateway でセットアップが簡潔
まとめ
API Gatewayは、サーバーレスアーキテクチャでAPIを管理するための中核的なサービスです。複数の統合タイプ、認証方式、スロットリング機構を組み合わせることで、セキュアで拡張性に優れた API 基盤を構築できます。
設計時には、以下を検討します:
- 通信方式の選択:HTTP/WebSocket、REST/HTTP APIの違い
- 統合タイプの設計:プロキシ/カスタム、統合先サービス
- 認証・認可の実装:リソースポリシー、IAM、Lambda/Cognito認可の組み合わせ
- 利用者制御:使用量プラン、APIキー、スロットリング設定
- 監視・運用:CloudWatch、CloudTrail、デプロイステージの管理
これらを適切に組み合わせることで、スケーラブルで安全なAPI基盤を実現できます。
重要ポイント
- ▸4つの統合タイプでバックエンド構成を柔軟に設計
- ▸プロキシ統合でマッピング自動化、カスタム統合できめ細かい制御
- ▸キャッシングとスロットリングでパフォーマンスと保護を確保
- ▸リソースポリシー・IAM・Lambda認可・Cognito認可を組み合わせ
- ▸使用量プランとAPIキーで利用者単位の課金・アクセス制御
このトピックの学習を完了しますか?
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
Amazon API Gateway に関連するトピックを続けて確認できます。