まとめ
Next.jsのデプロイ先としてVercelとAmplify Gen 2を比べるとき、単純なホスティング比較にすると判断を誤りやすい。
VercelはNext.jsを気持ちよく動かすための環境で、Amplify Gen 2はAWSバックエンド込みのアプリを組み立てるための環境だ。
見方を変えると、判断軸はかなり単純になる。
Next.jsを主役にするならVercel、AWSフルスタックを主役にするならAmplify Gen 2である。
Amplify Gen 2は便利だが、VercelのAWS版ではない。
Next.jsの実行基盤としてはAmplify Hosting computeの制約が残るため、On-Demand ISR、Edge API Routes、Streaming、SSR build outputの上限、ビルド分課金などを先に見ておく必要がある。
二つのサービスは同じ土俵に見えて、主語が違う
Vercelの主語はNext.jsである。
App Router、ISR、Streaming、Edge、Preview Deploy、画像最適化といったNext.jsの機能を、できるだけ考えずに使えるようにする。
フロントエンド中心のチームが、プロダクトを素早く出すための道具としてよくできている。
Amplify Gen 2の主語はAWSアプリケーションである。
TypeScriptで認証、データ、ストレージ、関数を定義し、Cognito、AppSync、DynamoDB、S3、Lambdaなどをまとめて扱う。
Next.jsはその上に載るフロントエンド、あるいはフルスタックUIとして位置づく。
この違いを外すと、「AmplifyはVercelより安そうだからNext.jsを載せる」という見方になる。
その判断は少し危ない。
| 観点 | Vercel | Amplify Gen 2 + Hosting |
|---|---|---|
| 主役 | Next.js | AWSフルスタックアプリ |
| 得意なこと | Next.jsの実行とPreview Deploy | AWSリソース込みの開発体験 |
| バックエンド | Vercel Functionsや外部サービス連携 | Cognito、AppSync、DynamoDB、S3、Lambda |
| 運用感 | PaaSに寄せる | AWSアカウント内で管理する |
| 向くチーム | Webプロダクト開発 | AWS標準基盤を前提にする開発 |
Amplify Gen 2は、AWSを直接組むよりかなり楽にしてくれる。
ただし、それはAWSの複雑さが消えるという意味ではない。
AWSの請求、IAM、リージョン、監視、各サービスの制約は、抽象化された形で残る。
Next.jsの機能を使うほど、Vercelとの差が出る
軽いSSG中心のサイトなら、Amplify Hostingでも十分に動く。
Next.js 12から15のSSR、SSG、ISR、API Routes、App Router、Image Optimizationなどは公式にサポートされている。
問題は、Next.jsを「最近のNext.jsらしく」使い込む場合だ。
App Router以降の機能には、ホスティング基盤との相性が強く出る。
| Next.js機能 | Vercel | Amplify Hosting |
|---|---|---|
| SSR / SSG | 強い | 対応 |
| ISR | 強い | 対応 |
| On-Demand ISR | 強い | 非対応 |
| App Router | 強い | 対応 |
| API Routes / Route Handlers | 強い | 対応。ただし制約に注意 |
| Edge API Routes | 強い | 非対応 |
| Middleware | 強い | 対応範囲に注意 |
| Streaming | 強い | 非対応 |
| Image Optimization | 強い | 対応。ただし出力サイズ制限あり |
| Preview Deploy | 非常に強い | あり |
特にCMS連携のメディアや管理画面では、On-Demand ISRが欲しくなる。
AI系のUIではStreamingが欲しくなる。
認証や地域判定ではEdge寄りの処理を使いたくなる。
このあたりを素直に使いたいなら、Vercelを選ぶ理由はかなり強い。
Amplifyを選ぶ場合は、使わない機能を先に決めることになる。
もう一つの差はサイズ制約だ。
Amplify HostingのSSRアプリでは、公式トラブルシュート上、SSR build outputの上限として220MBが示されている。
Prisma、Playwright、PDF生成、画像処理、monorepo由来の重い依存が入ると、アプリ本体よりもデプロイ成果物が先に太る。
| Amplifyで詰まりやすい要素 | 起きること |
|---|---|
| 重いサーバー側依存 | SSR build outputが膨らむ |
| monorepo | 不要なファイルや依存を巻き込みやすい |
| PDFや画像生成 | レスポンスサイズや実行環境の制約に当たりやすい |
| Streaming前提のUI | Amplify側の未対応に当たる |
| On-Demand ISR前提のCMS | 更新設計を変える必要がある |
Vercelにも制約や料金はある。
ただ、Next.js側の自然な設計とホスティング側の期待がずれにくい。
Amplify Gen 2を選ぶ理由は、AWSバックエンドにある
Amplify Gen 2が強いのは、Next.jsホスティング単体ではなく、AWSバックエンドをアプリ開発者の手元に引き寄せる点だ。
認証はCognito、データはAppSyncとDynamoDB、ファイルはS3、必要に応じてLambda。
これらをTypeScriptで定義し、開発者ごとのsandboxやブランチごとの環境として扱える。
この体験は、Vercelにはそのまま存在しない。
| やりたいこと | Amplify Gen 2が向く理由 |
|---|---|
| Cognito認証を使う | 認証とフロントの接続が自然 |
| AppSync / DynamoDBを使う | データモデルとAPIをまとめて扱える |
| S3にファイルを置く | 権限込みで構成しやすい |
| 開発者ごとのAWS環境がほしい | sandboxを使える |
| 社内のAWS統制に乗せたい | 請求、IAM、監査をAWS側に寄せられる |
| チーム人数が多い | Vercelのseat課金より有利になる場合がある |
この構成では、Next.jsはAWSアプリのUIである。
主役はAWS側のデータ、認証、権限、運用だ。
逆に、Next.jsが主役のプロダクトでAmplifyを選ぶなら、次の問いに答えた方がよい。
- On-Demand ISRを使わない設計でよいか
- Streamingを使わない設計でよいか
- Edge API Routesを使わない設計でよいか
- SSR build outputが220MBを超えない見込みがあるか
- PR Previewやブランチデプロイのビルド分課金を許容できるか
- 重い処理をLambda、ECS、S3、CloudFrontなどに逃がす設計を取れるか
ここに不安が多いなら、Amplify HostingをVercel代替として選ぶのは避けた方がよい。
使い分けの結論
判断表にするとこうなる。
| 状況 | 選ぶ候補 |
|---|---|
| Next.jsを素直に使いたい | Vercel |
| App Router、Streaming、ISRを重視する | Vercel |
| CMS連携メディアを作る | Vercel |
| PR Preview中心で開発する | Vercel |
| 少人数で速く出したい | Vercel |
| Cognito、AppSync、DynamoDBが主役 | Amplify Gen 2 |
| AWS請求、IAM、監査に寄せたい | Amplify Gen 2 |
| 社内AWS標準に乗せたい | Amplify Gen 2 |
| DockerでNext.jsを動かしたい | ECS系 |
| AWS上でNext.jsを分解して運用したい | SST / OpenNext |
| Amplifyのサイズ制約が不安 | Vercel、ECS、SST / OpenNextを再検討 |
Next.jsを使う理由が、Next.jsの開発体験と実行体験にあるならVercelでよい。
この判断はかなり強い。
Vercelを避ける理由がコストだけなら、Amplifyのビルド分課金、SSR実行課金、転送量、WAF、AWSバックエンド費用まで含めて試算した方がよい。
Amplify Gen 2を選ぶ理由は、AWSに寄せたいからである。
認証、データ、ストレージ、権限、環境分離をAWS内でまとめたいなら、Amplify Gen 2は有力な選択肢になる。
つまり、VercelとAmplify Gen 2の使い分けは「どちらが安いか」より先に、「何を主役にしたいか」で決めるべきだ。
Next.jsを主役にするのか。
AWSフルスタックを主役にするのか。
その問いに答えると、選択肢はかなり絞れる。