GAT技術ブログ

株式会社ギブ・アンド・テイクの技術ブログ

AWS CodePipeline と ECR を Tooling アカウントに集約し、ECS へクロスアカウントデプロイしてみた

AWS

はじめに（背景と目的）

本記事では、Tooling アカウント → 開発アカウント → 手動承認 → 本番アカウント の 3 アカウント構成で、

  • CI/CD パイプラインは Tooling アカウントに集約

  • CodePipeline から各アカウントの ECS へクロスアカウントデプロイ

を行う コンテナ CI/CD パイプラインの実装例を紹介します。

CI/CD パイプラインのベストプラクティスとして、環境ごとにアカウントを分離するマルチアカウント戦略が推奨されています。

一方で、「CI/CD パイプラインはどこに置く？ ECR はアカウントごとに分けるべき？ S3 / KMS / IAM のクロスアカウントは？」あたりで特に迷いがちです。

⚠️ 注意
ここで紹介する構成は、「こうしなければならない」ベストアンサーではなく、あくまで一つの実装パターンです。組織のセキュリティ要件や運用体制に応じて、別パターンも十分選択肢になり得ます。

そこで本記事では、以下の仕組みを構築してみました。

  • CI/CDパイプライン は Tooling アカウントに集約

  • デプロイは 開発アカウント → 手動承認 → 本番アカウント の順に進行

全体構成

アカウント構成

  • Tooling アカウント

    • CodePipeline / CodeBuild / Artifact S3 / KMS / ECR / CodeConnections を集約
    • GitHub からソース取得 → コンテナイメージをビルド → Tooling アカウントの ECR に push
    • 開発 / 本番アカウントの IAM ロールに AssumeRole → ECS を更新

  • 開発アカウント（Dev）

    • 開発用途の ECS サービスを稼働
    • 開発者が動作確認で利用する環境

  • 本番アカウント（Prod）

    • 本番 ECS サービスを稼働
    • 手動承認後にのみデプロイ

設計の考え方

Tooling アカウントの採用は、以下の AWS 公式サンプルを参考にしています。

また、ECR については 1 つのリポジトリを複数アカウントから共有しても十分なスケーラビリティが確保されている ことが、以下の公式ブログで解説されています。

※引用：AWS公式ブログ（Containers）『Sharing Amazon ECR repositories with multiple accounts using AWS Organizations』（2025年11月17日アクセス）URL： Sharing Amazon ECR repositories with multiple accounts using AWS Organizations | Containers

Some AWS services, like Amazon Elastic Container Registry (ECR), support scalability when a single instance is shared between accounts to reduce management overhead and increase visibility.

CI/CD パイプラインの流れ

  1. 開発者が変更を feature ブランチへ push し、GitHub で Pull Request（PR）を作成
  2. レビュー後に PR を main ブランチへマージ
  3. main ブランチの更新（push）を検知して、Tooling アカウントの CodePipeline が起動
  4. CodeBuild がコンテナイメージをビルドし、Tooling アカウント の ECR に push
  5. CodePipeline が開発アカウントのデプロイロールへ AssumeRole → 開発環境の ECS サービス更新
  6. 開発者が開発環境で動作確認
  7. CodePipeline の ManualApproval（手動承認）ステージでレビュー
  8. 承認後、CodePipeline が本番アカウントのデプロイロールへ AssumeRole → 本番 ECS サービス更新

実装ステップ（やってみた）

Step 1. VPC エンドポイントの作成（開発 / 本番アカウント）

開発・本番アカウントそれぞれで、ECS タスク実行用 VPC に以下の VPC エンドポイントを作成します。

  • com.amazonaws.ap-northeast-1.ecr.api
  • com.amazonaws.ap-northeast-1.ecr.dkr
  • com.amazonaws.ap-northeast-1.logs
  • com.amazonaws.ap-northeast-1.s3

ECR は api / dkr 用 VPC エンドポイントの両方が必要です。

Step 2. ecsTaskExecutionRole の作成（開発 / 本番アカウント）

両アカウントに ecsTaskExecutionRole が存在しなければ作成します。

  • 信頼ポリシー: ecs-tasks.amazonaws.com

  • アタッチポリシー: AmazonECSTaskExecutionRolePolicy

この AWS マネージドポリシーには以下の権限が含まれており、ECR からのイメージ pull / CloudWatch Logs 出力を担います。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

