← ブログ一覧

Vercel / AWS デプロイ戦略比較：実務選定ガイド

Vercel と AWS どちらにデプロイすべきか？コスト・パフォーマンス・運用負荷を比較し、プロジェクト特性による選定基準、移行戦略、ハイブリッド構成まで実務で即使える判断材料を提供します。

#クラウド#AWS#Next.js#DevOps
Vercel / AWS デプロイ戦略比較：実務選定ガイド

Vercel / AWS デプロイ戦略比較：実務選定ガイド

「Next.js を本番環境にデプロイしたいが、Vercel と AWS どちらを選ぶべきか？」「最初は Vercel で始めたが、コストが膨らんできた」「AWS は自由度が高いが、設定が複雑すぎる」——受託開発や自社プロダクト開発の現場で、こうした悩みは絶えません。

本記事では、Vercel と AWS の特性を実務視点で比較し、プロジェクトの規模・要件・予算に応じた選定基準、段階的な移行戦略、ハイブリッド構成のパターンまでを解説します。コスト試算表・フローチャート・実装例を含む実践ガイドです。

1. Vercel と AWS の基本特性比較

1.1 提供モデルの違い

| 観点 | Vercel | AWS | |------|--------|-----| | 抽象度 | 高（PaaS） | 低〜中（IaaS / PaaS 混在） | | 対象フレームワーク | Next.js 特化（他も対応） | フレームワーク非依存 | | 初期設定 | Git 連携のみ | VPC・IAM・CloudFront など要設定 | | 運用負荷 | ほぼゼロ | インフラ管理が必要 | | カスタマイズ性 | 制限あり | 完全な自由度 | | 料金体系 | トラフィック・Function 実行時間 | リソース使用量 |

1.2 Vercel が適しているケース

  • Next.js を使った MVP / 小規模 SaaS
    フレームワークとの統合が完璧で、デプロイ後すぐに運用可能。

  • フロントエンド中心のプロジェクト
    静的サイト + API Routes 程度なら、Vercel の無料枠でも十分。

  • チームに DevOps エンジニアがいない
    インフラ設定・運用をほぼ考えなくて良い。

  • 開発速度を最優先したい
    Git push で自動デプロイ・プレビュー環境が即座に生成される。

1.3 AWS が適しているケース

  • トラフィックが多い / 予測できない
    Vercel の従量課金が高額になるケースで、AWS の方がコスト効率が良い。

  • 既存の AWS リソースと統合が必要
    RDS・S3・Lambda など、既存インフラと密接に連携する場合。

  • コンプライアンス要件が厳格
    VPC 内での閉域運用・特定リージョンへのデータ局所化が必須。

  • 複雑なバックエンド処理が多い
    長時間実行 Lambda・ECS・Step Functions など、Vercel の制約を超える処理。

2. コスト比較：実務試算例

2.1 月間 100 万 PV の Next.js アプリケーション

前提条件

  • Next.js App Router（SSR / ISR 混在）
  • API Routes で DB アクセス（1 リクエスト 50ms）
  • 画像最適化あり（月 10GB 転送）

| 項目 | Vercel（Pro） | AWS（Amplify Hosting + Lambda） | |------|---------------|--------------------------------| | ホスティング | $20/月（基本料金） | $0.15/GB（転送量のみ） | | Function 実行 | $40/月（100 GB-時） | $5/月（Lambda 実行時間） | | 画像最適化 | $50/月（10GB） | $10/月（CloudFront + S3） | | 帯域幅 | 含まれる（1TB まで） | $9/月（100GB 転送） | | 合計 | 約 $110/月 | 約 $24/月 |

差分要因

  • Vercel の画像最適化は従量課金が高い（$5/GB）
  • Function 実行時間の課金単位が異なる（Vercel: GB-時、AWS: 実行時間）

2.2 月間 10 万 PV の静的サイト + 軽い API

| 項目 | Vercel（無料枠） | AWS（S3 + CloudFront） | |------|-----------------|------------------------| | ホスティング | $0（無料枠内） | $0.50/月（S3 ストレージ） | | Function 実行 | $0（無料枠内） | $1/月（Lambda 実行） | | 帯域幅 | $0（100GB まで） | $0.85/月（CloudFront） | | 合計 | $0 | 約 $2.35/月 |

