はじめに
こんにちは。
プログラミング初心者wakinozaと申します。
勉強中に調べたことを記事にまとめています。
十分気をつけて執筆していますが、なにぶん初心者が書いた記事なので、理解が浅い点などあるかと思います。
間違い等あれば、指摘いただけると助かります。
記事を参考にされる方は、初心者の記事であることを念頭において、お読みいただけると幸いです。
記事のテーマ
- AWS SAA 学習中に調べたことをまとめています。
- この記事では、AWSのAPI Gatewayについて記載しています。
目次
1. APIとは
2. API Gatewayの働き
3. 3つの形式
4. 認証・認可
5. 流量制限
6. ルーティング
7. カナリアリリース
1. APIとは
まず、API（Application Programming Interface）とは何かを定義したいと思います。
多義的で理解が難しい言葉ですが、大きく3つの意味を内包しています。
「ルール」「ソフトウェア」「なんでも屋」です。
1.1. ルールとしてのAPI
「ルール」という意味からみると、APIは、ソフトウェア同士が相互に通信するための規約（インターフェース）です。
Web APIにおいては、アプリケーションが外部に対して「このエンドポイント（URL等）に、この形式（JSON等）でデータを送れば、この処理を返すよ」という仕様を公開したものです。
このような規約を公開している理由は、クライアント（フロントエンド）とアプリケーション（バックエンド）を論理的に切り離すためです。
クライアントからアプリケーションに通信する場合、規約に適合さえしていれば、内部の仕組みを理解しなくても、アプリケーションを利用することができます。
一方バックエンドも、規約にさえ適合していれば、アプリケーションの振る舞いは変えずに、内部の仕様を変更できます。例えば、バックエンドの言語がPythonからNode.jsへ、MySQLからAuroraへ変更されても、規約が同じであれば、クライアントはその変化に気づくことなくアプリケーションを利用できます。
APIという規約によりフロントエンドとバックエンドを切り離すことで、変更容易性と情報隠蔽を同時に実現できるのです。
1.2. ソフトウェアとしてのAPI
APIの2つ目の側面が、「ソフトウェア」です。
APIはただのルールであるため、実際にリクエストが規約に適合するかを確認し、アプリケーションにデータを渡すためのソフトウェアが必要です。
この規約を遵守するために働くソフトウェアやソフトウェアの接続口のことを「API」と呼ぶ場合があります。
ソフトウェアとしてのAPIは、定義された規約に基づき、リクエストの検証やプロトコル変換を行い、バックエンドへ処理を委譲するリバースプロキシとしての役割を担います。
要するに、「ルールそのもの」と「ルールを実現するソフトウェア」を両方「API」と呼んでいるわけです。
「刑法」と「刑法を遵守するための警察官や警察署」を同じ名前で呼んでいるようなものであるため、ややこしいのです。
1.3. なんでも屋としてのAPI
さらに理解をややこしくするのが、ソフトウェアとしてのAPIに他の機能が付与されている点です。
ソフトウェアとしてのAPIの本来の役割は、リクエストが規約に適合するかを確認し、適合する場合は定められた形式に変換し、アプリケーションにデータを渡すことにありました。
しかし、アプリケーションの「前段階」で行っておきたい処理は、規約のチェック以外にも多数あります。
認証と認可、リクエスト数の制限・調整、キャッシュなどです。
それらの処理を、アプリケーション側で実現しようとすると、アプリケーションが複雑になります。
かといって、別のプログラムとして作成すると、リクエストがすべてのプログラムを経由しなければならず、ルーティングが複雑化します。
そのため、アプリケーションの前段階でやっておきたい共通処理を、ソフトウェアとしてのAPIにまとめて集約することになりました（共通処理の集約）。
前段階に必要な処理はソフトウェアとしてのAPIがまとめて実行するため、アプリケーションは純粋なビジネスロジックの実装に集中できます。
また、リクエストもAPIだけを経由すればよく、ルーティングもシンプルになります。
ビジネスロジックはアプリケーションが、前段階の通信の作法はソフトウェアとしてのAPIが担うという「責任の分離」 を行った結果、「アプリケーションの外部とのやり取り」全般を引き受けた「なんでも屋」APIが誕生したのです。
まとめると、APIとはもともとは「ソフトウェア同士が相互に通信するための規約」でした。
それがいつしか「ルールとしてのAPIを実現するソフトウェア」を指すようになり、さらにソフトウェアとしてのAPIに他の役割が追加されていった結果、「ルール」「ソフトウェア（やその接続口）」「なんでも屋」このすべてを「API」と呼ぶようになったのです。
なんてこったい。
ちなみに、AWSでは、ルールとしてのAPIを「API定義 (API Definition)」「API 仕様 (API Specification)」、ソフトウェアへの接続口としてのAPIを「APIエンドポイント」、なんでも屋としてのAPIを「API Gateway」と呼び分けます。
この記事では、AWSにおいてなんでも屋のAPIである「API Gateway」の役割について説明していきます。
2. Amazon API Gatewayの働き
Amazon API Gateway（以下、API Gateway）はAPIの公開・管理・認証・ルーティングなどを行うマネージドサービスです。
非常に多機能なので、個別の説明の前にまずは、全体像をざっくり説明します。
API Gatewayの主要な機能は以下の通りです。
| 機能 | 説明 | |
|---|---|---|
| 1 | WAF（Web Application Firewall）との統合 | AWS WAF と連携し、SQLインジェクションやクロスサイトスクリプティング（XSS）といった悪意のある攻撃パケットを、アプリケーションに届く前にブロックする |
| 2 | 認証・認可 | APIへのアクセスに対して、IAM権限やAmazon Cognitoで認証・認可を行い、アクセス制御を実現する機能 |
| 3 | 流量制限 | 設定されたリクエスト数/秒を超えていないか確認する |
| 4 | バリデーション | リクエストの仕様が正しいかを確認する |
| 5 | マッピングテンプレート | クライアントが送ってきたデータを、バックエンドが処理しやすい形に変換する |
| 6 | ルーティング | 適切なバックエンドにデータを受け渡す |
| 7 | キャッシュ | 処理したレスポンスをメモリに保存し、同様のリクエストが来た際に、バックエンドを介さずに即応する |
| 8 | カナリアリリース | APIの異なるバージョンや開発段階を管理し、新しいAPIなどの試験運用をサポートする |
| 9 | ログ記録 | リクエストの成功・失敗（4XX, 5XXエラー）、レスポンスタイム、アクセスログを Amazon CloudWatch に自動送信する |
| 10 | SDK の自動生成 | API開発者が、APIを利用するアプリを作成する開発者のために用意した接続ツールを提供する |
リクエスト受付時のフローは、以下の通りです。
- WAF 連携 : 不審な接続を遮断
- キャッシュ確認 : さっきと同じ質問なら、この時点で即応
- 認証・認可 : 正規のリクエストかを確認
- 流量制限 : リクエストの入場制限
- バリデーション : リクエストの不備のチェック
- マッピングテンプレート : バックエンドが処理しやすい形式に変換
- ルーティング : 適切なバックエンドへリクエストを受け渡す
リクエスト受付時のフローとは別に、APIの品質や開発を支援する機能が準備されています。
- ログ管理 : ログの書き出し
- カナリアリリース : 新しいAPIの試験運用をサポート
- SDKの自動生成 : 「APIを利用したアプリ」を開発する人向けの便利ツールの提供
3. 3つの形式
API Gatewayは、ルールとしてのAPIをいくつかサポートしています。
「REST形式のAPI」と「WebSocket形式のAPI」の2つの形式があり、「REST形式の規約」はさらに「REST API」と「HTTP API」の種類に分かれます。
このため、API Gatewayは「REST API」「HTTP API」「WebSocket API」3つの形式に対応しているといえます。
リクエストがどの形式かによって、機能の振る舞いが変わるため、3つの形式について先に説明していきます。
3.1. REST API
REST APIは、クライアントからのリクエストに対応して、レスポンスの形で返答するという形式のAPIです。
クライアントは、URLを利用したHTTP通信でリクエストを送ります。
通信の状態を管理しない、「ステートレス」な形式です。
キャッシュ、詳細なバリデーション、WAF連携、APIキー管理など、高度な運用機能が利用できます。
その反面、利用コストは高めになります。
REST APIの利用料金は、受信したAPIリクエストの数と、データ転送量（AWSからインタ―ネットへ出ていく通信）に対して発生します。
APIリクエスト料金は、リクエスト数とリージョンによって異なります。2026年4月時点の東京リージョンの価格は以下の通りです。
| APIリクエスト数 | 料金 |
|---|---|
| 333 million / 月まで | 4.25ドル/million リクエスト毎 |
| 次の 667 million / 月 | 3.53ドル/million リクエスト毎 |
| 次の 19 billion / 月 | 3.00ドル/million リクエスト毎 |
| 20 billion以上 / 月 | 1.91ドル/million リクエスト毎 |
データ転送（アウトバインド）の料金は、API独自の料金体系ではなく、AWS全体の共通価格が適用されます。価格は、リージョンごとに異なります。2026年4月時点の東京リージョンのデータ転送（アウトバインド）の価格は以下の通りです。
| データ量 | データ転送量（アウトバインド） |
|---|---|
| 100GB / 月まで | 無料 |
| 最初の 10TB / 月 | 0.114ドル/GB |
| 次の 40TB / 月 | 0.089ドル/GB |
| 次の 100TB / 月 | 0.086ドル/GB |
| 150TB以上 / 月 | 0.084ドル/GB |
3.2. HTTP API
HTTP API は、REST API の軽量版として提供されているAPI形式です
そのため、REST APIと同様、クライアントからのリクエストに対応して、レスポンスの形で返答します。
クライアントは、URLを利用したHTTP通信でリクエストを送ります。
通信の状態を管理しない、「ステートレス」な形式です。
HTTP API は低価格・低レイテンシーで提供できるように、REST APIと比べて機能が制限されています。
具体的には、API キー・クライアントごとのスロットリング・リクエストの検証・AWS WAF の統合・Private API endpointなどの機能が「HTTP API」ではサポートされていません。
ミリ秒単位の低レイテンシが求められるマイクロサービス間通信ならHTTP APIを、複雑な認可やセキュリティ対策が必要なエンタープライズ向け外部公開APIならREST APIを選択するとよいでしょう。
HTTP APIの利用料金は、受信したAPIリクエストの数と、データ転送量（アウトバインド）に対して発生します。
データ転送量（アウトバインド）は、AWS内で共通です。
APIリクエスト料金は、リクエスト数とリージョンによって異なります。2026年4月時点の東京リージョンの価格は以下の通りです。
| APIリクエスト数 | 料金 |
|---|---|
| 300 millionまで / 月 | 1.29ドル/million リクエスト毎 |
| 300 million以上 / 月 | 1.18ドル/million リクエスト毎 |
3.3. WebSocket API
WebSocket APIは、双方向・フルデュプレックス（全二重）通信を実現するためのWebSocketプロトコルを利用した双方向通信APIです。
一度接続を確立（ハンドシェイク）すると、明示的に切断するまで通信が維持されます。
そのため、通信の状態を保持する「ステートフル」な通信と言えます。
また、REST APIは、サーバー側でデータが更新されても、クライアント側から再度リクエストが送信されない限り、新しいデータを取得することができません。
しかし、WebSocket APIは双方向の通信をサポートしているため、サーバー側から任意のタイミングでデータをプッシュ可能です（プッシュ通知）。チャットアプリや、マルチプレイのゲームなどリアルタイム更新が必要な通信に向いています。
WebSocket APIの利用料金は、接続合計時間（分単位）と受信したAPIリクエストの数に対して発生します。
利用料金はリージョンによって異なります。2026年4月時点の東京リージョンの価格は以下の通りです。
接続料金は、接続時間に対して100万接続分あたり 0.2625 ドルの料金が発生します
APIリクエストの数に応じた料金は、以下の通りです。
| APIリクエスト数 | 料金 |
|---|---|
| 1 billionまで / 月 | 1.26ドル/million 毎 |
| 1 billion以上 / 月 | 1.06ドル/million 毎 |
4. 認証・認可
次に個別の機能の説明に移ります。
まず説明するのが、認証・認可です。
API Gatewayにおいては認証・認可を担っているのが「オーソライザー（Authorizer）」という機能です。
オーソライザーは、APIリクエストがアプリケーションサイドに届く前に、「そのリクエストを送信してきたユーザーが誰か（認証）」および「その操作を行う権限があるか（認可）」を判定する役割を果たします。
APIの形式に応じて、利用できるオーソライザーのタイプが異なります。
| オーソライザーの種類 | 特徴 | REST API | HTTP API | WebSocket API |
|---|---|---|---|---|
| Cognito ユーザープールオーソライザー | Amazon Cognitoが提供するマネージド型の認証機能を使用。開発者は認証ロジックを自身で実装する必要がない。 | 〇 | △(JWT経由) | × |
| Lambda オーソライザー | 独自のLambda関数で認証ロジックを記述。独自の認証システムや、複雑な認可ロジックが必要な場合 | 〇 | 〇 | 〇（$connectのみ） |
| JWT（JSON Web Token）オーソライザー | JWT（JSON形式で作成されたユーザーの認証情報や権限などを含む署名付きのトークン）を使用。Cognitoユーザープールが発行するJWTも使用できる。 | × | 〇 | × |
| IAM 認可 | AWSのIAMポリシー（SigV4署名）を使用。 | 〇 | 〇 | 〇 |
5. 流量制限
流量制限とは、設定されたリクエスト数を超えていないか確認することです。
過剰なリクエストが送信されても、API Gatewayの段階で拒否すれば、そのあとのアプリケーションサイドに負荷がかからず、コストも抑えることができます。
API Gatewayの流量制限機能としては、REST APIのみ利用できる「使用量プラン」があります。
使用量プランは、特定のクライアント（APIキー）に対して、APIの利用頻度や回数を制限するための仕組みです。
具体的には、以下の項目を設定し、利用量を制限します。
| 項目 | 内容 |
|---|---|
| スロットリング | 1秒当たりのリクエスト数（レート）や、一時的に許可されるリクエストの最大値（バースト）制限 |
| クォータ | 日、週、月などの期間あたりの合計リクエスト数を制限 |
6. ルーティング
API Gatewayは、マッピングテンプレート（クライアントが送ってきたデータを、バックエンドが処理しやすい形式に変換）によるデータ変換後に、データをアプリケーションにルーティングします。
API Gatewayは、パブリックなエンドポイントを持つAWSリソースに対して、インターネット経由でリクエストを転送できます。
しかし、もしルーティング対象がVPC内のプライベートサブネット内のリソースである場合、API Gatewayは、そのままではプライベートサブネット内のリソースへ直接通信できません。
その場合は、「VPCリンク」を作成します。
VPCリンクを作成することで、API Gatewayとプライベートサブネット内のリソースの間でインターネットを経由しないセキュアな通信が可能です。
また、VPCリンクを利用して通信を行う場合、対象となるプライベートサブネット内にロードバランサーを設置し、VPCリンクの対象をロードバランサーに設定します。
具体的には、API Gatewayからプライベートリソースへの通信の流れは、以下のようになります。
API Gateway → VPCリンク → ロードバランサー → プライベートサブネット内のリソース
リソースの手前にロードバランサーを配置する理由は、API Gatewayとリソース間を疎結合にすることで高可用性を実現できるためです。
ロードバランサーを介さない場合、リソースであるEC2の障害やAuto Scalingによるインスタンスの増減に対して、API Gateway側で宛先IPアドレスを更新する必要が生じ、可用性と柔軟性が損なわれます。
リソースへの通信にロードバランサーを経由させることで、複数のリソースへの負荷分散やヘルスチェックなどをロードバランサーに任せることができ、API GatewayはロードバランサーのDNS名にのみ通信を送るだけで、背後のリソースを気にする必要がなくなります。
APIの形式によって利用できるロードバランサーに違いがあります。
- REST API と WebSocket API : NLB（Network Load Balancer）のみ利用可能
- HTTP API : NLB と ALB（Application Load Balancer）が両方利用可能
7. カナリアリリース
API Gatewayは、「カナリアリリース」というデプロイ戦略をサポートしています。
カナリアリリースとは、新しいバージョン（カナリア）のソフトウェアやAPIを公開する際に、旧バージョンと新バージョンを同時に運用し、本番に近い環境で検証を行いながら、デプロイを進める方法です。
具体的には、旧バージョンの運用を続けながら、そのトラフィックの一部を新バージョン（カナリア）に流しながら、検証を行います。
実践的な環境で検証を行えるうえ、万が一致命的なバグがあっても影響を受けるユーザーを一部に限定できます。
また、新バージョンへ送られるトラフィックの比率を調整できるため、問題なければ新バージョンに100％移行、問題があれば旧バージョンに100％戻すといった柔軟な対応も可能です。
カナリアリリースを利用することで、リスクを分散し、ユーザーへの影響を最小限に抑えることができます。
カナリアリリースとよく比較されるデプロイ戦略に、「ブルー/グリーンデプロイ」があります。
こちらは、旧環境（ブルー）のコピーから新環境（グリーン）を作成し、変更やテストが完了後、ロードバランサーやDNSの設定を変えることで、トラフィックを一気にブルーからグリーンに変更します。
メリットは、ダウンタイムをほぼゼロにできることと、異常があればすぐに旧環境（ブルー）に戻すことが可能である点です。
デメリットは、環境を2つ用意するため、コストがかかる点です。
記事は以上です。
最後までお読みいただき、ありがとうございました。
参考情報一覧
この記事は以下の情報を参考にして執筆しました。
- AWS 認定資格試験テキスト AWS認定 ソリューション アーキテクト - アソシエイト 改定第3版
- 徹底攻略AWS認定ソリューション アーキテクト - アソシエイト 教科書 第3版
- ping-t
- Amazon API Gateway とは何ですか? (参照 2026-04-24)
- REST API と HTTP API のどちらかを選択する (参照 2026-04-24)
- API Gateway のユースケース (参照 2026-04-24)
- Amazon API Gateway の料金 (参照 2026-04-24)
- API Gateway の Canary リリースデプロイの設定(参照 2026-04-24)