「GitHub Actions は GitHub に依存してしまう。AWS だけで CI/CD を完結させたい」——そんなニーズに応えるのが AWS Code 4 兄弟（CodeCommit・CodeBuild・CodeDeploy・CodePipeline） です。さらに共通ライブラリは AWS CodeArtifact で管理するフルマネージドな AWS CI/CD パイプラインを構築します。

前のハンズオン（EC2 + GitHub Actions）との最大の違いは、すべてが AWS の中で完結することです。ソース管理・ビルド・ライブラリ管理・デプロイ、すべてを AWS サービスで担います。

[CodeCommit リポジトリ] ← git push
         ↓
[CodePipeline: my-cp-pipeline]
  Stage 1: Source  — CodeCommit からソースを取得
  Stage 2: Build   — CodeBuild で mvn package
                        ├─ CodeArtifact から認証トークン取得
                        ├─ common-lib を CodeArtifact に publish
                        ├─ CodeArtifact から common-lib を取得
                        └─ webapp.war を生成
  Stage 3: Deploy  — CodeDeploy で EC2 に配備
                        ├─ Tomcat を停止
                        ├─ WAR を配置
                        └─ Tomcat を再起動
         ↓
[EC2: Tomcat + Spring Boot]  my-cpapp
         ↓
[ALB: my-cp-alb] ← インターネット
         ↓
[RDS MySQL: my-cp-rds]

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

• CodeCommit + CodeBuild + CodeDeploy + CodePipeline による完全 AWS CI/CD
• CodeArtifact による Maven ライブラリの社内管理（Maven Central のプロキシも体験）
• buildspec.yml でビルド手順をコード化する
• git-remote-codecommit で AWS CLI 認証のまま CodeCommit に push する
• CloudFormation で全リソース（パイプラインを含む）を一括構築

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

-->

キーワード解説

① 全体構成を理解する

CodeArtifact とは

CodeArtifact は AWS が提供するマネージドな Maven リポジトリです。GitHub Packages との大きな違いの一つが Maven Central のプロキシ機能です。

mvn package
  └─ CodeArtifact (my-cp-libs)
       ├── 社内ライブラリ: com.example:common-utils:1.0.0  ← CodeBuild が publish
       └── 外部ライブラリ: org.springframework.boot:*      ← Maven Central から透過的に取得

外部依存関係も CodeArtifact 経由でキャッシュされるため、インターネット接続なしでも再現性の高いビルドが可能になります。

buildspec.yml の処理フロー

buildspec.yml は CodeBuild が実行するビルド手順を定義します：

phases:
  install:
    runtime-versions:
      java: corretto17    # Amazon Corretto 17 を使用

  pre_build:
    commands:
      # settings.xml に書き込んで Maven 認証を設定
      - CODEARTIFACT_TOKEN=$(aws codeartifact get-authorization-token ...)
      - CODEARTIFACT_URL=$(aws codeartifact get-repository-endpoint ...)

  build:
    commands:
      # common-lib を CodeArtifact に publish（すでに存在する場合はスキップ）
      - mvn deploy -f common-lib/pom.xml -Dcodeartifact.url="$CODEARTIFACT_URL"
      # app の WAR をビルド（CodeArtifact から common-lib を取得）
      - mvn package -f app/pom.xml -DskipTests -Dcodeartifact.url="$CODEARTIFACT_URL"
      - cp app/target/webapp.war webapp.war

artifacts:
  files:
    - webapp.war
    - appspec.yml
    - scripts/**/*   # CodeDeploy のフックスクリプト

ポイント：pom.xml の CodeArtifact URL はプレースホルダー（${codeartifact.url}）で、buildspec.yml が -Dcodeartifact.url= で実行時に渡します。pom.xml を事前に編集する必要はありません。

② CloudFormation スタックを作成する

自分の IP アドレスを確認し（curl https://checkip.amazonaws.com）、CloudFormation でインフラを一括作成します：

aws cloudformation deploy ^
  --template-file ec2-codepipeline/infra/template.yaml ^
  --stack-name my-cpapp-stack ^
  --parameter-overrides EmployeeId=my DBPassword=Handson1234! MyIP=123.456.78.901/32 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --region ap-northeast-1

所要時間：約 10〜15 分（VPC・EC2・RDS の作成に時間がかかります）

CloudFormation スタックが作成するリソース：

③ Outputs を確認する

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

CodeCommitCloneUrlHttp と ALBEndpoint の値を控えておきます。

④ git-remote-codecommit をインストールする

CodeCommit への push には git-remote-codecommit を使います。AWS CLI の認証情報をそのまま使えるため、Git 専用の認証情報を別途作成する必要がありません：

pip install git-remote-codecommit

インストール後、codecommit:: プレフィックスの URL で clone・push が可能になります。

⑤ ソースコードを CodeCommit に push する

⑤-1 CodeCommit リポジトリを clone する

git clone codecommit::ap-northeast-1://my-cpapp %TEMP%\my-cpapp

codecommit:: プレフィックスを使うことで、AWS CLI の認証情報が自動的に使われます（認証プロンプトは出ません）。

⑤-2 ソースコードをコピーして push する

xcopy ec2-codepipeline\* %TEMP%\my-cpapp\ /E /I /H /Y
cd %TEMP%\my-cpapp

git add .
git commit -m "initial commit"
git branch -M main
git push origin main

push が完了すると CodePipeline が自動的に起動します。

⑥ CodePipeline の動作を確認する

AWS コンソール → CodePipeline → my-cp-pipeline

3 つのステージが順番に実行されます：

合計：約 8〜10 分

⑦ CodeBuild のログを確認する

AWS コンソール → CodeBuild → my-cpapp-build → 「ビルド履歴」タブ

ビルド実行をクリックするとインラインログが確認できます。以下が表示されれば正常です：

=== CodeArtifact 認証トークン取得 ===
CodeArtifact URL = https://my-domain-XXXX.d.codeartifact.ap-northeast-1.amazonaws.com/maven/my-libs/
Maven settings.xml 生成完了
=== common-lib を CodeArtifact に publish ===
[INFO] BUILD SUCCESS
=== webapp WAR をビルド ===
[INFO] BUILD SUCCESS
=== デプロイパッケージを準備 ===
ビルド完了

CodeArtifact の認証トークンは 12 時間有効な一時トークンです。有効期限が切れても次のビルド時に自動取得されるため、管理の手間がありません。

⑧ CodeDeploy の状況を確認する

AWS コンソール → CodeDeploy → アプリケーション → my-cpapp → デプロイグループ → 最新のデプロイメント

各フックスクリプト（stop_server → install → start_server → validate_service）の実行結果が確認できます。デプロイが失敗した場合はここでエラー詳細を確認します。

⑨ アプリの動作確認をする

パイプラインが成功したら ALB 経由でアクセスします：

curl http://<ALBEndpoint の値>/api/health
rem → {"status":"ok","message":null,"data":"OK"}

curl http://<ALBEndpoint の値>/api/items
rem → {"status":"ok","message":null,"data":[]}

ブラウザで ALBEndpoint にアクセスするとアイテム管理 UI が表示されます。

⑩ CI/CD サイクルを体験する

CodeCommit にコードを push するだけでパイプラインが自動実行される CI/CD を体験します：

cd %TEMP%\my-cpapp

app\src\main\resources\templates\index.html を開いてタイトルを変更します：

<!-- 変更後 -->
<h1>Spring Boot + RDS Item Manager (EC2 v2) <span class="badge">CodePipeline</span></h1>

git add app\src\main\resources\templates\index.html
git commit -m "feat: update title to EC2 v2"
git push origin main

CodePipeline コンソール（my-cp-pipeline）で全ステージが成功になるまで待ちます（約 8〜10 分）。ALB にアクセスしてタイトルが変わっていることを確認します。

⑪ CodeArtifact のパッケージを確認する

AWS コンソール → CodeArtifact → ドメイン my-domain → リポジトリ my-libs → パッケージ一覧

com.example:common-utils:1.0.0 が登録されていることを確認します。CLI でも確認できます：

aws codeartifact list-packages ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --region ap-northeast-1

また、Maven Central のプロキシとして機能しているため、org.springframework.boot なども一覧に表示されます。これらは外部から初回取得時にキャッシュされたものです。

⑫ SSM Session Manager で EC2 に接続する（オプション）

キーペアなしで EC2 内部を確認できます：

aws ssm start-session ^
  --target i-xxxxxxxxxxxxxxxxx ^
  --region ap-northeast-1

# Tomcat のステータス確認
sudo systemctl status tomcat

# CodeDeploy エージェントのログ確認
sudo cat /var/log/aws/codedeploy-agent/codedeploy-agent.log

# SSM から取得した DB 接続情報の確認
sudo cat /opt/tomcat/current/bin/setenv.sh

# Tomcat ログの確認
sudo journalctl -u tomcat -n 50

⑬ リソースを削除する

CodeArtifact にパッケージが存在するとドメインが削除できないため、先にパッケージを手動削除します。

① CodeArtifact のパッケージを削除する

aws codeartifact delete-package-versions ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --format maven ^
  --namespace com.example ^
  --package common-utils ^
  --versions 1.0.0 ^
  --region ap-northeast-1

aws codeartifact delete-package ^
  --domain my-domain ^
  --domain-owner 123456789012 ^
  --repository my-libs ^
  --format maven ^
  --namespace com.example ^
  --package common-utils ^
  --region ap-northeast-1

② S3 バケットを空にする

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

aws s3 rm s3://<ArtifactBucketName の値> --recursive

③ CloudFormation スタックを削除する

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

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

echo 削除完了