判断
トラフィックが少ない段階では、Vercel の無料枠が圧倒的に有利。AWS は設定コストの方が高い。

2.3 コスト逆転ポイント

  • 月間トラフィックが 200 万 PV を超えると AWS が有利になるケースが多い。
  • 画像最適化を多用する場合、Vercel のコストが急激に増加。
  • Function 実行時間が長い（100ms 以上）場合も AWS の方が安くなる傾向。

3. パフォーマンス比較

3.1 レスポンス速度

| 指標 | Vercel | AWS（適切に設定した場合） | |------|--------|---------------------------| | Edge Function | 超高速（グローバル分散） | CloudFront Functions で同等 | | SSR レスポンス | 50〜150ms | 60〜200ms（Lambda@Edge 利用） | | 静的アセット | CDN 配信（自動） | CloudFront で同等 | | コールドスタート | ほぼなし（最適化済み） | Lambda で発生（Next.js 重い） |

実測例（東京リージョンから）

// Vercel デプロイ
Time to First Byte (TTFB): 95ms
First Contentful Paint (FCP): 420ms

// AWS Amplify + Lambda
Time to First Byte (TTFB): 140ms
First Contentful Paint (FCP): 480ms

差分要因

  • Vercel は Next.js に特化した最適化が施されている
  • AWS は汎用インフラのため、細かいチューニングが必要

3.2 ビルド速度

| 項目 | Vercel | AWS Amplify | |------|--------|-------------| | キャッシュ | 自動・高精度 | 手動設定が必要 | | 並列ビルド | 自動（Pro 以上） | 手動設定が必要 | | 平均ビルド時間 | 2〜4 分（中規模） | 5〜8 分（中規模） |

4. 運用負荷の比較

4.1 デプロイフロー

Vercel

# 初回設定（Git 連携のみ）
vercel login
vercel link

# 以降は Git push で自動デプロイ
git push origin main
# → 本番環境に自動反映
# → プレビュー URL が PR ごとに生成

AWS（Amplify）

# 初回設定（IAM・リポジトリ連携・ビルド設定）
aws amplify create-app --name my-app
aws amplify create-branch --app-id <APP_ID> --branch-name main

# amplify.yml の設定が必要
version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: .next
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

差分要因

  • Vercel はゼロコンフィグで動作
  • AWS は amplify.yml の記述・IAM 権限設定が必須

4.2 監視・ログ

| 項目 | Vercel | AWS | |------|--------|-----| | ログ閲覧 | Dashboard で即座に確認 | CloudWatch Logs（検索が煩雑） | | エラー通知 | 自動（メール・Slack） | SNS + Lambda で自前実装 | | メトリクス | リクエスト数・Function 実行時間 | CloudWatch で詳細に取得可能 | | 分散トレーシング | なし（サードパーティ必須） | X-Ray で実装可能 |

4.3 スケーリング

  • Vercel: 自動・無制限（料金は増える）
  • AWS: Lambda の同時実行数上限・CloudFront のキャッシュ設定など要調整

5. 選定フローチャート

graph TD
    A[デプロイ先を選定] --> B{Next.js を使う?}
    B -->|Yes| C{トラフィック予測は?}
    B -->|No| Z[AWS を検討]
    C -->|月 100 万 PV 未満| D{DevOps リソースは?}
    C -->|月 100 万 PV 以上| E{既存 AWS 資産は?}
    D -->|不足| F[Vercel 推奨]
    D -->|十分| G{コスト最優先?}
    G -->|Yes| H[AWS 検討]
    G -->|No| F
    E -->|多い| H
    E -->|少ない| I{コンプライアンス要件は?}
    I -->|厳格| H
    I -->|標準| J[Vercel でも可]

判断基準まとめ

| 条件 | Vercel | AWS | |------|--------|-----| | MVP / 検証フェーズ | ◎ | △ | | 月 100 万 PV 以下 | ◎ | △ | | 月 200 万 PV 以上 | △ | ◎ | | DevOps エンジニア不在 | ◎ | × | | 既存 AWS インフラと統合 | △ | ◎ | | VPC 内での閉域運用 | × | ◎ | | 開発速度最優先 | ◎ | △ | | コスト最優先（大規模） | △ | ◎ |

