はじめに

「EC2 が 1台では負荷が集中したときに対応できない」「障害で EC2 が落ちたら手動で復旧しなければならない」——これを解決するのが Auto Scaling Group（ASG） です。

この記事では、CDK Pipelines + CodeDeploy ハンズオンで構築した 単一 EC2 構成を、Auto Scaling Group + Launch Template にアップグレードします。CPU 負荷をかけて実際にスケールアウトを体験し、新しいインスタンスへ CodeDeploy が自動で WAR をデプロイする様子を確認します。

GitHub リポジトリ
  ↓ push（自動トリガー）
CodePipeline (my-cdk5-pipeline)
  ├── Source:        GitHub (CodeConnections 経由)
  ├── Build(Synth):  CodeBuild — cdk synth
  ├── Mutate:        パイプライン自己更新（セルフミューテーション）
  ├── InfraDeploy:   CloudFormation — VPC / ASG / RDS / ALB
  └── BuildAndDeployApp: ← post step
        CodeBuild: mvn package → webapp.war 生成
        CodeDeploy: ASG の全 Tomcat に一括デプロイ
                ↓
       [ALB: my-cdk5-alb]
                ↓
       ┌─────────────────────────────┐
       │  Auto Scaling Group (ASG)   │
       │  my-cdk5-asg                │
       │  ・最小 1台 / 最大 3台      │
       │  ・CPU 60% 超でスケールアウト│
       │  ├── EC2: Tomcat + WAR      │
       │  └── EC2: Tomcat + WAR（追加分）│
       └─────────────────────────────┘
                ↓
       [RDS: my-cdk5-rds-mysql]  ← MySQL 8.0

このハンズオンで体験できること：

• git push するだけで ASG の全インスタンスへ WAR が自動デプロイされる
• CPU に負荷をかけてスケールアウトを体験する
• スケールアウト後の新インスタンスへ CodeDeploy が自動で WAR をデプロイする（ライフサイクルフック）
• キーペア不要で SSM Session Manager からブラウザ経由でインスタンスに接続する

この記事は CDK Pipelines + CodeDeploy ハンズオン（cdk-webapp-pipeline） の発展記事です。
CodeDeploy・CDK Pipelines の基本を体験済みの方向けです。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-webapp-pipeline との比較

ファイル構成と役割

cdk-asg-webapp/
├── app.py                     ← CDK アプリ エントリポイント
├── cdk.json                   ← CDK 設定（key_name/my_ip なし・asg_* 追加）
├── appspec.yml                ← CodeDeploy: WAR 配置手順とライフサイクルフック
├── scripts/
│   ├── stop_tomcat.sh
│   ├── cleanup.sh
│   └── start_tomcat.sh
├── app/                       ← Spring Boot Webアプリ（Java）
├── pipeline/
│   └── pipeline_stack.py      ← CodePipeline + post step（ASG 対応）
├── stages/
│   └── deploy_stage.py        ← Stage（WebappStack を内包）
├── stacks/
│   └── webapp_stack.py        ← インフラスタック（ASGName を CfnOutput で公開）
└── components/
    └── webapp_construct.py    ← ASG ベースの L3 Construct

詳細なコードは GitHub を参照してください。

使用するAWSサービス

注意: ALBは無料枠がありません。スケールアウト中はEC2が複数台起動するため料金も増加します。ハンズオン後は必ずリソースを削除してください。

前提条件

AWS 認証確認:

aws sts get-caller-identity

CDK Bootstrap 確認:

aws cloudformation describe-stacks ^
  --stack-name CDKToolkit ^
  --query "Stacks[0].StackStatus" ^
  --output text ^
  --region ap-northeast-1

SSH キーペアは不要です。このハンズオンでは SSM Session Manager を使って EC2 に接続するため、キーペアの作成・設定は必要ありません。

作業順序

① プロジェクトのセットアップ（Python 仮想環境）
      ↓
② GitHub との接続を作成する（CodeConnections）
      ↓
③ cdk.json を設定する
      ↓
④ コードを全て GitHub にプッシュする（重要！）
      ↓
⑤ パイプラインスタックをデプロイする（初回のみ手動）
      ↓
⑥ パイプラインの実行状況を確認する
      ↓
⑦ アプリへアクセスする
      ↓
⑧ Auto Scaling を体験する（CPU 負荷 → スケールアウト → 自動デプロイ）
      ↓
⑨ CI/CD を体験する（アプリ変更を push で自動反映）
      ↓
⑩ リソース削除

① プロジェクトのセットアップ

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

プロンプトの先頭に (.venv) が表示されれば仮想環境が有効になっています。

重要: CDK コマンドはすべてこの仮想環境が有効な状態で実行する必要があります。
ターミナルを開き直した際は必ず最初に以下を実行してください。

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp
.venv\Scripts\activate

② GitHub との接続を作成する（CodeConnections）

cdk-webapp-pipeline を実施済みの場合: 同じリポジトリ aws-learning-projects を扱うため、
既存の接続（my-github-connection）をそのまま再利用できます。
② はスキップして、ARN の確認（②-4）から始めてください。

CodePipeline が GitHub リポジトリを監視するために、GitHub との接続（CodeConnections） を作成します。

重要: AWS コンソールと GitHub の操作は同じブラウザで行ってください。

接続を作成する

1. AWS コンソール検索（Alt+S）で CodePipeline と入力 → CodePipeline を開く
2. 左サイドバー → 「設定」 → 「接続」
3. リージョンが 東京（ap-northeast-1） になっていることを確認する
4. 「接続を作成」をクリック
5. プロバイダー: GitHub を選択
6. 接続名: my-github-connection（任意）
7. 「GitHub に接続する」をクリック

GitHub App をインストールする

8. 「Authorize」をクリック → AWS コンソールの「GitHub 接続設定」画面に自動で戻る
9. 「新しいアプリをインストールする」をクリック
10. 「Only select repositories」 を選択 → aws-learning-projects を追加
11. 「Install & Authorize」をクリック（メール認証コードが求められる場合は入力）
12. AWS コンソールに自動でリダイレクトされる → 「接続」ボタンをクリック

接続 ARN を確認する

接続一覧から接続の ARN をコピーします。

arn:aws:codeconnections:ap-northeast-1:123456789012:connection/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

ステータスが 「利用可能」 になっていることを確認してから次に進んでください。

控えておく情報: 接続 ARN（arn:aws:codeconnections:...）

③ cdk.json の設定

cdk.json の context セクションを自分の環境に合わせて編集します。

{
  "context": {
    "employee_id": "my",
    "db_password": "Handson1234!",
    "tomcat_version": "10.1.28",
    "asg_min_capacity": 1,
    "asg_max_capacity": 3,
    "asg_desired_capacity": 1,
    "github_owner": "your-github-username",
    "github_repo": "aws-learning-projects",
    "github_branch": "main",
    "connection_arn": "arn:aws:codeconnections:ap-northeast-1:..."
  }
}

key_name・my_ip は不要です。SSH の代わりに SSM Session Manager を使うため、キーペアやSSH許可IPの設定は必要ありません。

④ コードを GitHub にプッシュする（重要！）

cdk deploy の前に必ずプロジェクト全体を push してください。
パイプラインが cdk synth・Maven ビルドを実行する際、GitHub から取得したコードを使うためです。

cd C:\my-aws\aws-learning-projects

git add cdk-asg-webapp/
git commit -m "feat: cdk-asg-webapp ハンズオンを追加"
git push origin main

⑤ パイプラインスタックのデプロイ（初回のみ）

cd C:\my-aws\aws-learning-projects\cdk-asg-webapp

.venv\Scripts\activate

cdk synth

cdk deploy my-AsgPipelineStack

「Do you wish to deploy these changes?」に y を入力します。

所要時間: パイプラインスタック自体のデプロイは 3〜5 分。その後パイプラインが自動起動します。

デプロイ完了後、CodePipeline が自動起動します:

RDS の起動に時間がかかるため、InfraDeploy は 10〜20 分かかることがあります。

⑥ パイプラインの実行状況を確認する

1. AWS コンソール → CodePipeline を開く
2. my-cdk5-pipeline を選択
3. 各ステージが 「成功」 になるまで待つ

CloudFormation スタックの命名規則

{StageName}-{StackName}

my-AsgPipelineStack（パイプライン）と my-Deploy-WebappStack（インフラ）の 2つが別スタックとして CloudFormation に表示されます。

CloudFormation Outputs の確認

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs"

控えておく情報: ALBEndpoint、RDSEndpoint

⑦ アプリへアクセスする

BuildAndDeployApp ステージが完了したら、ALB 経由でアプリにアクセスします。

http://<ALBEndpoint>/webapp/

http://<ALBEndpoint>/（ルートパス）では Tomcat のデフォルト画面が表示されます。/webapp/ が必要です。

ALB の DNS 名を CLI で確認する場合:

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs[?OutputKey=='ALBEndpoint'].OutputValue" ^
  --output text

ASG インスタンスを確認する

AWS コンソール → EC2 → Auto Scaling グループ → my-cdk5-asg

• インスタンス タブを開く
• 1台の EC2 が InService になっていることを確認する

⑧ Auto Scaling を体験する

ASG のスケールアウト・スケールインを実際に体験します。CPU 使用率が 60% を超えると自動でインスタンスが追加されます。

現在の ASG 状態を確認する

aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].{Desired:DesiredCapacity,Min:MinSize,Max:MaxSize,Instances:Instances[*].{Id:InstanceId,State:LifecycleState}}"

出力例（初期状態: 1台が InService）:

{
    "Desired": 1,
    "Min": 1,
    "Max": 3,
    "Instances": [{ "Id": "i-0abc123...", "State": "InService" }]
}

