Amazon API Gateway設計ガイド：REST、HTTP、WebSocket APIの選び方とGCP、Azureとの違い

Amazon API Gatewayは、クライアントから届くAPIリクエストを受け、認証情報の検証、流量制御、ルーティング、ログ記録などを共通化するAWSのマネージドサービスです。

設計では機能を増やす前に、どのクライアントが何を呼ぶのか、入口とバックエンドのどちらに責任を置くのか、障害をどう検知するのかを決めます。

先に結論を示すと、一般的なHTTP APIではHTTP APIを候補にし、APIキー、クライアント別の流量制御、リクエスト検証、AWS WAF連携、プライベートAPIなどが必要ならREST APIを検討します。

• API Gatewayは、APIの入口で複数のバックエンドに共通する処理を受け持ちます。
• 認証と認可、APIキーと本人確認、スロットリングとコスト上限は、それぞれ別の問題です。
• AWS、Google Cloud、Azureでは、対応サービスの範囲と運用モデルが異なります。
• 製品名から選ぶのではなく、必要な制御、既存基盤、運用体制から選びます。

APIフロントが担う役割

APIフロントとは、ブラウザ、モバイルアプリ、外部システムなどのクライアントと、Lambda、コンテナ、業務システムなどのバックエンドの間に置く共通の入口です。

Amazon API Gatewayは、公開URLの提供、リクエストのルーティング、認証情報の検証、レート制限、ログとメトリクスの出力、バックエンドとの統合を担えます。

バックエンドにはAWS Lambda、公開HTTPエンドポイント、AWSサービス、VPC内のロードバランサーなどを接続できます。

統合は、API Gatewayが受け取ったリクエストを、どのバックエンドへどの形式で渡すかを定める接続設定です。

入口を共通化すると、各バックエンドが同じ認証処理やログ形式を個別実装する重複を減らせます。

ただし、業務上の権限判定や入力値の意味までゲートウェイに集めると、設定が複雑になり、変更箇所も追いにくくなります。

REST、HTTP、WebSocket APIの選び方

Amazon API GatewayにはREST API、HTTP API、WebSocket APIがあり、同じ名称の設定項目がすべての種類に存在するわけではありません。

現在の機能差は、AWSのREST APIとHTTP APIの公式比較で設計時に確認してください。

WebSocket APIは双方向通信を扱い、クライアントからの要求を待たずにサービス側からデータを送れます。

用途と接続先は、WebSocket APIの公式ガイドで確認できます。

選び方を「新しいからHTTP API」「高機能だからREST API」と決めると、必要な制御が欠けるか、使わない設定を抱えます。

先に要件表を作り、必要な機能を満たす最小の種類を選ぶ方が、構築後の変更理由を説明しやすくなります。

ゲートウェイとバックエンドの責任境界

API Gatewayに置く処理は、複数のAPIやバックエンドに共通し、入口で判定できるものに寄せます。

BFF（Backend for Frontend）は、Web、モバイル、外部パートナーなど、クライアントごとに必要なデータや操作をまとめるバックエンドです。

API GatewayはBFFへの入口とルーティングを担えますが、複数サービスを呼び出してレスポンスを組み立てる処理まで、必ずゲートウェイ設定に入れる必要はありません。

認証、認可、APIキーを分けて考える

認証は利用者やアプリの身元を確かめる処理で、認可は認証済みの主体に許された操作を判定する処理です。

サーバー間通信ではIAM、ユーザー向けAPIではCognitoなどが発行するJWT、独自要件がある場合はLambdaオーソライザーが候補になります。

どの方式でも、API Gatewayでトークンを検証しただけで業務上の認可が完了するとは限りません。

たとえば「ログイン済みである」は入口で確認できますが、「この注文を更新できる」は注文の所有者や状態を知るバックエンドで判定します。

APIキーは利用者を安全に認証する資格情報として扱わず、REST APIの利用プランでクライアントを識別し、使用量を集計する用途に限定します。