6. ハイブリッド構成パターン

「Vercel か AWS か」の二者択一ではなく、両方を組み合わせることで、それぞれの強みを活かせます。

6.1 パターン 1: フロントエンドは Vercel、バックエンドは AWS

構成

[ユーザー]
   ↓
[Vercel (Next.js)]
   ↓ (API 呼び出し)
[AWS API Gateway + Lambda]
   ↓
[RDS / DynamoDB]

メリット

  • Vercel の高速デプロイ・プレビュー環境を活用
  • バックエンドは AWS で柔軟に構築（既存システムとの統合も容易）

実装例

// app/api/users/route.ts (Vercel で動作)
export async function GET() {
  // AWS の API を呼び出し
  const res = await fetch('https://api.example.com/users', {
    headers: {
      'Authorization': `Bearer ${process.env.API_TOKEN}`
    }
  });
  const data = await res.json();
  return Response.json(data);
}

注意点

  • API のレイテンシが増加（Vercel → AWS 間の通信）
  • CORS 設定が必要

6.2 パターン 2: 静的コンテンツは Vercel、動的処理は AWS

構成

[Vercel (静的ページ + ISR)]
   |
   +-- 軽い API Routes (Vercel Function)
   +-- 重い処理 (AWS Lambda 直接呼び出し)

実装例

// app/api/heavy-task/route.ts
import { LambdaClient, InvokeCommand } from '@aws-sdk/client-lambda';

const lambda = new LambdaClient({ region: 'ap-northeast-1' });

export async function POST(request: Request) {
  const body = await request.json();
  
  const command = new InvokeCommand({
    FunctionName: 'heavy-data-processing',
    Payload: JSON.stringify(body)
  });
  
  const response = await lambda.send(command);
  const result = JSON.parse(new TextDecoder().decode(response.Payload));
  
  return Response.json(result);
}

メリット

  • Vercel の Function タイムアウト（Pro: 60 秒）を回避
  • 重い処理は AWS で実行し、コストを最適化

6.3 パターン 3: 画像最適化だけ AWS に移行

Vercel の画像最適化は高額なので、CloudFront + S3 + Lambda@Edge で自前実装。

実装例

// next.config.js
module.exports = {
  images: {
    loader: 'custom',
    loaderFile: './imageLoader.ts',
  },
};

// imageLoader.ts
export default function cloudflareLoader({ src, width, quality }) {
  const params = new URLSearchParams({
    url: src,
    w: width.toString(),
    q: (quality || 75).toString(),
  });
  return `https://images.example.com/optimize?${params}`;
}

AWS 側（Lambda@Edge）

const sharp = require('sharp');
const AWS = require('aws-sdk');
const s3 = new AWS.S3();

exports.handler = async (event) => {
  const request = event.Records[0].cf.request;
  const params = new URLSearchParams(request.querystring);
  const width = parseInt(params.get('w'));
  const quality = parseInt(params.get('q'));
  
  // S3 から元画像取得 → sharp で最適化 → 返却
  const original = await s3.getObject({
    Bucket: 'my-images',
    Key: params.get('url')
  }).promise();
  
  const optimized = await sharp(original.Body)
    .resize(width)
    .jpeg({ quality })
    .toBuffer();
  
  return {
    status: '200',
    body: optimized.toString('base64'),
    bodyEncoding: 'base64',
    headers: {
      'content-type': [{ value: 'image/jpeg' }],
      'cache-control': [{ value: 'public, max-age=31536000, immutable' }]
    }
  };
};

7. Vercel から AWS への移行戦略

7.1 段階的移行の手順

フェーズ 1: 静的アセットを AWS に移行

  1. S3 バケット作成・CloudFront ディストリビューション設定
  2. next.config.js で assetPrefix 設定
module.exports = {
  assetPrefix: 'https://cdn.example.com',
};
  1. ビルド後の public / .next/static を S3 にアップロード
aws s3 sync .next/static s3://my-bucket/static --cache-control "public, max-age=31536000, immutable"