SSM Session Manager でインスタンスに接続する

キーペアは不要です。AWS コンソールから直接ブラウザでターミナルを開けます。

1. EC2 → インスタンス → 対象インスタンスを選択
2. 「接続」ボタンをクリック
3. 「Session Manager」タブ → 「接続」をクリック

ブラウザでターミナルが開きます。

CLI から接続する場合:

rem インスタンス ID を取得
aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].Instances[0].InstanceId" ^
  --output text

rem 接続（Session Manager Plugin が必要）
aws ssm start-session ^
  --target i-0abc123def456789 ^
  --region ap-northeast-1

CPU 負荷をかける（スケールアウトをトリガーする）

インスタンスに接続したターミナルで実行します:

cd /tmp && stress-ng --cpu 2 --timeout 300s &
echo "CPU stress started (PID: $!)"

スケールアウトを監視する

1. AWS コンソール → CloudWatch → メトリクス → EC2 → Auto Scaling グループ別
2. my-cdk5-asg の CPUUtilization を確認
3. CPU が 60% を超えると、約 1〜3 分後にスケールアウトが始まる

ASG のインスタンス数を 10秒ごとに確認:

:loop
aws autoscaling describe-auto-scaling-groups ^
  --auto-scaling-group-names my-cdk5-asg ^
  --region ap-northeast-1 ^
  --query "AutoScalingGroups[0].Instances[*].{Id:InstanceId,State:LifecycleState}" ^
  --output table
timeout /t 10
goto loop

しばらく待つと 2台目のインスタンスが起動し InService になります。

スケールアウト後の CodeDeploy 自動デプロイを確認する

新しいインスタンスが起動すると、CodeDeploy が自動的に最新の WAR をデプロイします。

AWS コンソール → CodeDeploy → my-cdk5-deploy-app
→ デプロイグループ → デプロイ履歴

新しいデプロイが自動で実行されていることを確認します。パイプラインを手動実行しなくても、ライフサイクルフックにより新インスタンスへ最新 WAR が自動デプロイされます。

スケールインを確認する

CPU 負荷が終了（300秒後）すると CPU 使用率が下がり、スケールインが始まります。

ターゲット追跡ポリシーのデフォルトのスケールイン保護時間は 300秒。
負荷終了後、約 5〜10 分でインスタンス数が 1台に戻ります。

途中で手動停止する場合:

pkill stress-ng

⑨ CI/CD を体験する（アプリ変更を push で自動反映）

アプリのコードを変更して push するだけで、ASG の全インスタンスへ自動デプロイされることを確認します。

アプリの HTML を変更する

app/src/main/resources/templates/index.html を開き、以下の行を変更します:

変更前:

<h1>Spring Boot + RDS Item Manager</h1>

変更後:

<h1>Spring Boot + RDS Item Manager (ASG)</h1>

コミット＆プッシュ

cd C:\my-aws\aws-learning-projects
git add cdk-asg-webapp/app/src/main/resources/templates/index.html
git commit -m "feat: update webapp UI for ASG"
git push

パイプラインの自動起動を確認する

1. AWS コンソール → CodePipeline → my-cdk5-pipeline
2. push 後、数十秒以内にパイプラインが自動起動することを確認
3. BuildAndDeployApp ステージが完了したらブラウザで /webapp/ を更新する

「(ASG)」が付いた見出しが表示されれば、ASG 構成での CI/CD が正常に動作しています。

注意: InfraDeploy ステージはインフラに変更がない場合は「変更なし」でスキップされます。

⑩ リソース削除

課金を止めるために、ハンズオン完了後は必ず削除します。

ASG を含むスタックを削除すると、全インスタンスが自動終了されます。

削除順序が重要です。インフラスタック（my-Deploy-WebappStack）を先に削除してから、パイプラインスタック（my-AsgPipelineStack）を削除します。

1. インフラスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

echo WebappStack 削除完了

RDS の削除に 10〜15 分かかります。wait コマンドが完了するまでそのまま待ってください。

2. パイプラインスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-AsgPipelineStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-AsgPipelineStack ^
  --region ap-northeast-1

echo AsgPipelineStack 削除完了

3. SSM パラメータを削除する

aws ssm delete-parameter ^
  --name "/my/cdk5/db-password" ^
  --region ap-northeast-1

4. 仮想環境の終了

deactivate

5. GitHub との接続を削除する（オプション）

次のハンズオンでも使う場合はそのままでよいです。

CodePipeline → 設定 → 接続 → my-github-connection → 「削除」

削除確認

aws cloudformation list-stacks ^
  --region ap-northeast-1 ^
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE ^
  --query "StackSummaries[?contains(StackName, 'my-')].StackName"

空のリスト [] が返れば削除完了です。

削除されるリソース一覧

Auto Scaling のポイント解説

ASG ライフサイクルフックで新インスタンスへ自動デプロイ

CDK で codedeploy.ServerDeploymentGroup(auto_scaling_groups=[self.asg]) と指定すると、CodeDeploy が ASG にライフサイクルフックを自動設定します。

スケールアウト発生
  ↓
ASG: 新しいインスタンスを Launch Template から起動
  ↓
EC2 UserData: Java・Tomcat・CodeDeploy エージェントをインストール
  ↓
ライフサイクルフック: CodeDeploy が最新 WAR を自動デプロイ
  ↓
ALB ターゲットグループに追加（InService）

これにより、スケールアウト後の新インスタンスでもユーザーは何もしなくて済みます。

cdk-webapp-pipeline → cdk-asg-webapp の変化

cdk-webapp-pipeline               cdk-asg-webapp
─────────────────────────         ─────────────────────────
EC2 Instance（固定 1台）           Auto Scaling Group（1〜3台）
  ↓                                 ↓
SSH（キーペア必要）                 SSM Session Manager（キーペア不要）
  ↓                                 ↓
CodeDeploy: 名前タグで指定          CodeDeploy: ASG を直接指定
  ↓                                 ↓
スケールアウト不可                  CPU 60% 超で自動スケールアウト
  ↓                                 ↓
新インスタンスに WAR なし          ライフサイクルフックで自動 WAR デプロイ

トラブルシューティング

CodeDeploy 失敗時のログ確認:

AWS コンソール → CodeDeploy → my-cdk5-deploy-app → デプロイグループ → デプロイ履歴 → 失敗したデプロイ → 「ログの表示」

まとめ

ASG を導入することで「単一障害点の排除・自動スケーリング・スケールアウト時の自動デプロイ」を一度に体験できました。

コンソールで3層構成を視覚的に学びたい場合は AWSコンソール版ハンズオン、CDK の基本は CDK版ハンズオン（cdk-alb-ec2-rds）、カスタム Construct は CDK カスタム Construct ハンズオン、インフラ CI/CD は CDK Pipelines ハンズオン、アプリ CI/CD は CDK + CodeDeploy ハンズオン を参照してください。

The post CDK + Auto Scaling Group で Webアプリをオートスケーリング構成にする【CPU負荷でスケールアウト体験】 first appeared on CayTech Lab.

はじめに

「アプリのコードを push するだけで EC2 の Tomcat に自動デプロイされる仕組みを作りたい」——これを実現するのが CDK Pipelines + CodeDeploy の組み合わせです。

この記事では、CDK Pipelines ハンズオンで体験した インフラの CI/CD をさらに発展させ、Spring Boot（Java）アプリ（WAR ファイル）の自動デプロイまで含めた完全な CI/CD パイプラインを構築します。GitHub に push するだけで Maven ビルドが走り、CodeDeploy が EC2/Tomcat に WAR をホットデプロイします。

GitHub リポジトリ
  ↓ push（自動トリガー）
CodePipeline (my-cdk4-pipeline)
  ├── Source:        GitHub (CodeConnections 経由)
  ├── Build(Synth):  CodeBuild — cdk synth
  ├── Mutate:        パイプライン自己更新（セルフミューテーション）
  ├── InfraDeploy:   CloudFormation — VPC / EC2 / RDS / ALB / CodeDeploy 設定
  └── BuildAndDeployApp: ← post step
        CodeBuild: mvn package → webapp.war 生成
        CodeDeploy: EC2/Tomcat に WAR をホットデプロイ
                ↓
       [ALB: my-cdk4-alb]
                ↓
       [EC2: my-cdk4-ap-instance]  ← Tomcat + Spring Boot WAR
                ↓
       [RDS: my-cdk4-rds-mysql]    ← MySQL 8.0

このハンズオンで体験できること：

• git push するだけで Maven ビルド → CodeDeploy → WAR ホットデプロイが自動実行される
• インフラ（CloudFormation）とアプリ（CodeDeploy）の両方が push で自動更新される
• HTML を変更して push すると、数分でブラウザの表示が変わることを確認できる

この記事は CDK Pipelines ハンズオン（cdk-pipelines） の発展記事です。
CDK Pipelines の基本（セルフミューテーション・Stage・CodeConnections）を体験済みの方向けです。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-pipelines との比較

ファイル構成と役割

cdk-webapp-pipeline/
├── app.py                     ← CDK アプリ エントリポイント
├── cdk.json                   ← CDK 設定・Context 変数
├── appspec.yml                ← CodeDeploy: WAR 配置手順とライフサイクルフック
├── scripts/
│   ├── stop_tomcat.sh         ← CodeDeploy: ApplicationStop フック
│   ├── cleanup.sh             ← CodeDeploy: BeforeInstall フック
│   └── start_tomcat.sh        ← CodeDeploy: AfterInstall フック
├── app/                       ← Spring Boot Webアプリ（Java）
│   ├── pom.xml
│   └── src/main/...           ← ItemController / Item / ItemRepository / templates/
├── pipeline/
│   └── pipeline_stack.py      ← CodePipeline + post step 定義
├── stages/
│   └── webapp_stage.py        ← Stage（WebappStack を内包）
├── stacks/
│   └── webapp_stack.py        ← インフラスタック（CfnOutput で値を公開）
└── components/
    └── webapp_construct.py    ← カスタム L3 Construct（CodeDeploy 設定含む）

