個人開発 SaaS の AWS / Azure / GCP 移行計画 — Netlify + Supabase からのポータブル設計

この記事は約 6 分で読めます。

筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ

「個人開発でいきなり AWS にすべきか?」 — この問いに対する、運用中の SaaS 「たすきば Knowledge Relay」 の答えと、将来の AWS / Azure / GCP 移行を見据えた ポータブル設計 を整理します。

サービスの機能紹介・画面イメージ・コンセプトは公式プロダクトページをご覧ください。
👉 たすきば Knowledge Relay — 公式プロダクトページ

なぜ「最初から AWS」にしなかったか

ADR-0012 の結論:

観点	内容
MVP 期トラフィック	ほぼゼロ
AWS / Azure / GCP の無料枠	複雑、誤って課金される可能性
Netlify Personal + Supabase Free	固定費 $20/月で商用 SaaS として TOS 違反なく回せる
移行	アプリ層がポータブル設計なら将来でも遅くない

「今すぐ AWS にする必要がない」 という判断でした。

---

1. 移行トリガー

たすきばが AWS / Azure / GCP への移行を検討するのは:

トリガー 1: テナント数の閾値超え

テナント数	検討事項
200 超	Supabase のスケール限界が見え始める
1,000 超	ホスティングのコスト比較で AWS 有利になる可能性

トリガー 2: 法人テナントの要件

• 「自社の AWS 環境にデプロイしてほしい」(オンプレ要件)
• 「SOC2 Type II 認証された PaaS を使ってほしい」(コンプライアンス要件)

トリガー 3: 機能要件

• 大容量ファイル処理 (動画・添付ファイル解析等)
• リアルタイム通信 (Pusher / Ably の代替として WebSocket スケール)
• 機械学習モデルの自前ホスティング

---

2. アプリ層の移行マッピング

現行	移行先 (AWS 例)
Netlify	ECS Fargate / App Runner / Amplify
Edge Function	Lambda@Edge / CloudFront Function
Build	CodeBuild / GitHub Actions
Static asset	S3 + CloudFront

Next.js standalone build は、任意の Node.js 環境で動きます。Netlify 特有の機能 (Forms / Edge Functions) は使わない設計にしているため、移行で書き換える必要はありません。

---

3. DB 層の移行マッピング

現行	移行先
Supabase PostgreSQL	RDS PostgreSQL / Cloud SQL / Azure Database for PostgreSQL
Supabase Storage	S3 / GCS / Azure Blob
pgvector	RDS の pgvector 拡張 / Azure pgvector

Prisma を使っているため、DB 接続文字列を変えるだけで移行可能。migration ファイルは新環境で prisma migrate deploy を実行。

---

4. アプリ層をポータブルに保つ設計

これが最も重要な事前準備でした。

設計判断 1: PaaS 固有の API を使わない

Netlify Edge Functions / Vercel Edge Functions のような PaaS 特有の API は使わない。すべて 標準の Next.js Route Handler で実装。

設計判断 2: 環境変数で外部依存を切り替え可能に

// src/lib/storage.ts
export const storage = process.env.STORAGE_BACKEND === 'supabase'
  ? new SupabaseStorage()
  : new S3Storage();

ストレージ層は抽象化レイヤを通す。将来 S3 に切り替えるときは、環境変数を変えるだけで OK。

設計判断 3: embedding プロバイダも抽象化

// src/lib/embeddings.ts
export const provider: EmbeddingProvider = process.env.EMBEDDING_PROVIDER === 'voyage'
  ? new VoyageProvider()
  : new OpenAIProvider();

Voyage → OpenAI の切り替えも、設計上できる状態にしています。

---

5. DB 移行の最大の難所 — pgvector

最大の難所は DB 移行時の embedding データ。

pgvector の vector(1024) カラムは、PostgreSQL ベンダ間でフォーマット互換性があります。ただし:

確認事項	内容
pgvector 拡張のバージョン	移行先で対応バージョン確認
インデックスの種類	HNSW / IVFFlat の対応状況
vector 次元数	1024 次元の対応

移行手順

1. 移行先で pgvector 拡張を有効化 (拡張 install 権限が必要)
2. pg_dump でデータエクスポート
3. 移行先で pg_restore でインポート
4. インデックスを再構築 (CREATE INDEX ... USING hnsw)
5. アプリの DB 接続文字列を切り替え

ダウンタイムは数十分〜数時間が想定 されます。リハーサルを必ず行います。

---

6. Netlify → AWS だけでなく Azure / GCP も視野

クラウド	アプリ層	DB 層	コスト感
AWS	ECS / Lambda / Amplify	RDS PostgreSQL + pgvector	中堅
Azure	App Service / Container Apps	Azure Database for PostgreSQL	やや高い
GCP	Cloud Run	Cloud SQL PostgreSQL	やや安い

最終的にどこに移行するかは、

• 法人ユーザの希望
• 個別の課金体系
• 統合する周辺サービス

で決まります。当面は 柔軟性を保つ。

---

7. コスト試算 — 200 テナント想定

ADR-0012 内の試算:

項目	Netlify + Supabase	AWS
アプリホスティング	¥1,350 (Netlify Personal $9)	¥3,000-5,000 (ECS Fargate small)
DB	¥3,750 (Supabase Pro)	¥3,000-8,000 (RDS db.t4g.micro)
Storage	¥0 (Free 範囲内)	¥500-2,000 (S3 + 通信費)
CDN	¥0 (Netlify CDN)	¥1,000-3,000 (CloudFront)
合計	¥5,100	¥7,500-18,000

200 テナント規模なら、Netlify + Supabase Pro が圧勝。AWS は 1,000 テナント超 から比較優位になる試算。

---

8. 移行を恐れないマインドセット

「最初から完璧なインフラを選ぶ」のは個人開発では不可能です。

たすきばの三段階戦略:

段階	インフラ	コメント
MVP 期	Netlify Personal + Supabase Free	TOS 違反のない最小コスト
成長期	Netlify Personal + Supabase Pro	約 ¥5,100 / 月、200 テナント想定
拡大期	AWS / Azure / GCP	1,000 テナント超で比較優位

移行コストは、移行前提で設計することで最小化 できます。ポータブル設計を維持していれば、移行は ビジネス判断のタイミングに依存する技術問題ではなくなります。

---

おわりに

設計判断	効果
PaaS 固有 API を使わない	任意の Node.js 環境で動く
ストレージ抽象化レイヤ	環境変数で切替可能
Prisma 一本	DB 移行は接続文字列の変更
三段階戦略	MVP → 成長 → 拡大 で適切なインフラ

G 章 (インフラ・デプロイ) はここで完結。次回から H 章 (CI / テスト / 品質保証) に入ります。

本記事の移行戦略は、運用中の SaaS 「たすきば Knowledge Relay」 で実際に計画しているものです。
👉 たすきば Knowledge Relay — 公式プロダクトページ