AWSもAPIキーと使用量プランの公式ガイドで、APIキーを認証や認可に使わないよう案内しています。

IAMと権限設計の全体像は、サイト内のAWS IAMの基礎と権限設計でも整理しています。

公開範囲と防御を重ねる

APIの防御は、認証方式だけで完結しません。

• 公開APIか、VPC内からだけ呼べる内部APIかを決めます。
• 必要な場合はリソースポリシー、ネットワーク境界、AWS WAFなどを組み合わせます。
• 過剰な権限を避け、バックエンドへの接続にも最小権限を適用します。
• 機密情報やトークンをアクセスログへそのまま残さない設計にします。

REST APIとHTTP APIでは対応する防御機能が異なるため、APIタイプを決める前に公開範囲と脅威を整理します。

VPC、サブネット、経路、公開境界の考え方は、Amazon VPC設計ガイドが補足になります。

流量制御、キャッシュ、可観測性

スロットリングは防波堤であり、請求額の上限ではない

スロットリングは、一定時間に受け付けるリクエスト数を調整し、急増した負荷からバックエンドを守る仕組みです。

REST APIの使用量プランではAPIキーごとのレートとクォータを設定できますが、AWSはこれらをベストエフォートと説明しています。

そのため、クォータだけをアクセス遮断やコスト上限として頼らず、予算監視、アラーム、防御ルール、バックエンド側の保護も組み合わせます。

キャッシュは更新条件から設計する

REST APIのステージキャッシュは、参照が多く更新頻度が低いレスポンスでバックエンド負荷を減らせます。

ただし、利用者や権限で結果が変わるAPIでは、キャッシュキーを誤ると別の利用者向けデータを返す危険があります。

何をキーにするか、いつ無効化するか、どのデータをキャッシュしないかを先に決めます。

HTTP APIにはREST APIと同じキャッシュ機能がないため、必要に応じてCloudFront、バックエンド、クライアントのキャッシュを検討します。

ログは調査手順とセットにする

アクセスログには、追跡に使うリクエストID、ルート、ステータスコード、処理時間などを構造化して残します。

4xxと5xxを分け、API Gatewayで拒否したのか、統合先が失敗したのかを判別できる形にします。

メトリクスを保存するだけでは障害対応につながらないため、監視対象、しきい値、通知先、最初に確認するダッシュボードを運用手順に含めます。

CloudWatchのメトリクス、ログ、アラームを設計する順序は、Amazon CloudWatch設計ガイドで詳しく説明しています。

代表的な構成パターン

Lambdaを使うサーバーレスAPI

HTTP APIまたはREST APIからLambdaを呼び出し、データストアや他のAWSサービスへ接続する構成です。

小さく始めやすい一方、同期リクエストの中に長時間処理を入れず、必要ならキューやワークフローへ分離します。

実行モデルと運用上の判断軸は、AWS Lambdaと他クラウドの比較も参考になります。

コンテナ基盤を非公開で接続するAPI

API GatewayからVPCリンクを経由し、ロードバランサーの背後にあるECSやEKSへ接続する構成です。

入口をAPI Gatewayに集めながら、既存のコンテナ運用とアプリケーション実装を活かせます。

コンテナの実行単位やEKSとの違いは、Amazon ECSの設計ガイドで確認できます。

クライアント別のBFF

Web、モバイル、パートナー向けに入口やルートを分け、それぞれのBFFへ接続する構成です。

レスポンス形式や認可条件が明確に異なる場合に有効ですが、名前だけ分けて同じ処理を複製すると保守箇所が増えます。

共通処理とクライアント固有処理の境界を設計書に残します。

Google Cloud、Azureとの違い

三つのクラウドにはAPIの入口を管理するサービスがありますが、同じ機能を同じ単位で提供しているわけではありません。

Google Cloud API GatewayとCloud Endpointsは、どちらもAPI管理に使えますが、前者はゲートウェイとして配備し、後者はESPまたはESPv2を使う分散型の構成です。