詳細なコードは GitHub を参照してください。

使用するAWSサービス

注意: ALBは無料枠がありません。ハンズオン後は必ずリソースを削除してください。

前提条件

AWS 認証確認:

aws sts get-caller-identity

CDK Bootstrap 確認（CDKToolkit スタックが存在すれば実施済み）:

aws cloudformation describe-stacks ^
  --stack-name CDKToolkit ^
  --query "Stacks[0].StackStatus" ^
  --output text ^
  --region ap-northeast-1

GitHub アカウントが必要です。aws-learning-projects リポジトリに push できる状態にしておいてください。

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（AWS CLI で実施）
      ↓
② プロジェクトのセットアップ（Python 仮想環境）
      ↓
③ GitHub との接続を作成する（CodeConnections）
      ↓
④ cdk.json を設定する
      ↓
⑤ コードを全て GitHub にプッシュする（重要！）
      ↓
⑥ パイプラインスタックをデプロイする（初回のみ手動）
      ↓
⑦ パイプラインの実行状況を確認する
      ↓
⑧ アプリへアクセスする（/webapp/ 必須）
      ↓
⑨ CI/CD を体験する（アプリ変更を push で自動反映）
      ↓
⑩ リソース削除

【重要】⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

aws ec2 create-key-pair ^
  --key-name my-cdk4-key ^
  --query KeyMaterial ^
  --output text ^
  --region ap-northeast-1 > %USERPROFILE%\.ssh\my-cdk4-key.pem

%USERPROFILE%\.ssh\ が存在しない場合は先に mkdir %USERPROFILE%\.ssh を実行してください。

② プロジェクトのセットアップ

cd C:\my-aws\aws-learning-projects\cdk-webapp-pipeline

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

プロンプトの先頭に (.venv) が表示されれば仮想環境が有効になっています。

重要: CDK コマンド（synth / deploy / destroy）はすべてこの仮想環境が有効な状態で実行する必要があります。
ターミナルを開き直した際は必ず最初に以下を実行してください。

cd C:\my-aws\aws-learning-projects\cdk-webapp-pipeline
.venv\Scripts\activate

③ GitHub との接続を作成する（CodeConnections）

cdk-pipelines を実施済みの場合: 同じリポジトリ aws-learning-projects を扱うため、
既存の接続（my-github-connection）をそのまま再利用できます。
③ はスキップして、ARN の確認（③-4）から始めてください。

CodePipeline が GitHub リポジトリを監視するために、GitHub との接続（CodeConnections） を作成します。

重要: AWS コンソールと GitHub の操作は同じブラウザで行ってください。
別ブラウザで操作すると、AWS にリダイレクトされた際にデフォルトリージョン（バージニア北部等）でログインされる場合があります。

接続を作成する

1. AWS コンソール検索（Alt+S）で CodePipeline と入力 → CodePipeline を開く
2. 左サイドバー → 「設定」 → 「接続」
3. リージョンが 東京（ap-northeast-1） になっていることを確認する
4. 「接続を作成」をクリック
5. プロバイダー: GitHub を選択
6. 接続名: my-github-connection（任意）
7. 「GitHub に接続する」をクリック

GitHub App をインストールする

クリック後、GitHub の OAuth 認証画面が開きます。

8. 「Authorize」をクリック → AWS コンソールの「GitHub 接続設定」画面に自動で戻る
9. 「新しいアプリをインストールする」をクリック → GitHub の「Install & Authorize」画面が開く
10. 「Only select repositories」 を選択 → aws-learning-projects を追加
11. 「Install & Authorize」をクリック（メール認証コードが求められる場合は入力）
12. AWS コンソールに自動でリダイレクトされる → 「接続」ボタンをクリック

接続 ARN を確認する

接続一覧から接続の ARN をコピーします。

arn:aws:codeconnections:ap-northeast-1:123456789012:connection/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

重要: ステータスが 「利用可能」 になっていることを確認してから次に進んでください。

控えておく情報: 接続 ARN（arn:aws:codeconnections:...）

④ cdk.json の設定

cdk.json の context セクションを自分の環境に合わせて編集します。

{
  "context": {
    "employee_id": "my",
    "my_ip": "203.0.113.1/32",
    "db_password": "Handson1234!",
    "key_name": "my-cdk4-key",
    "tomcat_version": "10.1.28",
    "github_owner": "your-github-username",
    "github_repo": "aws-learning-projects",
    "github_branch": "main",
    "connection_arn": "arn:aws:codeconnections:ap-northeast-1:..."
  }
}

cdk-pipelines（前回）と同時にデプロイしてもリソース名が競合しません。前回は my-cdk3-xxx、今回は my-cdk4-xxx というプレフィックスになります。

⑤ コードを GitHub にプッシュする（重要！）

cdk-pipelines との重要な違い: このハンズオンでは cdk.json だけでなくプロジェクト全体を push する必要があります。

CDK Pipelines は GitHub から取得したコードで cdk synth を実行し、Maven ビルドも行います。
Java ソース（app/）・appspec.yml・scripts/ がリポジトリに存在しないと、パイプラインの BuildAndDeployApp ステップが失敗します。

cdk deploy の前に必ずコード全体を push してください。

cd C:\my-aws\aws-learning-projects

git add cdk-webapp-pipeline/
git commit -m "feat: cdk-webapp-pipeline ハンズオンを追加"
git push origin main

⑥ パイプラインスタックのデプロイ（初回のみ）

CDK Pipelines ではパイプライン自体を最初に1回だけ手動でデプロイします。以降はパイプラインが自動的に動作します。

cd C:\my-aws\aws-learning-projects\cdk-webapp-pipeline

.venv\Scripts\activate

cdk synth

cdk deploy my-WebappPipelineStack

「Do you wish to deploy these changes?」に y を入力します。

所要時間: パイプラインスタック自体のデプロイは 3〜5 分。その後パイプラインが自動起動します。

デプロイ完了後、CodePipeline が自動起動します:

RDS の起動に時間がかかるため、InfraDeploy は 10〜20 分かかることがあります。

⑦ パイプラインの実行状況を確認する

1. AWS コンソール → CodePipeline を開く
2. my-cdk4-pipeline を選択
3. 各ステージが 「成功」 になるまで待つ

CloudFormation スタックの命名規則

CDK Pipelines でステージをデプロイすると、CloudFormation スタック名は以下の形式になります:

{StageName}-{StackName}

my-WebappPipelineStack（パイプライン）と my-Deploy-WebappStack（インフラ）の 2つが別スタックとして CloudFormation に表示されます。

CloudFormation Outputs の確認

InfraDeploy ステージが完了したら、インフラスタックの Outputs を確認します。

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs"

控えておく情報: ALBEndpoint、EC2PublicIP、RDSEndpoint

⑧ アプリへアクセスする

BuildAndDeployApp ステージが完了（全ステージが成功）したら、ALB 経由でアプリにアクセスします。

ALB の DNS 名を確認する

Outputs の ALBEndpoint をブラウザで開きます。

重要: URL のパスに /webapp/ が必要です。

http://<ALBEndpoint>/webapp/

http://<ALBEndpoint>/（ルートパス）では Tomcat のデフォルト画面が表示されます。
WAR が webapp.war としてデプロイされるため、アプリは /webapp/ 以下に配置されます。

または CLI で ALBEndpoint を確認:

aws cloudformation describe-stacks ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs[?OutputKey=='ALBEndpoint'].OutputValue" ^
  --output text

アプリの動作確認

以下が表示されれば正常です:

• 「Spring Boot + RDS Item Manager」というタイトルが表示される
• アイテムの追加・削除ができる
• ブラウザをリロードしてもデータが保持される（RDS への永続化が成功）

EC2 に SSH 接続する（オプション）

ssh -i %USERPROFILE%\.ssh\my-cdk4-key.pem ec2-user@（EC2PublicIP）

EC2 接続後にログ確認などを行う場合（以下は EC2 上での操作）:

sudo systemctl status codedeploy-agent   # CodeDeploy エージェントの状態確認

sudo cat /opt/tomcat/logs/catalina.out   # Tomcat のログ確認

sudo ls -la /opt/tomcat/webapps/         # デプロイされた WAR を確認

EC2 から RDS への接続確認（オプション）

EC2 に SSH 接続後:

sudo dnf install -y mariadb105

DB_PASSWORD=$(aws ssm get-parameter \
  --name /my/cdk4/db-password \
  --query Parameter.Value \
  --output text \
  --region ap-northeast-1)

mysql -h <RDSEndpoint> -u admin -p${DB_PASSWORD} sampledb

mysql> SHOW TABLES;
mysql> exit

⑨ CI/CD を体験する（アプリ変更を push で自動反映）

CDK Pipelines + CodeDeploy の醍醐味は「アプリのコードを push するだけで EC2 の Tomcat に自動デプロイされる」ことです。

アプリの HTML を変更する

app/src/main/resources/templates/index.html を開き、以下の行を変更します:

変更前:

<h1>Spring Boot + RDS Item Manager</h1>

変更後:

<h1>Spring Boot + RDS Item Manager v2</h1>

コミット＆プッシュ

cd C:\my-aws\aws-learning-projects
git add cdk-webapp-pipeline/app/src/main/resources/templates/index.html
git commit -m "feat: update webapp UI to v2"
git push