④ ローカルの clone ディレクトリを削除する

rmdir /S /Q %TEMP%\my-cpapp

まとめ：学んだ概念

GitHub Actions を使った前のハンズオンと比較すると、CodePipeline は すべてが AWS 内で完結する一方、GitHub Actions は Git リポジトリと AWS の柔軟な組み合わせが強みです。どちらを使うかはチームの方針や既存インフラに合わせて選択しましょう。

次のステップとして、CDK + ECS Fargate ハンズオンで EC2 からコンテナ化への移行も体験してみましょう。

The post EC2 + CodePipeline（Code 3兄弟）で WebアプリをCI/CDデプロイする【完全 AWS CI/CD 体験】 first appeared on CayTech Lab.

「インフラは AWS でいいけど、デプロイは GitHub Actions でやりたい」——クラウドと Git を組み合わせたハイブリッドな CI/CD 構成は、多くの現場で採用されています。このハンズオンでは、EC2（Tomcat）への自動デプロイを GitHub Actions + AWS CodeDeploy で実現します。

さらに実務でよく見かける「社内共通ライブラリを GitHub Packages で管理・共有する」仕組みも体験できます。Spring Boot WAR をビルドする際に共通ライブラリを GitHub Packages からフェッチし、CodeDeploy で EC2 にデプロイするまでの一連のフローです。

[GitHub リポジトリ]
  ├── common-lib/ → push → GitHub Actions → GitHub Packages に publish
  └── app/        → push → GitHub Actions
                               ├── GitHub Packages から common-utils を取得
                               ├── mvn package → webapp.war
                               ├── zip → S3 にアップロード
                               └── CodeDeploy を呼び出す
                                        ↓
                          [EC2: Tomcat + Spring Boot WAR]  my-ec2app
                                        ↓
                          [ALB: my-ec2app-alb] ← インターネット
                                        ↓
                          [RDS MySQL: my-ec2app-rds]

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

• GitHub Packages を使った共通ライブラリの管理・共有
• GitHub Actions（OIDC 認証）で AWS にキーレスアクセス
• CodeDeploy + appspec.yml を使った EC2 へのデプロイ自動化
• SSM Parameter Store でデータベースパスワードを安全に管理
• CloudFormation によるインフラ一括構築（VPC / EC2 / ALB / RDS / CodeDeploy）

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

-->

キーワード解説

① 全体構成を理解する

このハンズオンの主役は 2 つのワークフローです。

①-1 common-lib のパブリッシュ（ec2-publish-lib.yml）

common-lib/ が変更されると起動し、Maven ライブラリを GitHub Packages に publish します。actions/setup-java が settings.xml を自動生成するため、認証設定は不要です。

①-2 アプリのデプロイ（ec2-app-deploy.yml）

app/ が変更されると起動します。処理の流れは次の通りです：

① OIDC で AWS に認証
② GitHub Packages から common-utils を取得しながら mvn package で WAR をビルド
③ zip 化して S3 にアップロード（webapp.war + appspec.yml + scripts/）
④ CodeDeploy でローリングデプロイ（〜1〜2 分）

デプロイパッケージの構造：

deploy.zip
├── webapp.war         ← Tomcat の webapps/ に配置
├── appspec.yml        ← CodeDeploy の設定
└── scripts/
    ├── stop_server.sh      ← Tomcat を停止・古い WAR を削除
    ├── start_server.sh     ← SSM から DB 情報を取得・Tomcat 起動
    └── validate_service.sh ← /api/health を最大 60 秒リトライ確認

② OIDC 認証と IAM ロールを設定する

GitHub Actions が AWS に安全にアクセスするための OIDC（OpenID Connect）認証 を設定します。アクセスキーをリポジトリに保存せずに AWS を操作できる現代的な方式です。

②-1 OIDC プロバイダーを登録する（初回のみ）

AWS コンソール → IAM → 「IDプロバイダー」→「プロバイダーを追加」

ECS ハンズオン（cdk-ecs-webapp）完了済みの場合はスキップ可。

②-2 IAM ロールを作成する

AWS CloudShell で以下を実行します（GITHUB_OWNER と REPO は自分のリポジトリに合わせて変更）：

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
GITHUB_OWNER="your-github-username"   # ← 自分の GitHub ユーザー名
REPO="your-github-repo"               # ← 自分の GitHub リポジトリ名
EMPLOYEE_ID="my"                      # ← 好きなプレフィックス（例: 123456）
ROLE_NAME="${EMPLOYEE_ID}-github-actions-role"

cat > /tmp/trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:${GITHUB_OWNER}/${REPO}:ref:refs/heads/main"
      }
    }
  }]
}
EOF

aws iam create-role \
  --role-name $ROLE_NAME \
  --assume-role-policy-document file:///tmp/trust-policy.json

# 権限ポリシーを付与（S3 + CodeDeploy）
cat > /tmp/permissions.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::${EMPLOYEE_ID}-ec2app-deploy-*/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "codedeploy:CreateDeployment",
        "codedeploy:GetDeployment",
        "codedeploy:GetDeploymentConfig",
        "codedeploy:RegisterApplicationRevision"
      ],
      "Resource": "*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name $ROLE_NAME \
  --policy-name "${ROLE_NAME}-policy" \
  --policy-document file:///tmp/permissions.json

# ロール ARN を表示
aws iam get-role --role-name $ROLE_NAME --query Role.Arn --output text

出力された ロール ARN（arn:aws:iam::...）をコピーしておきます。

③ GitHub Variables を設定する

GitHub リポジトリ → Settings → Secrets and variables → Actions → 「Variables」タブ

「New repository variable」で以下を追加します：

Variables vs Secrets：ARN や ID は機密情報ではないため Variables に保存します（パスワード類は Secrets を使う）。

④ CloudFormation スタックを作成する

自分の IP アドレスを確認し（curl https://checkip.amazonaws.com）、CloudFormation でインフラを一括作成します：

aws cloudformation deploy ^
  --template-file ec2-github-actions/infra/template.yaml ^
  --stack-name my-ec2app ^
  --parameter-overrides EmployeeId=my DBPassword=Handson1234! MyIP=123.456.78.901/32 ^
  --capabilities CAPABILITY_NAMED_IAM ^
  --region ap-northeast-1

所要時間：約 10〜15 分（RDS の作成に時間がかかります）

CloudFormation スタックが作成するリソース：

⑤ スタックの Outputs を確認する

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

⑥ common-lib を GitHub Packages に publish する

common-lib/pom.xml と app/pom.xml にある GitHub ユーザー名・リポジトリ名のプレースホルダーを自分のものに変更してから push します：

<!-- common-lib/pom.xml と app/pom.xml の両方を変更 -->
<url>https://maven.pkg.github.com/your-github-username/your-github-repo</url>

変更を push すると Publish common-utils to GitHub Packages ワークフローが自動起動します：

cd C:\my-aws\aws-learning-projects
git add ec2-github-actions/common-lib/ ec2-github-actions/app/pom.xml
git commit -m "feat: configure GitHub Packages URL for ec2-github-actions"
git push

GitHub リポジトリ → Actions タブ → Publish common-utils to GitHub Packages の実行を確認します。完了後、Packages タブに common-utils 1.0.0 が表示されます。

ResponseWrapper クラスとは：このハンズオンの共通ライブラリは API レスポンスを {"status":"ok","data":{...}} の統一形式にラップするユーティリティです。チーム開発でレスポンス形式を統一する際によく使われるパターンです。

⑦ アプリを初回デプロイする

app/ の変更を push して Deploy App to EC2 ワークフローを起動します：

cd C:\my-aws\aws-learning-projects
git add ec2-github-actions/app/
git commit -m "feat: initial deploy via GitHub Actions (EC2)"
git push

nothing to commit と表示された場合：index.html に空白行を追加して変更を作ります：

echo. >> ec2-github-actions\app\src\main\resources\templates\index.html
git add ec2-github-actions/app/src/main/resources/templates/index.html
git commit -m "chore: trigger initial deploy"
git push

⑧ GitHub Actions の進行を確認する

GitHub → Actions タブ → Deploy App to EC2 で各ステップの実行状況を確認します：

合計：約 3〜5 分

ポイントは 「Set up Java」ステップです。actions/setup-java に server-id: github を指定するだけで、GitHub Packages の認証情報を含む settings.xml が自動生成されます。Maven のパスワード設定を手書きする必要はありません。

⑨ ブラウザで動作確認する

ALBEndpoint の URL にアクセスすると「Spring Boot + RDS Item Manager (EC2)」が表示されます。

/api/health にアクセスして以下が返ることも確認します：

{"status":"ok","message":null,"data":"OK"}

このレスポンス形式こそが common-utils の ResponseWrapper が GitHub Packages 経由で取得・ビルドされた証拠です。

⑩ CI/CD サイクルを体験する

index.html のタイトルを変更して push すると、約 3〜5 分でブラウザに反映されます：

<!-- 変更後 -->
<h1>Spring Boot + RDS Item Manager (EC2 v2) <span class="badge">GitHub Actions</span></h1>

git add ec2-github-actions/app/src/main/resources/templates/index.html
git commit -m "feat: update title to EC2 v2"
git push

これが CI/CD の醍醐味です。コードを push するだけで自動的にデプロイが完了します。

⑪ SSM Session Manager で EC2 に接続する（オプション）

キーペアなしで EC2 内部を確認できます：

aws ssm start-session ^
  --target i-xxxxxxxxxxxxxxxxx ^
  --region ap-northeast-1

# Tomcat のステータス確認
sudo systemctl status tomcat

# デプロイログの確認
sudo cat /var/log/aws/codedeploy-agent/codedeploy-agent.log