後続の Step 3 で、この IAM ロールを ECR リポジトリポリシーの設定で明示的に許可します。

Step 3. ECR の作成（Tooling アカウント）

Tooling アカウントに、アプリケーション用の ECR リポジトリを 1 つ作成します。

タグ上書きで過去バージョンが消えると、切り戻しができなくなってしまうので、イメージタグのミュータビリティはイミュータブル（Immutable）にしました。

Immutable は 同じタグ名で既存イメージを上書きできない設定です。

今回はレジストリ全体に拡張スキャンを有効化し、リポジトリ単位の設定には依存しない構成にします。

リポジトリの作成完了。

レジストリ全体のスキャン設定から、「拡張スキャン」を有効化。
※拡張スキャン自体に Amazon ECR の追加料金はかかりませんが、スキャンには Amazon Inspector の料金が発生します。

開発中にイメージを大量に push すると、現行タスク定義が参照しているイメージまで削除される可能性があります。

従って、[アクション]-[ライフサイクルポリシー]の設定で、保持するコンテナイメージ数を増やしておきます。

保持イメージ数を 100 など十分大きい値にしておきます。

開発 / 本番アカウントの ecsTaskExecutionRole から Tooling アカウントの ECR を pull できるように、リポジトリポリシーを設定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountPullFromDevAndProdExecutionRoles",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::< 開発アカウントID >:role/ecsTaskExecutionRole",
          "arn:aws:iam::< 本番アカウントID >:role/ecsTaskExecutionRole"
        ]
      },
      "Action": [
        "ecr:BatchCheckLayerAvailability",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ]
    }
  ]
}

ポリシーは以下の「例: 別のアカウントを許可する」を 参考にしました。

Step 4. アプリケーションリポジトリ準備（Dockerfile & buildspec.yml）

4-1. ディレクトリ構成

GitHub リポジトリはシンプルに以下のような構成としました。

  • Dockerfile
  • buildspec.yml

4-2. Dockerfile

今回は、Apache（httpd）を 8080 番ポートで公開するだけのシンプルな Web サーバーコンテナを用意します。

# ベースは Amazon Linux 2023
FROM public.ecr.aws/amazonlinux/amazonlinux:2023

# Apache(httpd) を導入してキャッシュを削除
RUN dnf -y update \
 && dnf -y install httpd \
 && dnf clean all && rm -rf /var/cache/dnf

# httpd の待受ポートを 8080 に変更
RUN sed -i 's/^Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf

# シンプルなコンテンツを配置
RUN echo 'Hello from CI/CD Test!!!' > /var/www/html/index.html

# 公開するポート
EXPOSE 8080

# フォアグラウンドで httpd 起動
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]
4-3. buildspec.yml

CodeBuild から ECR に push するための buildspec.yml をリポジトリ直下に配置します。

version: 0.2

env:
  variables:
    ECR_REPO_NAME: "< Step3で作成したECRリポジトリ名 >" # ECR リポジトリ名
    CONTAINER_NAME: "WebServer"  # ECS のコンテナ名

