コンテナ（ECS/Fargate）、Lambda、S3 静的サイト の 3 つを同時に抱えるモダンなアプリを想定し、 リポジトリ／パイプラインの切り方を比較します。
※AWS Summit 2025 で得た知見を整理し、後日の PoC に備えた自分用メモです。
1. 用語と前提技術
| 項目 | 採用技術の一例 |
|---|---|
| CI/CD 基盤 | AWS CodePipeline / CodeBuild |
| IaC | AWS CDK v2（TypeScript 想定） |
| デプロイ対象 | - Amazon ECS (rolling update) - AWS Lambda (function code update) - Amazon S3 (static hosting) |
注: CDK は
aws-s3-deploymentで S3 へのアセットアップロード、
aws_lambda.Functionで Lambda コード更新、
ECS サービスのローリングアップデートを標準サポートしています。
CDK Assets 公式ページも参照ください。
2. パターン比較
A. リポジトリ／パイプラインを分割
| 観点 | 評価 |
|---|---|
| アーキテクチャ | フロント／バック／基盤をそれぞれ別リポジトリ & 別パイプライン |
| チーム体制 | フロント/バック/基盤それぞれ別チーム |
| ✅ メリット | - チーム責任範囲が明確 - 言語・フレームワークを自由に選べる - 影響範囲が限定され安全 |
| ❌ デメリット | - マイクロサービス数 × 環境数分パイプラインが増殖 - 可視化・コスト管理が煩雑 |
※IaCはTerraformやCloudFormationでも構築可能。
B. リポジトリ／パイプラインを統一
| 観点 | 評価 |
|---|---|
| アーキテクチャ | コード・IaC・パイプラインを 1 リポジトリに統合。CDK で多ターゲットを一括デプロイ |
| チーム体制 | - フルスタックエンジニアがアプリも基盤も開発 - マイクロサービス単位でチームを分割 |
| ✅ メリット | - コード & インフラの追跡が一元化 - CDK による環境コピーも容易 |
| ❌ デメリット | - 小さな修正でも全サービス再デプロイのリスク - デプロイ所要時間が長くなりがち - フルスタック人材確保が前提 |
このパイプライン構成が合いそうな例として、BedrockChatがあります。
フロント/バック/基盤がすべて同一レポジトリにあり、
CDKデプロイで本格的なRAGを１日で構築できます。
改善策: フォルダー差分を検知して 対象サービスだけ パイプラインを起動することもできますが、フォルダー検知ロジックの実装が必要です。
3. まとめ
| チーム規模 / 目的 / (条件) | 推奨パターン |
|---|---|
| 10 名以上 / コンポーネント分業 | A リポジトリ／パイプラインを分割 |
| 3–5 名 / OSS ライクな高速開発 / CDK利用可 | B リポジトリ／パイプラインを統一 |
“パイプライン数の爆発” と “全体デプロイ遅延” はトレードオフ。