Next.jsには3つのレンダリングモードがあり、それぞれ必要なインフラが異なる。
| モード | タイミング | 必要なインフラ |
|---|---|---|
| SSG（静的生成） | ビルド時にHTML生成 | S3だけでOK |
| SSR（サーバー描画） | リクエストのたびに処理 | 常時起動サーバーが必要 |
| ISR（増分再生成） | 一定時間ごとに再生成 | キャッシュ管理の仕組みが必要 |
Next.js + Hono + Supabase の場合：
フロント (Next.js)
├── Server Components → SSRが必要 → サーバーが要る
├── API Routes / Hono → Node.jsサーバーが要る
└── 静的ファイル (CSS等) → S3に置けばOK
💡 ポイント: 「Next.jsアプリ全体をそのままS3に置く」だけでは動かない。SSRを使う場合は必ずサーバーが必要。
| 方法 | 難易度 | コスト | 柔軟性 | SSR対応 |
|---|---|---|---|---|
| ECS (Fargate) | 高 | 中〜高 | ◎ | ◎ |
| Amplify | 低 | 低〜中 | △ | ◎ |
| EC2 | 最高 | 中 | ◎ | ◎ |
| Lambda + CloudFront | 中 | 低 | △ | △ |
ECS で Next.js をデプロイするイメージ：
1. Next.jsアプリを Dockerfile でコンテナ化
↓
2. ECR（コンテナレジストリ）にプッシュ
↓
3. ECS（Fargate）でコンテナを常時起動
↓
4. ALB（ロードバランサー）経由でアクセス
💡 ポイント: Lambda は実行時間制限（デフォルト29秒）とコールドスタート問題があるため、重いSSR処理には不向き。
| 比較軸 | Vercel | AWS |
|---|---|---|
| 設計思想 | Next.js専用最適化 | 汎用インフラ |
| 設定量 | ほぼゼロ | 自分で構成が必要 |
| ISR対応 | ゼロ設定で動く | 自前でキャッシュ構築が必要 |
| スケーリング | 自動 | 設定次第 |
| 無料枠 | あり | 従量課金 |
【Vercel の場合】
1. GitHubと連携
2. リポジトリ選択
3. Deploy ボタンを押す
→ 完了 🎉
【AWS ECS の場合】
1. Dockerfileを書く
2. ECRにプッシュする設定
3. ECSタスク定義を書く
4. Fargateクラスター作成
5. ALBの設定
6. セキュリティグループの設定
7. 独自ドメイン・SSL証明書の設定
→ 完了（数時間〜数日）
💡 ポイント: VercelはNext.jsの開発元が作ったサービス。ISR・Edge機能がゼロ設定で使える点が最大の強み。
Next.jsアプリをデプロイしたい
│
▼
AWSを使わないといけない縛りがあるか？
│
┌─┴─┐
No Yes
│ │
▼ ▼
Vercel SSRを使うか？
一択 ✅ │
┌─┴─┐
Yes No
│ │
▼ ▼
管理したくない S3 + CloudFront
│ で完結 ✅
┌─┴──┐
Yes No
│ │
▼ ▼
Amplify ECS(Fargate)
✅ ✅
💡 ポイント: Next.js + Vercel の組み合わせは個人開発・スタートアップ初期のベストプラクティス。AWSを選ぶ明確な理由がない限りVercel推奨。
| ミス | 改善策 |
|---|---|
| SSRアプリをS3だけにデプロイしようとする | SSRにはサーバーが必要。ECS・Amplify等を使う |
| LambdaでSSRを動かして遅延が発生する | コールドスタート問題を考慮してECSに切り替える |
| AWS縛りがないのにECSを選んで工数を使う | 縛りがなければVercel一択で良い |
| AmplifyとHonoを併用して役割が被る | HonoをメインにするならSupabase + Vercelの方がシンプル |
- 現在の構成（Next.js + Hono + Supabase + Vercel）は個人開発フェーズのベストプラクティス
- AWS ECSの経験があるため、将来的にAWSへ移行する場合はECS Fargateが最有力候補
- ISRをAWSで再現するのはかなり手間がかかるため、ISRを多用する場合はVercelを維持する理由になる