はじめに
「CI/CD やコンテナ化が重要だとは聞くけれど、実際どうやって構築すればいいのか分からない…」
そんなふうに感じていませんか?
AWSの研修や社内勉強会でECSやCodePipelineという言葉を耳にしても、いざ自分で環境を構築しようとすると、ハードルが高いですよね。
そこで本記事では、CloudFormationを使って、ビルド環境からWebアプリをデプロイ可能な基盤までを自動構築する方法を紹介します。
手動設定を最小限に抑え、ECS(Fargate)+ALB+CodePipeline+CodeBuildを配備します。
セキュリティを確保しつつ、プライベートVPC内で安全に運用できるWebアプリ環境を短時間で作成できます。
具体的には、Angularで作成したWebアプリをECS上にデプロイし、ALB経由でHTTPSアクセス可能な環境を構築します。
GitHub連携によるソース取得と自動ビルド、ECRへのイメージ登録までの流れを学ぶことができます。
ECSへのデプロイを自動化したい場合は、CodeDeployを追加構成として利用できます。
CI/CDやコンテナ化を実際に動かしてみて実践できるようにしましょう!
環境構成
以下の構成図のように、VPC内部で完結するWebアプリ基盤を構築します。
ALB(Application Load Balancer)は internal モードで動作し、ECS(Fargate) タスクへトラフィックをルーティングします。
ここでは“CI”部分(ビルド・イメージ作成・ECR登録)を自動化しており、“CD”部分(ECSへのデプロイ)はCodeDeployで拡張できます。
ECSサービスへのデプロイはこのテンプレートでは自動実行されませんが、後からCodeDeployを追加することで自動デプロイまで拡張可能です。