パイプラインの自動起動を確認する

1. AWS コンソール → CodePipeline → my-cdk4-pipeline
2. push 後、数十秒以内にパイプラインが自動起動することを確認
3. BuildAndDeployApp ステージが完了したらブラウザで /webapp/ を更新する

変更前後の見出しが切り替わっていれば、アプリの CI/CD が正常に動作しています。

補足: InfraDeploy ステージはインフラに変更がない場合は「変更なし」でスキップされ、高速に完了します。

注意: CodePipeline は main ブランチへの全ての push でトリガーされます。
.md ファイルだけ変更した場合でもビルド・デプロイが走ります。本番環境ではブランチ戦略や CodePipeline V2 のトリガーフィルターで絞ることができます。

⑩ リソース削除

課金を止めるために、ハンズオン完了後は必ず削除します。

削除順序が重要です。パイプラインによってデプロイされたスタック（my-Deploy-WebappStack）を先に削除してから、パイプラインスタック（my-WebappPipelineStack）を削除します。

1. アプリスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-Deploy-WebappStack ^
  --region ap-northeast-1

echo WebappStack 削除完了

RDS の削除に 10〜15 分かかります。wait コマンドが完了するまでそのまま待ってください。

2. パイプラインスタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-WebappPipelineStack ^
  --region ap-northeast-1

aws cloudformation wait stack-delete-complete ^
  --stack-name my-WebappPipelineStack ^
  --region ap-northeast-1

echo PipelineStack 削除完了

3. SSM パラメータを削除する

aws ssm delete-parameter ^
  --name "/my/cdk4/db-password" ^
  --region ap-northeast-1

4. 仮想環境の終了

deactivate

5. キーペアの削除

aws ec2 delete-key-pair ^
  --key-name my-cdk4-key ^
  --region ap-northeast-1

del %USERPROFILE%\.ssh\my-cdk4-key.pem

6. GitHub との接続を削除する（オプション）

次のハンズオンでも使う場合はそのままでよいです。

CodePipeline → 設定 → 接続 → my-github-connection → 「削除」

削除確認

aws cloudformation list-stacks ^
  --region ap-northeast-1 ^
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE ^
  --query "StackSummaries[?contains(StackName, 'my-')].StackName"

空のリスト [] が返れば削除完了です。

削除されるリソース一覧

CDK Pipelines + CodeDeploy のポイント解説

appspec.yml とライフサイクルフック

version: 0.0
os: linux
files:
  - source: webapp.war
    destination: /opt/tomcat/webapps/
    overwrite: true
hooks:
  ApplicationStop:
    - location: scripts/stop_tomcat.sh    # Tomcat 停止
  BeforeInstall:
    - location: scripts/cleanup.sh         # 古い WAR・展開ディレクトリを削除
  AfterInstall:
    - location: scripts/start_tomcat.sh    # Tomcat 起動

CodeDeploy はこの順序でフックを実行し、Tomcat の再起動を伴わずに WAR を差し替えます。

env_from_cfn_outputs の仕組み

インフラスタック（webapp_stack.py）は CodeDeploy のリソース情報を CfnOutput で公開します:

self.deploy_app_name_output = CfnOutput(
    self, "DeployApplicationName",
    value=web.deploy_application.application_name,
)

パイプライン（pipeline_stack.py）はこの出力をアプリデプロイステップの環境変数として受け取ります:

# pipeline_stack.py
build_and_deploy = CodeBuildStep(
    "BuildAndDeployApp",
    env_from_cfn_outputs={
        "DEPLOY_APP_NAME": stage.deploy_app_name_output,   # CloudFormation Output → 環境変数
    },
    commands=["aws deploy create-deployment --application-name $DEPLOY_APP_NAME ..."],
)

これにより、パイプラインのコードにリソース名をハードコードせず、CloudFormation が実際に作成したリソース名を動的に参照できます。

post step の役割

pipeline.add_stage(stage, post=[build_and_deploy])

post にステップを渡すことで、ステージ（InfraDeploy）の完了後に続けて BuildAndDeployApp が実行されます。これにより「インフラが確実に存在する状態でアプリをデプロイする」という順序が保証されます。

トラブルシューティング

CodeDeploy 失敗時のログ確認:

AWS コンソール → CodeDeploy → アプリケーション → デプロイグループ → デプロイ履歴 → 失敗したデプロイ → 「ログの表示」

まとめ

CDK Pipelines + CodeDeploy を組み合わせることで、「インフラもアプリも、コードが唯一の変更手段になる」GitOps の世界を体験できました。インフラ変更は CloudFormation が、アプリ変更は CodeDeploy が、それぞれ自動で EC2 に反映します。

コンソールで3層構成を視覚的に学びたい場合は AWSコンソール版ハンズオン、CDK の基本は CDK版ハンズオン（cdk-alb-ec2-rds）、カスタム Construct は CDK カスタム Construct ハンズオン、インフラ CI/CD のみは CDK Pipelines ハンズオン を参照してください。

The post CDK Pipelines で Spring Boot を CI/CD 自動デプロイする【CodeDeploy で WAR ホットデプロイ】 first appeared on CayTech Lab.

はじめに

「インフラの変更を反映するたびに cdk deploy を手動実行するのが面倒」「コードをプッシュするだけで AWS リソースが自動更新されるようにしたい」——これを実現するのが CDK Pipelines です。

この記事では、CDK カスタム Construct ハンズオンで構築した ALB + EC2(Tomcat) + RDS の3層構成を、CDK Pipelines（CodePipeline + CodeBuild） で CI/CD 化します。GitHub にコードをプッシュするだけで自動的にインフラがデプロイ・更新される仕組みを体験します。

GitHub リポジトリ
  ↓ push（自動トリガー）
CodePipeline (my-cdk3-pipeline)
  ├── Source:  GitHub (CodeConnections 経由)
  ├── Build:   CodeBuild — cdk synth
  ├── Mutate:  パイプライン自身を自動更新（セルフミューテーション）
  └── Deploy:  CloudFormation — ThreeTierStack
                  ↓
         [ALB: my-cdk3-alb]
                  ↓
         [EC2: my-cdk3-ap-instance]  ← Tomcat
                  ↓
         [RDS: my-cdk3-rds-mysql]    ← MySQL 8.0

このハンズオンで体験できること（インフラの CI/CD）：

• git push するだけで VPC / EC2 / RDS / ALB などのインフラ構築・更新が自動実行される
• SG ルール追加・インスタンスタイプ変更などのインフラ変更が push で自動反映される
• パイプライン自体の定義変更も自動反映される（セルフミューテーション）

このハンズオンで体験できないこと（アプリの CI/CD）：

このハンズオンでは HTML を EC2 の UserData に埋め込んでいます。UserData は EC2 の初回起動時にのみ実行される仕組みのため、push しても既存 EC2 上のファイルは書き換えられません。
Java アプリ（WAR ファイル）を push で自動デプロイしたい場合は、次のハンズオン cdk-webapp-pipeline（CodeDeploy を使用）で体験します。

この記事は CDK カスタム Construct ハンズオン（cdk-custom-constructs） の発展記事です。
CDK の基本（Bootstrap・synth・deploy）と カスタム Construct を体験済みの方向けです。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-custom-constructs との比較

インフラの構成は cdk-custom-constructs と完全に同等です。変わるのはデプロイの仕組み（手動 → 自動）です。

ファイル構成と役割

cdk-pipelines/
├── app.py                    ← CDK アプリ エントリポイント（PipelineStack を生成）
├── cdk.json                  ← CDK 設定・Context 変数（GitHub 接続情報を含む）
├── pipeline/
│   └── pipeline_stack.py     ← CodePipeline + Synth + Stage を定義するスタック
├── stages/
│   └── three_tier_stage.py   ← Stage（ThreeTierStack をデプロイ対象としてまとめる）
├── stacks/
│   └── three_tier_stack.py   ← 3層Web構成スタック（cdk-custom-constructs から流用）
└── components/
    └── three_tier_web.py     ← カスタム L3 Construct（cdk-custom-constructs から流用）

詳細なコードは GitHub を参照してください。

使用するAWSサービス

注意: ALBは無料枠がありません。ハンズオン後は必ずリソースを削除してください。

前提条件

AWS 認証確認:

aws sts get-caller-identity

CDK Bootstrap 確認（CDKToolkit スタックが存在すれば実施済み）:

aws cloudformation describe-stacks ^
  --stack-name CDKToolkit ^
  --query "Stacks[0].StackStatus" ^
  --output text ^
  --region ap-northeast-1

GitHub アカウントが必要です。aws-learning-projects リポジトリに push できる状態にしておいてください。

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（AWS CLI で実施）
      ↓
② プロジェクトのセットアップ（Python 仮想環境）
      ↓
③ GitHub との接続を作成する（CodeConnections）
      ↓
④ cdk.json を設定する
      ↓
⑤ コードを GitHub にプッシュする
      ↓
⑥ パイプラインスタックをデプロイする（初回のみ手動）
      ↓
⑦ パイプラインの実行状況を確認する
      ↓
⑧ 動作確認（ALBアクセス・SSH・RDS接続）
      ↓
⑨ CI/CD を体験する（インフラ変更を push で自動反映）
      ↓
⑩ リソース削除

【重要】⓪ 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成

aws ec2 create-key-pair ^
  --key-name my-cdk3-key ^
  --query KeyMaterial ^
  --output text ^
  --region ap-northeast-1 > %USERPROFILE%\.ssh\my-cdk3-key.pem

%USERPROFILE%\.ssh\ が存在しない場合は先に mkdir %USERPROFILE%\.ssh を実行してください。

