要約

サービス名	ざっくり表現
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が必須