ADR 024: Phase 2 インフラ構成に AWS 統一 (Amplify Hosting + ECS Express Mode + Aurora Serverless v2) を採用する
- Status: Accepted
- Date: 2026-04-23
- Deciders: tao
- Technical Story: moonshot (OKR 管理 SaaS) Phase 2 のインフラ再設計
Context and Problem Statement
Section titled “Context and Problem Statement”moonshot は OKR / 目標管理の Web アプリケーションで、現在 PoC (Phase 1) フェーズにある。
Phase 1 の構成（現在）
Section titled “Phase 1 の構成（現在）”| レイヤ | 技術 | 関連 ADR |
|---|---|---|
| フロントエンド | Next.js 15 (App Router) / Vercel ホスティング | ADR 001, 006, 010, 015 |
| バックエンド API | Hono (Clean Architecture) / ECS Fargate + ALB | ADR 002, 003 |
| データベース | Aurora Serverless v2 (PostgreSQL 17 系) / VPC プライベートサブネット | ADR 003 |
| ORM / Migration | Drizzle ORM | - |
| 認証 | Clerk (外部 SaaS) | ADR 004, 007 |
| IaC | Terraform (infra/modules/{vpc,alb,ecs,aurora,ecr,github-oidc,secrets}) | ADR 003, 018 |
| CI/CD | GitHub Actions + OIDC (アクセスキーレス) | ADR 017, 018 |
| デプロイ戦略 | ECR IMMUTABLE タグ + コミット SHA / Terraform はイメージタグを管理しない | ADR 021 |
Phase 1 で顕在化した課題
Section titled “Phase 1 で顕在化した課題”-
Vercel (HTTPS) → ALB (HTTP) の Mixed Content 問題 ALB は HTTP リスナー (Port 80) のみで、独自ドメイン・ACM 証明書未取得のため、ブラウザの Mixed Content ポリシーでリクエストがブロックされた。暫定対応として Next.js rewrites による同一オリジンプロキシを導入（ADR 023）。根本解決には独自ドメイン + ACM 証明書、もしくはベンダー統一が必要。
-
ALB のセキュリティグループを
0.0.0.0/0で開放 Vercel の Outbound IP レンジが固定されないため、送信元 IP で絞れない。ADR 023 でも PoC 段階の受容リスクとして明記されている。 -
VPC・ECS・ALB・ECR の IaC 記述に工数がかかった VPC サブネット / ルーティング、ALB ターゲットグループ、ECS タスク定義と
lifecycle { ignore_changes }、ECR IMMUTABLE タグ運用（ADR 021 の障害事例）など、アプリケーション本来の検証に入る前のリードタイムが長くなった。 -
ベンダー間連携の切り分けコストが高い Vercel / AWS / Clerk と 3 ベンダー構成のため、疎通問題発生時の一次切り分けにベンダー横断の知識が必要。
Phase 2 の目的
Section titled “Phase 2 の目的”- 構築工数を削減し、アプリケーション検証に時間を割けるようにする
- ベンダーを可能な限り統一し、Phase 1 で発生した連携トラブルを構造的に解消する
- PoC の延長線上で本番運用に耐えうる構成に近づける
- 担当者 (tao) の AWS プロトタイピングエンジニアというキャリア目標と整合する
Decision Drivers
Section titled “Decision Drivers”- 構築工数の削減: Phase 1 の VPC/ALB/ECR 設定に要した時間を削減
- ベンダー統一: HTTPS / CORS / ネットワーク経路の連携トラブル解消
- 本番運用への連続性: PoC 用の簡易構成ではなく延長線上で使える構成
- キャリア目標との整合: AWS の知見を深められる構成
- 既存資産の継承: Aurora Serverless v2、Clerk、Hono Clean Architecture、Drizzle スキーマは継続利用可能であること
- 移行コスト: DB マイグレーション・認証の再実装を発生させない
Considered Options
Section titled “Considered Options”- AWS 統一: Amplify Hosting + ECS Express Mode + Aurora Serverless v2 (継続)
- Google Cloud 統一: Cloud Run (フロント/バック) + Cloud SQL for PostgreSQL
- Vercel 統一: Vercel + Vercel Functions (Hono) + Vercel Postgres (Neon)
- Cloudflare 統一: Cloudflare Pages + Workers (Hono) + Hyperdrive + 外部 PostgreSQL
Decision Outcome
Section titled “Decision Outcome”Option 1: AWS 統一 (Amplify Hosting + ECS Express Mode + Aurora Serverless v2) を採用する。
-
Phase 1 の主要課題が構造的に解消される
- フロントとバックが同一 AWS アカウント内に収まるため、Mixed Content / CORS / プロキシ (ADR 023) が不要になる
- ECS Express Mode（re:Invent 2025 発表）はコンテナイメージ + IAM ロールのみで ALB・SG・オートスケーリング・TLS 証明書・カナリアデプロイが自動構成され、Phase 1 で工数のかかった部分がほぼ不要になる想定
-
既存資産をそのまま継承できる
- Aurora Serverless v2 (PostgreSQL 17): 継続利用。移行リスクなし
- Clerk: 継続利用（ADR 004）。Amplify Hosting / ECS どちらからも利用可能
- Hono (ADR 002) / Drizzle スキーマ (
packages/db/): コード変更なし - CI/CD の OIDC 認証 (ADR 018): 継続利用
-
キャリア目標と整合 AWS プロトタイピングエンジニア業務（=素早く PoC を立ち上げる）を、AWS の最新推奨パターンで実践できる。App Runner 代替の移行期における知見は市場価値が高い。
前提事実（Phase 2 着手時点で再確認必須）
Section titled “前提事実（Phase 2 着手時点で再確認必須）”- AWS App Runner は 2026 年 4 月 30 日以降、新規顧客への提供が停止される予定。既存顧客は継続利用可だが新機能追加はない
- AWS は App Runner の後継として、re:Invent 2025 で発表された ECS Express Mode を推奨
- ECS Express Mode は ECS の機能として提供され、追加料金はかからない（ALB/ECS/CloudWatch 等の基盤リソース料金は通常通り発生）
仕様は変動する可能性があるため、Phase 2 着手時に AWS 公式ドキュメントで再確認する。
Pros and Cons of the Options
Section titled “Pros and Cons of the Options”Option 1: AWS 統一 (Amplify Hosting + ECS Express Mode + Aurora Serverless v2)
Section titled “Option 1: AWS 統一 (Amplify Hosting + ECS Express Mode + Aurora Serverless v2)”- Good: Phase 1 の課題（Mixed Content、VPC/ALB 設定、ベンダー間切り分け）が同時に解消する
- Good: Aurora / Clerk / Hono / Drizzle を継続利用でき、移行コストが最小
- Good: AWS 知見を深められ、キャリア目標と整合する
- Good: 本番運用への連続性が高い（Express Mode から通常 ECS へのフォールバック可能）
- Bad: 純粋な構築速度では Vercel / Cloudflare に劣る
- Bad: ECS Express Mode は最大 25 サービスで ALB を共有する仕様。サービス固有の WAF ルール・TLS ポリシーが必要になった場合は通常 ECS への切り替えが必要
- Bad: ECS Express Mode はリリースから日が浅く、一次情報（AWS 公式ドキュメント、re:Invent セッション）に依存する場面が出る
- Bad: Amplify Hosting の Next.js 15 (App Router) / ViewTransitions (ADR 015) / Image Optimization / Middleware 互換性は Vercel 比で挙動差の検証が必要
- Bad: Vercel 特有の Preview Deployment (PR ごとの自動デプロイ URL) は Amplify では実現方式が異なり、既存の E2E (ADR 016) のプレビュー URL 運用も見直しが必要になる可能性
Option 2: Google Cloud 統一 (Cloud Run + Cloud SQL for PostgreSQL)
Section titled “Option 2: Google Cloud 統一 (Cloud Run + Cloud SQL for PostgreSQL)”- Good: Cloud Run はシンプルで構築が速い。コンテナベースで Hono をそのまま動かせる
- Good: IAM / VPC が一貫しており、ネットワーク設計のハマりどころが少ない
- Good: リクエストベースの課金で PoC と相性が良い
- Bad: AWS キャリア目標に寄与しない
- Bad: Aurora から Cloud SQL への DB 移行コスト（論理レプリケーション or ダンプ & リストア + Drizzle マイグレーション検証）が発生
- Bad: Cloud SQL のプライベート接続には VPC コネクタが別途必要で、Cloud Run ⇔ Cloud SQL の構成が意外と重い
Option 3: Vercel 統一 (Vercel + Vercel Functions + Vercel Postgres)
Section titled “Option 3: Vercel 統一 (Vercel + Vercel Functions + Vercel Postgres)”- Good: 構築速度が最速。インフラ作業はほぼゼロ
- Good: Next.js との親和性が最高 (Preview Deployment / ISR / Image Optimization 含めフル機能)
- Good: Phase 1 の Vercel ↔ AWS 連携問題は構造的に消滅
- Bad: AWS キャリア目標に全く寄与しない
- Bad: Hono をそのまま動かすには Vercel Functions / Edge Functions へのアダプタ検証が必要（ADR 014 の Hono RPC クライアントは問題なく動作する見込み）
- Bad: Aurora → Vercel Postgres (Neon) への DB 移行コストが発生
- Bad: 長時間処理・バックグラウンドジョブ・ScheduledJob 要件に弱く、将来的な機能拡張に制約が出る
- Bad: 本番運用時のコスト予測がトラフィック次第で読みにくい
Option 4: Cloudflare 統一 (Pages + Workers + Hyperdrive + 外部 PostgreSQL)
Section titled “Option 4: Cloudflare 統一 (Pages + Workers + Hyperdrive + 外部 PostgreSQL)”- Good: Hono は Cloudflare Workers が発祥で相性が最高
- Good: エッジ配信の性能とコスト効率が高い
- Good: Hyperdrive により遠隔 PostgreSQL への接続プーリング・クエリキャッシュが利用可能
- Bad: PostgreSQL は Cloudflare 外のサービス依存（Neon / Supabase / 既存 Aurora + VPC Peering）のため、「単一ベンダー統一」にはならない
- Bad: AWS キャリア目標に寄与しない
- Bad: Next.js App Router の Workers 対応は改善中ではあるが一部制約あり（
@opennextjs/cloudflare依存、Node.js 互換性の検証が必要） - Bad: Aurora を継続利用する場合、VPC Peering / PrivateLink 等の構成が必要で「統一」のメリットが薄れる
Consequences
Section titled “Consequences”Positive
Section titled “Positive”- Mixed Content / CORS / ベンダー間切り分けコストが構造的に消滅する
- Terraform の
infra/modules/{vpc,alb,ecs,ecr}の大部分が ECS Express Mode に吸収され、IaC コード量が減る見込み - フロント/バック/DB がすべて AWS 内に収まり、運用・監視（CloudWatch 一元化）・課金が単純化される
- Clerk / Hono / Drizzle / Aurora はそのまま継続利用でき、アプリケーション層のコード変更は最小
Negative / Trade-offs
Section titled “Negative / Trade-offs”- 既存 ADR への影響の棚卸しが必要:
- ADR 023 (HTTPS PoC プロキシ) は撤去対象（
next.config.tsの rewrites、client.tsのclientBaseUrl分岐、/proxy(.*)public route） - ADR 021 (ECS イメージタグ戦略) は ECS Express Mode 利用時にタスク定義の管理方法が変わるため再評価が必要
- ADR 018 (GitHub Actions OIDC) の IAM ロール権限スコープを Amplify / ECS Express Mode 向けに見直しが必要
- ADR 023 (HTTPS PoC プロキシ) は撤去対象（
- ECS Express Mode の ALB 共有仕様: サービス固有の WAF / TLS ポリシー要件が出てきた場合は通常 ECS への切り替えが必要
- Express Mode はリリース直後で情報量が少なく、トラブル時に一次情報（AWS 公式ドキュメント、re:Invent セッション）に依存する
- Amplify Hosting の Next.js 完全対応の検証必須: ViewTransitions (ADR 015)、Middleware (Clerk)、Image Optimization、ISR/SSG 挙動は Vercel 比で差分が出る可能性
- Preview Deployment 運用の見直し: Vercel の PR ごとのプレビュー URL は Amplify では branch ベースで構成が異なり、E2E (ADR 016) のプレビュー URL 指定も見直しが必要
- Aurora Serverless v2 の固定費は変わらない: ADR 003 の通り、min 0.5 ACU 運用だと月額 $45〜50 の固定費。なお Aurora Serverless v2 は現在
min_capacity = 0（scale-to-zero）をサポートしており（infra/modules/aurora/variables.tfでもデフォルト 0）、Phase 2 では scale-to-zero 運用を選べばアイドル時コストを削減可能
Neutral
Section titled “Neutral”- AWS 以外のベンダー (Google Cloud / Cloudflare / Vercel) の実運用知見は、本プロジェクトでは獲得できない
More Information
Section titled “More Information”取り組み順序 (Phase 2 初期)
Section titled “取り組み順序 (Phase 2 初期)”- 現 Phase 1 インフラは維持したまま、別ワークスペースで Phase 2 インフラを並行構築
- ECR リポジトリと OIDC IAM ロール（ADR 018 既存）を流用しつつ、ECS Express Mode での起動を PoC
- Aurora Serverless v2 はそのまま利用（新規サブネット追加や SG の再設定のみ）
- Amplify Hosting で Next.js 15 をデプロイし、Preview Deployment / Image Optimization / Middleware の挙動を Vercel と比較
- ステージング環境で E2E (ADR 016) が通ることを確認
- カットオーバー（DNS or 新規ドメインで段階移行）
- ADR 023 の HTTPS プロキシ実装を撤去（
next.config.tsrewrites、client.ts分岐、middleware の/proxy(.*)） - 旧 Vercel プロジェクト・旧 ECS/ALB を削除
着手前に整理しておくべき事項
Section titled “着手前に整理しておくべき事項”- バックエンドの公開範囲: インターネット公開 / Amplify からのみアクセス可 / VPC 内 PrivateLink 経由のどれを採用するか
- Aurora Serverless v2 の ACU 下限: Phase 1 の 0.5 ACU 運用を維持するか、scale-to-zero (min=0) に切り替えるか。scale-to-zero のコールドスタートが API p95 目標（ADR 003 の Pre-mortem シナリオ B）に影響しないか検証
- IAM ロール設計: タスク実行ロール / Express Mode インフラロール / Amplify サービスロール / CI/CD ロール (ADR 018, 019) の粒度方針。ADR 019 (Deploy ロール最小権限化) が Proposed のままであるため、Phase 2 着手時に Status を確定 (Accepted / Rejected / Superseded) し、Express Mode / Amplify 向けの権限スコープへ反映する
- 環境変数とシークレット:
apps/api/の Zod 検証パターン (ADR 011) は継続。infra/modules/secrets/の Secrets Manager 統合を Express Mode でどう注入するか - Clerk の Redirect URL / CORS 許可ドメイン: Vercel URL から Amplify URL への切り替え
- ドキュメントサイト（ADR 022, Starlight）: GitHub Pages のまま運用するか、Amplify Hosting に統合するか
将来的な見直しトリガー
Section titled “将来的な見直しトリガー”以下の要件が発生した場合、本 ADR を再評価する。
- サービス個別の WAF ルール・TLS ポリシー・認証統合が必要になった場合 → 通常 ECS 構成への切り替え
- WebSocket 等で大量の長時間接続を扱う必要が出た場合 → NLB or API Gateway WebSocket API
- AWS 外のベンダー固有機能（Cloudflare のエッジ機能等）が事業要件として必要になった場合
- ECS Express Mode の AWS 側仕様変更・非推奨化
- AWS App Runner availability change
- re:Invent 2025 CNS379 - Launch web applications in seconds with Amazon ECS Express Mode
- ADR 003: インフラの AWS 一元管理 (ECS Fargate + Aurora)
- ADR 004: Clerk 認証基盤
- ADR 018: GitHub Actions OIDC による AWS 認証
- ADR 021: ECS タスク定義のイメージタグ管理戦略
- ADR 023: PoC 段階における Vercel から ECS API への HTTPS 通信方針
- MADR Template