先に結論
API Gateway は、外から来るHTTPリクエストを受けて、Lambda や他のバックエンドへ渡す入口です。
AWS公式でも、アプリケーションがデータやビジネスロジックへアクセスするための front door と説明されています。
初心者向けにざっくり言うと、API Gatewayは URLを受ける窓口 で、Lambdaは 実際の処理をする中身 です。
| 役割 | 何をするか |
|---|---|
| API Gateway | リクエスト受付、ルーティング、認証、制御、レスポンスの入口整理 |
| Lambda | 実際の処理実行 |
| CloudWatch | ログやメトリクスを見る |
つまり、Lambdaをそのまま外へ見せるのではなく、API Gatewayを前に置いて どう受けるか を整理するイメージです。
この記事では、2026年4月23日時点で AWS公式の
What is Amazon API Gateway?、Amazon API Gateway concepts、Choose between REST APIs and HTTP APIs、About Amazon API Gatewayを確認しながら整理しています。
API Gatewayとは何か
API Gatewayは、AWSでAPIを作成、公開、保守、監視、保護するためのサービスです。
AWS公式でも、REST、HTTP、WebSocket API を扱えると案内されています。
ただ、初心者が最初に出会うのはたいてい Lambdaの前段に置くHTTPの入口 です。
たとえば、次のような流れです。
- ブラウザやアプリが
https://example.com/usersへアクセスする - API Gatewayがそのリクエストを受ける
- 決めたルールに従ってLambdaへ渡す
- Lambdaが処理する
- API Gatewayが結果をHTTPレスポンスとして返す
このため、API Gateway = LambdaをURLとして外へ出すための表玄関 と考えると分かりやすいです。
Lambdaの前段で何をしているのか
前段で何をしているのか を細かく見ると、主に次の役割があります。
1. リクエストの受付
まず、API Gatewayが外部からのHTTPリクエストを受けます。
Lambda単体に このURLへ来たらこの処理 というHTTP入口をそのまま持たせるのではなく、API Gatewayが受け口になります。
2. ルーティング
GET /users はこの処理、POST /orders はこの処理、のように、どのパスとメソッドをどこへ渡すかを整理します。
AWS公式の概念説明でも、リソースやメソッドを公開し、バックエンドHTTPエンドポイントやLambda関数へ統合すると説明されています。
3. 認証とアクセス制御
API Gatewayは、誰でも叩ける公開APIにするだけでなく、認証やアクセス制御の入口にもなります。
AWS公式でも、IAMポリシー、Lambda authorizer、各種認証メカニズムが案内されています。
つまり、Lambdaのコード側だけで守るのではなく、入口側でも制御できるわけです。
4. レート制御や保護
API Gatewayには、スロットリング、監視、CORS対応など、入口として必要になりやすい機能があります。
リクエストをそのまま全部流すのではなく、受け方を整える のが大きな役目です。
5. 監視しやすい形へまとめる
CloudWatchログやメトリクス、CloudTrailでの変更追跡など、運用側から見やすくするのも大事な役割です。
Lambdaのログだけ見ていると、入口で何が起きたかが見えにくいことがあります。
HTTP APIとREST APIの違い
ここは最初に少し混乱しやすいところです。
AWS公式では、API Gatewayには HTTP APIs と REST APIs があり、REST API の方が機能が多く、HTTP API はより軽量で低コスト寄りだと説明されています。
初心者向けには、まず次の理解で十分です。
| 種類 | 向いている場面 |
|---|---|
| HTTP API | LambdaやHTTPバックエンドの入口をシンプルに作りたい |
| REST API | より多いAPI管理機能が必要 |
AWS公式でも、API keys、per-client throttling、request validation、WAF 連携、private API endpoints などが必要なら REST API を選ぶ、と案内されています。
なので、まずLambdaの前段を素直に作りたい なら HTTP API、管理機能までしっかり使いたい なら REST API を候補にすると分かりやすいです。
API Gatewayが向いている場面
API Gatewayが向いているのは、たとえば次のような場面です。
- LambdaをHTTPで呼びたい
- APIの入口を1か所で整理したい
- 認証やCORS、スロットリングを入口で持ちたい
- バックエンドをLambdaやHTTPサービスで切り替えたい
- 運用や監視をAWS側に寄せたい
特に、サーバーレス構成ではかなり自然な選択肢です。
API Gatewayがやや重く感じる場面
一方で、何でもAPI Gatewayが最適とは限りません。
- 単純な社内向けHTTP入口だけで十分
- すでにALBや別のAPI基盤がある
- API管理機能をほとんど使わない
- Lambda以外の構成で別の入口の方が自然
こうした場合は、ALBや別の構成の方が素直なこともあります。
API Gatewayは便利ですが、AWSでAPIっぽいものは全部これ と決め打ちしない方が安全です。
よくある誤解
1. API GatewayはLambdaを動かすサービス
違います。
Lambdaを動かすのはLambda自身で、API Gatewayはその前で受ける入口です。
2. API Gatewayを置けば自動で安全
入口側でできることは多いですが、認証方式、権限、バックエンドの実装、ログ確認まで含めて初めて安全になります。
前段に置いたから大丈夫 ではありません。
3. HTTP APIとREST APIは名前が違うだけ
AWS公式でも、REST APIの方が機能が多く、HTTP APIはより軽量で低コスト寄りとされています。
同じHTTP入口でも、機能差を見た方がよいです。
どう理解するとよいか
初心者向けには、API Gatewayを HTTPの窓口を整えるサービス と考えるのがいちばん自然です。
Lambdaが中で処理し、API Gatewayが入口を担当する、と役割を分けるとかなり見通しが良くなります。
この見方をすると、
- URLやメソッドで振り分ける
- 認証や制御を前で持つ
- Lambdaを外へ直接さらさない
- 監視やログも入口視点で見られる
という価値がつながります。
この順で読むとつながりやすい
- AWSで最初に覚えたい基本用語まとめ｜EC2・IAM・S3・VPCのつながりを整理
- Lambda
- このAPI Gateway記事
- REST API
- 認証やレート制御、Webhook設計
この順で見ると、処理 と 入口 の役割差がかなり分かりやすくなります。
まとめ
API Gateway は、Lambdaの前でHTTPリクエストを受ける入口です。
単に転送するだけでなく、ルーティング、認証、制御、監視の入口整理をまとめて担います。
特に大事なのは、Lambdaが処理、API Gatewayが受け口 と役割を分けて理解することです。
この切り分けができると、サーバーレス構成の見え方がかなりすっきりします。
参考リンク
- AWS Docs: What is Amazon API Gateway?
- AWS Docs: Amazon API Gateway concepts
- AWS Docs: Choose between REST APIs and HTTP APIs
- AWS Docs: About Amazon API Gateway