# SSM から取得した DB 接続情報の確認
sudo cat /opt/tomcat/current/bin/setenv.sh

# Tomcat ログの確認
sudo journalctl -u tomcat -n 50

setenv.sh を確認すると、SSM Parameter Store から取得した DB ホスト名とパスワードが環境変数としてセットされていることがわかります。パスワードをコードに書かずに安全に注入できています。

⑫ リソースを削除する

① S3 バケットを空にする（デプロイアーティファクトが蓄積されているため先に削除）

aws s3 rm s3://my-ec2app-deploy-123456789012 --recursive

② CloudFormation スタックを削除する

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

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

echo スタック削除完了

まとめ：学んだ概念

GitHub Actions と AWS を組み合わせることで、Git push だけでインフラから独立してアプリをデプロイできる柔軟な CI/CD パイプラインを構築できます。次のステップとして、EC2 + CodePipeline ハンズオンで完全 AWS ネイティブな CI/CD も体験してみましょう。

The post EC2 + GitHub Actions で WebアプリをCI/CDデプロイする【GitHub Packages + CodeDeploy 体験】 first appeared on CayTech Lab.

「EC2 の OS パッチや Tomcat のインストール設定が面倒」「スケールアウト時のインスタンス管理が複雑」——これを解決するのが ECS Fargate（サーバーレスコンテナ） です。

この記事では、ASG ハンズオン（cdk-asg-webapp）で構築した EC2 + Auto Scaling Group 構成を、ECS Fargate + Docker コンテナにアップグレードします。EC2 の代わりに Docker コンテナで Spring Boot アプリを動かし、GitHub Actions がコンテナイメージをビルドして ECS へ自動デプロイする仕組みを体験します。

【インフラ担当】CDK Pipelines
GitHub リポジトリ
  ↓ push（常に起動）
CodePipeline (my-cdk6-pipeline)
  ├── Source:       GitHub (CodeConnections 経由)
  ├── Build(Synth): CodeBuild — cdk synth
  ├── Mutate:       パイプライン自己更新（セルフミューテーション）
  └── InfraDeploy:  CloudFormation — VPC / ECR / ECS / RDS / ALB

【アプリ担当】GitHub Actions（app/ または Dockerfile 変更時のみ起動）
  1. Docker ビルド（Maven → WAR → Tomcat コンテナ）
  2. ECR にイメージをプッシュ
  3. タスク定義を新リビジョンに更新（プレースホルダー → 実イメージ）
  4. ECS サービスをローリングデプロイ（〜2〜3分）
                ↓
       [ALB: my-cdk6-alb]
                ↓
       ECS Fargate Service (my-cdk6-service)
       ・コンテナ: Tomcat 10.1 + Spring Boot WAR
       ・CPU: 256 units / Memory: 512 MiB
                ↓
       [RDS: my-cdk6-rds-mysql]  ← MySQL 8.0

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

• Docker のマルチステージビルド（Maven → WAR → Tomcat コンテナ）
• ECR へのイメージプッシュと ECS Fargate でのコンテナ実行
• GitHub Actions（OIDC 認証）による Docker ビルド → ECR プッシュ → ECS ローリングデプロイ
• インフラ（CDK Pipelines）とアプリ（GitHub Actions）のデプロイを分離した実務パターン
• ECS Exec でコンテナ内のシェルに直接接続するデバッグ体験
• desired_count を変更するだけのシンプルなスケーリング体験

この記事は CDK + Auto Scaling Group ハンズオン（cdk-asg-webapp） の発展記事です。
cdk-asg-webapp を体験済みの方向けです（cdk-webapp-pipeline 完了でも OK）。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-asg-webapp との比較

ファイル構成と役割

cdk-ecs-webapp/
├── app.py                     ← CDK アプリ エントリポイント
├── cdk.json                   ← CDK 設定（asg_* → task_cpu / task_memory / desired_count）
├── Dockerfile                 ← NEW: コンテナイメージのビルド手順（cdk-asg-webapp にはない）
├── app/                       ← Spring Boot Webアプリ（Java）
├── pipeline/
│   └── pipeline_stack.py      ← CodePipeline（インフラのみ / アプリは GitHub Actions が担当）
├── stages/
│   └── deploy_stage.py        ← Stage（WebappStack を内包）
├── stacks/
│   └── webapp_stack.py        ← インフラスタック（ECR/ECS の名前を CfnOutput で公開）
└── components/
    └── webapp_construct.py    ← ECS Fargate ベースの L3 Construct

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

使用するAWSサービス

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

前提条件

Docker Desktop は不要です。コンテナのビルドは GitHub Actions runner 上（Ubuntu）で実行されるため、ローカル PC に Docker をインストールする必要はありません。

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

作業順序

① プロジェクトのセットアップ（Python 仮想環境）
      ↓
② GitHub との接続を設定する（CodeConnections）
      ↓
③ cdk.json の設定
      ↓
④ コードを GitHub にプッシュする（重要！）
      ↓
⑤ パイプラインスタックのデプロイ（初回のみ手動）
      ↓
⑥ パイプラインの実行状況を確認する
      ↓
⑦ インフラを確認する
      ↓
⑧ GitHub Actions を設定する（OIDC + IAM ロール）
      ↓
⑨ アプリを初回デプロイする
      ↓
⑩ ECS Exec でコンテナに接続する
      ↓
⑪ タスク数スケーリングを体験する
      ↓
⑫ リソースを削除する

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

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

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

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

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

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

② GitHub との接続を設定する（CodeConnections）

cdk-asg-webapp（または cdk-webapp-pipeline）を実施済みの場合: 同じリポジトリを扱うため、
既存の接続（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!",
    "task_cpu": 256,
    "task_memory": 512,
    "desired_count": 1,
    "github_owner": "your-github-username",
    "github_repo": "aws-learning-projects",
    "github_branch": "main",
    "connection_arn": "arn:aws:codeconnections:ap-northeast-1:..."
  }
}

task_cpu と task_memory の組み合わせ制限（Fargate の仕様）
CPU と Memory には決まった組み合わせがあります。256 CPU の場合、Memory は 512〜2048（512 単位）が有効です。

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

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

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

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

GitHub Actions も同時に起動する場合: app/ または Dockerfile の変更が含まれていると GitHub Actions（Deploy App to ECS）も起動しますが、この時点では ECS サービスがまだ存在しないため失敗します。インフラが完成してから ⑨ で改めてアプリをデプロイします。

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

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

.venv\Scripts\activate

cdk synth

cdk deploy

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

my-EcsPipelineStack が作成され、以降は GitHub push で自動デプロイされます。

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

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

初回の InfraDeploy に 20 分程度かかる理由: RDS の起動と ECS サービスの安定化（プレースホルダーコンテナの起動確認）に時間がかかります。

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

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

CloudFormation スタックの命名規則

my-EcsPipelineStack（パイプライン）と 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

⑦ インフラを確認する

ALB の URL を確認する

ALBEndpoint の URL にブラウザでアクセスします。

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

この時点では Tomcat のデフォルト画面（または 404）が表示されます。
ECS タスクがプレースホルダーイメージ（公式 Tomcat）で起動しているためで、正常な状態です。
Spring Boot アプリのデプロイは ⑨ で実施します。

ECS コンソールで確認する

ECS → クラスター → my-cdk6-cluster → サービス → my-cdk6-service

「タスク」タブで 1 タスクが RUNNING になっていることを確認します。
「タスク定義」タブでリビジョンが 1（プレースホルダー）になっていることを確認します。

⑧ GitHub Actions を設定する（OIDC + IAM ロール）

Spring Boot アプリのデプロイを担う GitHub Actions を設定します。
OIDC 認証によりアクセスキーをリポジトリに保存せずに AWS を操作できます。

OIDC プロバイダーを登録する

AWS コンソール → IAM → 左メニュー「IDプロバイダー」→「プロバイダーを追加」

「プロバイダーを追加」ボタンをクリックして完了。

URL と対象者を入力するだけでよいです（現在の UI ではサムプリントの手動取得は不要）。

IAM ロールを作成する（CloudShell）

AWS コンソール → 右上「CloudShell」アイコン → 以下を貼り付けて実行します。
GITHUB_OWNER を自分の GitHub ユーザー名に変更してください:

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
GITHUB_OWNER="your-github-username"   # ← 自分の GitHub ユーザー名に変更
REPO="aws-learning-projects"
ROLE_NAME="my-github-actions-role"

cat > /tmp/trust-policy.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::${ACCOUNT_ID}:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:${GITHUB_OWNER}/${REPO}:ref:refs/heads/main"
      }
    }
  }]
}
EOF

aws iam create-role \
  --role-name $ROLE_NAME \
  --assume-role-policy-document file:///tmp/trust-policy.json

# 権限ポリシーを作成（ECR push + ECS deploy に必要な最小権限）
cat > /tmp/permissions.json << EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["ecr:GetAuthorizationToken"],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecr:BatchCheckLayerAvailability", "ecr:PutImage",
        "ecr:InitiateLayerUpload", "ecr:UploadLayerPart", "ecr:CompleteLayerUpload"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "ecs:DescribeTaskDefinition", "ecs:RegisterTaskDefinition",
        "ecs:UpdateService", "ecs:DescribeServices"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": ["iam:PassRole"],
      "Resource": "*"
    }
  ]
}
EOF

aws iam put-role-policy \
  --role-name $ROLE_NAME \
  --policy-name "${ROLE_NAME}-policy" \
  --policy-document file:///tmp/permissions.json