② プロジェクトのセットアップ

cd C:\my-aws\aws-learning-projects\cdk-pipelines

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

プロンプトの先頭に (.venv) が表示されれば仮想環境が有効になっています。

重要: CDK コマンド（synth / deploy / destroy）はすべてこの仮想環境が有効な状態で実行する必要があります。
ターミナルを開き直した際は必ず最初に以下を実行してください。

cd C:\my-aws\aws-learning-projects\cdk-pipelines
.venv\Scripts\activate

③ GitHub との接続を作成する（CodeConnections）

CodePipeline が GitHub リポジトリを監視するために、GitHub との接続（CodeConnections） を作成します。接続の管理はブラウザから行います。

重要: AWS コンソールと GitHub の操作は同じブラウザで行ってください。
別ブラウザで GitHub を操作すると、AWS にリダイレクトされた際にデフォルトリージョン（バージニア北部等）でログインされる場合があります。

接続を作成する

1. AWS コンソール検索（Alt+S）で CodePipeline と入力 → CodePipeline を開く
2. 左サイドバー → 「設定」 → 「接続」
3. リージョンが 東京（ap-northeast-1） になっていることを確認する
4. 「接続を作成」をクリック
5. プロバイダー: GitHub を選択
6. 接続名: my-github-connection（任意）
7. 「GitHub に接続する」をクリック

GitHub App をインストールする

クリック後、GitHub の OAuth 認証画面が開きます。

8. 「Authorize」をクリック → AWS コンソールの「GitHub 接続設定」画面に自動で戻る
9. 「新しいアプリをインストールする」をクリック → GitHub の「Install & Authorize」画面が開く
10. 「Only select repositories」 を選択 → aws-learning-projects を追加
11. 「Install & Authorize」をクリック（メール認証コードが求められる場合は入力）
12. AWS コンソールに自動でリダイレクトされる → 「接続」ボタンをクリック

接続 ARN を確認する

接続一覧から作成した接続の ARN をコピーします。

arn:aws:codeconnections:ap-northeast-1:123456789012:connection/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

重要: ステータスが 「利用可能」 になっていることを確認してから次に進んでください。
「保留中」のままの場合は接続を選択して「保留中の接続を更新する」をクリックします。

控えておく情報: 接続 ARN（arn:aws:codeconnections:...）

④ cdk.json の設定

cdk.json の context セクションを自分の環境に合わせて編集します。

{
  "context": {
    "employee_id": "my",
    "my_ip": "203.0.113.1/32",
    "db_password": "Handson1234!",
    "key_name": "my-cdk3-key",
    "tomcat_version": "10.1.28",
    "github_owner": "your-github-username",
    "github_repo": "aws-learning-projects",
    "github_branch": "main",
    "connection_arn": "arn:aws:codeconnections:ap-northeast-1:..."
  }
}

cdk-custom-constructs（前回）と同時にデプロイしてもリソース名が競合しません。前回は my-cdk2-xxx、今回は my-cdk3-xxx というプレフィックスになります。

⑤ コードを GitHub にプッシュする

パイプラインはリポジトリのコードを監視します。まず現在の変更（cdk.json の更新）を push しておきます。

cd C:\my-aws\aws-learning-projects
git add cdk-pipelines/cdk.json
git commit -m "chore: cdk-pipelines の cdk.json を設定"
git push origin main

⑥ パイプラインスタックのデプロイ（初回のみ）

CDK Pipelines ではパイプライン自体を最初に1回だけ手動でデプロイします。以降はパイプラインが自動的に動作します。

cd C:\my-aws\aws-learning-projects\cdk-pipelines

.venv\Scripts\activate

cdk deploy

「Do you wish to deploy these changes?」に y を入力します。

所要時間: パイプラインスタック自体のデプロイは 3〜5 分

デプロイ完了後、CodePipeline が自動起動します:

所要時間: RDS の作成に 15〜20 分かかります。

⑦ パイプラインの実行状況を確認する

1. AWS コンソール → CodePipeline を開く
2. my-cdk3-pipeline を選択
3. 各ステージが 「成功」 になるまで待つ

実行履歴に「失敗」が表示されている場合:
パイプライン作成直後（GitHub App インストール前）に自動実行された結果が残っている場合があります。
確認すべき実行は「Webhook」トリガーの最新のもののみです。

CloudFormation スタックの命名規則

CDK Pipelines でステージをデプロイすると、CloudFormation スタック名は以下の形式になります:

{StageName}-{StackName}

CdkPipelinesStack（パイプライン）と Deploy-ThreeTierStack（インフラ）の 2つが別スタックとして CloudFormation に表示されます。これは想定通りです。

CloudFormation Outputs の確認

Deploy ステージが完了したら、インフラスタックの Outputs を確認します。

aws cloudformation describe-stacks ^
  --stack-name Deploy-ThreeTierStack ^
  --region ap-northeast-1 ^
  --query "Stacks[0].Outputs"

控えておく情報: ALBEndpoint、EC2PublicIP、RDSEndpoint

⑧ 動作確認

8-1. ALB 経由でWebアクセス確認

Outputs の ALBEndpoint をブラウザで開きます。

EC2 が作成されてから Tomcat が起動するまで 10〜15 分かかります（UserData で Java・Tomcat のインストールが実行されるため）。Deploy ステージ完了直後は 502 Bad Gateway が表示されることが多いです。しばらく待ってリトライしてください。

以下が表示されれば正常です:

AP Server - my-cdk3 3-Tier Web
Deployed via AWS CDK Pipelines (auto-deployed on git push).

8-2. EC2 に SSH 接続する

Outputs の SSHCommand を実行します。

ssh -i %USERPROFILE%\.ssh\my-cdk3-key.pem ec2-user@（EC2PublicIP）

8-3. EC2 から RDS への接続確認

EC2 に SSH 接続後（以下は EC2 上での操作）:

sudo dnf install -y mariadb105

DB_PASSWORD=$(aws ssm get-parameter \
  --name /my/cdk3/db-password \
  --query Parameter.Value \
  --output text \
  --region ap-northeast-1)

mysql -h <RDSEndpoint> -u admin -p${DB_PASSWORD} sampledb

mysql> SHOW DATABASES;
mysql> exit

8-4. SSH 接続を切断する

exit

⑨ CI/CD を体験する（インフラ変更を push で自動反映）

CDK Pipelines の醍醐味は「インフラのコードを push するだけで CloudFormation への変更が自動反映される」ことです。

注意: このハンズオンで自動デプロイできるのはインフラ（CloudFormation リソース）のみです。
HTML や WAR などのアプリファイルは対象外です（次のハンズオン cdk-webapp-pipeline で体験します）。

EC2 にタグを追加して CI/CD を確認する

EC2 タグの追加は EC2 の置き換えなし（in-place 更新）で行われるため、Tomcat が止まらず 2〜3 分でパイプラインが完了します。EC2 コンソールのタグタブで変更を目視確認できます。

stacks/three_tier_stack.py を開き、以下を追加します:

from aws_cdk import Tags

Tags.of(web.instance).add("DeployedBy", "CDK Pipelines v2")

push する

cd C:\my-aws\aws-learning-projects
git add cdk-pipelines/stacks/three_tier_stack.py
git commit -m "test: EC2 タグ追加で CDK Pipelines CI/CD を確認"
git push origin main

パイプラインの自動起動を確認する

1. AWS コンソール → CodePipeline → my-cdk3-pipeline
2. push 後、数十秒以内にパイプラインが自動起動することを確認
3. Deploy ステージが完了するまで待つ（2〜3 分）

タグが反映されたことを確認する

EC2 コンソール → インスタンス → my-cdk3-ap-instance → 「タグ」タブ

DeployedBy = CDK Pipelines v2 が追加されていれば、インフラの CI/CD が正常に動作しています。

⑩ リソース削除

課金を止めるために、ハンズオン完了後は必ず削除します。

削除順序が重要です。パイプラインによってデプロイされたスタック（Deploy-ThreeTierStack）を先に削除してから、パイプラインスタック（CdkPipelinesStack）を削除します。

1. パイプラインで作成されたスタックを削除する

aws cloudformation delete-stack ^
  --stack-name Deploy-ThreeTierStack ^
  --region ap-northeast-1

削除完了（RDS の削除に 10〜15 分かかります）を確認:

aws cloudformation describe-stacks ^
  --stack-name Deploy-ThreeTierStack ^
  --region ap-northeast-1

「does not exist」エラーが出れば削除完了です。

2. パイプラインスタック自体を削除する

cd C:\my-aws\aws-learning-projects\cdk-pipelines

.venv\Scripts\activate

cdk destroy

「Are you sure you want to delete?」に y を入力します。

--app is required エラーが出る場合は cdk-pipelines ディレクトリで実行していません。
必ず cd C:\my-aws\aws-learning-projects\cdk-pipelines を先に実行してください。

3. アーティファクト S3 バケットを削除する（必要な場合）

CDK Pipelines が自動生成するアーティファクトバケットは手動削除が必要な場合があります。

aws s3 ls | findstr pipelineartifacts

バケットが残っている場合:

aws s3 rb s3://<バケット名> --force

4. 仮想環境の終了

deactivate

5. キーペアの削除（手動）

aws ec2 delete-key-pair ^
  --key-name my-cdk3-key ^
  --region ap-northeast-1

del %USERPROFILE%\.ssh\my-cdk3-key.pem

6. GitHub との接続を削除する（手動）

CodePipeline → 設定 → 接続 → my-github-connection → 「削除」

削除されるリソース一覧

CDK Pipelines のポイント解説

なぜ cdk deploy は初回だけ必要なのか

