Vercel vs AWS ホスティング比較

【Vercel構成】
GitHub push → Vercel（自動ビルド）
  ├─ Next.js（フロント）
  ├─ API Routes / Hono
  └─ Edge Functions
         ↓
    Supabase（DB・Auth・Storage）

【AWS構成】
GitHub push → ECR（イメージ保存）
         ↓
       ECS（コンテナ実行）
         ↓
       ALB（ロードバランサー）
         ↓
       RDS（PostgreSQL）

# 環境変数の管理
NEXT_PUBLIC_SUPABASE_URL=https://xxx.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=xxx   # フロントから使う
SUPABASE_SERVICE_ROLE_KEY=xxx       # NEXT_PUBLIC_ 絶対につけない

ブランチ戦略
main               → 本番（production）
feature/xxx        → プレビューURL自動生成（制限なし）
staging（固定）    → ステージング環境として運用

# GitHub Actions（CI/CD例）
- name: Build Docker image
  run: docker build -t my-app .

- name: Push to ECR
  run: docker push $ECR_URI/my-app:latest

- name: Update ECS service
  run: aws ecs update-service --cluster my-cluster --service my-app

VPC設計
├─ パブリックサブネット → ALB（外部からアクセス可）
└─ プライベートサブネット
     ├─ ECS（外部から直接アクセス不可）
     └─ RDS（外部から直接アクセス不可）

現実的なロードマップ
フェーズ1: Vercel Hobby + Supabase Free（ほぼ無料）
フェーズ2: Vercel Pro + Supabase Pro（$45/月〜）
フェーズ3: AWS Lambda + RDS（大規模・要件複雑化したら）

Vercel（自動）
リクエスト急増 → Serverless Functionsが自動で増える
リクエスト減少 → 自動で減る（開発者は何もしない）

AWS ECS（手動設定）
{
  "minCapacity": 2,
  "maxCapacity": 10,
  "targetValue": 70.0,  // CPU使用率70%でスケールアウト
  "predefinedMetricType": "ECSServiceAverageCPUUtilization"
}

コールドスタートが起きやすい状況
  └─ 深夜・早朝など閑散時間帯の後
  └─ アクセスが少ないエンドポイント
  └─ 初回デプロイ直後

判断フロー
Next.jsを使う？
  └─ YES → Vercelを検討
Edge / Middlewareを使う？
  └─ YES → Vercel一択に近い
大規模 or コンプライアンス要件？
  └─ YES → AWS
  └─ NO  → Vercel Pro + Supabaseで十分