費用
以下は 1 時間あたりのおおよその料金目安です(東京リージョン / 2025年11月時点)。
| サービス | 構成 | 料金(1時間あたり) | 備考 |
|---|---|---|---|
| ECS (Fargate) | vCPU 0.25 / 0.5GB x 2 | 約 0.03 USD | 常時稼働2タスク想定 |
| ALB (internal) | 1台 | 約 0.02 USD | リスナー1ポート構成 |
| ECR | 1リポジトリ | 約 0.01 USD | 保持は3イメージまで |
| CodeBuild | ビルド時のみ | 約 0.01 USD | 実行時間1分×2回 |
| S3, Logs, Endpoints | 軽量利用 | 約 0.01 USD | 合計目安 |
| EC2 | 1台(動作確認用) | 約 0.05 USD | 1時間利用 |
合計:約 0.13 USD / 時間(約 20 円 / 時間)
各リソースの説明
CI/CD関連
CodePipeline
アプリケーションのビルドからデプロイまでの流れを自動化します。 GitHubからのソース取得をトリガーとして、CodeBuildによるビルド、ECRへのDockerイメージ登録を順番に実行します。
今回はデプロイの自動化は対象外にしていますが、CodeDeployを組み合わせることでECSへのデプロイの自動化も可能です。
CodeBuild
AngularアプリのビルドおよびDockerイメージの作成を担当します。 buildspec.yaml にビルド手順を定義し、イメージをECRにプッシュします。
ECR(Elastic Container Registry)
Dockerイメージを保存するプライベートレジストリです。 この環境では、最新の3イメージのみを保持するライフサイクルポリシーを適用しています。
コンテナ関連
ECS(Elastic Container Service)
Angularアプリを実行するコンテナ基盤です。 Fargateを利用するため、EC2インスタンスの管理は不要です。 CodePipelineによってECRへ新しいイメージを登録できます。
ECSへのデプロイは本記事の範囲外ですが、将来的にCodeDeployを組み合わせることで、自動デプロイに拡張できます。
ALB(Application Load Balancer)
内部トラフィック専用(internal)として構成され、HTTPS(443)でアクセスを受け付けます。 ALBはECSのターゲットグループにトラフィックをルーティングし、ヘルスチェックにより正常なタスクへ自動分散します。
事前準備
CloudFormationテンプレートを実行する前に、以下の3点を準備しておきましょう。
- Angularアプリを格納したGitHubリポジトリの作成(本記事で利用するリポジトリにサンプルアプリケーションが入っています)
- CodeStar Connections で GitHub 接続を設定し、ARN を取得
- HTTPS通信に使用する ACM 証明書の発行(ALB用)
CloudFormationでリソース配備
リポジトリのクローン
GitHubリポジトリをローカル環境にクローンし、CloudFormationテンプレートおよびスクリプトを確認します。
git clone https://github.com/TeTeTe-Jack/aws-handson-ecs-nginx-cicd.git
cd aws-handson-ecs-nginx-cicd
パイプラインの配備
pipeline.yaml を使用して、CodePipeline・CodeBuild・ECRなどのCIリソースを構築します。
参考:CloudFormationの実行方法を参考にCloudFormationのスタックを作成してください。
利用するパラメタは以下です。
| パラメタ | 参考値 | 説明 |
|---|---|---|
| SystemName | demo | プロジェクト名 各リソースのプレフィックスとして扱われます。 |
| Environment | dev/stg/prod | 配備環境 開発/ステージング/本番の用途に合わせてご利用ください。 |
| GitHubConnectionArn | arn:aws:codeconnections:**** | CodeConnectionsのARN |
| GitHubFullRepositoryId | *****/***** | GitHubのリポジトリ |
| GitHubBranch | main | 利用するブランチ |
| BuildComputeType | BUILD_GENERAL1_SMALL | CodeBuildで利用するEC2 最小リソースを指定 |
| BuildImage | aws/codebuild/amazonlinux-x86_64-standard:5.0 | CodeBuildで利用する サーバのイメージ |
| EcrRepoName | demo-nginx-html | ECRのリポジトリ名 |
| ArtifactBucketName | <指定なし> | ビルド時のArtifact格納先バケット 指定しない場合は自動作成 |
配備が完了したら、CodePipelineのサービスメニューを開きます。

パイプラインが作成されています。クリックしてください。

パイプラインが成功していることを確認してください。

パイプラインで作成されたイメージのURIを取得します。
Elastic Container Registory(ECR)のサービスメニューを開きます。

作成されたリポジトリを選択してください。

イメージを選択してください。

「URI」をメモしてください。

サービスの配備
service.yaml を利用して、VPC・ECS・ALBなどの本番基盤を配備します。
参考:CloudFormationの実行方法を参考にCloudFormationのスタックを作成してください。
利用するパラメタは以下です。
| パラメタ | 参考値 | 説明 |
|---|---|---|
| SystemName | demo | プロジェクト名 各リソースのプレフィックスとして扱われます。 |
| Environment | dev/stg/prod | 配備環境 開発/ステージング/本番の用途に合わせてご利用ください。 |
| VpcCidr | 10.0.0.0/16 | VPCのCIDR |
| PrivateSubnet1Cidr | 10.0.10.0/24 | Subnet1のCIDR |
| PrivateSubnet2Cidr | 10.0.11.0/24 | Subnet2のCIDR |
| ContainerPort | 80 | コンテナのポート |
| DesiredCount | 2 | コンテナの起動数 |
| TaskCpu | 0.25 | コンテナのCPU |
| TaskMemory | 512 | コンテナのメモリ |
| HealthCheckPath | /healthz | ALB→コンテナのヘルスチェックパス |
| AcmCertificateArn | arn:aws:acm:********* | ACMで管理している証明書のARN |
| AlbSslPolicy | ELBSecurityPolicy-TLS13-1-2-Res-2021-06 | ALBのSSLポリシー |
| PrivateHostedZoneName | internal.demo.local | プライベートホストゾーンの名前 |
| DnsRecordName | app | アプリケーションのレコード名 |
| AppImageUri | 123456789012.dkr.ecr.****** | ECRのイメージURI |
スタックが正常に配備されるとサービスが利用可能な状態になっています。
動作確認用のサーバ配備
CloudFormationの winserv.yaml を実行して、Windows Server 2025 検証インスタンスを起動します。 このサーバはVPC内のECSタスクへアクセスできるため、接続確認に利用します。
参考:CloudFormationの実行方法を参考にCloudFormationのスタックを作成してください。
利用するパラメタは以下です。
| パラメタ | 参考値 | 説明 |
|---|---|---|
| SystemName | demo | プロジェクト名 各リソースのプレフィックスとして扱われます。 |
| Environment | dev/stg/prod | 配備環境 開発/ステージング/本番の用途に合わせてご利用ください。 |
| VpcId | vpc-*********** | VPC ID 管理コンソールを利用する場合は、 ドロップダウンリストが表示されます。 |
| SubnetId | subnet-************* | サブネットID 管理コンソールを利用する場合は、 ドロップダウンリストが表示されます。 |
| InstanceType | t3.small | EC2インスタンスの インスタンスタイプ |
| VolumeSizeGiB | 30 | EC2インスタンスにアタッチする ボリュームサイズ(GB) |
| KeyName | keypair名 | EC2インスタンスの キーペア名 |
| CreateSsmEndpoints | demo-nginx-html | ECRのリポジトリ名 |
| ArtifactBucketName | true | SSM関連のエンドポイントを 作成する場合はtrue 作成しない場合はfalse |
スタックを正常に配備されてから少し経つとフリートマネージャーからリモートデスクトップ接続ができるようになります。
Fleet Managerのサービスメニューを開きます。

配備したWindowsサーバが表示されます。接続するノードを選択します。

「ノードアクション」>「接続」>「リモートデスクトップ接続」を順番に選択します。

指定されたキーペアでリモートデスクトップ接続をします。

リモートデスクトップ接続ができます。

参考:CloudFormationの実行方法
管理コンソールから実行する場合
検索メニューからCloudFormationを選択してください。

画面右上の「スタックの作成」>「新しいリソースを生成(標準)」を選択してください。

CloudFormationのテンプレート指定方法を選択します。以下を選択して、「次へ」クリックしてください。
- テンプレートの準備:「既存のテンプレートを選択」
- テンプレートソース:「テンプレートファイルをアップロード」
- テンプレートファイルのアップロード:「ファイルの選択」をクリックしテンプレートファイルを選択してください。

スタック名とスタックパラメタを入力します。以下を入力して「次へ」をクリックしてください。
- スタック名:同一リージョンで一意のスタック名を入力してください。
- パラメータ:各パラメタを入力してください。

スタックオプションの設定画面です。任意で設定してください。
最後の行のIAMロールに関する注意事項をチェックし、「次へ」をクリックしてください。
スタックが作成され、リソースの配備が始まります。

しばらくすると、スタックのステータスが「CREATE‗COMPLETE」となります。

AWS CLIで実行する場合
AWS CLIで実行する前にIAMで各種リソースが配備するための権限があるか確認してください。
CloudFormationでスタックを配備するコマンドは以下です。
Linux / macOS 版
aws cloudformation deploy \
--template-file ./service.yaml \
--stack-name demo-service-stack \
--capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \
--parameter-overrides \
SystemName=demo \
Environment=prod \
VpcId=vpc-xxxxxxxx \
SubnetId=subnet-xxxxxxxx \
AcmCertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx \
--region ap-northeast-1
Windows Powershell 版
aws cloudformation deploy `
--template-file .\service.yaml `
--stack-name demo-service-stack `
--capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND `
--parameter-overrides `
SystemName=demo `
Environment=prod `
VpcId=vpc-xxxxxxxx `
SubnetId=subnet-xxxxxxxx `
AcmCertificateArn=arn:aws:acm:ap-northeast-1:123456789012:certificate/xxxxxxxx `
--region ap-northeast-1
動作確認
Fleet Managerから動作確認用のWindowsサーバにアクセスしてください。
ALBのDNS名(またはプライベート DNS名)を確認し、ブラウザからHTTPSアクセスできれば成功です。

おわりに
今回の構成では、CloudFormationだけでビルドパイプライン(CI)+コンテナ環境+VPC内通信を自動構築できました。
手動設定を極力省くことで、環境差異やヒューマンエラーを防ぎ、再現性の高いデプロイが可能になります。
次のステップとしては、CodeDeployを組み合わせたBlue/Greenデプロイや、ECSサービスのスケーリング設定を追加してみてください。
「Infrastructure as Code(IaC)」を活用し、AWSの自動化を武器にした開発スタイルを身につけていきましょう!
AWSのCI/CDについてより詳しく知りたい方は以下のコースをおすすめします。
- AWSのCI/CDの基礎から知りたい方:Developer Associate向けのコース
- より高度な方式について知りたい方:Devops Engineer Professional向けのコース