パイプラインが存在しない状態では GitHub push を検知できません。初回の cdk deploy でパイプライン自体を作成する必要があります。以降はパイプラインが自分自身を更新（セルフミューテーション）するため、再度 cdk deploy を手動実行する必要はありません。

Stage クラスの役割

# stages/three_tier_stage.py
class ThreeTierStage(cdk.Stage):
    def __init__(self, ...):
        super().__init__(...)
        ThreeTierStack(self, "ThreeTierStack")  # ← Stage に含めるスタック

Stage に複数スタックを含めると、パイプラインが順序制御してデプロイします:

class MultiStackStage(cdk.Stage):
    def __init__(self, ...):
        super().__init__(...)
        NetworkStack(self, "NetworkStack")  # ← 先にデプロイ
        AppStack(self, "AppStack")          # ← Network の後にデプロイ

モノレポでの primary_output_directory

このリポジトリは複数ハンズオンが共存するモノレポ構成のため、cdk synth をサブディレクトリで実行する設定が必要です:

CodeBuildStep(
    "Synth",
    commands=[
        "cd cdk-pipelines",        # ← サブディレクトリに移動
        "pip install -r requirements.txt",
        "npx cdk synth",
    ],
    primary_output_directory="cdk-pipelines/cdk.out",  # ← cdk.out の場所を指定
)

トラブルシューティング

パイプライン失敗時のログ確認（CodeBuild）:

1. AWS コンソール → CodePipeline → my-cdk3-pipeline
2. 失敗したステージの「詳細」→「ログを表示」をクリック
3. CloudWatch Logs でエラーを確認

まとめ

CDK Pipelines の最大のメリットは「インフラのコードが唯一の変更手段になる」点です。誰かが AWS コンソールで手動変更しても、次の push でコードの状態に戻されます。これにより環境の一貫性を保てます。

今回はインフラの CI/CD のみを体験しました。アプリ（Java WAR ファイル）の自動デプロイを体験したい場合は、次のハンズオン cdk-webapp-pipeline（CodeDeploy を使用）で体験できます。

コンソールで3層構成を視覚的に学びたい場合は AWSコンソール版ハンズオン、CDK の基本は CDK版ハンズオン（cdk-alb-ec2-rds）、カスタム Construct は CDK カスタム Construct ハンズオン を参照してください。

The post CDK Pipelines でインフラの CI/CD を構築する【git push だけで ALB + EC2 + RDS が自動デプロイ】 first appeared on CayTech Lab.

はじめに

前回のAWSコンソール版ハンズオン（Spring Boot Webアプリ）では、コンソールでインフラを手動構築してSCPでWARをデプロイしました。

この記事では、同じ構成を CloudFormation で自動化します。template.yaml 1ファイルにVPC・SG・IAM・SSM・RDS・ALB・EC2（約30リソース）を定義し、さらに EC2のUserDataがS3からWARを自動取得してTomcatにデプロイするため、コマンド数本でWebアプリが動く状態まで一気に構築できます。

ローカル環境（VSCode）
  ├── app/target/webapp.war（mvn packageでビルド済み）
  ├── template.yaml（約30リソースを定義）
  └── AWS CLI コマンド
        ↓ スタック作成（コマンド1本）
AWS環境
  ├── S3バケット（webapp.war置き場）
  └── VPC（10.0.0.0/16）
        ├── パブリックサブネット1・2（ALB + EC2）
        ├── プライベートサブネット1・2（RDS）
        ├── IGW + ルートテーブル
        ├── IAMロール（SSM + S3読み取り権限）
        ├── ALB SG → EC2 SG → RDS SG（SG-to-SG制御）
        ├── SSM Parameter Store（/my/webapp/db-password）
        ├── RDS MySQL 8.0（db.t3.micro / sampledb）
        ├── ALB（HTTP:80）→ TG（HTTP:8080）
        └── EC2（t2.micro）
              UserDataが自動実行:
              1. Java + Tomcat インストール
              2. SSMからDBパスワード取得 → setenv.sh作成
              3. S3からwebapp.warをダウンロード → ROOT.warとして配置
              4. Tomcat起動（Spring Bootアプリが自動展開）

このハンズオンで体験できること：

• WARのデプロイをS3 + UserDataで完全自動化する設計
• SSMからDB接続情報を取得してsetenv.shを自動作成する仕組み
• delete-stack 1本でALB・RDS・IAMなど全リソースを自動削除

テンプレートとアプリのソースコードはGitHubで公開しています：

aws-handson/alb-ec2-rds-webapp at main · caymezon/aws-handson

AWS HANDSON. Contribute to caymezon/aws-handson development by creating an account on GitHub.

github.com

この記事は AWSコンソール版ハンズオン の比較記事です。
コンソール版でSCPデプロイの仕組みを理解した後に読むと理解が深まります。

-->

CloudFormation vs コンソール：どれだけ違うか

キーワード解説

前提条件

aws sts get-caller-identity
aws --version
java -version
mvn -version

構築されるリソース（約30個）

template.yaml の詳細はGitHubを参照してください：

aws-handson/alb-ec2-rds-webapp/template.yaml at main ?? caymezon/aws-handson

AWS HANDSON. Contribute to caymezon/aws-handson development by creating an account on GitHub.

github.com

作業順序

⓪ Webアプリをビルドする（mvn package）
      ↓
⓪-2 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（コンソールで実施）
      ↓
② S3バケットを作成してWARをアップロードする
      ↓
③ スタックを作成する（aws cloudformation create-stack）
      ↓
④ 作成完了・Outputsを確認する（RDS待ち15〜20分）
      ↓
⑤ 動作確認（ALBアクセス・アイテム追加削除）
      ↓
⑥ スタックを削除する（S3バケットも忘れず削除）

⓪ Webアプリのビルド

アプリのソースコードはGitHubで公開しています：

aws-handson/alb-ec2-rds-webapp/app at main ?? caymezon/aws-handson

AWS HANDSON. Contribute to caymezon/aws-handson development by creating an account on GitHub.

github.com

cd C:\（プロジェクトフォルダ）\alb-ec2-rds-webapp\app
mvn package -DskipTests
dir target\webapp.war

webapp.war（約20〜30MB）が生成されていれば成功です。

⓪-2 自分のIPアドレスを確認する

curl https://checkip.amazonaws.com

控えておく情報: 自分のIPアドレス（例: 203.0.113.1）

① キーペアの作成（コンソールで実施）

CloudFormationではキーペアのダウンロードができないため、コンソールで先に作成します。

AWSコンソール → EC2 → キーペア → 「キーペアを作成」

ダウンロードされた my-webapp-key.pem を保存します。

C:\Users\ユーザー名\.ssh\my-webapp-key.pem

② S3バケットの作成とWARのアップロード

EC2のUserDataがS3から webapp.war をダウンロードするため、スタック作成より前にアップロードしておく必要があります。

プロジェクトフォルダに移動する

cd C:\（プロジェクトフォルダ）\alb-ec2-rds-webapp

S3バケットを作成する

バケット名はグローバルで一意である必要があります。末尾に任意の識別子を加えてユニークにしてください。

aws s3 mb s3://my-webapp-bucket-（任意の識別子） --region ap-northeast-1

WARをS3にアップロードする

aws s3 cp app\target\webapp.war s3://my-webapp-bucket-（任意の識別子）/webapp.war

アップロードを確認します。

aws s3 ls s3://my-webapp-bucket-（任意の識別子）/

2026-04-18 10:00:00   26214400 webapp.war

③ スタックの作成

以下のコマンドを実行します。各パラメータを自分の値に置き換えます。

aws cloudformation create-stack ^
  --stack-name my-webapp-stack ^
  --template-body file://template.yaml ^
  --region ap-northeast-1 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --parameters ^
    ParameterKey=KeyName,ParameterValue=my-webapp-key ^
    ParameterKey=MyIP,ParameterValue=（⓪-2で確認したIP）/32 ^
    ParameterKey=DBPassword,ParameterValue=（任意のパスワード） ^
    ParameterKey=WARBucketName,ParameterValue=my-webapp-bucket-（任意の識別子）

CAPABILITY_NAMED_IAM について: 名前を指定したIAMリソース（EC2ロールなど）を作成する場合に必要なフラグです。

TomcatVersion パラメータについて: デフォルト値は 10.1.28。変更する場合は ParameterKey=TomcatVersion,ParameterValue=10.1.xx を追加します。利用可能なバージョンは https://archive.apache.org/dist/tomcat/tomcat-10/ で確認します。

成功すると以下のような StackId が表示されます。

{
    "StackId": "arn:aws:cloudformation:ap-northeast-1:123456789012:stack/my-webapp-stack/xxxxx"
}

④ 作成完了・Outputsの確認

注意: RDSの作成には約15〜20分かかります。EC2のUserDataでWARのデプロイも行うため、さらに数分かかります。

作成状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-webapp-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

Outputs（接続情報）の確認

CREATE_COMPLETE になったら以下を実行します。

aws cloudformation describe-stacks ^
  --stack-name my-webapp-stack ^
  --query "Stacks[0].Outputs" ^
  --output table

+--------------------+-------------------------------------------------------------------+
|  OutputKey         |  OutputValue                                                      |
+--------------------+-------------------------------------------------------------------+
|  ALBEndpoint       |  http://my-webapp-alb-1234567890.ap-northeast-1.elb.amazonaws.com |
|  EC2PublicIP       |  x.x.x.x                                                         |
|  RDSEndpoint       |  my-webapp-rds-mysql.xxxxx.ap-northeast-1.rds.amazonaws.com      |
|  DBPasswordParamName |  /my/webapp/db-password                                         |
|  SSHCommand        |  ssh -i ~/.ssh/my-webapp-key.pem ec2-user@x.x.x.x               |
+--------------------+-------------------------------------------------------------------+