echo "=== Role ARN（次の手順でコピー）==="
aws iam get-role --role-name $ROLE_NAME --query Role.Arn --output text

出力された ロール ARN（arn:aws:iam::...）をコピーしておきます。

GitHub Variables を設定する

GitHub リポジトリ → Settings → Secrets and variables → Actions → 「Variables」タブ

「New repository variable」で以下の2つを追加します:

Variables と Secrets の使い分け: ARN や EMPLOYEE_ID は機密情報ではないため Variables に保存します（Secrets は使いません）。

ワークフローファイルを push する

.github/workflows/ecs-app-deploy.yml は既にリポジトリに含まれています。
このファイルを push してワークフローをアクティブにします:

cd C:\my-aws\aws-learning-projects
git add .github/workflows/ecs-app-deploy.yml
git commit -m "feat: add GitHub Actions ECS deploy workflow"
git push

このワークフローは paths フィルターにより app/ か Dockerfile が変わった時だけ起動します。
このコミットでは GitHub Actions はスキップされ、CDK Pipelines のみが起動（インフラ差分なしで数分で完了）します。

⑨ アプリを初回デプロイする（GitHub Actions）

GitHub Actions の設定が完了したので、Spring Boot アプリを ECS に初めてデプロイします。

アプリのタイトルを変更する

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

変更前:

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

変更後:

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

コミット＆プッシュ

cd C:\my-aws\aws-learning-projects
git add cdk-ecs-webapp/app/src/main/resources/templates/index.html
git commit -m "feat: initial app deploy via GitHub Actions"
git push

app/ の変更のため、GitHub Actions が起動します（CDK Pipelines も起動しますがインフラ差分なしで数分で完了）。

GitHub Actions の進行を確認する

GitHub リポジトリ → Actions タブ → Deploy App to ECS ワークフローの進行を確認します。

ブラウザで動作確認する

Deploy to ECS ステップが完了したら、ALB の URL にアクセスします。

「Spring Boot + RDS Item Manager (ECS v2)」の画面が表示されることを確認します。

ECS コンソールで確認: ECS → サービス → 「タスク」タブ
タスク定義のリビジョンが 2 以上（GitHub Actions による更新後）になっていることを確認します。

⑩ ECS Exec でコンテナに接続する

cdk-asg-webapp では SSM Session Manager で EC2 に接続しましたが、ECS Fargate では ECS Exec でコンテナ内のシェルに直接接続できます。

実行中のタスク ARN を確認する

aws ecs list-tasks ^
  --cluster my-cdk6-cluster ^
  --service-name my-cdk6-service ^
  --desired-status RUNNING ^
  --region ap-northeast-1 ^
  --query "taskArns" ^
  --output text

出力例:

arn:aws:ecs:ap-northeast-1:123456789012:task/my-cdk6-cluster/abcdef1234567890

複数件表示される場合: ローリングデプロイ中は新旧2タスクが同時に動きます。
ECS コンソール → サービス → 「タスク」タブでリビジョン番号が大きい方（最新）の ARN を使ってください。

コンテナに接続する

aws ecs execute-command ^
  --cluster my-cdk6-cluster ^
  --task arn:aws:ecs:ap-northeast-1:123456789012:task/my-cdk6-cluster/abcdef1234567890 ^
  --container my-cdk6-app ^
  --interactive ^
  --command "/bin/sh" ^
  --region ap-northeast-1

Session Manager Plugin が必要: 接続には AWS CLI の Session Manager Plugin が必要です。
インストール手順は AWS 公式ドキュメント を参照してください。

コンテナ内で確認する

# 環境変数（DB接続情報）を確認
echo $DB_HOST
echo $DB_PASSWORD

# デプロイされた WAR を確認（ROOT.war として配置される）
ls /usr/local/tomcat/webapps/

# 接続を終了
exit

catalina.out は存在しません: Docker コンテナの Tomcat はファイルにログを書かず、stdout（標準出力） に直接出力します。ログは CloudWatch Logs に転送されます。

aws logs tail /ecs/my-cdk6-app ^
  --follow ^
  --region ap-northeast-1

終了は Ctrl+C。

⑪ タスク数スケーリングを体験する

cdk-asg-webapp では stress-ng で CPU 負荷をかけて自動スケールを体験しましたが、
ECS Fargate では desired_count を直接変更するだけでスケールできます。

スケールアウト（1台 → 2台）

aws ecs update-service ^
  --cluster my-cdk6-cluster ^
  --service my-cdk6-service ^
  --desired-count 2 ^
  --region ap-northeast-1

ECS コンソール → サービス → 「タスク」タブで 2 タスクが RUNNING になることを確認します。
ALB がどちらのタスクにもリクエストを分散するようになります（ラウンドロビン）。

スケールイン（2台 → 1台）

aws ecs update-service ^
  --cluster my-cdk6-cluster ^
  --service my-cdk6-service ^
  --desired-count 1 ^
  --region ap-northeast-1

数分後に 1 タスクが停止し、1 台構成に戻ります。

ECS と ASG のスケーリング比較

• ECS: desired_count を変更するだけ（コマンド一発、秒単位で反映）
• ASG: CPU 閾値・CloudWatch アラーム・スケーリングポリシーが必要（設定が複雑）

ECS Fargate はコンテナ単位なので起動が速く（30秒〜）、EC2 の起動を待つ ASG より素早くスケールできます。

⑫ リソースを削除する

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

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

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-EcsPipelineStack ^
  --region ap-northeast-1

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

echo EcsPipelineStack 削除完了

3. GitHub Actions IAM ロールを削除する

CloudFormation の管理外のため、手動で削除します:

aws iam delete-role-policy ^
  --role-name my-github-actions-role ^
  --policy-name my-github-actions-role-policy

aws iam delete-role ^
  --role-name my-github-actions-role

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

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

5. 仮想環境の終了

deactivate

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

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

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

7. OIDC プロバイダーを削除する（オプション）

他のリポジトリでも使う場合はそのままでよいです。
不要な場合は IAM → IDプロバイダー → token.actions.githubusercontent.com → 「削除」

削除確認

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

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

EC2 → コンテナへの移行ポイント

cdk-asg-webapp（EC2 + ASG）          cdk-ecs-webapp（ECS Fargate）
─────────────────────────────       ─────────────────────────────
Launch Template                     Dockerfile
  ↓ UserData（シェルスクリプト）        ↓ マルチステージビルド（20行）
Java インストール                     Maven → WAR → Tomcat（イメージ内）
Tomcat インストール
CodeDeploy エージェントインストール
  ↓                                   ↓
