先に要点
先に要点
- 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年6月時点の 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)を確認して整理しています。料金や仕様は更新されるため、本番採用時は必ず最新の公式ページで確認してください。
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 が要る)。
ALB(Application Load Balancer)
すでにEC2/ECSを動かしていてLambdaも混ぜたい時に有利。Cognito連携やWAFも使える。リクエスト単位ではなく時間+LCU課金。
判断は次のフローで切るとブレません。
| 観点 | Lambda Function URL | API Gateway | ALB |
|---|---|---|---|
| 認証 | IAM か なし | JWT/Lambda authorizer/IAM/API key | OIDC/Cognito 連携 |
| WAF直結 | 不可(CloudFront経由) | 可(REST/HTTP両対応) | 可 |
| カスタムドメイン | 非対応(CloudFront併用) | 対応 | 対応 |
| タイムアウト | 最大15分(Lambda側) | 最大29秒 | 長め(設定可) |
| 課金モデル | 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直結・プライベートエンドポイント・CloudWatch へのアクセスログ詳細などは REST API 固定で、HTTP API には存在しないことです。逆にHTTP APIは新しく、JWTオーソライザー(OIDC/OAuth 2.0ネイティブ)とCORS自動化を持ち、料金が安く、レイテンシも公式・各社ベンチで1〜2割低い傾向があります。
| 機能 | HTTP API | REST API |
|---|---|---|
| 料金(受信100万リクエスト) | $1.00(初め3億件) | $3.50 |
| API key / Usage Plan(従量課金・配布) | なし | あり(REST固定) |
| リクエスト/レスポンス検証・変換(VTL) | なし | あり(REST固定) |
| WAF直結 | なし | あり(REST固定) |
| JWTオーソライザー(OIDC/OAuth2) | 組み込みあり | なし(Lambda authorizerで代替) |
| CORS自動化 | あり(設定だけ) | 手動で組む場面が多い |
| プライベートAPIエンドポイント | なし | あり |
具体的な落とし穴を1つ。「外部パートナーにAPIキーを配って、契約プランごとに月間リクエスト上限を切りたい」という要件。これは Usage Plan の機能ですが、HTTP API には存在しません。HTTP APIで作り始めてから「キー発行と従量制限が要る」と気づくと、REST APIへの作り直しになります。API keyや従量課金を売り物にするAPIなら、最初からREST APIを選ぶのが正解です。
料金の目安も押さえておきます。月300万リクエスト程度なら、HTTP APIで $3、REST APIで $10.5(いずれも月額・リクエスト分のみ)。Lambdaの実行料金やデータ転送($0.09/GB)、REST APIのキャッシュ(0.5GBで $0.02/時 ≒ 月約 $15)は別途です。無料利用枠は両タイプとも月100万リクエストが12か月分付きます。
Lambda authorizer の落とし穴(キャッシュ共有)
認証をコードに書きたくない時、Lambda authorizer(自作の認可関数)をAPI Gatewayの前に挟む構成がよく使われます。ここに実務で踏みやすい地雷があります。
API Gatewayはオーソライザーの結果をキャッシュします。キャッシュキーは「識別ソース(identity source)」、つまりトークンを取り出すヘッダーなどの値です。問題は、このキャッシュがデフォルトでAPI内の全ルートに共有されることです。
| 項目 | 内容 |
|---|---|
| 現象 | GET /reports は許可、DELETE /users/{id} は本来拒否のはずなのに、同じトークンで連続で叩くと削除が通ってしまう。 |
| 原因 | オーソライザーが「ルートごとに違うポリシー」を返しているのに、キャッシュキーがトークンだけ。最初に /reports で生成された許可ポリシーがTTLの間、全ルートで使い回される。 |
| 確認手順 | CloudWatch でオーソライザーLambdaの呼び出し回数を見る。連続リクエストで呼び出しが1回しか増えていなければキャッシュヒット。ログに到達したルートを出して、想定と違うルートで再評価されていないか照合する。 |
| 回避 | 識別ソースに $context.routeKey を追加し、ルートごとにキャッシュを分ける。あるいはオーソライザーで「広い許可」を返さず、後段のLambda側でルートとリソースの権限を必ず再チェックする。 |
ポイントを整理します。
- キャッシュ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配下でEC2/ECSを運用 → ALBにLambdaターゲットを足す方が入口が1つにまとまる
- API管理機能(キー配布・検証・キャッシュ)をほぼ使わない → HTTP APIで十分、あるいはFunction URL
- 29秒を超える長時間処理 → API Gatewayの統合タイムアウト上限に当たる
API Gatewayは便利ですが、「AWSでAPIっぽいものは全部これ」と決め打ちしない方が安全です。
API Gatewayに関するよくある質問
Q. 最初に選ぶのは HTTP API と REST API のどちら？
A. 「APIキー配布・Usage Planによる従量課金・リクエスト検証・WAF直結・プライベートエンドポイント」のどれかが要るならREST API。それらが不要で、JWT認証・CORS・低料金・低レイテンシを重視するなら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。月300万リクエストならHTTP APIで約 $3、REST APIで約 $10.5(リクエスト分のみ)。データ転送 $0.09/GB、REST APIのキャッシュ(0.5GBで約 $0.02/時)は別途。無料枠は両タイプ月100万件×12か月。
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