控えておく情報: ALBEndpoint、EC2PublicIP、RDSEndpoint

⑤ 動作確認

ALBのヘルスチェック確認

EC2 → ターゲットグループ → my-webapp-tg → 「ターゲット」タブ

EC2のステータスが 「healthy」 になるまで待ちます（EC2起動後5〜10分）。

Tomcatの起動 + WARのデプロイはEC2「実行中」からさらに数分かかります。initial や unhealthy が続く場合はしばらく待ちます。

ALB経由でWebアプリにアクセスする

Outputsに表示された ALBEndpoint をブラウザで開きます。

http://（ALBEndpointのDNS名）

Spring Boot + RDS Item Manager
ALB → EC2(Tomcat) → RDS MySQL の3層構成で動作しています。

が表示されれば成功です。

アイテムの追加・削除を試す

1. テキストボックスにアイテム名を入力して「追加」をクリック
2. アイテムが一覧に表示されることを確認
3. 「削除」ボタンでアイテムが削除されることを確認

ブラウザをリロードしてもデータが保持されていれば、RDSへの永続化が成功しています。

（任意）ログでデプロイ過程を確認する

OutputsのSSHCommandでEC2に接続して確認します。

sudo cat /var/log/user-data.log

# Tomcatのログ（Spring Bootのスタートアップログ）
sudo tail -50 /opt/tomcat/logs/catalina.out

# setenv.shの内容確認（DB接続情報が正しく設定されているか）
sudo cat /opt/tomcat/bin/setenv.sh

exit

⑥ スタックの削除

課金を止めるために、ハンズオン完了後は必ず削除します。

スタックを削除する

aws cloudformation delete-stack ^
  --stack-name my-webapp-stack ^
  --region ap-northeast-1

注意: RDS削除には約10〜15分かかります。

削除状況の確認

aws cloudformation describe-stacks ^
  --stack-name my-webapp-stack ^
  --query "Stacks[0].StackStatus" ^
  --output text

削除完了の確認（以下のエラーが表示されれば削除完了）:

An error occurred (ValidationError) when calling the DescribeStacks operation:
Stack with id my-webapp-stack does not exist

S3バケットを削除する

S3バケットはCloudFormationで管理していないため手動で削除します。

aws s3 rm s3://my-webapp-bucket-（任意の識別子） --recursive
aws s3 rb s3://my-webapp-bucket-（任意の識別子）

キーペアを削除する（任意）

EC2 → キーペア → my-webapp-key を選択 → 「アクション」→「削除」

コンソール版との比較

トラブルシューティング

失敗時の詳細確認コマンド

aws cloudformation describe-stack-events ^
  --stack-name my-webapp-stack ^
  --query "StackEvents[?ResourceStatus=='CREATE_FAILED'].[ResourceType,ResourceStatusReason]" ^
  --output table

まとめ

CloudFormation版の最大のポイントはWARデプロイの自動化です。コンソール版ではSCPでWARを転送してSSHでsetenv.shを作成する必要がありましたが、今回はS3にWARをアップロードするだけでUserDataが全て自動で行います。

コンソール操作でSCPデプロイの仕組みを手を動かして確認したい場合は、AWSコンソール版ハンズオンを参照してください。

The post CloudFormationでSpring Boot WebアプリをALB + EC2(Tomcat) + RDS に自動デプロイする手順【S3 + UserData / WAR自動配布】 first appeared on CayTech Lab.

GitHub×AWSで実現できること

自動化の全体像

コード変更（git push）
  ↓
GitHub Actions自動実行
  ↓
ビルド・テスト
  ↓
AWSへ自動デプロイ
  ↓
本番環境更新

メリット：

• 手動デプロイの排除
• ヒューマンエラー削減
• リリース時間短縮
• 一貫性のある環境構築

できることの例

事前準備

必要なもの

GitHub側：

• GitHubアカウント
• リポジトリ（Public/Private）

AWS側：

• AWSアカウント
• IAMユーザー（適切な権限）
• 対象サービス（EC2/S3など）

IAMユーザー作成

手順：

1. AWSコンソール → IAM
2. Users → Add users
3. ユーザー名: github-actions-user
4. Access key - Programmatic access ✅
5. Attach policies directly:
   - AmazonEC2FullAccess（EC2デプロイ用）
   - AmazonS3FullAccess（S3デプロイ用）
6. Create user
7. Access Key ID と Secret Access Key を保存

注意： 本番環境では最小権限の原則に従い、必要な権限のみ付与してください。

GitHub Secretsに認証情報を保存

1. GitHubリポジトリ → Settings
2. Secrets and variables → Actions
3. New repository secret

登録する情報：
- AWS_ACCESS_KEY_ID: （IAMのAccess Key ID）
- AWS_SECRET_ACCESS_KEY: （IAMのSecret Access Key）
- AWS_REGION: ap-northeast-1（東京リージョン）

ハンズオン1：EC2にNode.jsアプリを自動デプロイ

システム構成

GitHub Repository
  ↓ git push
GitHub Actions
  ↓ SSH接続
EC2インスタンス
  ↓ アプリ更新
Webアプリ公開

EC2インスタンスの準備

1. インスタンス起動：

AMI: Amazon Linux 2023
インスタンスタイプ: t2.micro（無料枠）
セキュリティグループ:
  - SSH (22) ← 自分のIP
  - HTTP (80) ← 0.0.0.0/0
  - Custom (3000) ← 0.0.0.0/0（開発用）

2. SSH接続して環境構築：

ssh -i your-key.pem ec2-user@your-ec2-ip

# Node.jsインストール
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash
source ~/.bashrc
nvm install 20
nvm use 20

# アプリディレクトリ作成
mkdir ~/myapp
cd ~/myapp

# pm2インストール（プロセス管理）
npm install -g pm2

3. SSH鍵をGitHub Secretsに登録：

秘密鍵（your-key.pem）の内容をコピー

GitHub Secrets に登録：
- EC2_SSH_KEY: （秘密鍵の内容）
- EC2_HOST: （EC2のパブリックIP）
- EC2_USER: ec2-user

サンプルアプリ作成

package.json：

{
  "name": "github-aws-demo",
  "version": "1.0.0",
  "scripts": {
    "start": "node server.js"
  },
  "dependencies": {
    "express": "^4.18.0"
  }
}

server.js：

const express = require('express');
const app = express();
const PORT = process.env.PORT || 3000;

app.get('/', (req, res) => {
  res.send(`
    
GitHub Actions × AWS EC2
    
自動デプロイ成功！
    
デプロイ時刻: ${new Date().toLocaleString('ja-JP')}
  `);
});

app.get('/health', (req, res) => {
  res.json({ status: 'OK' });
});

app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

GitHub Actions設定

.github/workflows/deploy-ec2.yml：

name: Deploy to EC2

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Deploy to EC2
        env:
          SSH_KEY: ${{ secrets.EC2_SSH_KEY }}
          HOST: ${{ secrets.EC2_HOST }}
          USER: ${{ secrets.EC2_USER }}
        run: |
          # SSH秘密鍵を設定
          echo "$SSH_KEY" > private_key.pem
          chmod 600 private_key.pem
          
          # EC2にファイル転送
          scp -i private_key.pem -o StrictHostKeyChecking=no -r \
            server.js package.json ${USER}@${HOST}:~/myapp/
          
          # EC2でアプリ更新
          ssh -i private_key.pem -o StrictHostKeyChecking=no ${USER}@${HOST} << 'EOF'
            cd ~/myapp
            npm install
            pm2 restart myapp || pm2 start server.js --name myapp
            pm2 save
          EOF
          
          # 秘密鍵削除
          rm -f private_key.pem
      
      - name: Verify deployment
        run: |
          sleep 5
          curl -f http://${{ secrets.EC2_HOST }}:3000/health || exit 1
          echo "Deployment successful!"

デプロイ実行

1. リポジトリにプッシュ：

git add .
git commit -m "Add EC2 auto deploy"
git push origin main

2. GitHub Actionsで確認：

Actions タブ
→ Deploy to EC2 ワークフロー
→ ログ確認
→ ✅ 成功

3. ブラウザでアクセス：

http://your-ec2-ip:3000
→ 「自動デプロイ成功！」表示

完了！ コードを変更してpushするたびに自動デプロイされます。

GitHub Actionsの実践例は「【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い」でも紹介しています。

ハンズオン2：S3で静的サイトを自動公開

システム構成

GitHub Repository（HTML/CSS/JS）
  ↓ git push
GitHub Actions
  ↓ AWS CLI
S3バケット
  ↓ 静的Webホスティング
インターネット公開

S3バケット作成

1. バケット作成：

1. S3コンソール → Create bucket
2. Bucket name: my-github-demo-site（グローバルで一意）
3. Region: ap-northeast-1
4. Block Public Access: すべてOFF（公開用）
5. Create bucket

2. 静的Webホスティング有効化：

バケット → Properties
→ Static website hosting → Enable
→ Index document: index.html
→ Error document: error.html
→ Save changes