appspec.yml + scripts/*.sh           Dockerfile のみ
S3 → CodeDeploy → WAR デプロイ       ECR → ECS タスク更新 → ローリングデプロイ
  ↓                                   ↓
SSM Session Manager（EC2 に接続）     ECS Exec（コンテナに直接接続）
  ↓                                   ↓
CPU 自動スケール（ASG ポリシー）        desired_count を変更（コマンド一発）

appspec.yml / scripts/*.sh / UserData の複雑な設定が、Dockerfile の 20 行に集約されます。

トラブルシューティング

まとめ

EC2 + CodeDeploy から ECS Fargate + GitHub Actions への移行で、EC2 の OS 管理・エージェント管理から解放され、Dockerfile 1ファイルにデプロイ設定が集約されることを体験できました。

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

The post CDK + ECS Fargate で Webアプリをコンテナ化する【EC2 からコンテナへの移行体験】 first appeared on CayTech Lab.

「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.

「CDKで書いたインフラコードをdev環境とprod環境で使い回したい」「スタックがどんどん肥大化してきた」——これを解決するのが CDK カスタム Construct です。

この記事では、CDK版ハンズオンで構築した ALB + EC2(Tomcat) + RDS の3層構成を、カスタム L3 Construct（ThreeTierWebConstruct） に切り出します。同じインフラを「再利用可能な部品」として定義することで、スタックのコード量が約170行 → 約30行に削減されることを体験します。

インターネット
  ↓ HTTP(80)
[ALB: my-cdk2-alb]
  ↓ HTTP(8080)  ← SG-to-SG 制御
[EC2: my-cdk2-ap-instance]  ← Tomcat
  ↓ MySQL(3306)  ← SG-to-SG 制御
[RDS: my-cdk2-rds-mysql]  ← MySQL 8.0

┌─ ThreeTierWebConstruct ────────────────────────────────────────┐
│  VPC / SG / SSM / RDS / EC2 Role / EC2 / ALB をすべて内包    │
└────────────────────────────────────────────────────────────────┘

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

• Construct クラスを継承して独自の L3 Construct を自作する方法
• @dataclass で設定値（Props）を型安全にまとめる CDK の慣習を理解
• スタックを「Construct を呼ぶだけの30行」に削減し、インフラ定義とデプロイ単位を分離する設計を体験
• 同じ Construct を dev/prod など複数環境で使い回す拡張イメージをつかむ

このハンズオンの特徴：

• CDK版（cdk-alb-ec2-rds）の約170行スタックが 約30行に削減される
• インフラの構成はまったく同じ（ALB + EC2 + RDS）でコード構造だけが変わる
• ThreeTierWebConstruct を複数スタックから呼び出すだけで環境を増やせる設計になる

この記事は CDK版ハンズオン（cdk-alb-ec2-rds） の発展記事です。
CDK の基本（Bootstrap・synth・deploy）を体験済みの方向けです。コード詳細は GitHub を参照してください。

-->

キーワード解説

cdk-alb-ec2-rds との比較

インフラの構成は cdk-alb-ec2-rds と完全に同等です。変わるのはコードの書き方（設計）だけです。

ファイル構成と役割

cdk-custom-constructs/
├── app.py                          ← CDK アプリ エントリポイント
├── cdk.json                        ← CDK 設定・Context 変数
├── requirements.txt
├── components/
│   └── three_tier_web.py           ← カスタム L3 Construct（本ハンズオンの主役）
│       ├── ThreeTierWebProps       ←   Construct に渡す設定値（dataclass）
│       └── ThreeTierWebConstruct  ←   ALB + EC2 + RDS をカプセル化した Construct
└── stacks/
    └── three_tier_stack.py         ← Props を組み立て、Construct を呼ぶだけの約30行スタック

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

使用するAWSサービス

注意: ALBは無料枠がありません。ハンズオン後は必ず cdk destroy で削除してください。

前提条件

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

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（AWS CLI で実施）
      ↓
② プロジェクトのセットアップ（Python 仮想環境）
      ↓
③ cdk.json を設定する
      ↓
④ コードの構造を理解する（デプロイ前に読む）
      ↓
⑤ CDK Synth（テンプレート確認）
      ↓
⑥ デプロイ（cdk deploy）
      ↓
⑦ 動作確認（ALBアクセス・SSH・RDS接続）
      ↓
⑧ Construct の再利用性を確認する（参考）
      ↓
⑨ CDK diff（参考）
      ↓
⑩ リソース削除（cdk destroy）

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

curl https://checkip.amazonaws.com

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

① キーペアの作成

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

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

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

cd C:\my-aws\aws-learning-projects\cdk-custom-constructs

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

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

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

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

③ cdk.json の設定

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

{
  "context": {
    "employee_id": "my",
    "my_ip": "203.0.113.1/32",
    "db_password": "Handson1234!",
    "key_name": "my-cdk2-key",
    "tomcat_version": "10.1.28"
  }
}

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

④ コードの構造を理解する（デプロイ前に読む）

このハンズオンの主役は コードの設計です。デプロイ前にファイルの役割を確認しておきます。

Props クラス（components/three_tier_web.py）

@dataclass
class ThreeTierWebProps:
    employee_id: str
    my_ip: str
    db_password: str
    key_name: str
    tomcat_version: str = field(default="10.1.28")  # 省略可能

@dataclass で設定値の型と省略時デフォルトを明示しています。スタック側から ThreeTierWebProps(employee_id=..., ...) として渡します。

Props とは: Construct に「何を作るか」を伝える設定値のまとまりです。型ヒントがあることで、どんな値が必要かが一目で分かります。

Construct クラス（components/three_tier_web.py）

class ThreeTierWebConstruct(Construct):
    def __init__(self, scope, id, *, props: ThreeTierWebProps):
        super().__init__(scope, id)
        self.vpc = ec2.Vpc(...)          # ← self に保存 → スタックから参照可能
        self.alb = elbv2.ApplicationLoadBalancer(...)
        self.instance = ec2.Instance(...)
        self.db_instance = rds.DatabaseInstance(...)

self.alb のように self 属性に保存した値はスタックから参照できます。ローカル変数に代入した場合はスタックから見えません。

スタック（stacks/three_tier_stack.py）

class ThreeTierStack(Stack):
    def __init__(self, scope, id, **kwargs):
        super().__init__(scope, id, **kwargs)

        props = ThreeTierWebProps(employee_id=..., my_ip=..., ...)

        # ← この1行で VPC / SG / RDS / EC2 / ALB が全部できる
        web = ThreeTierWebConstruct(self, "Web", props=props)

        CfnOutput(self, "ALBEndpoint",
            value=f"http://{web.alb.load_balancer_dns_name}")

スタックは Props の組み立てと Outputs の定義だけに集中できます。インフラの詳細は Construct にすべて委譲されています。

cdk-alb-ec2-rds との比較:

⑤ CDK Synth（テンプレート確認）

cdk synth

cdk.out/ に CloudFormation テンプレートが生成されます。この段階では AWS へのデプロイは行われません。

cdk-alb-ec2-rds の cdk synth と同じ CloudFormation テンプレートが生成されることを確認できます。Construct を使っても最終的な CloudFormation リソース数は変わりません。CDK の抽象化はコードの書き方を変えますが、生成されるインフラは同等です。

⑥ デプロイ

cdk deploy

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

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

デプロイ完了後、Outputs が表示されます:

Outputs:
CdkCustomConstructsStack.ALBEndpoint = http://my-cdk2-alb-xxxx.ap-northeast-1.elb.amazonaws.com
CdkCustomConstructsStack.EC2PublicIP = x.x.x.x
CdkCustomConstructsStack.RDSEndpoint = my-cdk2-rds-mysql.xxxx.ap-northeast-1.rds.amazonaws.com
CdkCustomConstructsStack.SSHCommand = ssh -i %USERPROFILE%\.ssh\my-cdk2-key.pem ec2-user@x.x.x.x
CdkCustomConstructsStack.MySQLConnectCommand = mysql -h my-cdk2-rds-mysql.xxxx... -u admin -pHandson1234! sampledb

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

⑦ 動作確認

7-1. ALB のヘルスチェック確認

EC2 → ターゲットグループ → 「ターゲット」タブ

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

7-2. ALB 経由でWebアクセス確認

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

http://（ALBEndpoint の DNS 名）

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

AP Server - my-cdk2 3-Tier Web
Deployed via AWS CDK Custom Construct (ThreeTierWebConstruct).

7-3. EC2 に SSH 接続する

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

7-4. EC2 から RDS への接続確認

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

sudo dnf install -y mariadb105

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

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

-- テーブル作成
CREATE TABLE items (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- データ挿入
INSERT INTO items (name) VALUES ('Apple'), ('Banana');

-- データ確認
SELECT * FROM items;

-- 後片付け
DROP TABLE items;

EXIT;

7-5. SSH 接続を切断する

exit

⑧ Construct の再利用性を確認する（参考）

カスタム Construct の最大の利点は 同じ定義を複数回使い回せる ことです。
app.py を以下のように書き換えると、同じインフラを dev / prod の2環境同時にデプロイできます。

# app.py（参考: 複数環境デプロイの例）
ThreeTierStack(app, "CdkConstructsDevStack",
    env=cdk.Environment(region="ap-northeast-1"),
    # cdk deploy CdkConstructsDevStack -c employee_id=dev01 ...
)
ThreeTierStack(app, "CdkConstructsProdStack",
    env=cdk.Environment(region="ap-northeast-1"),
    # cdk deploy CdkConstructsProdStack -c employee_id=prod01 ...
)

CloudFormation では同じ YAML を2つコピーするか、パラメータで分岐させる必要がありました。CDK では Construct を使うことでコードの重複なしに複数環境を管理できます。

⑨ CDK の差分確認（参考）

cdk diff

コードを変更した後、デプロイ前に差分を確認できます。

⑩ リソース削除

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

cdk destroy

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

所要時間: RDS の削除に 10〜15 分かかります。

削除されるリソース一覧

キーペアの削除（手動）

CDK が管理していないリソースは手動で削除します:

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

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

仮想環境の終了

deactivate

(.venv) が消えて通常のプロンプトに戻れば完了です。

削除完了の確認

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

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

Construct のポイント解説

なぜ self.alb のように属性に保存するのか

Construct 内のリソースをスタックから参照するには self 属性に保存する必要があります。

# Construct 内（three_tier_web.py）
self.alb = elbv2.ApplicationLoadBalancer(...)   # ← self に保存 → スタックから参照可能
listener  = alb.add_listener(...)               # ← ローカル変数  → スタックからは見えない

スタック側では web.alb.load_balancer_dns_name のようにアクセスできます。

props パターン

Construct の設定値は @dataclass で Props クラスにまとめるのが CDK の慣習です。型ヒントでどんな値が必要か一目で分かります。

@dataclass
class ThreeTierWebProps:
    employee_id: str        # 必須（型ヒントあり）
    my_ip: str              # 必須
    tomcat_version: str = field(default="10.1.28")  # 省略可能（デフォルト値あり）

Construct ID の役割

ThreeTierWebConstruct(self, "Web", props=props)
#                           ^^^^
#                           Construct ID（同じスタック内で一意にする）

CDK はこの ID を使って CloudFormation リソース名を自動生成します。同じスタックに同じ Construct を複数配置する場合は ID を変えます（例: "DevWeb", "ProdWeb"）。

トラブルシューティング

デプロイ失敗時のログ確認:

aws cloudformation describe-stack-events ^
  --stack-name CdkCustomConstructsStack ^
  --region ap-northeast-1 ^
  --query "StackEvents[?ResourceStatus=='CREATE_FAILED'].[ResourceType,ResourceStatusReason]" ^
  --output table

まとめ

カスタム Construct の最大のメリットは インフラを「部品」として設計できる 点です。今回の ThreeTierWebConstruct は1行で3層構成のすべてを生成します。同じ Construct を dev/prod で呼ぶだけで環境を増やせ、スタックのコードは Props の組み立てと Outputs のみの約30行に収まります。

コンソールで3層構成を視覚的に学びたい場合は AWSコンソール版ハンズオン、CloudFormation での自動化は CloudFormation版ハンズオン、CDK の基本（CloudFormation との比較）は CDK版ハンズオン（cdk-alb-ec2-rds） を参照してください。

The post AWS CDK カスタム Construct でALB + EC2 + RDS 3層構成を再利用可能な部品に切り出す【スタック170行 → 30行】 first appeared on CayTech Lab.

「CloudFormation の YAML 460行をもっとシンプルに書けないか」——それを実現するのが AWS CDK（Cloud Development Kit） です。

この記事では、CloudFormation版ハンズオンで構築した ALB + EC2(Tomcat) + RDS の3層構成を、AWS CDK（Python） で再現します。YAML を Python コードで書き直すことで、460行 → 約200行に削減できることを体験します。

インターネット
  ↓ HTTP(80)
[ALB: my-cdk-alb-alb]  ← インターネット向け / パブリックサブネット 2AZ
  ↓ HTTP(8080)  ← ALB SG → EC2 SG（SG-to-SG 制御）
[EC2: my-cdk-alb-ap-instance]  ← Tomcat / パブリックサブネット AZ-a
  ↓ MySQL(3306)  ← EC2 SG → RDS SG（SG-to-SG 制御）
[RDS: my-cdk-alb-rds-mysql]  ← MySQL 8.0 / プライベートサブネット AZ-a

[VPC: my-cdk-alb-vpc (10.0.0.0/16)]
  ├── パブリックサブネット (10.0.0.0/24) [AZ-a]  ← ALB + EC2
  ├── パブリックサブネット (10.0.1.0/24) [AZ-b]  ← ALB（2AZ 必須）
  ├── プライベートサブネット (10.0.2.0/24) [AZ-a]  ← RDS 配置
  └── プライベートサブネット (10.0.3.0/24) [AZ-b]  ← DBサブネットグループ用

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

• Python コードで AWS インフラを定義する CDK の世界観を理解
• ec2.Vpc 1つでVPC・IGW・ルートテーブルを自動生成する L2 Construct の威力を体験
• cdk synth で CloudFormation テンプレートを生成・確認
• cdk diff でデプロイ前の差分確認（CloudFormation の変更セット相当）
• cdk deploy / cdk destroy でワンコマンドデプロイ・削除

このハンズオンの特徴：

• CloudFormation 版で460行必要だった YAML が Python コード約200行で記述できる
• cdk destroy 1本でALB・RDS・IAMなど全リソースを自動削除
• コードの変更差分を cdk diff で即確認できる（CloudFormation の変更セットより簡単）

この記事は CloudFormation版ハンズオン の発展記事です。
同じ構成を CDK で再現し、IaC の進化を体験したい方向けです。CDK のコード詳細は GitHub を参照してください。

-->

キーワード解説

CloudFormation vs CDK：どれだけ違うか

使用するAWSサービス

注意: ALBは無料枠がありません。ハンズオン後は必ず cdk destroy で削除してください。

前提条件

AWS 認証確認:

aws sts get-caller-identity

構築されるリソース

CDK が cdk deploy 時に自動生成するリソース一覧です。

CloudFormation 版では約27リソースを YAML に個別定義しましたが、CDK では ec2.Vpc 1つがVPC・IGW・ルートテーブル等を自動生成するため、Python コードとして書くのは主要リソースのみです。

作業順序

⓪ 自分のIPアドレスを確認する
      ↓
① キーペアを作成する（AWS CLI で実施）
      ↓
② プロジェクトのセットアップ（Python 仮想環境）
      ↓
③ cdk.json を設定する
      ↓
④ CDK Bootstrap（初回のみ）
      ↓
⑤ CDK Synth（テンプレート確認）
      ↓
⑥ デプロイ（cdk deploy）
      ↓
⑦ 動作確認（ALBアクセス・SSH・RDS接続）
      ↓
⑧ CDK diff（参考）
      ↓
⑨ リソース削除（cdk destroy）

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

curl https://checkip.amazonaws.com

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

セキュリティグループで 203.0.113.1/32 の形式（末尾に /32）で使用します。

① キーペアの作成

CDK では cdk deploy 時にキーペアのダウンロードができないため、事前に AWS CLI で作成します。

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

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

控えておく情報: キーペア名 my-cdk-alb-key

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

CDK の Python プロジェクトを実行するために、Python 仮想環境（venv）を作成してパッケージをインストールします。

cd C:\my-aws\aws-learning-projects\cdk-alb-ec2-rds

python -m venv .venv

.venv\Scripts\activate

pip install -r requirements.txt

仮想環境が有効になると、プロンプトの先頭に (.venv) が表示されます。

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

cd C:\my-aws\aws-learning-projects\cdk-alb-ec2-rds
.venv\Scripts\activate

プロンプトに (.venv) が付いていることを確認してから CDK コマンドを実行してください。

③ cdk.json の設定

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

{
  "context": {
    "employee_id": "my",
    "my_ip": "203.0.113.1/32",
    "db_password": "Handson1234!",
    "key_name": "my-cdk-alb-key",
    "tomcat_version": "10.1.28"
  }
}

cdk.json はバージョン管理に含めます（cdk.context.json は .gitignore 対象）。

CDK の詳細なコード（stacks/alb_ec2_rds_stack.py など）は GitHub を参照してください。

④ CDK Bootstrap（初回のみ）

CDK が AWS 環境にデプロイするために必要なリソース（S3 バケット等）を事前にセットアップします。
同じアカウント・リージョンで一度だけ実行すれば以降は不要です。

cdk bootstrap は app.py を実行しないため、仮想環境の有効・無効に関わらず実行できます。② で有効にした仮想環境はそのままで進めてください。

rem アカウントIDを確認
aws sts get-caller-identity --query Account --output text

rem Bootstrap を実行（アカウントIDを置き換えて実行）
cdk bootstrap aws://123456789012/ap-northeast-1

正常完了すると「CDKToolkit」という CloudFormation スタックが作成されます。

⑤ CDK Synth（テンプレート確認）

デプロイ前に CDK が生成する CloudFormation テンプレートを確認します。この段階では AWS へのデプロイは行われません。

cdk synth

cdk.out/ ディレクトリに CloudFormation テンプレート（JSON）が生成されます。

CloudFormation 版との比較ポイント:

• CDK が自動生成したVPC・ルートテーブル等のリソースが含まれていることを確認
• Python コード（約200行）から生成されたテンプレートの行数を確認（はるかに多い）

なぜテンプレートは増えるのか: CDK の Python コードは「人間が書く量」を減らすための抽象化です。実際に AWS に渡される CloudFormation テンプレートは CDK が自動生成するため、行数は多くなります。

rem 生成されたテンプレートをテキストエディタで確認
notepad cdk.out\CdkAlbEc2RdsStack.template.json

⑥ デプロイ

cdk deploy

実行中に「Do you wish to deploy these changes?」と表示されたら y を入力します。

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

デプロイ完了後、Outputs が表示されます:

Outputs:
CdkAlbEc2RdsStack.ALBEndpoint = http://my-cdk-alb-alb-xxxx.ap-northeast-1.elb.amazonaws.com
CdkAlbEc2RdsStack.EC2PublicIP = x.x.x.x
CdkAlbEc2RdsStack.RDSEndpoint = my-cdk-alb-rds-mysql.xxxx.ap-northeast-1.rds.amazonaws.com
CdkAlbEc2RdsStack.SSHCommand = ssh -i %USERPROFILE%\.ssh\my-cdk-alb-key.pem ec2-user@x.x.x.x
CdkAlbEc2RdsStack.MySQLConnectCommand = mysql -h my-cdk-alb-rds-mysql.xxxx... -u admin -pHandson1234! sampledb

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

⑦ 動作確認

7-1. ALB のヘルスチェック確認

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

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

Tomcat の起動はEC2が「実行中」になってからさらに 3〜5 分かかります。

ターゲットグループの ARN を CLI で確認する場合:

aws elbv2 describe-target-groups ^
  --names my-cdk-alb-tg ^
  --query TargetGroups[0].TargetGroupArn ^
  --output text ^
  --region ap-northeast-1

7-2. ALB 経由でWebアクセス確認

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

http://（ALBEndpoint の DNS 名）

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

AP Server - my-cdk ALB + EC2 + RDS
Deployed via AWS CDK (Python). Connects to RDS MySQL in the private subnet.

EC2 のパブリック IP に直接アクセスしても表示されません（ポート 8080 は ALB SG からのみ許可しているため）。

7-3. EC2 に SSH 接続する

Outputs の SSHCommand を実行します（パスは実際のパスに修正します）。

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

7-4. EC2 から RDS への接続確認

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

sudo dnf install -y mariadb105

# SSM Parameter Store からパスワードを取得
DB_PASSWORD=$(aws ssm get-parameter \
  --name /my/cdk-alb/db-password \
  --query Parameter.Value \
  --output text \
  --region ap-northeast-1)

# RDS に接続（Outputs の RDSEndpoint を使用）
mysql -h <RDSEndpoint> -u admin -p${DB_PASSWORD} sampledb

-- テーブル作成
CREATE TABLE items (
  id INT AUTO_INCREMENT PRIMARY KEY,
  name VARCHAR(100),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- データ挿入
INSERT INTO items (name) VALUES ('Apple'), ('Banana');

-- データ確認
SELECT * FROM items;

-- 後片付け
DROP TABLE items;

EXIT;

7-5. SSH 接続を切断する

exit

7-6. UserData の実行ログ確認

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

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

エラーなく最後まで実行されていれば正常です。

⑧ CDK の差分確認（参考）

コードを変更した後、デプロイ前に差分を確認できます。これが CDK の強力な機能の1つです。

cdk diff

CloudFormation の変更セット相当の情報が自動で表示されます。

Stack CdkAlbEc2RdsStack
Resources
[~] AWS::EC2::Instance EC2Instance
 └─ [~] UserData
     └─ [~] .Fn::Base64
         └─ ...

⑨ リソース削除

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

cdk destroy

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

所要時間: RDS の削除に 10〜15 分かかります。

削除されるリソース一覧

キーペアの削除（手動）

CDK が管理していないリソースは手動で削除します:

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

del %USERPROFILE%\.ssh\my-cdk-alb-key.pem

仮想環境の終了

ハンズオンが終わったらプロンプトの (.venv) を外します。

deactivate

(.venv) が消えて通常のプロンプトに戻れば完了です。

(.venv) が付いている状態とは: このプロジェクト専用の Python 環境（venv）が有効な状態です。deactivate しなくてもターミナルを閉じれば自動的に解除されます。次回 CDK コマンドを使う際は再度 .venv\Scripts\activate が必要です。

削除完了の確認

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

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

CDK Bootstrap リソースの削除（任意）

CDK を今後も使う場合は残したままでよいです。
削除する場合は AWS コンソールで CDKToolkit スタックを手動削除します。

CDK のポイント解説

L1 / L2 / L3 Construct の違い

このハンズオンでは主に L2 Construct を使用しています。ec2.Vpc 1つを書くだけで、CloudFormation では15+ リソースが必要だったVPC・IGW・ルートテーブル・サブネット設定を自動生成します。

CDK Context 変数

cdk.json の context に設定した値は self.node.try_get_context("key") で取得できます。
デプロイ時に -c key=value で上書きも可能です:

cdk deploy -c my_ip=1.2.3.4/32 -c db_password=MyPass123!

cdk synth で CloudFormation テンプレートを確認

rem cdk.out/ に生成されたテンプレートをテキストエディタで確認
notepad cdk.out\CdkAlbEc2RdsStack.template.json

CDK コードの詳細（stacks/alb_ec2_rds_stack.py 全文）は GitHub を参照してください。

トラブルシューティング

デプロイ失敗時のログ確認:

aws cloudformation describe-stack-events ^
  --stack-name CdkAlbEc2RdsStack ^
  --region ap-northeast-1 ^
  --query "StackEvents[?ResourceStatus=='CREATE_FAILED'].[ResourceType,ResourceStatusReason]" ^
  --output table

コンソール版・CloudFormation版との比較

まとめ

CDK の最大の魅力は プログラミング言語でインフラを書ける点です。CloudFormation の460行の YAML が Python 約200行に削減されただけでなく、cdk diff による差分確認や L2 Construct による抽象化など、開発者体験が大きく向上します。

コンソールで3層構成の概念を視覚的に学びたい場合は AWSコンソール版ハンズオン、まずCloudFormationで同じ構成を試したい場合は CloudFormation版ハンズオン を参照してください。

The post AWS CDK（Python）でALB + EC2(Tomcat) + RDS 3層構成を構築する手順【CloudFormation 460行 → CDK 200行】 first appeared on CayTech Lab.

前回のAWSコンソール版ハンズオン（ALB + EC2 + RDS）では、Tomcatに静的HTMLを配置して3層構成を体験しました。

今回はそこからさらに一歩進め、Spring Boot + Maven で作成したWebアプリケーションをWARファイルとしてビルドし、EC2（Tomcat）にデプロイして RDS MySQLにJDBCで接続するCRUDアプリを動かすハンズオンを紹介します。

インターネット
  ↓ HTTP(80)  ← ALB SGで全IPから許可
ALB（my-webapp-alb）
  [パブリックサブネット1: 10.0.1.0/24 AZ-a]
  [パブリックサブネット2: 10.0.2.0/24 AZ-c]  ← ALBの2AZ要件
  ↓ HTTP(8080)  ← EC2 SGでALB SGからのみ許可（SG-to-SG）
EC2（my-webapp-ap-instance）
  Tomcat 10 + webapp.war（Spring Boot）
  [パブリックサブネット1: 10.0.1.0/24 AZ-a]
  ↓ JDBC/MySQL(3306)  ← RDS SGでEC2 SGからのみ許可（SG-to-SG）
RDS MySQL（my-webapp-rds-mysql）← sampledb / items テーブル
  [プライベートサブネット1: 10.0.3.0/24 AZ-a]

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

• Spring Boot WebアプリをMavenでWARファイルにビルドする方法
• SCPでWARをEC2に転送してTomcatにデプロイする手順
• SSM Parameter StoreのDB接続情報をEC2上の環境変数として注入する方法
• JdbcTemplateでRDS MySQLにCRUD操作するSpring Bootアプリの動作

アプリのソースコード・CloudFormationテンプレートは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

この記事は CloudFormation版ハンズオン の比較記事です。
コンソール操作でWARのデプロイ手順を手を動かして確認したい方向けです。

-->

キーワード解説

前フェーズとの違い

使用するAWSサービス

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

構築するリソース一覧

全体の作業順序

⓪ Webアプリをビルドする（mvn package）
      ↓
⓪-2 自分のIPアドレスを確認する
      ↓
① キーペア作成
      ↓
② VPC作成
      ↓
③ サブネット作成（4つ）
      ↓
④ インターネットゲートウェイ作成・アタッチ
      ↓
⑤ ルートテーブル設定
      ↓
⑥ セキュリティグループ作成（ALB用・EC2用・RDS用）
      ↓
⑦ IAMロール作成
      ↓
⑧ SSM Parameter Store作成
      ↓
⑨ RDS DBサブネットグループ作成
      ↓
⑩ RDS MySQL インスタンス作成（※約10〜15分かかる）
      ↓
⑪ EC2インスタンス起動（Tomcat）
      ↓
⑫ ターゲットグループ作成
      ↓
⑬ ALB作成・リスナー設定
      ↓
⑭ Webアプリのデプロイ（WAR転送・Tomcat起動）
      ↓
⑮ 動作確認（ALB → EC2 → RDS CRUD）
      ↓
⑯ リソース削除

⓪ Webアプリのビルド

Webアプリのソースコードはこちら：

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

GitHubからクローンするか、ローカルにすでにあるソースコードを使います。

ビルド前の確認：

java -version
mvn -version

Java 17以上、Maven 3.x が表示されることを確認します。

WARファイルをビルドする：

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

-DskipTests はローカルにDBがないためテストをスキップします。初回は依存ライブラリのダウンロードで数分かかります。

[INFO] BUILD SUCCESS

ビルド成果物を確認する：

dir target\webapp.war

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

アプリの機能: アイテム一覧表示・追加・削除の3機能。Spring Boot + JdbcTemplate + Thymeleaf で構成されています。DB接続情報は環境変数（DB_HOST・DB_PASSWORD）から読み込みます。

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

https://checkip.amazonaws.com

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

セキュリティグループで 203.0.113.1/32 の形式（末尾に /32）で使用します。

① キーペアの作成

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

「キーペアを作成」をクリック。ダウンロードされた .pem ファイルを保存します。

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

② VPCの作成

AWSコンソール → VPC → 「VPCを作成」

「VPCを作成」をクリック。

③ サブネットの作成（4つ）

AWSコンソール → VPC → サブネット → 「サブネットを作成」

VPCに my-webapp-vpc を選択して、以下の4つを1回の操作で作成します（「新しいサブネットを追加」で追加できます）。

「サブネットを作成」をクリック。

パブリックサブネットのIPv4自動割り当てを有効化

my-webapp-public-subnet-1 と my-webapp-public-subnet-2 それぞれに対して：

サブネットを選択 → 「アクション」→「サブネットの設定を編集」→ 「パブリックIPv4アドレスの自動割り当てを有効化」 にチェック → 「保存」

④ インターネットゲートウェイの作成・アタッチ

作成

AWSコンソール → VPC → インターネットゲートウェイ → 「インターネットゲートウェイを作成」

「インターネットゲートウェイを作成」をクリック。

VPCへのアタッチ

作成したIGWを選択 → 「アクション」→「VPCにアタッチ」→ my-webapp-vpc を選択 → 「インターネットゲートウェイのアタッチ」

⑤ ルートテーブルの設定

注意: EC2を起動する前にこの手順を完了させてください。IGWルートがない状態でEC2を起動すると、UserDataのTomcatインストールが失敗します。

5-1. パブリック用ルートテーブル

AWSコンソール → VPC → ルートテーブル → 「ルートテーブルを作成」

作成後、「ルート」タブ → 「ルートを編集」→「ルートを追加」

「変更を保存」をクリック。

「サブネットの関連付け」タブ → 「サブネットの関連付けを編集」→ パブリックサブネット2つにチェック → 保存

• my-webapp-public-subnet-1
• my-webapp-public-subnet-2

5-2. プライベート用ルートテーブル

「サブネットの関連付けを編集」→ プライベートサブネット2つにチェック → 保存

• my-webapp-private-subnet-1
• my-webapp-private-subnet-2

⑥ セキュリティグループの作成

6-1. ALB用セキュリティグループ

AWSコンソール → EC2 → セキュリティグループ → 「セキュリティグループを作成」

インバウンドルール:

なぜ全開放か: ALBはWebサービスの入口なので不特定多数を許可。EC2はALB SGからのみ8080番を受け付けるSG-to-SG制御で守られています。

6-2. EC2用セキュリティグループ

インバウンドルール:

アウトバウンドルール（変更しない）:

アウトバウンドルールを削除してはいけない: EC2からのTomcatインストール（パッケージダウンロード）に必要です。

6-3. RDS用セキュリティグループ

インバウンドルール:

⑦ IAMロールの作成

AWSコンソール → IAM → ロール → 「ロールを作成」

信頼されたエンティティ

許可ポリシー

ロール名

「ロールを作成」をクリック。

⑧ SSM Parameter Storeの作成

AWSコンソール → Systems Manager → パラメータストア → 「パラメータの作成」

「パラメータの作成」をクリック。

SecureStringとは: KMSで暗号化して保存するタイプです。取得時は --with-decryption オプションが必要です。CloudFormation版はString型になりますが、コンソールではSecureStringを推奨します。

⑨ RDS DBサブネットグループの作成

AWSコンソール → Aurora and RDS → サブネットグループ → 「DBサブネットグループの作成」

アベイラビリティーゾーンとサブネットの追加:

「作成」をクリック。

⑩ RDS MySQL インスタンスの作成

AWSコンソール → Aurora and RDS → データベース → 「データベースの作成 ▲」→「フル設定」

「フル設定」を選ぶ: VPC・サブネットグループ・SGなどを細かく指定するため、必ず「フル設定」を選択します。

注意: RDSの作成は約10〜15分かかります。

エンジンの選択

テンプレート

設定

インスタンスの設定

ストレージ

接続

追加設定

「追加設定」を開きます。

「データベースの作成」をクリック。

控えておく情報: 作成完了後の「エンドポイント」ホスト名

my-webapp-rds-mysql.xxxxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com

⑪ EC2インスタンスの起動（Tomcat）

注意: EC2を起動する前に⑤のルートテーブル設定が完了していることを確認してください。

AWSコンソール → EC2 → インスタンス → 「インスタンスを起動」

基本設定

ネットワーク設定

「編集」をクリックして以下を設定します。

IAMロール

「高度な詳細」→「IAMインスタンスプロファイル」→ my-webapp-ec2-role を選択

UserData

「高度な詳細」→「ユーザーデータ」に以下を貼り付けます。

このUserDataではTomcatをインストールするのみです。アプリのデプロイは⑭で手動で行います。

#!/bin/bash
set -xe
exec > >(tee /var/log/user-data.log) 2>&1

dnf install -y java-17-amazon-corretto wget

TOMCAT_VERSION="10.1.28"
cd /opt
wget -q https://archive.apache.org/dist/tomcat/tomcat-10/v${TOMCAT_VERSION}/bin/apache-tomcat-${TOMCAT_VERSION}.tar.gz
tar xzf apache-tomcat-${TOMCAT_VERSION}.tar.gz
mv apache-tomcat-${TOMCAT_VERSION} tomcat
chmod +x /opt/tomcat/bin/*.sh

cat > /opt/tomcat/webapps/ROOT/index.html << 'HTMLEOF'
<html><body><h1>Tomcat is ready. Deploy webapp.war to complete setup.</h1></body></html>
HTMLEOF

/opt/tomcat/bin/startup.sh

「インスタンスを起動」をクリック。

控えておく情報: インスタンスのパブリックIPアドレス

⑫ ターゲットグループの作成

AWSコンソール → EC2 → ターゲットグループ → 「ターゲットグループの作成」

ヘルスチェック

「次へ」をクリック。

ターゲットの登録

一覧から my-webapp-ap-instance を選択 → ポートが 8080 であることを確認 → 「保留中として以下を含める」をクリック → 「ターゲットグループの作成」

⑬ ALBの作成・リスナー設定

AWSコンソール → EC2 → ロードバランサー → 「ロードバランサーの作成」

「Application Load Balancer」の「作成」をクリック。

基本的な設定

ネットワークマッピング

セキュリティグループ

my-webapp-alb-sg のみを選択（デフォルトSGは削除）。

リスナーとルーティング

「ロードバランサーの作成」をクリック。

控えておく情報: 「DNS名」（例: my-webapp-alb-1234567890.ap-northeast-1.elb.amazonaws.com）

⑭ Webアプリのデプロイ

これが前回のハンズオンとの最大の違いです。WARファイルをEC2に転送してTomcatにデプロイします。

14-1. EC2にSSH接続する

ssh -i C:\Users\ユーザー名\.ssh\my-webapp-key.pem ec2-user@（EC2のパブリックIP）

14-2. setenv.sh を作成してDB接続情報を注入する

TomcatはEC2起動時に /opt/tomcat/bin/setenv.sh を読み込み、環境変数をJVMに渡します。Spring Bootアプリは DB_HOST と DB_PASSWORD 環境変数からDB接続情報を取得します。

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

# setenv.shを作成（RDSエンドポイントは⑩で控えた値に置き換える）
sudo tee /opt/tomcat/bin/setenv.sh << EOF
export DB_HOST=my-webapp-rds-mysql.xxxxxxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com
export DB_PASSWORD=$DB_PASSWORD
EOF

sudo chmod +x /opt/tomcat/bin/setenv.sh

内容を確認します。

sudo cat /opt/tomcat/bin/setenv.sh

export DB_HOST=my-webapp-rds-mysql.xxxxx.ap-northeast-1.rds.amazonaws.com
export DB_PASSWORD=（設定したパスワード）

14-3. WARファイルをEC2に転送する

**ローカルの別ターミナル（SSH接続していないターミナル）**で実行します。

scp -i C:\Users\ユーザー名\.ssh\my-webapp-key.pem ^
  C:\（プロジェクトフォルダ）\alb-ec2-rds-webapp\app\target\webapp.war ^
  ec2-user@（EC2のパブリックIP）:/home/ec2-user/

転送完了後、SSH接続中のターミナルで確認します。

ls -lh ~/webapp.war

14-4. Tomcatを停止してWARをデプロイする

# Tomcatを停止
sudo /opt/tomcat/bin/shutdown.sh
sleep 3

# 既存のROOTアプリを削除してWARをデプロイ
sudo rm -rf /opt/tomcat/webapps/ROOT /opt/tomcat/webapps/ROOT.war
sudo cp ~/webapp.war /opt/tomcat/webapps/ROOT.war

# Tomcatを起動（setenv.shが読み込まれる）
sudo /opt/tomcat/bin/startup.sh

14-5. デプロイを確認する

Tomcatは ROOT.war を自動展開してアプリを起動します。1〜2分待ってから確認します。

# Tomcatログを確認
sudo tail -50 /opt/tomcat/logs/catalina.out

以下のログが表示されれば成功です。

INFO: Starting ProtocolHandler ["http-nio-8080"]
INFO: Server startup in [XXXX] milliseconds

# EC2内からの疎通確認
curl -s http://localhost:8080/ | head -5

HTMLが返ってくればデプロイ成功です。

exit

⑮ 動作確認

15-1. ALBのヘルスチェック確認

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

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

15-2. ALB経由でWebアプリにアクセスする

⑬で控えたALBのDNS名をブラウザで開きます。

http://（ALBのDNS名）

以下の画面が表示されれば成功です。

Spring Boot + RDS Item Manager
ALB → EC2(Tomcat) → RDS MySQL の3層構成で動作しています。
アイテムの追加・削除がRDSに永続化されます。

15-3. アイテムの追加・削除を試す

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

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

15-4. RDSのデータをSQLで直接確認する（任意）

ssh -i C:\Users\ユーザー名\.ssh\my-webapp-key.pem ec2-user@（EC2のパブリックIP）

sudo dnf install -y mariadb105

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

mysql -h （RDSエンドポイント） -u admin -p"$DB_PASSWORD" sampledb

SELECT * FROM items;
EXIT;

Webアプリで追加したデータが表示されれば完全成功です。

exit

⑯ リソースの削除

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

ALBの課金: インスタンスが稼働中は課金されます（約$0.008/時間 + LCU料金）。

削除順序

1. ALBを削除
2. ターゲットグループを削除
3. EC2インスタンスを終了
4. RDSインスタンスを削除（約10〜15分）
5. RDS DBサブネットグループを削除
6. SSM Parameter Storeのパラメータを削除
7. IAMロールを削除
8. セキュリティグループを削除（RDS用 → EC2用 → ALB用の順）
9. VPCを削除（サブネット・ルートテーブルも一括削除）
10. キーペアを削除（任意）

1. ALBを削除する

EC2 → ロードバランサー → my-webapp-alb を選択 → 「アクション」→「削除」

2. ターゲットグループを削除する

EC2 → ターゲットグループ → my-webapp-tg を選択 → 「アクション」→「削除」

3. EC2インスタンスを終了する

EC2 → インスタンス → my-webapp-ap-instance を選択 → 「インスタンスの状態」→「インスタンスを終了」

4. RDSインスタンスを削除する

Aurora and RDS → データベース → my-webapp-rds-mysql を選択 → 「アクション」→「削除」

5. RDS DBサブネットグループを削除する

Aurora and RDS → サブネットグループ → my-webapp-rds-subnet-group → 「削除」

6. SSM Parameter Storeを削除する

Systems Manager → パラメータストア → /my/webapp/db-password → 「削除」

7. IAMロールを削除する

IAM → ロール → my-webapp-ec2-role を選択 → 「削除」

8. セキュリティグループを削除する

依存関係があるため以下の順番で削除します。

1. my-webapp-rds-sg
2. my-webapp-ec2-sg
3. my-webapp-alb-sg

9. VPCを削除する

VPC → お使いのVPC → my-webapp-vpc を選択 → 「アクション」→「VPCの削除」

VPCを削除するとサブネット・ルートテーブルも一括削除されます。IGWのデタッチが必要な場合は先に行います。

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

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

トラブルシューティング

まとめ

前回（静的HTML）との最大の違いは、⑭のWARデプロイです。setenv.sh でSSMから取得したDB接続情報を環境変数としてTomcatに渡し、Spring BootアプリがRDS MySQLに接続してCRUD操作できる本格的なWebアプリになりました。

CloudFormationでインフラ構築からWARデプロイまで自動化したい場合は、CloudFormation版ハンズオンを参照してください。S3にWARをアップロードするだけで、UserDataが自動デプロイまで行います。

The post AWSコンソールでSpring Boot WebアプリをALB + EC2(Tomcat) + RDS にデプロイする手順【WAR / JdbcTemplate / CRUD】 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.