先に要点
- API Gateway は Lambda の前に置くHTTPの入口で、ルーティング・認証・スロットリング・監視をまとめて担う。
- 入口は API Gateway だけではない。Lambda Function URL(最安・最小)、ALB(既存ECS/EC2と同居)との選定フローを先に持つと迷わない。
- API Gateway の HTTP API と REST API は別物。API key・Usage Plan・リクエスト検証・WAF直結はREST固定、JWTオーソライザーとCORS自動化と低料金はHTTP API側。
- Lambda authorizer はキャッシュがデフォルトで全ルート共有。識別ソースに
$context.routeKeyを足さないと、別エンドポイントの権限が使い回されて事故になる。
先に要点
API Gateway は、外から来るHTTPリクエストを受けて、Lambda や他のバックエンドへ渡す入口です。AWS公式でも、アプリケーションがデータやビジネスロジックへアクセスするための front door(表玄関)と説明されています。
初心者向けにざっくり言うと、API Gatewayは「URLを受ける窓口」で、Lambdaは「実際の処理をする中身」です。
| 役割 | 何をするか |
|---|---|
| API Gateway | リクエスト受付、ルーティング、認証、スロットリング、レスポンスの入口整理 |
| Lambda | 実際の処理実行 |
| CloudWatch | ログやメトリクスを見る |
つまり、Lambdaをそのまま外へ見せるのではなく、API Gatewayを前に置いて「どう受けるか」を整理するイメージです。
この記事は、2026年10月時点の AWS公式ドキュメント(What is Amazon API Gateway? / Choose between REST APIs and HTTP APIs / Control access to HTTP APIs with Lambda authorizers / Amazon API Gateway pricing / REST API と HTTP API のクォータ)と、AWS の料金データを確認して整理しています。料金や仕様は更新されるため、本番採用時は必ず最新の公式ページで確認してください。
API Gatewayとは何か
API Gatewayは、AWSで API を作成・公開・保守・監視・保護するためのマネージドサービスです。REST API、HTTP API、WebSocket API の3タイプを扱えます。
ただ、初心者が最初に出会うのはたいてい「Lambdaの前段に置くHTTPの入口」です。たとえば次のような流れになります。
このため、「API Gateway = LambdaをURLとして外へ出すための表玄関」と考えると分かりやすいです。
まず決めるべきは「入口を何にするか」
ここが今回いちばん伝えたいところです。「LambdaをHTTPで呼ぶ＝とりあえずAPI Gateway」と反射的に決めると、あとで料金や運用が重くなります。入口の候補は実際には3つあります。
Lambda Function URL
Lambda単体に直接HTTPSのURLを付ける機能。追加サービス不要で最安・最小構成。ただし認証は AWS_IAM か NONE の2択のみ、WAF を直接付けられない(前段に CloudFront が要る)。エンドポイントはインターネット経由のみで、PrivateLink(VPCエンドポイント)には対応しない。
API Gateway
JWT/Lambda オーソライザー、リクエスト検証、Usage Plan、WAF直結、キャッシュなどのAPI管理機能を持つ(リクエスト検証・Usage Plan・WAF・キャッシュは REST API のみ)。サーバーレスのAPI入口の王道。
ALB(Application Load Balancer)
すでにEC2/ECSを動かしていてLambdaも混ぜたい時に有利。Cognito連携やWAFも使える。リクエスト単位ではなく時間+LCU課金。
判断は次のフローで切るとブレません。
- 1
- 2
- 3
- 4
| 観点 | Lambda Function URL | API Gateway | ALB |
|---|---|---|---|
| 認証 | IAM か なし | IAM/Lambda authorizer/Cognito/JWT(HTTP API)/API key(REST API) | OIDC/Cognito 連携 |
| WAF直結 | 不可(CloudFront経由) | REST APIのみ可(HTTP APIは不可) | 可 |
| カスタムドメイン | 非対応(CloudFront併用) | 対応 | 対応 |
| タイムアウト | 最大15分(Lambda側) | 既定で最大29秒(HTTP APIは30秒。REST APIのリージョン/プライベートAPIは引き上げ申請可) | 長め(設定可) |
| 課金モデル | Lambda呼び出しのみ | リクエスト従量 | 時間+LCU |
| 向く場面 | 内部呼び出し・最小コスト | 公開API・管理機能が必要 | 既存ALB配下に同居 |
ざっくり言うと、内部からIAMで叩くだけなら Function URL、ブラウザ公開や管理機能が要るなら API Gateway、既存のALBがあるなら ALB という分け方が現実的です。
HTTP APIとREST APIの違い(ここで選定を間違えやすい)
API Gatewayに決めた後、もう一段の分岐があります。HTTP API と REST API は名前が似ているだけの別サービスで、機能と料金がはっきり違います。
最大の注意点は、API key・Usage Plan・リクエスト検証・WAF直結・プライベートエンドポイント・キャッシュ・実行ログや X-Ray トレース・レスポンスストリーミングなどは REST API 固定で、HTTP API には存在しないことです(CloudWatch へのアクセスログはどちらも出せます)。逆にHTTP APIは機能を絞ったぶん料金が安く、JWTオーソライザー(OIDC/OAuth 2.0ネイティブ)と自動デプロイを持ちます。公式の比較ページも「REST API の機能が要らなければ HTTP API」という整理です。
| 機能 | HTTP API | REST API |
|---|---|---|
| 料金(受信100万リクエスト、バージニア北部 / 東京) | $1.00 / $1.29(月3億件まで) | $3.50 / $4.25(月3億3,300万件まで) |
| API key / Usage Plan(従量課金・配布) | なし | あり(REST固定) |
| リクエスト/レスポンス検証・変換(VTL) | なし | あり(REST固定) |
| WAF直結 | なし | あり(REST固定) |
| JWTオーソライザー(OIDC/OAuth2) | 組み込みあり | なし(Cognito オーソライザーか Lambda authorizer で代替) |
| CORS自動化 | あり(設定だけ) | 手動で組む場面が多い |
| プライベートAPIエンドポイント | なし | あり |
| レスポンスストリーミング | なし | あり |
具体的な落とし穴を1つ。「外部パートナーにAPIキーを配って、契約プランごとに月間リクエスト上限を切りたい」という要件。これは Usage Plan の機能ですが、HTTP API には存在しません。HTTP APIで作り始めてから「キー発行と従量制限が要る」と気づくと、REST APIへの作り直しになります。API keyや従量課金を売り物にするAPIなら、最初からREST APIを選ぶのが正解です。
料金の目安も押さえておきます(2026年10月に AWS の料金データで確認)。月300万リクエスト程度なら、バージニア北部で HTTP API が $3、REST API が $10.5、東京では $3.87 と $12.75 です(いずれも月額・リクエスト分のみ)。Lambdaの実行料金やデータ転送(料金ページの例では $0.09/GB)、REST APIのキャッシュ(0.5GBでバージニア北部 $0.02/時 ≒ 月約 $15、東京 $0.028/時 ≒ 月約 $20)は別途です。無料利用枠は、料金ページでは新規顧客向けに REST・HTTP とも月100万リクエスト(最大12か月)と案内されていますが、2025年7月15日以降に作成したアカウントはクレジット制の新しい無料枠に変わっているので、自分のアカウントで何が有効かは請求コンソールで確認してください。
Lambda authorizer の落とし穴(キャッシュ共有)
認証をコードに書きたくない時、Lambda authorizer(自作の認可関数)をAPI Gatewayの前に挟む構成がよく使われます。ここに実務で踏みやすい地雷があります。
API Gatewayはオーソライザーの結果をキャッシュします。キャッシュキーは「識別ソース(identity source)」、つまりトークンを取り出すヘッダーなどの値です。問題は、HTTP API の場合、このキャッシュがデフォルトでそのオーソライザーを使う全ルートに共有されることです(公式ドキュメントに明記されています)。
| 項目 | 内容 |
|---|---|
| 現象 | GET /reports は許可、DELETE /users/{id} は本来拒否のはずなのに、同じトークンで連続で叩くと削除が通ってしまう。 |
| 原因 | オーソライザーが「ルートごとに違うポリシー」を返しているのに、キャッシュキーがトークンだけ。最初に /reports で生成された許可ポリシーがTTLの間、全ルートで使い回される。 |
| 確認手順 | CloudWatch でオーソライザーLambdaの呼び出し回数を見る。連続リクエストで呼び出しが1回しか増えていなければキャッシュヒット。ログに到達したルートを出して、想定と違うルートで再評価されていないか照合する。 |
| 回避 | 識別ソースに $context.routeKey を追加し、ルートごとにキャッシュを分ける。あるいはオーソライザーで「広い許可」を返さず、後段のLambda側でルートとリソースの権限を必ず再チェックする。 |
$context.routeKey を足すと、ルートごとにキャッシュが分かれるポイントを整理します。
- キャッシュTTL(
authorizerResultTtlInSeconds)の最大は3600秒(1時間)。TTLが長いほど、権限変更や失効が反映されるまで最大1時間ずれる。即時失効が要るならTTLを短く(例: 0〜60秒)する。 - TTLを0にすると毎リクエストでオーソライザーが呼ばれ、レイテンシとLambda料金が増える。「速さ」と「権限の鮮度」はトレードオフ。
- オーソライザーで
Allowを返す対象を"Resource": "*"のように広く書くと、上記のキャッシュ共有と相まって他APIまで通る危険がある。返すポリシーのリソースは必要最小に絞る。
最終的な認可は処理側のLambdaでも持つのが安全側の設計です。
Lambdaの前段で何をしているのか
ここで改めて、API Gatewayが入口で担う役割を整理します。
役割1
リクエストの受付とルーティング
外部からのHTTPリクエストを受け、GET /users はこの統合、POST /orders はこの統合、のようにパスとメソッドで振り分けます。Lambdaにいちいちルーティングを書かせず、入口側で整理できます。
役割2
認証とアクセス制御
IAMポリシー、Lambda authorizer、HTTP APIならJWTオーソライザー、REST APIならAPI keyと、入口側で認証を持てます。Lambdaのコードだけで守るのではなく、手前で弾ける点が価値です。
役割3
スロットリングと保護
スロットリング(流量制限)、CORS 対応、REST APIならWAF直結など、入口として必要な保護を一括で持てます。バックエンドが過負荷で落ちる前に、入口で受け方を整えられます。
役割4
監視
CloudWatch のログ・メトリクス、CloudTrail での変更追跡で、入口視点の運用が可能です。Lambdaのログだけ見ていると、認証で弾かれたのか到達前に落ちたのかが切り分けにくくなります。
API Gatewayがやや重く感じる場面
何でもAPI Gatewayが最適とは限りません。
呼び出し元がAWS内部の別リソースだけ
Lambda Function URL + IAM の方が安くシンプル
ALBにLambdaターゲットを足す方が入口が1つにまとまる
API管理機能(キー配布・検証・キャッシュ)をほぼ使わない
HTTP APIで十分、あるいはFunction URL
29秒を超える長時間処理
既定の統合タイムアウト(REST 29秒・HTTP 30秒)に当たる
API Gatewayは便利ですが、「AWSでAPIっぽいものは全部これ」と決め打ちしない方が安全です。
API Gatewayに関するよくある質問
Q. 最初に選ぶのは HTTP API と REST API のどちら？
A. 「APIキー配布・Usage Planによる従量課金・リクエスト検証・WAF直結・プライベートエンドポイント・キャッシュ・レスポンスストリーミング」のどれかが要るならREST API。それらが不要で、JWT認証・低料金を重視するならHTTP API。迷ったらHTTP APIで始め、REST固定機能が出てきたら作り直す前提で。
Q. Lambda Function URL ではダメなのですか？
A. 呼び出し元がAWS内部だけ(IAM認証で十分)で、WAF・カスタムドメイン・APIキーが不要なら Function URL が最小・最安です。逆に、ブラウザから公開する・WAFを付ける・カスタムドメインを使う・キーを配るなら API Gateway を選びます。
Q. ALB との違いは？
A. ALBはEC2/ECS向けの汎用ロードバランサーで、Cognito連携やWAFも使えます。すでにALB配下のサービスがあるならLambdaターゲットを足す方が楽です。API管理機能(キー・Usage Plan・リクエスト検証・キャッシュ)が標準装備な点はAPI Gatewayが有利です。
Q. 料金はどれくらい？
A. バージニア北部では受信100万リクエストあたりHTTP APIが $1.00、REST APIが $3.50(東京は $1.29 と $4.25)。月300万リクエストならバージニア北部でHTTP API 約 $3、REST API 約 $10.5(リクエスト分のみ)。データ転送、REST APIのキャッシュ(0.5GBでバージニア北部 約 $0.02/時、東京 約 $0.028/時)は別途。無料枠は料金ページでは月100万件(最大12か月)と案内されていますが、2025年7月15日以降の新規アカウントはクレジット制なので請求コンソールで確認してください。
Q. Lambda authorizer のキャッシュで権限が混ざるのはなぜ？
A. キャッシュキーが識別ソース(トークンなど)だけで、デフォルトでAPI内の全ルート共有のためです。ルートごとに違う権限を返すなら、識別ソースに $context.routeKey を足してルート別キャッシュにします。TTL最大は3600秒で、長いほど失効反映が遅れます。
Q. CORS 対応はどうする？
A. HTTP APIなら設定で許可オリジン・ヘッダー・メソッドを指定するだけでプリフライト(OPTIONS)も自動応答します。REST APIは手動でOPTIONSメソッドとヘッダーを組む場面が多く、Lambda側で返すパターンもあります。
Q. WebSocket やオンプレ連携もできますか？
A. WebSocket APIでチャットやリアルタイム通知のサーバーレス構成が組めます。オンプレやプライベートな ECS/EC2へは VPC Link 経由で内部のALB/NLBに接続でき、API Gatewayを「公開フロント + 既存サービスのプロキシ」として使えます。
まとめ
API Gateway は、Lambdaの前でHTTPリクエストを受ける入口です。ただし入口の選択肢は Function URL・API Gateway・ALB の3つあり、まず入口を何にするかを選定フローで決めるのが先です。
API Gatewayに決めたら、次はHTTP API と REST APIの分岐。API key・Usage Plan・リクエスト検証・WAF直結が要るならREST固定です。認証を Lambda authorizer で組むなら、キャッシュが全ルート共有である点を理解し、$context.routeKey とポリシーの最小化で守る。この3つを押さえると、サーバーレス構成の入口設計がぐっと事故になりにくくなります。
この順で読むとつながりやすい
- AWSで最初に覚えたい基本用語まとめ｜EC2・IAM・S3・VPCのつながりを整理
- Lambda
- このAPI Gateway記事
- REST API
- 認証(JWT・IAM)やスロットリング、Webhook設計
参考リンク
- AWS Docs: What is Amazon API Gateway?
- AWS Docs: Choose between REST APIs and HTTP APIs
- AWS Docs: Usage plans and API keys for REST APIs
- AWS Docs: Control access to HTTP APIs with Lambda authorizers
- AWS Docs: Amazon API Gateway pricing
- AWS Docs: Lambda function URLs
- AWS Docs: Creating and managing Lambda function URLs
- AWS Docs: Quotas for configuring and running a REST API
- AWS Docs: Quotas for configuring and running an HTTP API
- AWS Billing: Explore AWS services with AWS Free Tier