3. バケットポリシー設定：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-github-demo-site/*"
    }
  ]
}

サンプルサイト作成

index.html：

  
  
  
  


  

    
GitHub Actions × S3
    
静的サイトの自動デプロイ成功！
    

  
  

style.css：

body {
  font-family: Arial, sans-serif;
  display: flex;
  justify-content: center;
  align-items: center;
  min-height: 100vh;
  margin: 0;
  background: linear-gradient(135deg, #667eea 0%, #764ba2 100%);
}

.container {
  background: white;
  padding: 2rem;
  border-radius: 10px;
  box-shadow: 0 10px 30px rgba(0,0,0,0.3);
  text-align: center;
}

h1 {
  color: #333;
  margin-bottom: 1rem;
}

script.js：

document.getElementById('timestamp').textContent = 
  `最終デプロイ: ${new Date().toLocaleString('ja-JP')}`;

GitHub Actions設定

.github/workflows/deploy-s3.yml：

name: Deploy to S3

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      
      - name: Sync to S3
        run: |
          aws s3 sync . s3://my-github-demo-site \
            --exclude ".git/*" \
            --exclude ".github/*" \
            --delete
      
      - name: Invalidate CloudFront (optional)
        run: |
          echo "CloudFront未使用の場合はスキップ"
          # aws cloudfront create-invalidation \
          #   --distribution-id YOUR_DISTRIBUTION_ID \
          #   --paths "/*"

デプロイ実行

1. プッシュ：

git add .
git commit -m "Add S3 static site deploy"
git push origin main

2. S3エンドポイントにアクセス：

http://my-github-demo-site.s3-website-ap-northeast-1.amazonaws.com

完了！ HTMLを変更するたびに自動で公開されます。

ハンズオン3：Lambda関数の自動デプロイ

システム構成

GitHub Repository（Lambda関数）
  ↓ git push
GitHub Actions
  ↓ zip & AWS CLI
Lambda関数更新
  ↓ API Gateway
REST API公開

Lambda関数作成

1. AWSコンソールでLambda作成：

Lambda → Create function
Function name: github-demo-function
Runtime: Node.js 20.x
Create function

2. 環境変数設定（オプション）：

Configuration → Environment variables
Key: STAGE
Value: production

サンプル関数

index.js：

exports.handler = async (event) => {
  console.log('Event:', JSON.stringify(event));
  
  const name = event.queryStringParameters?.name || 'World';
  const timestamp = new Date().toISOString();
  
  return {
    statusCode: 200,
    headers: {
      'Content-Type': 'application/json',
      'Access-Control-Allow-Origin': '*'
    },
    body: JSON.stringify({
      message: `Hello, ${name}!`,
      timestamp: timestamp,
      environment: process.env.STAGE || 'development',
      deployedBy: 'GitHub Actions'
    })
  };
};

package.json：

{
  "name": "github-lambda-demo",
  "version": "1.0.0",
  "description": "GitHub Actions Lambda deployment demo"
}

GitHub Actions設定

.github/workflows/deploy-lambda.yml：

name: Deploy to Lambda

on:
  push:
    branches: [main]
    paths:
      - 'lambda/**'

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
      - name: Checkout code
        uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '20'
      
      - name: Install dependencies
        working-directory: ./lambda
        run: npm install --production
      
      - name: Create deployment package
        working-directory: ./lambda
        run: |
          zip -r function.zip .
      
      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v2
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}
      
      - name: Deploy to Lambda
        working-directory: ./lambda
        run: |
          aws lambda update-function-code \
            --function-name github-demo-function \
            --zip-file fileb://function.zip
      
      - name: Wait for update
        run: |
          aws lambda wait function-updated \
            --function-name github-demo-function
      
      - name: Test Lambda function
        run: |
          aws lambda invoke \
            --function-name github-demo-function \
            --payload '{"queryStringParameters":{"name":"GitHub"}}' \
            response.json
          cat response.json

API Gateway設定（オプション）

REST APIとして公開：

1. API Gateway → Create API
2. REST API → Build
3. Create resource: /hello
4. Create method: GET
5. Integration type: Lambda Function
6. Lambda Function: github-demo-function
7. Deploy API → Stage: prod

エンドポイント：

https://xxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/hello?name=World

応用パターン

パターン1：環境別デプロイ

複数環境の管理：

on:
  push:
    branches:
      - main      # 本番環境
      - develop   # 開発環境

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Set environment
        run: |
          if [ "${{ github.ref }}" == "refs/heads/main" ]; then
            echo "ENVIRONMENT=production" >> $GITHUB_ENV
            echo "LAMBDA_FUNCTION=prod-function" >> $GITHUB_ENV
          else
            echo "ENVIRONMENT=development" >> $GITHUB_ENV
            echo "LAMBDA_FUNCTION=dev-function" >> $GITHUB_ENV
          fi
      
      - name: Deploy
        run: |
          aws lambda update-function-code \
            --function-name ${{ env.LAMBDA_FUNCTION }} \
            --zip-file fileb://function.zip

パターン2：ブルーグリーンデプロイ

無停止デプロイ：

- name: Create new version
  run: |
    VERSION=$(aws lambda publish-version \
      --function-name my-function \
      --query 'Version' --output text)
    echo "VERSION=$VERSION" >> $GITHUB_ENV

- name: Update alias
  run: |
    aws lambda update-alias \
      --function-name my-function \
      --name production \
      --function-version ${{ env.VERSION }}

パターン3：ロールバック機能

デプロイ失敗時の自動ロールバック：

- name: Deploy and test
  id: deploy
  run: |
    # デプロイ
    aws lambda update-function-code ...
    
    # ヘルスチェック
    if ! curl -f https://api.example.com/health; then
      exit 1
    fi

- name: Rollback on failure
  if: failure() && steps.deploy.outcome == 'failure'
  run: |
    aws lambda update-function-code \
      --function-name my-function \
      --s3-bucket backup-bucket \
      --s3-key previous-version.zip

トラブルシューティング

問題1：EC2デプロイでSSH接続失敗

エラー：

Permission denied (publickey)

原因：

• SSH鍵の改行コードが正しくない
• 鍵の権限が適切でない

解決：

# 改行コードを明示的に処理
run: |
  echo "$SSH_KEY" | tr -d '\r' > private_key.pem
  chmod 600 private_key.pem

問題2：S3デプロイで403エラー

原因：

• IAMユーザーに権限がない
• バケットポリシーが未設定

解決：

1. IAMユーザーに AmazonS3FullAccess 付与
2. バケットポリシーで PublicReadGetObject 設定
3. ブロックパブリックアクセスを確認

問題3：Lambda関数が更新されない

原因：

• 関数名が間違っている
• zipファイルサイズ超過（50MB制限）

解決：

# 関数名確認
aws lambda list-functions

# zipサイズ確認
ls -lh function.zip

# 大きい場合はS3経由でデプロイ
aws s3 cp function.zip s3://my-bucket/
aws lambda update-function-code \
  --function-name my-function \
  --s3-bucket my-bucket \
  --s3-key function.zip

セキュリティベストプラクティス

1. IAM権限の最小化

NG（フルアクセス）：

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

OK（必要な権限のみ）：

{
  "Effect": "Allow",
  "Action": [
    "s3:PutObject",
    "s3:DeleteObject",
    "lambda:UpdateFunctionCode"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket/*",
    "arn:aws:lambda:ap-northeast-1:*:function:my-function"
  ]
}

2. Secrets管理

GitHub Secrets以外の選択肢：

• AWS Secrets Manager：より高度な管理
• AWS Systems Manager Parameter Store：無料枠あり

GitHub ActionsでSecrets Manager使用：

- name: Get secrets
  run: |
    SECRET=$(aws secretsmanager get-secret-value \
      --secret-id my-app-secret \
      --query SecretString --output text)
    echo "::add-mask::$SECRET"
    echo "SECRET=$SECRET" >> $GITHUB_ENV

3. 監査ログ

CloudTrailで操作履歴記録：

CloudTrail → Create trail
→ S3バケットに操作ログ保存
→ GitHub Actionsの操作も記録

まとめ

GitHub ActionsとAWSの連携で、強力な自動化基盤を構築できます。

実装したハンズオン：

1. EC2自動デプロイ：Node.jsアプリをSSH経由でデプロイ
2. S3静的サイト：HTML/CSS/JSを自動公開
3. Lambda関数：サーバーレス関数の自動更新

メリット：

• 手動作業の削減
• デプロイミスの防止
• 一貫性のある環境
• リリース時間の短縮

コスト：

• GitHub Actions：パブリックリポジトリは無料
• AWS無料枠：1年間または月次制限内
• 実質コスト：ほぼ無料で始められる

まずは簡単なS3デプロイから始めて、徐々に複雑な構成に挑戦してみましょう！

関連記事

• 【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い

【試行錯誤の記録】GitHub ActionsでWordPress自動投稿！403エラーとの戦い

はじめにVSCodeでMarkdownを書いて、git push するだけでWordPressに自動投稿される――そんな夢のようなシステムを作ろうと、GitHub Actions連携に挑戦しました。しかし、待っていたのは 403 Forbi...

caymezon.com

2026.01.12

• GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI完全ガイド：コマンドラインでGitHub操作を効率化

GitHub CLI（ghコマンド）は、GitHubの操作をコマンドラインで完結できる公式ツールです。ブラウザを開かずに、リポジトリ作成からIssue管理、Pull Request作成まで、すべてターミナルで行えます。この記事では、実際の導...

caymezon.com

2026.01.31

• VSCodeでGitを使いこなす：初心者から実務まで完全ガイド

VSCodeでGitを使いこなす完全ガイド｜GUI操作とCLIコマンドを徹底比較

はじめにVSCodeでアプリケーション開発をしている方の多くが、Gitによるバージョン管理を導入しています。しかし、「CLIコマンドならわかるけど、VSCodeのGUI操作がよくわからない」「どのメニューから操作すればいいのか迷う」といった...

caymezon.com

2026.02.02

The post GitHub×AWS実践ハンズオン：ActionsでEC2自動デプロイから始める連携活用術 first appeared on CayTech Lab.