Google CloudのAPI Gateway公式ドキュメントとCloud Endpoints公式ドキュメントを分けて確認すると、構成の違いを判断しやすくなります。

Azure API Managementは、入口の転送だけでなく、APIの管理、ポリシー、開発者向けの発見と利用開始まで扱う点に特徴があります。

対応する構成要素は、Azure API Management公式ドキュメントで確認できます。

設計を決める手順

1. 利用者と通信方式を列挙する
   ブラウザ、モバイル、サーバー間、外部パートナーを分け、HTTPと双方向通信のどちらが必要かを整理します。
2. 公開範囲を決める
   インターネット公開、社内限定、VPC内限定を分け、接続元と経路を図にします。
3. 認証と認可を分ける
   誰であるかを何で検証し、どの操作を許すかをどこで判定するかを記録します。
4. 共通処理の置き場所を決める
   ルーティング、流量制御、変換、ログ、業務ルールを、APIフロントとバックエンドに割り当てます。
5. 必要機能からAPIタイプを選ぶ
   HTTP APIで満たせない要件を明示し、REST APIを選ぶ理由を残します。
6. 障害時の観測方法を決める
   リクエストID、ログ、メトリクス、アラーム、担当者の調査手順を用意します。
7. 小さな経路で検証する
   代表的な1本のAPIで認証、エラー、負荷、ログ、デプロイとロールバックを確認します。

よくある設計ミス

高機能な種類を先に選ぶ

REST APIの機能を使う予定がないのに採用すると、設定項目と運用判断だけが増えます。

必要機能の一覧を作り、HTTP APIで不足する項目を採用理由にします。

APIキーをログイン情報として使う

APIキーは認証や認可の代わりになりません。

IAM、JWT、Lambdaオーソライザーなどで主体を検証し、業務上の認可はバックエンドでも行います。

ゲートウェイへ業務ロジックを集める

複雑なマッピングや条件分岐を設定へ詰め込むと、テストとレビューが難しくなります。

入口で共通化する処理と、コードで管理する業務処理を分けます。

ログを出すだけで運用を終える

ログの保存先があっても、通知条件と調査手順がなければ復旧は早まりません。

障害の種類ごとに、誰が何を見て判断するかまで決めます。

同期APIで長時間処理を完了させる

時間のかかる処理はタイムアウトと再試行の影響を受けやすいため、要求を受け付けた後にキューやワークフローへ渡す非同期化を検討します。

導入前チェックリスト

• クライアント、通信方式、公開範囲を図にしたか
• 認証と業務上の認可を分けたか
• APIキーを本人確認に使っていないか
• REST APIを選ぶ機能要件を説明できるか
• 流量制御をコストの厳密な上限と誤解していないか
• 機密情報を除いたアクセスログを設計したか
• 4xx、5xx、遅延を誰が調べるか決めたか
• キャッシュキーと無効化条件を確認したか
• 設定をコード化し、変更レビューとロールバックを行えるか
• 料金、上限、対応リージョンを実装時点の公式情報で再確認したか

APIフロント設計の結論

Amazon API Gatewayは、APIの入口で共通の制御と観測をそろえ、バックエンドの実装をクライアントから分離するためのサービスです。

HTTP API、REST API、WebSocket APIの選択は、機能の多さではなく、通信方式、公開範囲、認証、流量制御、キャッシュ、運用に必要な機能から決めます。

最初の実務は、既存APIを1本選び、クライアントからバックエンドまでの経路と、各層が負う責任を書き出すことです。

その図と要件表があれば、AWS、Google Cloud、Azureのどのサービスを使う場合でも、製品名に引っ張られずに設計を比較できます。

参考にした公式情報

• Amazon API Gateway製品ページ
• Amazon API Gateway開発者ガイド
• REST APIとHTTP APIの機能比較
• REST APIのAPIキーと使用量プラン
• Google Cloud API Gatewayドキュメント
• Google Cloud Endpointsドキュメント
• Azure API Managementドキュメント