要約
| サービス名 | ざっくり表現 |
|---|---|
| CloudFormation | インフラ構成自動化サービス |
| CodePipeline | 継続的デリバリー(※)自動化サービス |
| Systems Manager | 運用自動化・統合管理サービス |
※デリバリーとは
ソフトウェアやシステムをユーザーや本番環境に届けること
（ビルド・テスト・デプロイ）
【環境構築フェーズ】 【開発フェーズ】
CloudFormation ──┬──> VPC, EC2, RDSなど構成
└──> CodePipeline（CI/CDフローで更新）
【運用フェーズ】
Systems Manager ──> パッチ当て、パラメータ管理、ログイン管理、RunCommand
| 項目 | ① CloudFormation | ② CodePipeline | ③ Systems Manager |
|---|---|---|---|
| 主目的 | インフラ（AWSリソース）の構成をコードで定義・自動構築 | アプリのビルド・テスト・デプロイなどのCI/CDパイプライン構築 | 運用タスク（設定変更、パッチ適用、コマンド実行など）の自動化・統制 |
| 人手の削減 | 環境構築の手動作業を削減 | 開発フロー（Push → Build → Deploy）の手動作業を削減 | EC2へのSSH不要・一括コマンド実行などにより、運用工数を削減 |
| 具体例 | - VPC構築 - ALB＋EC2構築 - IAM設定のコード化 |
- GitHubのPushをトリガーに自動デプロイ - 手動承認付きCD |
- EC2へRunCommandで一括コマンド実行 - SSM Parameter Storeで設定管理 |
サービスと対象レイヤー表(内包サービスが分かるように表記)
| No. | サービス名 | 対象領域 | 主な機能・役割 | 主なユースケース | 管理レイヤー | 特徴的な点 |
|---|---|---|---|---|---|---|
| 1 | CloudFormation | IaC（インフラのコード管理） | AWSリソース構成をYAML/JSONでテンプレート化し、自動で構築・変更 | VPCやEC2、RDSなどのインフラ構築をコードで一元化し、再現性を持たせた運用 | インフラレイヤー | 宣言型。依存関係解決、変更セット、ドリフト検出など多機能 |
| └─ 1.1 CDK (Cloud Development Kit) | IaC（開発者向け抽象化ツール） | CloudFormationの抽象レイヤー。TypeScript等でリソース定義 | インフラをより開発者フレンドリーに定義（クラスベース） | インフラレイヤー | CloudFormationをラップし、プログラム的に定義が可能 | |
| 2 | CodePipeline | CI/CD（自動化パイプライン） | アプリのビルド、テスト、デプロイを自動化。各フェーズを接続してパイプライン化 | Git連携から本番デプロイまでの一連の流れを自動化 | アプリレイヤー | GUI/コードでステージ定義。各種サービスと連携可 |
| └─ 2.1 CodeBuild | CI（ビルド） | ソースコードのビルド、テスト、Dockerイメージ作成などを実行 | JavaやNodeなどのアプリのユニットテストやビルドなど | アプリレイヤー | コンテナ内で任意のビルド処理を定義可能 | |
| └─ 2.2 CodeDeploy | CD（デプロイ） | EC2, Lambda, オンプレミス環境へのアプリ自動デプロイ | Blue/Greenデプロイやローリングアップデート | アプリレイヤー | フェイルセーフ、段階的デプロイ、ロールバック機能対応 | |
| 3 | Elastic Beanstalk | インフラ＋アプリ自動管理 | アプリケーションをアップロードするだけで、必要なインフラも自動構築・スケーリング | 簡易的なWebアプリホスティング、開発初期の環境構築 | 両方 | 内部でCloudFormation, EC2, AutoScaling等を使用（ブラックボックス的） |
| 4 | Systems Manager | 構成管理・運用自動化 | パッチ適用、インベントリ収集、RunCommand、State管理、オートメーションなど | セキュリティパッチの自動適用、全社的な設定変更の一斉反映 | 両方 | Hybrid環境（オンプレ・他クラウド）対応、SSM Agentによる柔軟な制御 |
| 5 | OpsWorks | 構成管理（Chef / Puppet） | EC2などの構成をChef/Puppetで管理 | サーバの中長期運用における構成管理、OSレベルでの制御 | インフラレイヤー | 現在は非推奨方向、Systems Managerに移行が進む |
関連構成の一例（流れ）
[1] CloudFormation/CDK
└─ 環境を構築（VPC, EC2, IAM等）
[2] CodePipeline
├─ [2.1] CodeBuild → ソースコードをビルド
└─ [2.2] CodeDeploy → ビルド済みアプリを本番にデプロイ
[5] Systems Manager
└─ 構成の維持、パッチ適用、運用自動化
例：シナリオ毎の推奨サービス
| シナリオ例 | 推奨サービス構成 |
|---|---|
| インフラ全体をコードで管理・展開したい | CloudFormation / CDK |
| アプリのビルド〜デプロイを自動化したい | CodePipeline + CodeBuild + CodeDeploy |
| アプリとインフラの簡易運用を1パッケージで管理したい | Elastic Beanstalk |
| 構成管理・運用の自動化を一元的に行いたい | Systems Manager（可能ならOpsWorksは回避） |
🔍 Elastic Beanstalk の立ち位置と役割
以下の疑問が出来たので「Elastic Beanstalk」を調査
アプリとインフラの簡易運用を1パッケージで管理できる「Elastic Beanstalk」があるなら、
「cloudfarmation」や「codepipeline」を使う必要がなくない？
Elastic Beanstalk（以下EB）は「PaaS的なサービス」であり、以下を抽象化して自動構築してくれます。
EC2 / Auto Scaling / ELB / S3 / CloudWatch Logs / IAMロール、RDS（任意） / CodeDeploy（内部で使用される）
実は裏で CloudFormation を使ってリソースを定義している（ただしユーザーは意識しなくて良い）
つまり、 初心者や少人数開発チームが簡単にデプロイまで可能な仕組み 。
✅ Beanstalkだけで完結するケース（= CloudFormationやCodePipelineが不要）
| 状況 | 結論 |
|---|---|
| 小規模なWebアプリで、複雑なデプロイ戦略や環境分離が不要な場合 | Beanstalk単体で十分 |
| 手軽にステージング／本番を使い分け、簡易的なCI/CDも不要な場合 | 他サービスは不要 |
❌ Beanstalk「だけでは足りない」ケース（＝CloudFormationやCodePipelineが必要）
| 状況 | 推奨される補完サービス | 理由 |
|---|---|---|
| マルチアカウント構成・セキュリティ制御の明確な設計が必要 | CloudFormation | Beanstalkでは詳細なIAM構成やVPC設計を制御しにくい |
| より高度なCI/CD（ステージ分け、承認フロー、複雑なジョブ定義）を行いたい | CodePipeline / CodeBuild | EBのデプロイは単純すぎて複雑なCI/CDには不向き |
| アプリとは別にインフラ（VPC、RDSなど）を先に細かく制御して構築したい | CloudFormation + EB | EBのRDS管理は柔軟性に乏しく、削除時に一緒に消えてしまうなどの制約あり |
| EBで管理できないリソース（DynamoDB、SQS、Lambdaなど）も含めて統合管理したい | CloudFormation | EBでは非対応のサービスも多いため、外部で管理が必要 |
まとめ
| 観点 | Beanstalkだけで完結 | 他サービスが必要な場合 |
|---|---|---|
| 開発初期・PoC | ✅ | |
| 少人数チーム | ✅ | |
| 大規模プロダクション | ❌ | ✅ CloudFormationやCodePipelineなどが必要 |
| 柔軟なCI/CD構成 | ❌ | ✅ CodePipelineなどで統制 |
| 明示的なインフラ制御 | ❌ | ✅ CloudFormationが必須 |