はじめに
本記事の目的
本記事では、AWS EC2環境での自動化と継続的デリバリ(CD)について解説します。
これまで手動で行っていたデプロイ作業を自動化し、コードの変更がスムーズに本番環境へ反映される仕組みを学びます。
前提知識
この記事を理解するためには、以下の基本知識があるとスムーズです。
- EC2の基本操作(インスタンス作成、接続方法など)
- Gitの基本コマンド(
clone
、commit
、push
など)
自動化・継続的デリバリ(CD)がなぜ重要か
手動デプロイは時間がかかり、ヒューマンエラーのリスクも高くなります。
CI/CDを導入することで以下のメリットがあります。
- デプロイ作業の省力化
- 更新の高速化
- テスト自動化による品質向上
- 環境間の差異や設定ミスの防止
CI/CDの概要
CI(継続的インテグレーション)とは?
開発者がコードを頻繁に共有リポジトリへ統合し、自動テストを実行して動作の安定性を確保する仕組みです。
- バグの早期発見
- 統合時の競合や不具合の減少
CD(継続的デリバリ / デプロイメント)とは?
CIでテスト済みのコードを、自動的に本番環境やステージング環境へ反映する流れです。
- デリバリ:本番環境へのリリース準備まで自動化
- デプロイメント:本番環境へのリリースまで自動化
EC2におけるCI/CDのイメージ図
- 開発者がGitリポジトリにコードをプッシュ
- 自動ビルド・テストが実行される
- 成功後、自動でEC2にデプロイ
- ユーザーが最新機能を利用可能になる

AWS CodeDeploy & CodePipelineとは
CodeDeployの役割
CodeDeployは「アプリケーションをEC2に自動でデプロイしてくれるサービス」です。
従来なら、サーバーにSSH接続してファイルをコピーして、アプリを再起動して…という手間が必要でした。CodeDeployを使えば、その作業を自動化できます。
また、デプロイ方式は2種類あり、用途に合わせて選べます。
- In-place方式:既存のEC2上のアプリを置き換える方式
- Blue/Green方式:新しい環境を用意して切り替える方式(ダウンタイム削減に強い)
CodePipelineの役割
CodePipelineは「ソースコードの更新からビルド・テスト・デプロイまでを自動で流してくれるパイプライン管理サービス」です。
GitHubやCodeCommitにコードをプッシュすると、それをトリガーにして以下を順番に実行します。
- ソースコードの取得
- ビルド(CodeBuildなどと連携)
- テスト実行
- デプロイ(CodeDeployなどと連携)
つまり、ソース更新 → 自動ビルド → 自動テスト → 自動デプロイ という一連の流れを、クリック操作ほぼ不要で実現できます。
基本の流れ(イメージ)
- GitHubやCodeCommitでコードを更新
- CodePipelineが変更を検知
- ビルド・テストを実行
- CodeDeployがEC2に新しいアプリを反映

環境作成
目的とゴール
- GitHub へ push → EC2 に自動でファイル配置(/var/www/html を更新)
- 動作確認はブラウザ or curl で “配置されたこと” を見るだけ
前提
- GitHub リポジトリ作成(README可)
- AWS リージョン、VPC/サブネット、パブリックSG(80/TCP)
- EC2 起動(Amazon Linux / パブリックIPあり)
- EC2にアタッチしているIAMロールに、SSMの権限、S3のGetObject権限が存在すること
デプロイ成果物の構成
Gitリポジトリ(もしくはS3に置く成果物)のディレクトリ例
.
├─ appspec.yml
├─ (配布したいファイル群) # ここが source:/ の対象 → /var/www/html へ展開
└─ scripts/
├─ install_dependencies.sh
├─ start_server.sh
└─ stop_server.sh
appspec.yml サンプル
CodeDeployでアプリをどう配置するかは appspec.yml という設定ファイルで定義します。
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html
hooks:
AfterInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
ApplicationStart:
- location: scripts/start_server.sh
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: root
- どのファイルをどこに配置するか(
files
) - デプロイ前後に実行するスクリプト(
hooks
)
を記述しておくと、EC2への反映やサービス再起動も自動でやってくれます。
スクリプト例
scripts/install_dependencies.sh
アプリの依存関係をインストールする処理。
#!/bin/bash
set -e
echo "Installing dependencies..."
yum update -y
yum install -y httpd
# 必要に応じて npm install や pip install などを追加
scripts/start_server.sh
ApacheやNode.jsなどを起動する処理。
#!/bin/bash
set -e
echo "Starting server..."
systemctl enable httpd
systemctl start httpd
scripts/stop_server.sh
デプロイ前にアプリを停止する処理。
#!/bin/bash
set -e
echo "Stopping server..."
systemctl stop httpd || true
EC2側の準備(CodeDeploy Agent のインストール)
CodeDeployでデプロイを受けられるように、EC2にはCodeDeploy Agentをインストールしておきます。
Amazon Linuxの場合の例
sudo yum update -y
sudo yum install -y ruby wget
cd /home/ec2-user
wget https://aws-codedeploy-ap-northeast-1.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto
sudo service codedeploy-agent start
インストール後、sudo service codedeploy-agent status
で動作確認できます。
CodeDeploy 設定
GitHubにpushしたコードを自動的にEC2へ配置できるようにします。
サービスロール(CodeDeploy用)
- CodeDeployがEC2へアクセスできるようにIAMロールを用意します。
- ロールの作成手順:
- IAMで「ロール作成」
- 信頼されたエンティティは「CodeDeploy」
- ポリシーに
AWSCodeDeployRole
をアタッチ - ロール名(例:
CodeDeployServiceRole
)を付けて保存
このロールをデプロイグループ作成時に割り当てます。
アプリケーション作成
- AWSマネジメントコンソールで CodeDeploy を開く
- 「アプリケーションを作成」を選択
- アプリケーション名 を入力(例:
my-web-app
) - コンピューティングプラットフォーム は「EC2/オンプレミス」を選択

