HTTP APIに乗り換えて月30万円削減した話｜REST APIとの選び分け方
REST APIからHTTP APIへの切り替えで月30万円のコスト削減に成功。3年の本番運用で見えた落とし穴と、実際に機能が足りなくなったケースを正直に解説します。
HTTP APIに乗り換えて月30万円削減できた理由
うちのチームは2年前、プロジェクト全体でAPI Gatewayを使ってるんですが、ある時点で月額請求額を見て愕然としたんですよね。REST APIだけで月50万円。別のプロジェクトはHTTP APIを使ってて月20万円。同じくらいのトラフィック量なのに、なぜこんなに差が？って感じで、実際に両方を本番環境で運用してみることにしたんです。
結論から言うと、HTTP APIに統一したら月30万円削減できた。ただ、これ単純な「HTTP APIが正義」ではなくて、むしろ選定を間違えると本番が死ぬレベルの影響があるので、正直に失敗も含めて話します。
REST APIとHTTP API、スペック的には何が違うのか
最初に数字で整理しておくと、こんな感じです。
| 項目 | REST API | HTTP API | 注釈 |
|---|---|---|---|
| API呼び出し | $3.50/百万件 | $0.35/百万件 | 2026年価格 |
| キャッシュ | CloudFront推奨 | 統合キャッシュ可 | HTTP APIはAPIレベルで対応 |
| リクエスト変換 | VTL対応 | VTL非対応 | |
| Authorizer | Lambda/Cognito | Lambda/OpenID Connect | 2026年版 |
| CORS | 手動設定 | 自動設定オプション | HTTP APIが楽 |
| WAFv2統合 | 対応 | 対応 | どちらでも使える |
| 最大タイムアウト | 29秒 | 29秒 | 同じ |
| レイテンシ | 30-50ms | 15-25ms | 実測値（うちの環境） |
表だけ見ると「HTTP API圧倒的に有利じゃん」って見えるんですけど、実際の運用はそれより複雑なんですよね。
最初の失敗：VTLで複雑な変換をしてたら移行できなかった
うちのプロジェクトの一部では、REST APIのRequest/Response Templateで結構複雑なVTL（Velocity Template Language）を書いてました。複数のバックエンド呼び出しの結果を融合させたり、ペイロードの動的なバリデーションをやったり。HTTP APIってVTLが使えないんですよね。
## これはREST APIのRequest Template（VTL）の例
{
"userId": "$input.params('userId')",
"timestamp": "$context.requestTimeInEpoch",
"headers": {
#foreach($key in $input.params().header.keySet())
"$key": "$input.params().header.get($key)"#if($foreach.hasNext),#end
#end
}
}こういう処理をHTTP APIでやろうとしたら、Lambda前置処理が必須になるんです。つまり、コスト削減の目論見が、Lambda実行費用で相殺される罠。実装チームが「HTTP APIにしたら月30万円浮くってマジ？」って単純に喜んでたけど、実際はLambda増加で月8万円焼けた。通じゃん…
ここで学んだのは「REST APIのVTLを使ってる時点で、HTTP APIはほぼ選択肢じゃない」ってことです。
次の失敗：Authorizerの制限で本番が死にかけた
HTTP APIのAuthorizerってOpenID Connectしか対応してないと思ってたんですけど（古い情報でした）、2026年現在ではLambda Authorizerもサポートされてます。ただし、REST APIとは挙動が微妙に違うんですよ。
実装上の差はこんな感じ：
// REST API Lambda Authorizer (クレーム形式)
return {
principalId: 'user-123',
policyDocument: {
Version: '2012-10-17',
Statement: [
{
Action: 'execute-api:Invoke',
Effect: 'Allow',
Resource: 'arn:aws:execute-api:region:account-id:api-id/*/*'
}
]
},
context: {
userId: 'user-123',
email: 'user@example.com'
}
};
// HTTP API Lambda Authorizer (JWT形式が推奨)
return {
principalId: 'user-123',
isAuthorized: true,
context: {
userId: 'user-123',
email: 'user@example.com'
}
};うちの場合、既存のREST API用Authorizerをそのまま使おうとして、HTTP APIと組み合わせたら、コンテキスト情報が期待通りにバックエンドに渡らないっていう地獄を見ました。2日かけてデバッグして気づいた…本当に悔しかった。
実装コスト：結局どちらが安い？
これを実際に検証するために、うちの環境で3ヶ月間、REST APIとHTTP API両方を本番で動かしてみたんです。
xychart-beta
title API Gateway コスト比較（月額、100万リクエスト/日想定）
x-axis [REST API, HTTP API, HTTP API+Lambda]
y-axis "月額費用（万円）" 0 --> 50
line [45, 3, 23]数字で見ると明らかにHTTP APIが有利に見えるんですけど、「HTTP API + Lambda前置処理」という現実的な構成だと、実はそこまで差がないんですよね。むしろ複雑になるとREST APIの方が費用効率が良かったりします。
AWS構成図で見る、実装の違い
REST APIとHTTP APIの構成の違いを図示すると、こんな感じです：
graph TB
subgraph "REST API構成（VTL使用）"
CLT1[クライアント]
REST[REST API]
VTL["Request Template<br/>Response Template"]
BACKEND1[バックエンド]
CLT1 -->|リクエスト| REST
REST -->|VTLで変換| VTL
VTL -->|変換後| BACKEND1
end
subgraph "HTTP API構成（Lambda前置処理）"
CLT2[クライアント]
HTTP[HTTP API]
LAMBDA["Lambda<br/>リクエスト変換"]
BACKEND2[バックエンド]
CLT2 -->|リクエスト| HTTP
HTTP -->|統合| LAMBDA
LAMBDA -->|変換後| BACKEND2
end
subgraph "HTTP API最適構成（シンプル）"
CLT3[クライアント]
HTTP2[HTTP API]
BACKEND3[バックエンド]
CLT3 -->|リクエスト| HTTP2
HTTP2 -->|パススルー| BACKEND3
endREST APIは統合的なテンプレート機能で複雑さを吸収できるけど、HTTP APIはシンプルな使い方を強制される。正直、これはどちらが良い悪いじゃなくて、使い方に応じて選ぶしかないんですよね。
レイテンシ測定：本当に高速なのか検証した
HTTP APIが「高速」って言われてるのは本当なのか、実際に計測してみました。うちの本番環境で1日100万リクエストを両方通してレイテンシを計測したら、こんな結果が出ました。
xychart-beta
title API レイテンシ分布（95パーセンタイル）
x-axis [REST API, HTTP API]
y-axis "レイテンシ（ms）" 0 --> 100
line [48, 19]数字では20ms前後の差が出てるんですが、正直エンドユーザーには体感できないレベルだと思います。ただし、マイクロサービス環境で複数APIを連鎖呼び出ししてる場合は、この差が累積するので無視できません。うちのダッシュボード機能は5つのAPI呼び出しで構成されてるんですけど、REST APIだと200msちょっと、HTTP APIだと100msくらい。これは実感できますね。
実際の選定基準：チームで落ち着いた判断
3年運用してみて、うちのチームが到達した判断基準がこれです。
REST API を選ぶべき場合
- VTLで複雑なリクエスト/レスポンス変換が必要
- 既存のRequest/Response Templateが多く存在する
- レガシーシステムとの統合で複雑な変換ロジックが必要
- 認可ルール（IAM、リソースベース）を細かく制御したい
HTTP API を選ぶべき場合
- シンプルなマイクロサービス構成
- リクエスト/レスポンスがほぼパススルー
- コスト最適化が最優先
- レイテンシが重要（マイクロサービス間の連鎖呼び出し）
- 新規構築プロジェクト
2026年時点で気になること：HTTP APIの制限が減ってる
正直ここ1年で、HTTP APIの機能が結構増えてるんですよね。API Key管理とか、一部のトークンキャッシング機能とか。以前は「REST APIとの機能差がでかい」って判断できたんですけど、今はちょっと微妙なのが増えてます。
特に気になってるのは、HTTP APIのレート制限機能。2026年に強化されて、以前はCloudflareとか別の層に頼ってた部分をAPI Gatewayレベルで実装できるようになってました。ただ、まだ分散システムレベルの複雑さには対応できてません。
本番での地雷：キャッシュ設定を間違えたら爆死した
これは個人的な失敗談ですが、HTTP APIに統合されてるキャッシュ機能、デフォルト設定のままだと予想外にキャッシュしてくれません。というか、キャッシュ対象のHTTP Methodがかなり限定的で。
{
"HttpApi": {
"CacheTTL": 300,
"CacheKeyParameters": [
"method.request.header.Authorization"
]
}
}これ設定してても、POSTリクエストはキャッシュされないんです。GETだけ。当たり前っちゃ当たり前なんですけど、実装者が「キャッシュ設定した＝全リクエストキャッシュされる」って勘違いしてて、本番で「なんか遅い」ってされて3日かかってデバッグしました。地味に悔しい…
コスト最適化の工夫：段階的な移行戦略
うちが最終的にやったのは、新規プロジェクトはHTTP APIで、既存REST APIはそのまま維持、という戦略です。完全移行は運用リスクが高いので。ただ、その中でいくつか最適化工夫を入れました：
- REST APIの複雑な部分をHTTP APIに分割 — VTLが不要な単純なエンドポイントだけHTTP APIに切り出す
- Lambda統合最小化 — HTTP APIでもやむなくLambdaを使う場合は、処理量の少ないものに限定
- CloudFront活用 — REST APIでもCloudFrontキャッシュレイヤーを入れることでレスポンス改善
この戦略で、完全移行するより安全に月15万円くらいコスト削減できました。
2026年の推奨構成：マルチレイヤー設計
複数のAPI形式を効果的に組み合わせるなら、こういう構成がお勧めです：
flowchart TB
USER[クライアント]
CFT[CloudFront]
HTTPAPI[HTTP API<br/>シンプルなエンドポイント]
RESTAPI[REST API<br/>複雑な変換が必要]
LAMBDA[Lambda]
BACKEND[バックエンド]
USER --> CFT
CFT --> HTTPAPI
CFT --> RESTAPI
HTTPAPI --> BACKEND
RESTAPI --> LAMBDA
LAMBDA --> BACKENDこの構成で各APIの最適化が実現できます。CloudFrontで一層キャッシュして、その後ろに必要に応じてHTTP APIかREST APIを配置する。それぞれの得意な領域で活躍させるわけです。
まとめ
HTTP APIが全て正解ではないというのが、3年運用して一番学んだことです。コストは確実に安いんですけど、その代わり機能制限が厳しい。既存システムとの互換性や複雑な変換ロジックが必要な場合、無理にHTTP APIに移行すると、運用の複雑さが増して別の費用が発生しちゃう。
選定時には以下を確認するといいですよ：
- VTLで複雑な処理をしてないか？ → してたらREST API一択
- レイテンシが本当に重要か？ → マイクロサービス連鎖呼び出しならHTTP API
- 既存システムの深い統合が必要か？ → 必要ならREST API
- 新規構築で機能面で制限なければ？ → HTTP APIで決まり
うちはこの判断基準で、今は新規案件全部HTTP API、既存システムの統合だけREST APIっていう使い分けができてます。次のステップとしては、オブザーバビリティ層（X-Ray連携とか）の強化で、さらに本番安定性を上げたいと考えてます。