phases:
  pre_build:
    commands:
      - echo "Logging in to Amazon ECR..."
      - aws --version
      - AWS_ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
      - REPOSITORY_URI=${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com/${ECR_REPO_NAME}
      - aws ecr get-login-password --region ${AWS_REGION} | docker login --username AWS --password-stdin ${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_REGION}.amazonaws.com
      - '[[ "${CODEBUILD_RESOLVED_SOURCE_VERSION:-}" =~ ^[0-9a-fA-F]{40}$ ]] || { echo "ERROR: CODEBUILD_RESOLVED_SOURCE_VERSION が40桁のコミットSHAではありません。"; exit 1; }'
      - IMAGE_TAG="${CODEBUILD_RESOLVED_SOURCE_VERSION:0:7}"
      - echo "Image tag = ${IMAGE_TAG}"

  build:
    commands:
      - echo "Build started on $(date)"
      - echo "Building Docker image..."
      - docker build -t "${REPOSITORY_URI}:${IMAGE_TAG}" .

  post_build:
    commands:
      - echo "Build completed on $(date)"
      - echo "Pushing Docker images..."
      - docker push ${REPOSITORY_URI}:${IMAGE_TAG}
      - echo "Writing imagedefinitions.json for ECS deploy..."
      - printf '[{"name":"%s","imageUri":"%s"}]' "${CONTAINER_NAME}" "${REPOSITORY_URI}:${IMAGE_TAG}" > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json

ポイントは以下の 2 つです。

  • イメージタグにコミットハッシュ（先頭 7 桁）を付与

  • ECS デプロイ用のアーティファクトを生成
    imagedefinitions.json を出力し、CodePipeline → ECS アクションで参照します。 このファイルには コンテナ名 と イメージ URI が json 形式で含まれます。

この Dockerfile と buildspec.yml を GitHub に push しておきます。

Step 5. CodeConnections の作成（Tooling アカウント）

CodeBuild のビルドプロジェクト作成時に必要になるので、あらかじめ Tooling アカウントで CodeConnections を作成します。

まず、AWS マネジメントコンソールで CodePipeline を開き、左ペインの 「接続」 を選択して作成していきます。

今回はソースリポジトリとして GitHub を利用するため、プロバイダーに GitHub を選択し、「GitHub に接続する」 をクリックします。

認証情報を入力して GitHub にサインインします。

「接続名」 を入力し、作成します。

接続が問題なく作成されると、以下のようにステータスが 「利用可能」 になります。

補足ですが、執筆時点（2025 年 11 月時点）では CodeConnections は大阪リージョンでサポートされていません。

そのため、リポジトリの DR（災害対策）やリージョン構成を検討する際には、この点に留意する必要があります。

Step 6. CodeBuild プロジェクト作成 & ロールへの権限追加（Tooling アカウント）

Tooling アカウントで CodeBuild プロジェクトを新規作成します。

プロジェクトタイプで「デフォルトプロジェクト」を選択。

ソースプロバイダに「GitHub」を選択。

GitHub リポジトリには「https://github.com/< github-user-name >/< repository-name >」の形式で URL を入力し、「アカウント認証情報を管理します。」の項目をクリックします。

別ページに遷移するので、プルダウンから 先ほど作成した CodeConnections を選択して保存します。

GitHub App 経由での接続したいリポジトリ認証が成功すると、「アカウントは AWS が管理する GitHub アプリを使用して正常に接続されました。」と表示されます。

CodePipeline 側で Webhook（GitHub 連携）を設定するため、CodeBuild の「プライマリソースのウェブフックイベント」にはチェックを入れません。

ここで Webhook を有効化し、さらに CodePipeline 側でも Webhook を設定してしまうと、1 回のコミットで CodeBuild が二重に起動するため注意が必要です。

「オペレーティングシステム」の項目では Amazon Linux を選択し、VPC に関連付けない（非 VPC）構成でビルドします。

Buildspec の設定では 「buildspec ファイルを使用する」 を選択。 Buildspec 名 はデフォルトの buildspec.yml を使用したいため、「Buildspec 名 - オプショナル」には何も入力しません。

バッチ設定・アーティファクト設定もデフォルトのままとします。

ログ設定もデフォルトのままにし、ビルドプロジェクトを作成します。

ビルドプロジェクトが正常に作成されました。

自動生成される CodeBuild の IAM ロールには ECR 関連の権限が不足しているため、このままではビルドフェーズで権限不足によるエラーが発生します。

そのため、以下のような ECR 関連のポリシーを追加で付与します。


        {
            "Effect": "Allow",
            "Action": [
                "ecr:GetAuthorizationToken"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:DescribeRepositories",
                "ecr:ListImages",
                "ecr:DescribeImages",
                "ecr:BatchGetImage",
                "ecr:InitiateLayerUpload",
                "ecr:UploadLayerPart",
                "ecr:CompleteLayerUpload",
                "ecr:PutImage"
            ],
            "Resource": "arn:aws:ecr:ap-northeast-1:< ToolingアカウントID >:repository/< ECRリポジトリ名 >"
        }

Step 7. ECS クラスター / サービスの準備（開発/ 本番 アカウント）

まず 開発アカウント側で ECS を作成し、後で 本番アカウントにも同様の構成を用意します。

クラスターの作成

クラスターを新規作成。

クラスター名だけ指定し、他はデフォルト（Fargate）で作成

ECS クラスターが正常に作成されました。

タスク定義の作成

タスク定義を新規作成。

任意のタスク定義ファミリー名を入力

タスク定義におけるインフラストラクチャ関連の項目は、すべてデフォルト設定のままにしています。

  • コンテナ名: WebServer（Step 4 の CONTAINER_NAME と一致）

  • イメージ URI: 後から CodePipeline に上書きされるため、一旦 ECR のサンプルイメージを入れておく 例: https://gallery.ecr.aws/ecs-sample-image/amazon-ecs-sample

  • コンテナポート: 8080（Dockerfile 内の待ち受けポートに合わせる）

タスク定義が正常に作成されました。

サービスの作成

サービスを新規作成。

  • タスク定義: 上記で作成したタスク定義

  • サービス名: 任意

必要なタスク数は 1 としておきました。

事前に作成しておいた VPC ・ プライベートサブネット ・セキュリティグループ を指定します。
また、セキュリティグループは以下のように設定しました。

◆ インバウンドルール：
→ ALB の SG からの 8080 番ポートを許可

◆ アウトバウンドルール：
→ VPC エンドポイントの SG への 443 通信を許可
 → S3 プレフィックスリストへの 443 通信を許可

既に作成済みの ALB・リスナールール（HTTP8080）・ターゲットグループ（HTTP8080）を指定してECS サービスを作成します。

現時点ではタスクが正常に起動しなくて問題ありません。
後続の CI/CD パイプラインでイメージが更新されるため、このタイミングでは失敗していても想定どおりです。

Step 8. Artifact S3 バケット用の KMS キー作成（Tooling アカウント）

CodePipeline のアーティファクトを格納する S3 バケットで使用する KMS キー を Tooling アカウントに作成します。

キーポリシーは後続の Step 12 で修正するため、この時点ではカスタマーマネージドキーを作成するだけで問題ありません。

Step 9. CodePipeline作成（Tooling アカウント）

構成イメージは以下の通りです。

  • Source : GitHub（CodeConnections）
  • Build : Step 6 の CodeBuild
  • DeployDev : 開発アカウントの ECS へデプロイ
  • ManualApproval : 手動承認
  • DeployProd : 本番アカウントの ECS へデプロイ

CodePipeline を新規作成。

「カスタムパイプラインを構築する」を選択。

パイプライン名を入力し、アーティファクトストアの暗号化キーに Step 8 の KMS キーを指定。

アーティファクト格納先の S3 バケットは、開発／本番アカウントの IAM ロールからアクセスされるため、カスタマーマネージド KMS キーで暗号化されたバケットを指定します。

Step 5 の CodeConnections を選択して、後はデフォルトの設定のまま[次に]を選択しました。

[その他のビルドプロバイダー]から、[CodeBuild]を選択し、Step6 の CodeBuild を選択。

その他はデフォルトの設定のまま[次に]を選択しました。

テストステージは今回はスキップしました。

2025年11月7日時点では、デプロイ先の選択肢として、以下キャプチャのサービスを指定できます。

今回は、この中から「ECS」を選択しました。

マネジメントコンソール上では別アカウントの ECS を直接指定できないため、Step 7 で開発環境・本番環境に作成したクラスター名とサービス名を入力したうえで［次へ］を選択しました。

Tooling アカウント内に該当のクラスター／サービスが存在しないため、「Cluster not found」エラーが表示されますが、無視して問題ありません。

パイプラインの作成完了

パイプラインの実行はこの時点では失敗しますが、想定どおりの挙動なので問題ありません。

最終形に合わせて、以下のアクションも追加しておきます。

  • ManualApproval : 手動承認
  • DeployProd : 本番アカウントの ECS へデプロイ

まずは「ManualApproval」のアクションを追加します。

続いて「DeployProd」のアクションを追加します。

クラスター名とサービス名には、Step 7 で作成したステージング環境／本番環境アカウントのクラスター名・サービス名を指定します。

プルダウンには Tooling アカウント内に存在するクラスター名・サービス名しか表示されないため、プルダウンからは選択せず、値を直接入力。

最後に、パイプラインを忘れずに保存します。

Step 10. クロスアカウントデプロイ用 IAM ロール作成（開発 / 本番アカウント）

開発 / 本番アカウントに、Tooling アカウントから ECS デプロイを行うためのロールを作成します。

信頼ポリシー
Step 9 で自動生成された CodePipeline のサービスロール名を、Principal に指定します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::< ToolingアカウントID >:role/service-role/AWSCodePipelineServiceRole-ap-northeast-1-< パイプライン名 >"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

IAMポリシー 


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowEcsServiceAndTaskManagement",
            "Effect": "Allow",
            "Action": [
                "ecs:DescribeServices",
                "ecs:DescribeTaskDefinition",
                "ecs:DescribeTasks",
                "ecs:ListServices",
                "ecs:RegisterTaskDefinition",
                "ecs:UpdateService"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowS3AccessForArtifacts",
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::< ToolingアカウントのArtifact S3バケット名 >/*"
        },
        {
            "Sid": "AllowKmsDecryptForArtifacts",
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt"
            ],
            "Resource": "arn:aws:kms:ap-northeast-1:< ToolingアカウントID >:key/< Step8のKMSキーID >"
        },
        {
            "Sid": "AllowPassRoleForEcsTaskExecution",
            "Effect": "Allow",
            "Action": [
                "iam:PassRole"
            ],
            "Resource": "arn:aws:iam::< 開発/本番アカウントID >:role/ecsTaskExecutionRole"
        }
    ]
}

Artifact S3 / KMS は Tooling アカウントにあるため、クロスアカウントでの GetObject / Decrypt が必要です。

ここで作成したロール ARN は、Step 11・12・13 で使うのでメモしておきます。

Step 11. CodePipeline サービスロールに sts:AssumeRole を追加（Tooling アカウント）

Tooling アカウントの CodePipeline サービスロール AWSCodePipelineServiceRole-Region-Pipeline_Name に、開発 / 本番のデプロイロールへ AssumeRole するための権限を付与します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::< 開発アカウントID >:role/< Step10のECSデプロイ用ロール >",
                "arn:aws:iam::< 本番アカウントID >:role/< Step10のECSデプロイ用ロール >"
            ]
        }
    ]
}

Step 12. KMS キーポリシー修正（Tooling アカウント）

Step 8 の KMS キーに対し、以下のようなキーポリシーを設定します。


{
  "Version": "2012-10-17",
  "Id": "key-consolepolicy-3",
  "Statement": [
    {
      "Sid": "Allow access for Key Administrators",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::< ToolingアカウントID >:role/< 管理者用IAMロール名 >"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowKeyUseFromCrossAccountDeployRole",
      "Effect": "Allow",
      "Principal": {
        "AWS": [
          "arn:aws:iam::< 開発アカウントID >:role/< Step10のECSデプロイ用ロール >",
          "arn:aws:iam::< 本番アカウントID >:role/< Step10のECSデプロイ用ロール >",
          "arn:aws:iam::< Tooling アカウントID >:role/service-role/AWSCodePipelineServiceRole-< リージョン >-< パイプライン名 >",
          "arn:aws:iam::< Tooling アカウントID >:role/service-role/codebuild-< パイプライン名 >-service-role"
        ]
      },
      "Action": [
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:ViaService": "s3.ap-northeast-1.amazonaws.com"
        }
      }
    }
  ]
}

Step 13. Artifact S3 バケットポリシー（Tooling アカウント）

Artifact S3 側でも、開発 / 本番の ECS デプロイロールからの s3:GetObject を許可します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowRoleFromAccountBReadWriteObjects",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::< 開発アカウントID >:role/< Step10のECSデプロイ用ロール >",
                    "arn:aws:iam::< 本番アカウントID >:role/< Step10のECSデプロイ用ロール >"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::< ToolingアカウントのArtifactS3バケット >/*"
        }
    ]
}

Step 14. CodePipeline の設定を CLI で修正（Tooling アカウント）

最後に、アクション名の変更と、CodePipeline の Deploy アクションに Step 10 で作成した開発／本番アカウントの ECS デプロイ用ロール ARN を設定します。

コンソールではクロスアカウントロールを指定できないため、CLI で設定していきます。

このあたりの手順は、以下の記事も参考になります。

まず、現在のパイプラインの設定を取得します。


aws codepipeline get-pipeline --name "パイプライン名" >pipeline.json

出力された pipeline.json を編集します。修正箇所は以下の 3 点です。

  • 開発環境の Deploy アクション名を変更
  • 開発環境の ECS Deploy アクションに IAM ロール（roleArn）を指定
  • 本番環境の ECS Deploy アクションに IAM ロール（roleArn）を指定
開発環境（DeployDev）の設定

DeployDev ステージ内の Deploy アクションについて、アクション名を Deploy → DeployDev に変更したうえで、roleArn の項目を追記し、Step10 の開発環境の ECS デプロイ用ロール ARN を指定します。


        {
            "name": "DeployDev",
            "actions": [
                {
                    "name": "DeployDev",
                    "actionTypeId": {
                        "category": "Deploy",
                        "owner": "AWS",
                        "provider": "ECS",
                        "version": "1"
                    },
                    "runOrder": 1,
                    "configuration": {
                        "ClusterName": "< ECSクラスター名 >",
                        "ServiceName": "< ECSサービス名 >"
                    },
                    "outputArtifacts": [],
                    "inputArtifacts": [
                        {
                            "name": "BuildArtifact"
                        }
                    ],
                    "roleArn": "arn:aws:iam::< 開発アカウントID > :role/< Step10のECSデプロイ用ロール >",
                    "region": "ap-northeast-1",
                    "namespace": "DeployVariables"
                }
            ],
            "onFailure": {
                "result": "ROLLBACK"
            }
        },
本番環境（DeployProd）の設定

DeployProd ステージの Deploy アクションについても同様に、roleArn の項目を追記し、Step10 の本番環境の ECS デプロイ用ロール ARN を指定します。


        {
            "name": "DeployProd",
            "actions": [
                {
                    "name": "DeployProd",
                    "actionTypeId": {
                        "category": "Deploy",
                        "owner": "AWS",
                        "provider": "ECS",
                        "version": "1"
                    },
                    "runOrder": 1,
                    "configuration": {
                        "ClusterName": "< ECSクラスター名 >",
                        "ServiceName": "< ECSサービス名 >"
                    },
                    "outputArtifacts": [],
                    "inputArtifacts": [
                        {
                            "name": "BuildArtifact"
                        }
                    ],
                    "roleArn": "arn:aws:iam::< 本番アカウント ID > :role/< Step10のECSデプロイ用ロール >",
                    "region": "ap-northeast-1"
                }
            ]
        }

編集内容を pipeline.json に反映したら、CloudShell からパイプライン定義を更新します。
※ pipeline.json 内の metadata セクションは削除したうえでコマンドを実行すること


aws codepipeline update-pipeline --cli-input-json file://pipeline.json

なお、pipeline.json に metadata セクションが残ったままだと、以下のようなエラーになります。 そのため、metadata セクションは削除したうえで更新コマンドを実行してください。


Parameter validation failed:
Unknown parameter in input: "metadata", must be one of: pipeline

動作確認

Dockerfile の 'Hello from CI/CD Test!!!' を、以下のとおり 'Hello from CI/CD Test!!! (Latest)' に変更します。

変更は feature ブランチへ push し、PR を作成 → レビュー → main へマージします。

# ベースは Amazon Linux 2023
FROM public.ecr.aws/amazonlinux/amazonlinux:2023

# Apache(httpd) を導入してキャッシュを削除
RUN dnf -y update \
 && dnf -y install httpd \
 && dnf clean all && rm -rf /var/cache/dnf

# httpd の待受ポートを 8080 に変更
RUN sed -i 's/^Listen 80/Listen 8080/' /etc/httpd/conf/httpd.conf

# シンプルなコンテンツを配置
RUN echo 'Hello from CI/CD Test!!! (Latest)' > /var/www/html/index.html

# 公開するポート
EXPOSE 8080

# フォアグラウンドで httpd 起動
CMD ["/usr/sbin/httpd", "-D", "FOREGROUND"]

PR マージにより main ブランチが更新されると、CodePipeline が自動起動し、開発環境へのデプロイまで進みます。

開発環境の ALB の DNS 名へアクセスすると、変更が反映されていることを確認できます。

本番環境はまだ ManualApproval（手動承認）を行っていないため、表示内容は変更前のままです。

ManualApproval（手動承認）で承認します。

承認後、本番環境へのデプロイまで完了しました。

最後に本番環境の ALB の DNS 名へアクセスし、変更が反映されたことを確認できました。

まとめ

本記事では、Tooling / 開発 / 本番の 3 アカウント構成で、Tooling アカウント に CI/CD を集約しつつ CodePipeline から各アカウントへクロスアカウントデプロイする一例を紹介しました。

ECR や CodePipeline を Tooling アカウント 側に集約し、ECS だけを環境アカウントに持つことで、パイプライン運用とイメージ管理を一元化しつつ、環境分離も担保できる構成になります。

ただし、これはあくまで実装パターンの一つにすぎません。ECR を環境ごとに分ける、パイプラインを環境アカウント側に置くなど、組織の要件や運用ポリシーによって別の設計が適するケースも十分にあり得ます。

本記事の内容が、構成検討の一助となれば幸いです。