はじめに
AWSのAPI Gatewayを触り始めて、最初に「ん？」となったのがこれでした。REST API と HTTP API。──いや、HTTP APIだってRESTfulに叩けるじゃん、名前で区別する意味ある？と、しばらく画面の前で固まったんです（正直、命名した人を軽く恨みました）。
同じところで詰まっている人、けっこういるんじゃないでしょうか。この記事は、私がAWS + Terraformのハンズオンで引っかかったこの2つの違いを、公式ドキュメントに全部当てて整理し直した学習ログです。結論から置いておきます。
忙しい人向けの結論
- REST API も HTTP API も、どちらも「HTTPで叩くRESTfulなAPI」を作るサービス。中身は “高機能・高価な旧世代（REST API）” と “軽量・廉価な新世代（HTTP API）” の違い。
- 覚えるのは「REST APIだけが持つ高級機能」の差分だけ。それが要らなければHTTP APIで足りる。
- 迷ったらHTTP APIから。AWS自身も原則そう言っている。ただし差分は一方通行ではなく、HTTP API側だけの強みもある（後述）。
対象読者はこのあたりを想定しています。
- AWSを学習中で、API GatewayのREST/HTTPの違いが腹落ちしていない人
- DVA / SAA で「どっちを選ぶ？」系の問題を反射で解けるようにしたい人
- Terraformで
aws_apigatewayv2_*を書いていて「これHTTP APIだよな？」と確認したい人
参考
そもそも API Gateway には3種類ある
差分の話に入る前に全体像を。API Gatewayで作れるAPIは、実は3種類あります。
- REST API … 老舗・全部入り。機能がいちばん多い
- HTTP API … 新しい軽量版。今回のハンズオンで使ったのはこれ
- WebSocket API … 双方向リアルタイム通信用（チャットや通知など）。用途が別なので今回は脇に置きます
つまり、あなた（と私）が混乱している「REST API vs HTTP API」は、同じ「HTTPで叩くAPI」を作る2つの選択肢なんです。WebSocketだけは別物、と切り分けると一気に見通しがよくなります。
名前の正体 ── どっちも「RESTfulなHTTPで叩くAPI」
ここが混乱の震源地なので、公式の一文をそのまま引きます。
REST APIs and HTTP APIs are both RESTful API products.
（Choose between REST APIs and HTTP APIs より）
そう、AWS自身が「両方ともRESTfulなAPIだよ」と言っている。名前は技術的な区別というより、登場した時期と機能量で付いた歴史的なラベルだと思ってください。REST APIが老舗の全部入りモデル、HTTP APIがあとから出た必要十分な廉価モデル。この一言で腹落ちすれば、名前の紛らわしさは9割片付きます。
機能差 ── REST APIだけが持つ「高級機能」を差分で覚える
まず、共通してできることを押さえます。ここを「両方できる」と知っておくと、差分だけに集中できます。
- Lambda統合（プロキシ統合を含む）
- Lambdaオーソライザー / IAM認可 / Cognito
- CORS設定
- カスタムドメイン
- ステージ・ルート単位のスロットリング
逆に、片方にしかない機能があります。まず「REST APIだけが持つ高級機能」を覚えるのが最短ルートです。ここが要らなければHTTP APIで十分、という判断がそのままできるからです。
| 機能 | HTTP API | REST API | どんな時に要る？ |
|---|---|---|---|
| APIキー・使用量プラン | ✕ | ○ | 顧客ごとに利用量を制限・従量課金する（有料API提供） |
| レスポンスキャッシュ | ✕ | ○ | 同じ応答を使い回して高速化・バックエンド負荷を減らす |
| AWS WAF連携 | ✕ | ○ | SQLインジェクション等の攻撃からAPIを守る |
| リクエスト（ボディ）検証 | ✕ | ○ | Lambdaを呼ぶ前にAPI Gateway側で入力をチェック |
| VTLマッピングテンプレート1 | ✕ | ○ | 非プロキシ統合でリクエスト/レスポンスを変換 |
| プライベートAPI（VPC内限定） | ✕ | ○ | 社内・VPC内からのみアクセスさせる |
この6つが「REST APIだけの高級機能」。試験でも実務でも、まずこのリストが判断の起点になります。
WAFについては、少し注意が要ります。
「2025年にHTTP APIもWAF対応した」と書いている個人ブログを見かけますが、これは正確ではありません。2025年3月のAWSの発表は「REST API向けWAFの提供リージョン拡大」の話で、HTTP APIのWAF対応ではないんです。AWS公式の比較ドキュメントは、この記事を書いている時点でも「AWS WAF … HTTP API ✕」のまま。
どうしてもHTTP APIをWAFで守りたいときは、前段にCloudFrontを置いてそこにWAFを付ける、という構成になります（API Gatewayに“直接”は付けられない、が正確な理解です）。その際は、既定の execute-api エンドポイントに直接アクセスされてWAFを素通りされないよう、そのエンドポイントを無効化してカスタムドメイン経由に限定するところまでがワンセットです。
逆に、HTTP API側だけが持つ強みもある
ここが私がいちばん誤解していた点でした。「REST APIが上位互換で、HTTP APIはその廉価な劣化版」だと思い込んでいたんですが、差分は一方通行ではありません。HTTP API側にしかない武器もあります。
- ネイティブJWTオーソライザー … 汎用的なOIDC / OAuth 2.0のJWTを、Lambdaを書かずに組み込みで検証できる。REST APIにはこの汎用JWTオーソライザーが無く、Cognito以外のJWTを検証するにはLambdaオーソライザーを自作することになります（REST APIでもCognito User Poolオーソライザーなら組み込みで扱えます）
- 自動デプロイ（
$defaultステージ +auto_deploy）… ルートや統合を変えるたびに勝手にデプロイされる。REST APIは明示的なdeploymentが要ります - AWS Cloud Map とのプライベート統合
- 設計がシンプルなぶん、低レイテンシ
「JWT認可は両方できる」と雑に覚えていると、ここでズレます。組み込みのJWTオーソライザーはHTTP API固有の強み、と正確に押さえておくと後で効いてきます。
見落としがちなトレードオフ（可観測性）
安さと手軽さだけを見てHTTP APIに飛びつくと、あとで刺さる落とし穴があります。可観測性まわりがREST API寄りなんです。
- AWS X-Rayトレース … REST APIのみ
- 実行ログ（execution logs）… REST APIのみ
- ほかにエッジ最適化エンドポイント、カナリアリリース、Data Firehoseへの直接ログ出力などもREST API側
学習中の小さなAPIなら気になりませんが、「本番でリクエストをX-Rayで追いたい」となった段階で、HTTP APIだと素直には刺さらない。ここは私も整理して初めて気づいた点で、選定時のチェックポイントとして頭の隅に置いておくと安全です。
料金と “どっちから始めるか”
料金面では、同じことをするならHTTP APIのほうがリクエスト単価が大幅に安い、というのが大きな決め手になります。だからAWS自身も「特別な理由がなければHTTP APIから始めよ」というスタンスです。
具体的な金額（1リクエストあたりの単価や無料枠）は変動が激しく、記事に書くとすぐ古くなって誤情報になりがちなので、あえて数字は載せません。最新は公式の料金ページで確認してください。
まとめ
長くなったので要点を。
- REST APIもHTTP APIも「HTTPで叩くRESTfulなAPI」。違いは高機能・高価（REST）か、軽量・廉価（HTTP）か
- 覚えるのは「REST APIだけが持つ高級機能」＝APIキー / キャッシュ / WAF / リクエスト検証 / VTL / プライベートの差分だけ
- ただし一方通行ではない。JWTオーソライザーや自動デプロイはHTTP API側の強み。逆にX-Rayなど可観測性はREST API寄り
- 迷ったらHTTP APIから。上の高級機能が要るときだけREST API
これでAPI Gateway周りの前提（統合・プロキシ統合・ステージ・API種別）は一通りつながりました。次は terraform plan を実行して、学んだ概念が実際のリソース作成計画にどう現れるか答え合わせしてみる予定です。同じところで詰まった人がいたら、どこが一番しっくりこなかったか、コメントで教えてもらえると嬉しいです。
-
VTL（Velocity Template Language）は、API Gatewayがリクエスト/レスポンスを変換するときに使うテンプレート言語。プロキシ統合（丸ごとLambdaに渡す）ではなく、間で整形したいときに使います。 ↩