フェーズ 2: API Routes を AWS Lambda に移行

  1. API Gateway + Lambda 構築（Terraform / CDK 推奨）
  2. Vercel の環境変数に AWS API のエンドポイント追加
  3. フロントエンドから徐々に AWS API を呼び出すように変更

フェーズ 3: SSR を AWS に移行

  1. Amplify Hosting または SST (Serverless Stack) を使用
  2. Next.js の standalone ビルドを Lambda にデプロイ
// next.config.js
module.exports = {
  output: 'standalone',
};
  1. CloudFront でキャッシュ戦略を細かく設定

フェーズ 4: Vercel を完全停止

7.2 移行時のリスクと対策

| リスク | 対策 | |--------|------| | ダウンタイム | Blue-Green デプロイ・DNS 切り替えで最小化 | | パフォーマンス劣化 | 事前に負荷テスト・CloudFront 設定を最適化 | | 環境変数の漏洩 | AWS Secrets Manager で管理・IAM で厳格に制御 | | ビルド時間増加 | CodeBuild でキャッシュ戦略を実装 |

8. 実装チェックリスト

8.1 Vercel デプロイ時の必須設定

  • [ ] 環境変数を Vercel Dashboard で設定（.env.local は使わない）
  • [ ] プレビュー環境のパスワード保護（商用前）
  • [ ] カスタムドメインの設定・DNS 検証
  • [ ] 本番環境の Protection 有効化（誤デプロイ防止）
  • [ ] 画像最適化の formats 設定（WebP / AVIF）
// next.config.js
module.exports = {
  images: {
    formats: ['image/avif', 'image/webp'],
    deviceSizes: [640, 750, 828, 1080, 1200, 1920, 2048, 3840],
  },
};

8.2 AWS デプロイ時の必須設定

  • [ ] VPC・サブネット・セキュリティグループ設計
  • [ ] IAM ロールの最小権限設定
  • [ ] CloudFront の Cache Policy 設計
  • [ ] Lambda のメモリ・タイムアウト設定最適化
  • [ ] CloudWatch Logs の保持期間設定（コスト削減）
  • [ ] AWS WAF の設定（DDoS 対策）
  • [ ] Secrets Manager で機密情報管理

Terraform 例

resource "aws_cloudfront_distribution" "main" {
  enabled = true
  
  origin {
    domain_name = aws_s3_bucket.static.bucket_regional_domain_name
    origin_id   = "S3-static"
  }
  
  default_cache_behavior {
    allowed_methods  = ["GET", "HEAD", "OPTIONS"]
    cached_methods   = ["GET", "HEAD"]
    target_origin_id = "S3-static"
    
    forwarded_values {
      query_string = false
      cookies {
        forward = "none"
      }
    }
    
    viewer_protocol_policy = "redirect-to-https"
    min_ttl                = 0
    default_ttl            = 86400
    max_ttl                = 31536000
  }
}

まとめ

Vercel と AWS の選定は、「今のプロジェクトフェーズ」と「3 ヶ月後の予測」の両方を考慮する必要があります。

Vercel を選ぶべきケース

  • MVP 検証・スモールスタート
  • DevOps リソースが限られている
  • 開発速度を最優先したい
  • 月間トラフィックが 100 万 PV 以下

AWS を選ぶべきケース

  • 大規模トラフィックが見込まれる
  • 既存 AWS インフラとの統合が必要
  • コンプライアンス要件が厳格
  • 長期的なコスト最適化を重視

ハイブリッド構成を検討すべきケース

  • Vercel で始めたが、特定機能（画像最適化・重い処理）のコストが高騰
  • フロントエンドの開発速度は維持しつつ、バックエンドは柔軟に構築したい

重要なのは、**「最初から完璧を目指さない」**こと。まずは Vercel で素早く検証し、トラフィックが増えてから段階的に AWS に移行する戦略が、多くのスタートアップで有効です。

受託開発のデプロイ戦略設計でお困りですか？
Yureate では、Next.js アプリケーションの最適なデプロイ先選定から実装・移行支援までサポートしています。初回相談は無料ですので、お気軽にお問い合わせください。

この内容について相談する他の記事を見る