APIゲートウェイとは？認証・ルーティング・制限の仕組みを図解

ひよこ

APIゲートウェイは何をするの？

ペンギン先生

APIへの入口をまとめ、リクエストを適切なバックエンドへ送る仕組みだよ。製品や設定によって認証、レート制限、変換、ログなども担当する。小さな受付をイメージすると分かりやすいね。

ひよこ

入口をまとめる利点は？

ペンギン先生

クライアントから内部の構成を隠し、共通のルールを適用しやすくなるよ。ただし入口を増やすことで通信経路や設定も増える。単一のアプリなら、既存のサーバーやロードバランサーで足りる場合もあるんだ。

ひよこ

ロードバランサーと同じもの？

ペンギン先生

機能は重なるけれど、ロードバランサーは主に負荷の振り分け、APIゲートウェイはAPI単位の認証や利用制御などに重点があるよ。製品によって境界が違うので、名前より必要な機能で比較しよう。

ひよこ

認証を任せればアプリの確認は不要？

ペンギン先生

不要にはならないよ。入口で誰かを確認できても、その人が特定の注文を読んでよいかという業務上の認可は別。バックエンドへの直接アクセスを防ぐことや、転送するID情報を信頼できる経路で渡すことも必要なんだ。

ひよこ

APIキーがあればログインの代わりになる？

ペンギン先生

APIキーの意味は製品次第だよ。たとえばAmazon API Gatewayの使用量プランのキーは、利用者の認証・認可の代わりにしないよう公式が案内している。利用量を識別するキーと、アクセス権限を検証する仕組みを分けよう。

ひよこ

レート制限で攻撃も請求額も抑えられる？

ペンギン先生

過負荷対策の一部にはなるけれど、すべての攻撃や費用を防ぐ保証ではないよ。AWSのスロットリングとクォータもベストエフォート。WAFや予算監視、アプリの処理量の制限などを必要に応じて組み合わせるんだ。

ひよこ

ゲートウェイが故障したら？

ペンギン先生

入口が使えないと影響が広いので、冗長化や監視、タイムアウトを設計するよ。マネージドでもバックエンドの障害、設定ミス、リージョンの問題まで自動的に解消するわけではないんだ。

ひよこ

BFFもゲートウェイのこと？

ペンギン先生

BFFは画面やクライアントに合わせたバックエンドを用意する設計だよ。ゲートウェイと組み合わせることはあるけれど、同義ではない。データの集約や業務ロジックをどこに置くかを整理して選ぼう。

リクエストはどう通る？

クライアント → ゲートウェイ → 対象サービス → 応答

ゲートウェイでトークンを検証して/ordersを注文サービスへ送る例を考えます。注文サービスは、その利用者が指定された注文を読めるかを確認します。トークンが有効であることだけで、全注文の閲覧を許可してはいけません。

入口で共通化できること・残ること

機能・API種別によって対応は異なります。Amazon API GatewayのREST API・HTTP API・WebSocket APIも同一の機能セットではありません。

導入前の小さな確認

正常な要求に加え、期限切れトークン、他人のデータへのアクセス、バックエンド停止、短時間の集中アクセスを検証します。429などを受けた再試行も、無制限に繰り返さず、処理の重複が許されるかを含めて設計します。

参考資料

確認日：2026年9月26日。製品の仕様・料金・対応環境は導入時にも確認してください。

• Amazon API Gateway overview：API種別とゲートウェイ機能。
• API Gateway throttling：ベストエフォート制限と429。
• API keys and usage plans：APIキーと認証の区別、クォータの限界。