デプロイグループ作成
- アプリケーションを選択し「デプロイグループを作成」
- デプロイグループ名 を入力(例:
my-deploy-group
) - サービスロール で先ほど作成したIAMロールを選択
- デプロイ先 にEC2インスタンスを指定
- EC2にはタグ(例:
Key=Name, Value=MyWebServer
)を付与しておく - デプロイグループでは「EC2インスタンスタグ」を選び、そのタグを指定
- EC2にはタグ(例:
- AWS CodeDeploy エージェントのインストールは1回のみを選択
- デプロイ設定はCodeDeployDefault.AllAtOnceを選択し、全インスタンスに一斉デプロイできるようにする。
- Load balancerはチェックを外して無効にする。(テストのため)



CodePipeline 設定(GitHub 連携)
EC2 へ自動デプロイする仕組みを完成させるために、最後に CodePipeline を設定します。
これにより、GitHub にコードを push するたびに、自動的に CodeDeploy が呼び出され、EC2 に最新のアプリケーションが反映されるようになります。
新規パイプライン作成
AWS マネジメントコンソールで CodePipeline を開き、「パイプラインを作成」から進めます。
- 作成オプションはカスタムパイプラインを構築するを選択
- 実行モードは優先済みを選択
- サービスロールは新しいサービスロールを選択し、ロール名を設定します。
忘れずに「AWS CodePipeline がサービスロールを作成できるようになるため、この新しいパイプラインでの使用が可能になります。」にチェックをいれます。


ソースステージの設定(GitHub 連携)
ソースに GitHub を選択し、リポジトリとブランチを指定します。
このとき、AWS が GitHub と連携するために認証を求められるので、GitHub アカウントで承認してください。
さらに、「Webhook 連携」を有効にしておくと、GitHub 側で push が発生したタイミングで自動的にパイプラインが実行されます。

ビルドステージの設定(今回はスキップ)
今回は静的ファイルや簡単なサンプルアプリを対象としているので、ビルドステージは不要です。
「ビルドなし(スキップ)」を選択して進めます。
※ Node.js アプリやコンテナイメージを利用する場合は、このステージで CodeBuild を設定することになります。
デプロイステージの設定(CodeDeploy)
デプロイ先に CodeDeploy を選択し、前の手順で作成した アプリケーション/デプロイグループ を指定します。
これで GitHub → CodePipeline → CodeDeploy → EC2 という流れが完成します。

まとめ
本記事では AWS EC2 への自動デプロイ環境構築 をテーマに、CodeDeploy と CodePipeline を活用した CI/CD の基本を解説しました。
振り返ると、流れは以下のようになります。
- 前提知識の整理
- EC2 の基本操作
- Git の基本コマンド
- CI/CD がなぜ必要なのか
- CI/CD の概要理解
- CI(継続的インテグレーション):コードを統合・テストして品質を担保
- CD(継続的デリバリ/デプロイメント):本番環境へ自動反映
- 環境構築の実践
- GitHub リポジトリと EC2 の準備
- appspec.yml とスクリプト群でデプロイ手順を定義
- CodeDeploy Agent の導入
- CodeDeploy 設定
- アプリケーションとデプロイグループを作成
- IAM ロールを設定し、EC2 をデプロイ対象に
- CodePipeline 設定(GitHub 連携)
- GitHub push → パイプライン起動 → CodeDeploy が自動反映
- Webhook でリアルタイムにトリガー可能
コメント