ローンチのときは、Vercelが最高でした。git push するだけでデプロイが終わり、プレビュー環境も勝手に立ち上がる。インフラのことを考えずに、機能開発に集中できました。
でも、利用が伸びてきた今。月の請求額を見るたびに「このまま Vercel で良いのだろうか」と、ふとよぎる。AWS に移せばもっと安くなるんじゃないか――。
同じ悩みを、技術決裁者の方からよく伺います。
先にこの記事の立場をお伝えします。これは乗り換えを勧める記事ではありません。むしろ、調べていくと「今の Vercel で十分なケース」がかなり多い。煽らず、判断軸だけを中立にお渡しします。
対象は、Next.js を Vercel で運用中で、規模拡大・コスト・要件（コンプライアンス等）から AWS を検討し始めた、情シス・技術決裁者・内製組織の方です。
結論を先に言うと、判断軸は次の4つです。
- コスト
- 運用負荷
- コンプライアンス・要件
- チーム体制
順番に見ていきます。
なぜ今、Vercel か AWS かが話題になるのか
理由はシンプルで、Next.js を採用する中小企業が増え、最初の立ち上げ先として Vercel を選ぶケースが定番になったからです。その先に「スケールしてきたら？」という次の問いが、自然と生まれています。
ここで一つ、大事な前提を共有させてください。
実は Vercel の基盤は、主に AWS の上で動いています（2026年5月時点・Vercel 公式のコンプライアンス情報）。20リージョン・126の配信拠点（PoP）を持つネットワークも、その上に構築されています。
つまり「Vercel 対 AWS」は、敵同士の二者択一ではありません。Vercel は AWS をマネージド（運用代行込み）で包んだ層、という関係です。
ですから本当の問いは、こう置き換えられます。
AWS の上を自分たちで組むか、Vercel に任せるか。
これは優劣の対立ではなく、運用責任をどこまで自分で持つかの線引きの問題です。この視点を持っておくと、以降の判断がぶれません。
まず大前提：Vercel は「悪者」ではない
請求額だけを見て「高い＝損」と判断するのは、少し早いです。Vercel が裏で肩代わりしてくれている仕事を、セットで見る必要があります。
Vercel が解決してくれていること：
git pushだけでデプロイが完結する- プルリクごとにプレビュー環境が自動で立つ
- CDN・画像最適化・エッジ配信が、設定ほぼゼロで動く
- SSL 更新・スケーリング・ロールバックも自動
さらに、Next.js を作っているのは Vercel 社です。そのため App Router など Next.js の新機能への追従が速いという、素直なメリットがあります。
「インフラ専任を置いていない、あるいは置きたくない」チームにとって、これらを肩代わりしてもらえる価値は、料金の額面以上に大きいことが多いです。
なお「Vercel は高い」という評判には注意が必要です。Vercel は 2024年に帯域単価を 1GBあたり $0.40 から $0.15 へ引き下げています（2026年6月時点・出典あり）。古い評判のまま判断すると、現状とずれます。
判断軸1：コスト──「月額」ではなく「合計コスト」で見る
よくある誤解は、Vercel の請求額と「AWS ならこれくらいで済むはず」の見積もりを、単純比較してしまうことです。
ここには見落としがちな隠れコストがあります。
Vercel 側で効いてくるのはどこか
Vercel Pro は 1シート $20/月のシート課金で、各 Pro チームに月 $20 の利用クレジットが付きます（2026年5月時点・公式料金ページ）。ただし実コストは、ここに従量課金が積み上がる構造です。
- 帯域（Fast Data Transfer）：東京リージョンで月1TBが込み、超過は約 $0.16/GB（2026年2月時点）
- エッジリクエスト：月1,000万件が込み、超過は100万件あたり約 $2.60（東京、同上）
- Function 実行・画像最適化・ISR の読み書き
請求の内訳を見て「どこが効いているか」を把握する習慣が、何より先です。
補足として、Vercel は2025〜26年に Fluid Compute / Active CPU 課金を導入しました。CPU が実際に動いている時間だけ課金し、I/O 待ちの間は CPU 課金が止まる仕組みです。AI 推論などアイドル時間の長い処理では、最大90%のコスト削減になりうると Vercel は説明しています（2026年6月時点・公式ブログ）。
AWS 側で乗ってくるのはどこか
一方の AWS も、EC2 や Lambda の料金だけでは終わりません。
- データ転送（egress）：CloudFront は北米・欧州で月1TB無料、その後 $0.085/GB 前後（2026年6月時点）。ただし egress は「他社比で高くつく」と指摘されやすい領域です
- 構築工数・運用人件費・学習コスト・障害対応の当番
設定次第で、本来 $1,000〜2,000/月で済む構成が $10,000/月になってしまう浪費例も報告されています（2026年6月時点・個別ケース）。
数字は変動するため、本文では断定的な金額比較はしません。比較は必ず、両者とも「合計コスト（TCO）」で、自社の実トラフィックと最新の公式単価を使って再計算してください。
ものさしとして一つだけ目安を置くなら、「インフラ費が人件費1人分に近づいてきたら、専任を置く前提で AWS も比較対象に入る」あたりです（断定ではなく目安として）。
判断軸2：運用負荷──浮いた工数を、誰が引き受けるのか
AWS に移すと、構成の自由度やチューニングの細かさが手に入ります。その引き換えに発生するのが、運用責任です。
Vercel が裏でやってくれていた仕事を、自前で持つことになります。
- スケーリング
- SSL 更新
- CDN キャッシュ
- ロールバック
- 監視・パッチ適用・IAM（アクセス権限）管理
- 障害対応の当番
ただし「AWS に移す＝全部自前」ではありません。マネージドサービスを使えば、運用負荷は抑えられます。
- AWS Amplify Hosting：フルマネージド寄り
- ECS + Fargate：コンテナ運用を任せられる
- Lambda + OpenNext：Next.js の ISR・オンデマンド再検証・ストリーミング SSR・画像最適化を AWS 上で本番サポート（2026年6月時点・OpenNext 公式）
ここにトレードオフがあります。マネージドに寄せるほど運用は楽になりますが、その分 Vercel とのコスト差は縮みます。
内製組織への現実的なアドバイスとしては、まず Vercel で運用ログ（どこが重いか）を取ること。ボトルネックが特定の機能に集中しているなら、「その部分だけ AWS に切り出す」ハイブリッドも有力です。この発想は、既存システムを作り直さずにAI化する現実的なアプローチとも通じます。一気に全部寄せる必要はありません。
なお自前ホスティングには、もう一段の難所があります。単一サーバーでの next start は簡単ですが、スケールで複数インスタンスにした途端、キャッシュ同期・オンデマンド再検証・ストリーミングの正しい動作が「機能要件」として必要になります（2026年3月時点・Next.js 公式）。Adapter API などで整備は進んでいますが、本番品質で動かす検証コストは残ります。
判断軸3：コンプライアンス・要件──ここは「コスト無関係」で決まる
コスト計算より優先される要件があります。ここに該当する場合、安いかどうかの土俵の外で結論が出ます。
たとえば、こういう要件です。
- データの保存リージョンを固定したい
- 官公庁・医療・金融系の調達要件がある
- ISMS や P マーク運用との整合が必要
- VPC（Virtual Private Cloud＝仮想的に分離された自社専用ネットワーク）内に閉じたい
- 社内システムとプライベート接続（閉域接続）したい
VPC 内に閉じたい、閉域でつなぎたい、といった要件は AWS 側が向くケースです。
一方で Vercel も、コンプライアンスにきちんと対応しています。SOC 2 Type 2、ISO 27001、PCI DSS、GDPR などに対応し、データの既定リージョンは米国ですが、顧客が東京・大阪を含む各リージョンを選択できます（2026年5月時点・公式）。
ただし境界線があります。専用の隔離環境・専用送信IP・VPC peering・閉域トンネル・データ所在の固定などが必須なら、Vercel では Enterprise プラン（Secure Compute）が前提となり、個別見積りになります。Pro では満たせません。
日本の文脈も一つ。国内データ所在を一律に義務付ける一般法は今のところありませんが、業界要件や契約で求められるケースはあります（2026年6月時点・個人情報保護委員会の整理など）。政府情報システムは原則ガバメントクラウド利用です。
ここで大切なのは、どちらが優れているかではなく「あなたの要件が、どちらの土俵か」という問いに置き換えること。要件で決まる場合は、コスト比較の前に、満たすべき条件の棚卸しに立ち戻ってください。
判断軸4：チーム体制──「運用できる人がいるか」が最後の決め手
技術的に可能でも、運用する人がいなければ移行は失敗します。AWS は、チームに求められるスキルセットの前提が変わります。
参考までに、AWS スキルを持つ DevOps エンジニアの平均給与は、米国で約 $115,000/年（2025年）という調査があります（2026年6月時点・出典あり）。日本の相場とは異なりますが、「マネージドで肩代わりされていた運用を、社内の誰かが引き受ける」ことの重みは共通です。
内製を進めたい組織には、こう捉えてほしいです。AWS を触れる人材の育成も、立派な投資対象です。短期のコストだけでなく「チームが何を学ぶか」という戦略と結びつけて考える。これは を地域目線で読むときの視点とも重なります。
もう一つの選択肢が、移行と運用を受託に任せ、社内は機能開発に集中する分担です。当番の負荷を AI ＋人のハイブリッド運用で軽くする発想も含めて、外に持つこともできます。
見極めのために、この質問に答えてみてください。
- 深夜の障害に、誰が対応しますか？
- AWS の請求を読める人は、社内にいますか？
- 移行中も、サービスを止められませんか？
これに迷いなく答えられるかどうかが、現実の分岐点です。
実践：判断を進めるための簡易チェックリスト
4つの軸を、行動に落とし込みます。
「今は動かさない」で良い条件
- 月額が許容範囲に収まっている
- 運用専任を置く余裕がない
- 特別なコンプライアンス要件がない
→ この場合は、Vercel のままで良いです。
「部分移行を検討」のサイン
- 特定機能だけ、帯域や実行コストが突出している
- 一部のデータだけ、リージョン要件がある
「本格移行を検討」のサイン
- インフラ費が人件費規模に到達している
- 調達要件で AWS が必須
- 運用できるチームと予算が揃っている
進め方の順番は、こうです。
- Vercel で、現状の負荷とコスト内訳を可視化する
- 要件を棚卸しする
- 小さく検証（PoC）してから移す
いきなり全面移行はしません。この「小さく始める」進め方は、AI導入をPoCから始める方法と同じ考え方です。インフラの移行判断にも、そのまま使えます。
よくある質問（FAQ）
Q1. Vercel は将来的に必ず高くなって、いずれ AWS に移すことになりますか？
いいえ。サービスの伸び方と構成次第です。多くのケースで Vercel のままが合理的で、移行が必要になるのは、帯域や実行コストが突出したとき、あるいは特定の要件が出たときに限られます（2026年6月時点の一般的傾向）。
Q2. 中途半端に両方使うのは、非効率ですか？
むしろ現実的な解になることがあります。フロントは Vercel、重い処理やデータ要件のある部分だけ AWS、というハイブリッドはよく取られる構成です。一気に寄せる必要はありません。
Q3. AWS に移すと、開発スピードは落ちますか？
何もしなければ、落ちる可能性はあります。Vercel が自動でやっていたデプロイ・プレビュー・スケーリングを、自前で再構築する必要があるためです。Amplify などのマネージドサービスや CI/CD（自動ビルド・自動デプロイの仕組み）の整備で、その差は縮められます。
まとめ：乗り換えありきではなく、「今の自分たちの土俵」を知ることから
4つの判断軸――コスト・運用負荷・コンプライアンス・チーム体制――を振り返りました。
結論はシンプルです。多くの場合、まずは Vercel で十分。移行は、要件と数字が揃ってからで良いのです。
大切なのは、金額の大小そのものではなく、各軸の意味を理解したうえで判断すること。これは、開発の費用を透明に公開するときや、ときと、同じ価値観です。
そして数字は、必ず最新の公式情報を「時点付き」で確認してください。単価は変わります。本記事の数値も、判断の入口としてお使いいただき、最終確認は自社のトラフィックで再計算するのが前提です。
私たちゼットリンカーは、Next.js のフルスクラッチ開発から、Vercel での立ち上げ・AWS への移行設計・移行後の運用まで、一緒に伴走してきました。「まだ Vercel のままで良いか」「どこから AWS を検討すべきか」を、現状のコストとチーム体制を見ながら中立に整理するご相談を承っています。乗り換えありきではなく、まず動かさない判断も含めて、無理のない範囲からご一緒できればと思います。
この記事を書いた人
株式会社ゼットリンカー