AWS Code* ファミリー徹底解説 Vol1 全体像 GHA ecspresso比較

1. この記事について

1-1. 本記事のゴール

AWS の CI/CD を本番運用したい、あるいは現在利用している GitHub Actions や ecspresso から移行・併用を検討しているエンジニアを主な対象としている。
本シリーズ Vol1 は「AWS Code* ファミリーとは何か」という全体像の把握から、「どのサービスを自チームに採用すべきか」という具体的な選定判断まで、1本で完走できる構成になっている。

Vol2 以降では各サービスの詳細な実装・運用を深掘りするが、Vol1 単独で採用判断できるよう、比較軸・選定フロー・移行ガイドを全て網羅している。
既存の GitHub Actions+OIDC 環境を持つチームは §3 で、ecspresso を使っているチームは §4 で、それぞれ「Code* へ移行すべきか・共存すべきか」の具体的な判断材料を得られる。

本記事を読み終えると、以下のことができるようになる:

• AWS Code* 5サービスの役割・境界・連携経路を俯瞰し、全体像マップを頭に入れる
• GitHub Actions vs CodeBuild/CodePipeline の 7軸比較 (コスト / 権限 / 監査 / Runner速度 / 保守性 / AWS統合度 / 学習コスト) で自チームの選定判断を下せる
• ecspresso vs CodeDeploy の ECS Blue/Green 選択軸と Lambda Canary の唯一性を理解し、ECS デプロイ方式の最適解を選択できる
• Terraform (Code Connections + IAM Role) による CI/CD 基盤の基礎実装をそのままプロジェクトに適用できる
• CodeCommit・CodeStar・CodeCatalyst 廃止後の移行パスを把握し、既存パイプラインを安全に再構築できる

各節の構成 (§3〜§7 はすべて Terraform HCL / AWS CLI / コンソール操作の3点セット形式):

1-2. 読者像

前提知識: AWS CLI・Terraform の基礎的な操作経験があること。
CI/CD パイプラインの基本概念 (Source→Build→Test→Deploy の流れ) を理解しているエンジニアを想定している。

主な対象読者:

• AWS 上で新規 CI/CD 基盤を構築する予定があるエンジニア・インフラアーキテクト
• 現在 GitHub Actions を使っているが、AWS 深統合やマネージドビルド環境への移行・拡張を検討しているチームのリーダー
• ecspresso を使った ECS デプロイを CodeDeploy に置き換えるか、あるいは共存させるかを判断したいエンジニア
• CodeCommit・CodeStar が廃止されたことを知り、既存パイプラインの移行先を探しているエンジニア
• チーム規模の拡大・コンプライアンス要件の強化に伴い、CI/CD 基盤を一から見直したいチーム

本記事は「入門向けサービス紹介」ではなく「採用判断の材料を提供すること」を目的としているため、
基本的な AWS の操作経験を前提にした中級以上の内容となっている。
AWS のサービスを初めて触れる方は、先に AWS 公式の Developer Tools 概要ページを参照してから本記事を読むことを推奨する。

1-3. なぜ今これを書くか

AWS の CI/CD サービス群は、2024年に大きな転換点を迎えた。

廃止・停止サービスの整理 (2024年):

• CodeCommit 新規利用停止 (2024-07): 10年以上提供されてきた AWS マネージド Git ホスティングサービスが、新規アカウントへの提供を停止した。既存の CodeCommit リポジトリは引き続き利用できるが、新規作成はできない。GitHub / GitLab / Bitbucket + Code Connections (旧 CodeStar Connections) への移行が事実上の標準対応となっている。
• CodeStar 完全廃止 (2024-07): CodePipeline・CodeBuild・CodeCommit・ElasticBeanstalk を束ねるプロジェクト管理サービスが完全に廃止された。従来 CodeStar で管理していたリソースは、CloudFormation テンプレート + CodePipeline V2 による代替構築が必要になった。
• CodeCatalyst (停止予定): GA 後に停止の方向性が示されており、既存ユーザーは CodePipeline V2 + CodeBuild への移行を検討する必要がある状況だ。

こうした変化の中で、国内の技術ブログでは「現役5サービスの全体像」「廃止サービスの移行ガイド」「GitHub Actions / ecspresso との比較・選定判断」という3軸を1本の記事で完走しているものは少ない。
加えて、CodePipeline V2 への移行 (V1 との API 差異)、Code Connections への名称変更 (旧 CodeStar Connections)、OIDC ベースの認証標準化など、2024年以降の変更点を反映した最新の解説も不足している状況だ。

本シリーズはその情報空白を埋めることを目的として起草した。
Vol1 (本記事) だけでも採用判断が完結するよう、§3〜§7 の各章では Terraform HCL / AWS CLI / コンソール操作の3点セット形式でコードスニペットを提供する。
実際のプロジェクトでそのまま参照・コピーできる実用性を最優先にした構成だ。

CodePipeline V1 → V2 への移行についての注記:

CodePipeline は 2023年に V2 としてメジャーアップデートされ、V1 との API 仕様が一部変更された。
V1 を使い続けているチームは早期に V2 へ移行することを強く推奨する。
V2 の主な追加機能は以下の通りだ:

• 並列実行 (Parallel Stages): 複数の Build/Test ステージを並行実行してパイプライン時間を短縮
• 変数 (Variables): パイプライン実行ごとに動的パラメータを渡す機能 (環境変数の柔軟な受け渡し)
• 条件分岐 (Conditions): ステージ実行の条件制御 (ブランチ名・タグ・環境変数に基づくスキップ)
• Event-based trigger: EventBridge 経由のトリガーが標準化され、CloudWatch Events との直接連携が廃止

Terraform では aws_codepipeline リソースで pipeline_type = "V2" を指定するだけで V2 に切り替えられる。
既存 V1 パイプラインの Terraform state を V2 に移行する際は、terraform state mv を使わず新規リソースとして再作成するのが安全だ (V1→V2 のインプレース移行で予期せぬ State 差分が発生するケースがある)。
V1 のままでは並列ステージや変数サポートが使えないため、新規パイプライン設計では必ず V2 を選択すること。

1-4. 3点セット解説形式について

§3〜§7 の実装章では、以下の3点セット形式でコードスニペットを提供する。
チームの技術スタックや既存インフラの状況によって最適な方法が異なるため、3形式を並記することで読者が必要な部分だけ参照できる設計にしている。

1. Terraform HCL:
インフラをコードで管理する IaC 形式。
aws_codestarconnections_connection / aws_iam_role / aws_iam_policy_document 等のリソース定義を提供する。
チームで再利用可能なモジュールとして設計してあるため、プロジェクトにそのまま適用できる。

2. AWS CLI:
ターミナルから直接 AWS リソースを操作するコマンド形式。
aws codeconnections / aws codebuild / aws codepipeline / aws codedeploy の主要コマンドを網羅している。
既存の Shell スクリプトに組み込む用途や、トラブルシューティング時の確認コマンドとしても活用できる。

3. コンソール操作:
AWS マネジメントコンソールの GUI 操作手順。
各ステップを番号付きで解説しており、Terraform が使えない環境でも同等の設定を完了できる。
初回セットアップ時の動作確認・設定の視覚的な把握にも役立てられる。

本シリーズで参照している関連記事:

• GitHub Actions+OIDC Terraform CI/CD 完全ガイド: §3 で徹底比較する GHA+OIDC 構成の詳細はこちら
• ecspresso ECS Deploy Terraform 実践ガイド: §4 で比較する ecspresso 構成の詳細はこちら

AWS Developer Tools 公式ドキュメント

2. 全体像 (現役5サービス + 非推奨3サービス)

2-1. 現役5サービス概観

AWS Code* ファミリーの現役5サービスは、CI/CD パイプラインの各フェーズに対応した役割分担がされている。
各サービスの詳細実装は Vol2〜Vol4 で深掘りするが、ここでは全体像把握のための概要を示す。

CodeBuild: ソースコードのビルド・テスト・パッケージングを実行するマネージドサービス。
Docker コンテナ上で実行され、Linux / Windows 環境に対応している。
インフラ管理不要の完全マネージド型で、VPC 内実行・カスタムイメージ利用・キャッシュ戦略も可能だ。
GitHub Actions の Runner に相当するが、AWS リソースとのネイティブ統合が強みとなる。

CodePipeline V2: CI/CD の全フェーズをオーケストレーションするサービス。
GitHub / Bitbucket / S3 をソースとして CodeBuild・CodeDeploy と連携し、EventBridge でのトリガーにも対応している。
V2 では V1 にはなかった並列ステージ・変数・条件分岐が使えるようになり、複雑なパイプライン設計が可能になった。

CodeDeploy: ECS・Lambda・EC2 へのデプロイを担うサービス。
ECS では Blue/Green デプロイ、Lambda では Canary デプロイ (段階的トラフィック切り替え) をネイティブサポートしている。
特に Lambda の Canary デプロイは CodeDeploy 以外では実現が難しく、Serverless 本番運用での唯一性がある。

CodeArtifact: npm / pip / Maven / NuGet のパッケージレジストリをマネージドで提供するサービス。
プライベートリポジトリの提供と、アップストリームの public パッケージ (npmjs.org / PyPI) の透過的プロキシ機能を持つ。
サプライチェーン攻撃のリスク低減・SBOM 管理と組み合わせたセキュリティ強化に活用できる。

CodeGuru: ML ベースのコードレビューとランタイムパフォーマンス分析を提供するサービス。
CodeGuru Reviewer は PR に対して自動コードレビューコメントを生成し、CodeGuru Profiler はランタイムのホットスポットを可視化する。
GitHub / Bitbucket との統合も可能で、CI/CD パイプラインへの組み込みができる。

2-2. 非推奨3サービスと移行先

廃止・非推奨サービスの現状と移行先を整理する。詳細な移行手順は §7 で解説する。

CodeCommit (新規利用停止: 2024-07):
新規アカウントでの利用が停止された。既存リポジトリは継続利用可能だが、早期移行を推奨する。
移行先: GitHub.com / GitLab.com / Bitbucket + Code Connections (旧 CodeStar Connections)。

CodeStar (完全廃止: 2024-07):
プロジェクト管理・リソースまとめサービスとして完全廃止。CloudFormation スタック + CodePipeline V2 で代替構築が必要だ。
移行先: CodePipeline V2 + CloudFormation テンプレート化 + 各サービス個別管理。

CodeCatalyst (停止予定):
統合開発環境として GA されたが、停止の方向性が示されている。
移行先: CodePipeline V2 + CodeBuild + IDE 直接統合 (VS Code Remote / Cloud9 等)。
新規プロジェクトへの CodeCatalyst 採用は現時点では推奨しない。

なお、廃止された各サービスの詳細な移行コマンド・Terraform 差分・コンソール操作手順は §7 で3点セット形式で解説する。

2-3. 関連サービスとの連携境界

Code* ファミリーは単体で完結するサービスではなく、以下の AWS サービスと連携して CI/CD パイプラインを構成する:

• ECR (Elastic Container Registry): CodeBuild でビルドしたコンテナイメージのプッシュ先。CodeDeploy の ECS Blue/Green デプロイで参照するイメージを格納する
• S3: CodeBuild のビルドアーティファクト保管・CodePipeline のソース (ZIP) 格納先として利用する
• IAM: 各サービスが実行する操作の権限管理。CodeBuild Role / CodePipeline Role / CodeDeploy Role の設計が最重要ポイント (§6 で詳解)
• CloudWatch Logs: CodeBuild のビルドログ・CodeDeploy のデプロイイベントログの集約先として利用する
• EventBridge: CodePipeline V2 のトリガー (GitHub push イベント → EventBridge → Pipeline 起動) に利用。スケジュール実行にも対応する

これらの連携サービスの権限管理 (IAM Role 設計) は §6 で Terraform + AWS CLI + コンソールの3点セットで詳解する。
特に IAM Role のスコープ設計ミス (過剰権限付与) は本番環境でのインシデント原因になりやすいため、最小権限の原則に基づいた設計が最優先事項となる。

3. vs GitHub Actions+OIDC (cmd_037 比較)

3-1. なぜ GitHub Actions と比較するか

AWS Code を検討するチームの多くはすでに GitHub Actions (GHA) を運用中*、あるいは GHA を出発点として学習を進めている。GHA は GitHub リポジトリと密結合した CI/CD プラットフォームであり、豊富なマーケットプレイス Actions と高い柔軟性から国内外で広く採用されている。一方で「AWS リソースとの認証」「監査ログの一元化」「長時間ビルドのコスト」という課題も顕在化してきた。

AWS Code* は AWS マネージドサービスとして IAM・CloudTrail・VPC との統合を前提に設計されており、GHA とはアーキテクチャ上の思想が異なる。本章では 7 つの軸で両者を比較し、チームの状況に応じた選定指針を示す。なお GHA+OIDC を用いた Terraform CI/CD の詳細は GitHub Actions+OIDC Terraform CI/CD 完全ガイド で解説しているため、移行を検討する際は本記事と合わせて参照されたい。

3-2. GHA vs AWS Code* 選定マトリクス

3-3. コスト詳細

GitHub Actions のコスト構造

GHA の料金は Hosted Runner の実行時間 (分単位、端数切り上げ) で課金される。public リポジトリは完全無料。private リポジトリはプランに応じた無料枠 (GitHub Free: 2,000 min/月、GitHub Team: 3,000 min/月、GitHub Enterprise: 50,000 min/月) を超えると従量課金となる。OS 換算率として Linux は 1×、Windows は 2×、macOS は 10× が適用されるため、macOS ビルドを多用する場合はコストが跳ね上がる点に注意が必要だ。

Self-hosted Runner を EC2 上に立てれば GHA 側の実行時間課金は発生しないが、EC2 のインスタンス費用と管理コストが別途発生する。月間ビルド時間が 500 分を超え、かつ long-running なジョブが多い場合は CodeBuild との比較計算が有効だ。

AWS Code* のコスト構造

CodeBuild はビルド実行時間 (秒単位、最小 1 分) で課金される。general1.small (3 vCPU/3 GB RAM) は $0.005/min が基本レートで、最初の 100 ビルド分/月は無料枠が適用される。スペックが上がるほど単価が上昇し、gpu1.x2large は $3.50/min となる。CodePipeline はアクティブなパイプライン 1 本あたり $1/月 (最初の 1 本は無料) で、実行回数に関わらず一定額が課金される設計だ。

ネットワーク費用の差異

GHA Hosted Runner は GitHub のクラウド上で動作するため、ECR への docker push/pull・S3 へのアーティファクトアップロードなど AWS リソースへのアクセスにはインターネット経由の API 呼び出しが発生する。AWS のデータ転送アウト費用 ($0.09/GB 〜) が見えにくいコストとして積み上がる点を見落としやすい。CodeBuild は VPC 内に配置して VPC エンドポイントを利用すれば AWS サービス間通信のデータ転送費を最小化できる。

3-4. 権限管理の違い

GHA: OIDC 経由 AWS 認証

GHA から AWS リソースにアクセスするには OIDC (OpenID Connect) を使用して一時的な IAM 認証情報を取得する方法が推奨される。aws-actions/configure-aws-credentials Action が OIDC トークンを AWS STS に提示し、指定した IAM Role を AssumeRoleWithWebIdentity で引き受ける仕組みだ。Terraform での OIDC プロバイダーと IAM Role の定義例を以下に示す。

resource "aws_iam_openid_connect_provider" "github" {  url = "https://token.actions.githubusercontent.com"  client_id_list  = ["sts.amazonaws.com"]  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]}resource "aws_iam_role" "github_actions" {  name = "github-actions-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Federated = aws_iam_openid_connect_provider.github.arn }Action = "sts:AssumeRoleWithWebIdentity"Condition = {  StringLike = { "token.actions.githubusercontent.com:sub" = "repo:your-org/your-repo:*"  }} }]  })}

AWS Code*: IAM Role 直接アタッチ

CodeBuild や CodePipeline ではサービスロールを IAM Role として直接アタッチするため、OIDC プロバイダーの設定が不要だ。IAM Role の Principal に CodeBuild サービスプリンシパルを指定するだけで最小権限の認証基盤が完成する。

resource "aws_iam_role" "codebuild" {  name = "codebuild-service-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "codebuild.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy_attachment" "codebuild_ecr" {  role = aws_iam_role.codebuild.name  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryPowerUser"}

IAM Role に aws:SourceAccount や aws:SourceArn の Condition を付与すれば他アカウントからの AssumeRole を防止できる。GHA の OIDC と異なり GitHub Token の漏洩リスクがない点もセキュリティ上の利点となる。

3-5. 選定指針 ― どちらを選ぶか

5 シナリオ別推奨

5 ステップ判断フレームワーク

1. リポジトリの所在 — GitHub 完結なら GHA が自然な選択
2. ビルド時間 — 平均 10 分超かつ月 500 回以上なら CodeBuild がコスト優位になりやすい
3. 監査要件 — SOC2/PCI-DSS 対応や内部監査証跡が必要なら AWS Code*
4. AWS 統合の深さ — ECR・ECS・Lambda との直接統合が必要なら AWS Code*
5. チームの学習リソース — AWS 経験が薄く GHA に慣れているなら GHA から始めて Code* を段階導入する選択肢もある

3-6. AWS Code* + GHA 併用構成 ― 3点セット

AWS と GitHub の両方を活用する「ハイブリッド構成」も現実的な選択肢だ。CodeStar Connections を使えば CodePipeline のソース取得を GitHub リポジトリに向けられる。GHA でユニットテストを実行し、メインブランチへのマージをトリガーに CodePipeline でデプロイするという役割分担が典型的な併用パターンとなる。

Terraform HCL: GitHub 接続 (aws_codestarconnections_connection)

resource "aws_codestarconnections_connection" "github" {  name = "github-connection"  provider_type = "GitHub"}resource "aws_codepipeline" "main" {  name  = "main-pipeline"  role_arn = aws_iam_role.codepipeline.arn  artifact_store { location = aws_s3_bucket.artifacts.bucket type  = "S3"  }  stage { name = "Source" action {name = "Source"category= "Source"owner= "AWS"provider= "CodeStarSourceConnection"version = "1"output_artifacts = ["source_output"]configuration = {  ConnectionArn = aws_codestarconnections_connection.github.arn  FullRepositoryId = "your-org/your-repo"  BranchName = "main"} }  }  stage { name = "Build" action {name = "Build"category= "Build"owner= "AWS"provider= "CodeBuild"version = "1"input_artifacts  = ["source_output"]output_artifacts = ["build_output"]configuration = {  ProjectName = aws_codebuild_project.main.name} }  }}

AWS CLI: パイプライン・接続確認

# アクティブなパイプライン一覧aws codepipeline list-pipelines --region ap-northeast-1# パイプライン実行履歴 (最新 10 件)aws codepipeline list-pipeline-executions \  --pipeline-name main-pipeline \  --max-items 10 \  --region ap-northeast-1# GitHub 接続一覧 (PENDING → コンソール承認が必要)aws codestar-connections list-connections \  --provider-type GitHub \  --region ap-northeast-1

コンソール: Developer Tools → Connections 承認手順

1. AWS マネジメントコンソール → Developer Tools → Settings → Connections
2. Create connection を選択 → プロバイダーに GitHub を選択
3. Connect to GitHub ボタンをクリック → GitHub OAuth 認証画面でリポジトリアクセスを承認
4. 接続名 (例: github-connection) を入力 → Connect をクリック
5. ステータスが Available になったことを確認してから CodePipeline でソースとして使用する

公式ドキュメント: Working with connections to GitHub — AWS CodePipeline

4. vs ecspresso (cmd_077 比較) + Lambda Canaryとの違い

4-1. ecspresso とは

ecspresso は KAYAC が OSS として開発・公開した ECS デプロイ専用 CLI ツールだ。
ECS タスク定義 (ecs-task-def.json) と ECS サービス定義 (ecs-service-def.json) をファイルで管理し、
ecspresso deploy コマンド1本でデプロイを完結させるシンプルな設計が特徴となっている。

本 §4 では ecspresso と CodeDeploy を「ECS デプロイ」という共通領域において比較し、自チームのユースケースに最適な選択肢を判断する材料を提供する。
ecspresso の実践的な構成例・Terraform 連携パターンについては、別記事「ecspresso ECS Deploy Terraform 実践ガイド」で詳解しているため、合わせて参照してほしい。

ecspresso の主な特徴:

• ECS 専用設計: ECS サービス / タスク定義のみを管理対象とし、アプリリリース作業に特化した CLI ツール
• ファイルベースの宣言型: ecs-task-def.json と ecs-service-def.json を Git 管理でき、CI/CD パイプラインへの組み込みコストが低い
• 軽量バイナリ: 依存パッケージが少なく、バイナリ1本で動作する。GitHub Actions や CodeBuild 環境へのインストールが容易
• Rolling / Blue/Green 両対応: deploymentConfiguration の設定で Rolling Update と ALB Blue/Green を切り替えられる
• 高速ロールバック: デプロイ失敗時に前バージョンへ即時ロールバック可能。CodeDeploy の待機時間が不要なため切り戻しが速い
• Terraform との分業: Terraform がインフラ全体 (VPC / ALB / ECS クラスター / IAM) を管理し、ecspresso がアプリリリースを担う分業構成が多い

Terraform との位置づけ:
Terraform がインフラ全体を Infrastructure as Code として管理するのに対して、ecspresso はアプリケーションのリリースフローに特化している。
ECS クラスター / ALB / IAM ロールは Terraform で初期構築し、以降のアプリリリース (タスク定義の更新・Blue/Green 切り替え) は ecspresso に委譲するパターンがよく使われる。
この構成では Terraform と ecspresso のスコープが明確に分離されるため、チーム内での役割分担 (インフラ担当 vs アプリ担当) がしやすい利点がある。

4-2. ECS Blue/Green 選択軸 (QG-3)

ecspresso と CodeDeploy はどちらも ECS の Blue/Green デプロイをサポートしているが、設計思想・実装方式・運用コストに大きな違いがある。
どちらを選ぶかの判断に使える比較軸を以下に整理する。

ecspresso Blue/Green の実装方式:
ecspresso では ecs-service-def.json の deploymentController を CODE_DEPLOY に設定し、ALB のターゲットグループ ARN を loadBalancers に指定することで Blue/Green を有効化する。
デプロイ実行時は ecspresso が新タスクセットを起動し、ヘルスチェック通過後に ALB リスナーが Blue から Green ターゲットグループへ切り替わる。
ロールバックは ecspresso rollback コマンドか --rollback-events DEPLOYMENT_FAILURE オプションで自動化できる。

CodeDeploy Blue/Green の実装方式:
CodeDeploy は aws_codedeploy_deployment_group に deploymentStyle { deployment_type = "BLUE_GREEN" } を指定するだけで、
ALB ターゲットグループの切り替えから古い Blue タスクの終了まで全てをマネージドで管理する。
blueGreenDeploymentConfiguration で Green 環境への待機時間・Blue タスクの終了タイミングを細かく制御でき、
auto_rollback_configuration でデプロイ失敗時 / アラーム発火時の自動ロールバックを設定できる。
CodePipeline V2 と組み合わせると Source → Build → Deploy の全パイプラインが一元管理され、デプロイ履歴・承認ゲート・アラーム連動ロールバックを単一コンソールで可視化できる。

4-3. Lambda Canary との違い

Lambda の Canary デプロイ (段階的トラフィック切り替え) は CodeDeploy のみが提供する機能であり、ecspresso では対応していない。
Lambda を含むデプロイ戦略の設計において、CodeDeploy が唯一の AWS Native 選択肢となる。

Lambda Canary デプロイの仕組み:
CodeDeploy は Lambda エイリアスのトラフィック重みを段階的に更新することで Canary デプロイを実現する。
新バージョンへのトラフィック割合を時間経過とともに増やし、異常検知時は自動ロールバックが走る設計だ。

デプロイ設定 (deploymentConfig) の主要オプション:

Pre/Post Hook でのバリデーション:
CodeDeploy の Lambda デプロイでは BeforeAllowTraffic / AfterAllowTraffic フックに Lambda 関数を設定でき、
デプロイ前後に自動バリデーション (スモークテスト / ヘルスチェック) を実行できる。
フックが FAIL を返した場合は自動ロールバックが発動する設計だ。

ecspresso との本質的な差異:
ecspresso は ECS タスクセットの切り替えのみを担うため、Lambda の Canary デプロイには対応していない。
ECS と Lambda を両方デプロイするチームが ecspresso を選択すると、Lambda 側は別途 CodeDeploy または SAM デプロイで管理する二重管理になる。
デプロイ基盤を一元化したい場合、または Lambda 本番環境に Canary デプロイが必要な場合は CodeDeploy + CodePipeline V2 の統合構成が推奨される。

AppSpec YAML による Lambda Canary 設定例:
CodeDeploy の Lambda デプロイでは AppSpec ファイルでフック関数を指定する。
BeforeAllowTraffic フックでスモークテストを実行し FAIL を返すことで自動ロールバックが発動するため、本番障害前にデプロイを安全に停止できる。

version: 0.0Resources:  - myLambdaFunction:Type: AWS::Lambda::FunctionProperties:  Name: myLambdaFunction  Alias: live  CurrentVersion: "1"  TargetVersion: "2"Hooks:  - BeforeAllowTraffic: beforeTrafficHookFunction  - AfterAllowTraffic: afterTrafficHookFunction

このように Lambda の段階的リリースには AppSpec + CodeDeploy の組み合わせが必須であり、ecspresso では代替できない。
Lambda を本番運用するチームは CodeDeploy の Lambda Canary 機能を優先的に評価することを推奨する。

4-4. 3点セット: CodeDeploy ECS Blue/Green 設定例

Terraform HCL

resource "aws_codedeploy_app" "ecs_app" {  compute_platform = "ECS"  name = "my-ecs-app"}resource "aws_codedeploy_deployment_group" "ecs_bg" {  app_name= aws_codedeploy_app.ecs_app.name  deployment_group_name  = "my-ecs-bg-group"  deployment_config_name = "CodeDeployDefault.ECSAllAtOnce"  service_role_arn = aws_iam_role.codedeploy_ecs.arn  deployment_style { deployment_option = "WITH_TRAFFIC_CONTROL" deployment_type= "BLUE_GREEN"  }  blue_green_deployment_config { deployment_ready_option {action_on_timeout = "CONTINUE_DEPLOYMENT"wait_time_in_minutes = 0 } terminate_blue_instances_on_deployment_success {action= "TERMINATE"termination_wait_time_in_minutes = 5 }  }  ecs_service { cluster_name = aws_ecs_cluster.main.name service_name = aws_ecs_service.app.name  }  load_balancer_info { target_group_pair_info {prod_traffic_route {  listener_arns = [aws_lb_listener.https.arn]}target_group {  name = aws_lb_target_group.blue.name}target_group {  name = aws_lb_target_group.green.name} }  }  auto_rollback_configuration { enabled = true events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]  }}

AWS CLI

# デプロイグループ一覧確認aws deploy list-deployment-groups \  --application-name my-ecs-app \  --query "deploymentGroups" \  --output table# ECS Blue/Green デプロイ実行aws deploy create-deployment \  --application-name my-ecs-app \  --deployment-group-name my-ecs-bg-group \  --deployment-config-name CodeDeployDefault.ECSAllAtOnce \  --revision 'revisionType=AppSpecContent,appSpecContent={content="{\"version\":0.0,\"Resources\":[{\"TargetService\":{\"Type\":\"AWS::ECS::Service\",\"Properties\":{\"TaskDefinition\":\"arn:aws:ecs:ap-northeast-1:123456789012:task-definition/my-app:5\",\"LoadBalancerInfo\":{\"ContainerName\":\"app\",\"ContainerPort\":8080}}}}]}"}' \  --description "Deploy v1.5.0 ECS Blue/Green"# デプロイ状態確認aws deploy get-deployment \  --deployment-id d-XXXXXXXXX \  --query "deploymentInfo.{status:status,created:createTime}" \  --output json

コンソール操作

1. AWS コンソール → [Developer Tools] → [CodeDeploy] → [Applications]2. [Create application] → [Application name] に任意名 → [Compute platform: Amazon ECS] → [Create]3. [Deployment groups] タブ → [Create deployment group]4. [Service role] に CodeDeploy 用 IAM ロール ARN を入力5. [Deployment type] → [Blue/green] を選択6. [Environment configuration] → [Amazon ECS] → クラスター名・サービス名を選択7. [Load balancers] → 対象 ALB を選択 → Production listener / Blue TG / Green TG を設定8. [Deployment settings] → [Traffic rerouting] で即時切り替えか待機時間を設定9. [Rollback configuration] → [Roll back when a deployment fails] にチェック → [Save]10. 初回デプロイ: [Create deployment] → AppSpec YAML または JSON を貼り付け → [Deploy]

CodeDeploy ECS Blue/Green 公式ドキュメント

5. サービス選定フロー (チーム規模/ワークロード/コンプラ別判断ツリー)

5-1. 選定3軸

AWS Code* ファミリー・GitHub Actions (GHA)・ecspresso の3者から最適な構成を選定するには、チームの現状に基づいた3つの軸で判断することを推奨する。

軸1: チーム規模

軸2: ワークロード

軸3: コンプライアンス要件

3軸の組み合わせ方:
3軸は独立した評価軸ではなく、相互に影響し合うため優先順位をつけて判断することを推奨する。
コンプライアンス要件が「厳格」であれば、チーム規模やワークロードにかかわらず Code* フルスタックが事実上の唯一解になる。
次にワークロードを確認し、Lambda Canary が必須かどうかで CodeDeploy の導入要否が決まる。
チーム規模は「現在」ではなく「1〜2年後の想定規模」で評価することが重要だ。
採用判断後にチームが急成長して移行コストが増大するケースは多いため、中長期の成長見込みを加味した上で選定すること。

5-2. 判断ツリー (QG-4)

3軸を組み合わせた選定判断フローを以下に示す。
まず「AWS 完結型か GitHub 中心か」で大きく分岐し、次に「ECS のみか Lambda 込みか」で CodeDeploy か ecspresso かが決まる設計だ。
判断ツリーは一方向に進む必要はなく、複数の条件が該当する場合は最も制約の強い条件 (コンプライアンス厳格・Lambda Canary 必須 等) を優先して選定することを推奨する。
また、判断ツリーは「現時点」での選定に使うものであり、チームの成長・ワークロードの変化に応じて定期的に再評価することが重要だ。

よくある選定ミスとその回避策:

• ミス1: ECS + Lambda を ecspresso で一元管理しようとする → Lambda Canary デプロイが使えないため、Lambda 本番リリースのリスク管理が手動になる。回避策: Lambda は CodeDeploy に担わせる
• ミス2: コンプライアンス要件が厳しくなった後に GHA から Code* へ移行しようとする → CI/CD パイプライン全体の再設計コストが高い。回避策: 初期設計時にコンプライアンス要件を確認し、Code* 採用を前向きに検討する
• ミス3: 小規模チームで Code* フルスタックを選択し管理コストに疲弊する → CodePipeline / CodeBuild の設定管理・IAM ロール設計は学習コストが高い。回避策: GHA + ecspresso から始めてチームが成熟したら段階的に Code* に移行する
• ミス4: Code Connections の OAuth 認証を自動化しようとする → 初回 GitHub OAuth 認証はコンソール手動操作が必須。回避策: Terraform で接続リソースを作成後、コンソールで手動認証を完了させてから後続の CodePipeline 設定を apply する手順を CI/CD 構築ドキュメントに明記する
• ミス5: ecspresso の deploymentController を変更せず Blue/Green を有効化しようとする → ECS サービス作成後に deploymentController は変更不可。Blue/Green に変更するには ECS サービスを再作成する必要がある。回避策: 初期設計時に Blue/Green を使うかどうかを決定し、deploymentController: CODE_DEPLOY を指定してサービスを作成する

5-3. 推奨パターン表

よく使われる構成パターンを3点に絞って整理する。

パターン選択の補足:
GHA と Code* はどちらかを選ぶ必要はなく、ハイブリッド構成も可能だ。
例えば GHA で PR テストを実行し、本番デプロイのみ CodePipeline V2 + CodeDeploy を使うというパターンは、学習コストを段階的に分散しながら AWS Native の本番デプロイ安全性を確保できる現実的な選択肢だ。
ecspresso と CodeDeploy はどちらもデプロイツールとして独立しているため、ECS サービスごとに使い分けることもできる。

段階的な移行パス:
既存環境から Code* への移行は一度に全て切り替える必要はない。
以下のような段階的なアプローチが現場では多く採用されている:

GHA を完全廃止する必要はなく、Step3 以降も開発環境テストや OSS CI は GHA を継続しながら本番フローだけ Code を使う構成が長期間維持されるケースが多い。
チームの学習コストと移行コストのバランスを考慮し、最も価値の高い領域から段階的に Code を導入することを推奨する。

選定を見直すタイミング:
初期選定後に以下の状況が発生したら、選定の再評価を検討すること:

• チームが 10人を超えてロール分離・承認ゲートが必要になった → Code* 移行を検討
• Lambda を本番運用するようになり Canary デプロイが必要になった → CodeDeploy 導入を優先
• コンプライアンス認証 (PCI-DSS / HIPAA 等) の取得を目指すことになった → Code* フルスタックへの移行計画を早期に策定
• ecspresso を使っているが ECS 以外のサービスも同一パイプラインで管理したくなった → CodeDeploy + CodePipeline V2 への統合を検討

5-4. 3点セット: Code Connections 設定例

Code Connections (旧 CodeStar Connections) は GitHub / Bitbucket / GitLab を CodePipeline V2 のソースとして接続するための認証連携サービスだ。
Code* フルスタック構成では必須の設定となる。
なお、Terraform リソース名は aws_codestarconnections_connection (旧名) と aws_codeconnections_* (新名) が混在している状況のため、2026年4月時点では旧名の aws_codestarconnections_connection を使うのが安定した選択だ。

Code Connections の認証フロー:
接続の作成には AWS コンソール上での OAuth 認証が必要だ。
aws codeconnections create-connection コマンドで接続リソースを作成しても、コンソールで GitHub への OAuth 認証を完了させるまでは接続ステータスが PENDING のままとなり、CodePipeline では使用できない。
Terraform で接続リソースを作成後、コンソールで手動の OAuth 認証を完了させるという手順が現状の制約となっている。
この初回手動認証ステップは設計上省略できないため、自動化フローでは aws codeconnections get-connection で AVAILABLE ステータスを確認してから後続の Terraform apply を実行する構成が推奨される。
GitLab への接続は provider_type = "GitLab" または "GitLabSelfManaged" (セルフホスト GitLab) で設定できる。
一度 AVAILABLE になった接続は複数の CodePipeline から再利用可能なため、接続を複数作成せず一本化して管理することがベストプラクティスだ。

Terraform HCL

resource "aws_codestarconnections_connection" "github" {  name = "github-connection"  provider_type = "GitHub"}resource "aws_codepipeline" "main" {  name = "my-app-pipeline"  role_arn= aws_iam_role.codepipeline.arn  pipeline_type = "V2"  artifact_store { location = aws_s3_bucket.artifacts.bucket type  = "S3"  }  stage { name = "Source" action {name = "Source"category= "Source"owner= "AWS"provider= "CodeStarSourceConnection"version = "1"output_artifacts = ["source_output"]configuration = {  ConnectionArn = aws_codestarconnections_connection.github.arn  FullRepositoryId = "my-org/my-repo"  BranchName = "main"} }  }}

AWS CLI

# Code Connections 一覧確認aws codeconnections list-connections \  --query "Connections[].{Name:ConnectionName,Status:ConnectionStatus,Provider:ProviderType}" \  --output table# 新規接続作成 (GUI 認証が別途必要)aws codeconnections create-connection \  --provider-type GitHub \  --connection-name github-connection# 接続 ARN を取得して CodePipeline に設定aws codeconnections get-connection \  --connection-arn arn:aws:codeconnections:ap-northeast-1:123456789012:connection/XXXXXXXX \  --query "Connection.{ARN:ConnectionArn,Status:ConnectionStatus}" \  --output json

コンソール操作

1. AWS コンソール → [Developer Tools] → [Settings] → [Connections]2. [Create connection] → プロバイダー (GitHub / Bitbucket / GitLab) を選択3. [Connection name] に任意名を入力 → [Connect to GitHub]4. GitHub の OAuth 認証画面で [Authorize AWS Connector for GitHub] をクリック5. 接続対象の GitHub Organization またはアカウントを選択 → [Connect]6. 接続ステータスが [Available] になったことを確認7. CodePipeline のソース設定で Connection ARN を指定

Code Connections 公式ドキュメント

6. Terraform 実装 (Vol1範囲: Code Connections + IAM Role 基盤)

6-1. Code Connections (GitHub 接続)

Code Connections は GitHub / Bitbucket / GitLab を CodePipeline V2 のソースとして接続するための認証連携サービスだ。
Terraform リソース名は aws_codestarconnections_connection (旧 CodeStar Connections 名) が2026年4月時点では安定している。
aws_codeconnections_connection (新名) も存在するが、プロバイダーバージョンによって挙動が異なるため旧名を推奨する。

重要制約: 初回 OAuth 認証はコンソール手動必須

terraform apply で接続リソースを作成しても、ステータスは PENDING のままだ。
GitHub の OAuth 認証はコンソールから手動で行う必要があり、この手順を自動化することはできない。
CI/CD パイプラインの初期セットアップ手順書には必ずこのコンソール操作手順を含めること。

resource "aws_codestarconnections_connection" "github" {  name = "github-connection"  provider_type = "GitHub"  tags = { Environment = var.environment ManagedBy= "terraform"  }}output "github_connection_arn" {  value = aws_codestarconnections_connection.github.arn  description = "Code Connections ARN (CodePipeline V2 Source に指定する)"}output "github_connection_status" {  value = aws_codestarconnections_connection.github.connection_status  description = "PENDING → コンソールで OAuth 認証が必要。AVAILABLE になったら CodePipeline が利用可能"}

初回 terraform apply 後のコンソール手動操作:

1. AWS コンソール → [Developer Tools] → [Settings] → [Connections]2. ステータスが [Pending] の接続をクリック3. [Update pending connection] をクリック4. GitHub の OAuth 認証画面で [Authorize AWS Connector for GitHub] をクリック5. 接続対象の GitHub Organization またはアカウントを選択 → [Connect]6. ステータスが [Available] に変わったことを確認7. 以降は Terraform で ARN を参照可能になる

6-2. IAM Role for CodeBuild

CodeBuild ジョブが ECR / S3 / CloudWatch Logs / SSM Parameter Store にアクセスするための最小権限 IAM ロールを定義する。
codebuild.amazonaws.com を信頼ポリシーに指定することで、CodeBuild サービスがこのロールを引き受けられるようになる。

data "aws_iam_policy_document" "codebuild_assume_role" {  statement { effect  = "Allow" actions = ["sts:AssumeRole"] principals {type  = "Service"identifiers = ["codebuild.amazonaws.com"] }  }}data "aws_iam_policy_document" "codebuild_policy" {  statement { sid = "LogsAccess" effect = "Allow" actions = ["logs:CreateLogGroup","logs:CreateLogStream","logs:PutLogEvents", ] resources = ["arn:aws:logs:*:*:log-group:/aws/codebuild/*"]  }  statement { sid = "S3ArtifactAccess" effect = "Allow" actions = ["s3:GetObject","s3:GetObjectVersion","s3:PutObject", ] resources = ["${aws_s3_bucket.artifacts.arn}","${aws_s3_bucket.artifacts.arn}/*", ]  }  statement { sid = "ECRAccess" effect = "Allow" actions = ["ecr:BatchCheckLayerAvailability","ecr:GetDownloadUrlForLayer","ecr:BatchGetImage","ecr:GetAuthorizationToken","ecr:PutImage","ecr:InitiateLayerUpload","ecr:UploadLayerPart","ecr:CompleteLayerUpload", ] resources = ["*"]  }  statement { sid = "SSMParameterAccess" effect = "Allow" actions = ["ssm:GetParameter","ssm:GetParameters","ssm:GetParametersByPath", ] resources = ["arn:aws:ssm:*:*:parameter/${var.environment}/*"]  }  statement { sid = "CodeConnectionsAccess" effect = "Allow" actions = ["codestar-connections:UseConnection", ] resources = [aws_codestarconnections_connection.github.arn]  }}resource "aws_iam_role" "codebuild" {  name= "${var.project}-codebuild-role"  assume_role_policy = data.aws_iam_policy_document.codebuild_assume_role.json  tags = { Environment = var.environment ManagedBy= "terraform"  }}resource "aws_iam_role_policy" "codebuild" {  name= "${var.project}-codebuild-policy"  role= aws_iam_role.codebuild.id  policy = data.aws_iam_policy_document.codebuild_policy.json}

6-3. IAM Role for CodePipeline

CodePipeline が CodeBuild の起動・S3 の読み書き・Code Connections の利用・CodeDeploy の呼び出しを行うための IAM ロールを定義する。
codepipeline.amazonaws.com を信頼ポリシーに指定する。

data "aws_iam_policy_document" "codepipeline_assume_role" {  statement { effect  = "Allow" actions = ["sts:AssumeRole"] principals {type  = "Service"identifiers = ["codepipeline.amazonaws.com"] }  }}data "aws_iam_policy_document" "codepipeline_policy" {  statement { sid = "S3ArtifactAccess" effect = "Allow" actions = ["s3:GetObject","s3:GetObjectVersion","s3:GetBucketVersioning","s3:PutObject", ] resources = ["${aws_s3_bucket.artifacts.arn}","${aws_s3_bucket.artifacts.arn}/*", ]  }  statement { sid = "CodeBuildAccess" effect = "Allow" actions = ["codebuild:BatchGetBuilds","codebuild:StartBuild", ] resources = ["*"]  }  statement { sid = "CodeConnectionsAccess" effect = "Allow" actions = ["codestar-connections:UseConnection", ] resources = [aws_codestarconnections_connection.github.arn]  }  statement { sid = "CodeDeployAccess" effect = "Allow" actions = ["codedeploy:CreateDeployment","codedeploy:GetApplication","codedeploy:GetApplicationRevision","codedeploy:GetDeployment","codedeploy:GetDeploymentConfig","codedeploy:RegisterApplicationRevision", ] resources = ["*"]  }  statement { sid = "ECSAccess" effect = "Allow" actions = ["ecs:DescribeServices","ecs:DescribeTaskDefinition","ecs:DescribeTasks","ecs:ListTasks","ecs:RegisterTaskDefinition","ecs:UpdateService", ] resources = ["*"]  }  statement { sid = "IAMPassRole" effect = "Allow" actions = ["iam:PassRole", ] resources = ["*"] condition {test  = "StringEqualsIfExists"variable = "iam:PassedToService"values = [  "cloudformation.amazonaws.com",  "elasticbeanstalk.amazonaws.com",  "ec2.amazonaws.com",  "ecs-tasks.amazonaws.com",] }  }}resource "aws_iam_role" "codepipeline" {  name= "${var.project}-codepipeline-role"  assume_role_policy = data.aws_iam_policy_document.codepipeline_assume_role.json  tags = { Environment = var.environment ManagedBy= "terraform"  }}resource "aws_iam_role_policy" "codepipeline" {  name= "${var.project}-codepipeline-policy"  role= aws_iam_role.codepipeline.id  policy = data.aws_iam_policy_document.codepipeline_policy.json}

6-4. S3 Artifact バケット

CodePipeline の各ステージ間で成果物を受け渡すための S3 バケットを定義する。

resource "aws_s3_bucket" "artifacts" {  bucket = "${var.project}-${var.environment}-codepipeline-artifacts"  tags = { Environment = var.environment ManagedBy= "terraform"  }}resource "aws_s3_bucket_versioning" "artifacts" {  bucket = aws_s3_bucket.artifacts.id  versioning_configuration { status = "Enabled"  }}resource "aws_s3_bucket_server_side_encryption_configuration" "artifacts" {  bucket = aws_s3_bucket.artifacts.id  rule { apply_server_side_encryption_by_default {sse_algorithm = "AES256" }  }}resource "aws_s3_bucket_public_access_block" "artifacts" {  bucket = aws_s3_bucket.artifacts.id  block_public_acls = true  block_public_policy  = true  ignore_public_acls= true  restrict_public_buckets = true}

6-5. Provider 設定

Vol1 で使用する Terraform Provider のバージョン制約を定義する。
required_version >= 1.9 は check ブロック (Terraform 1.5+) と動的ブロックを活用するために指定する。

terraform {  required_version = ">= 1.9"  required_providers { aws = {source  = "hashicorp/aws"version = "~> 5.0" }  }  backend "s3" { bucket = "my-terraform-state" key = "aws-code-family/terraform.tfstate" region = "ap-northeast-1"  }}provider "aws" {  region = var.aws_region  default_tags { tags = {Project  = var.projectEnvironment = var.environmentManagedBy= "terraform" }  }}

6-6. 3点セット: CodePipeline V2 完全定義

Vol1 の Terraform 基盤を統合した CodePipeline V2 の全体定義を示す。
Source → Build → Deploy の3ステージ構成で、Code Connections・CodeBuild・CodeDeploy を連携させる。

Terraform HCL

resource "aws_codepipeline" "main" {  name = "${var.project}-pipeline"  role_arn= aws_iam_role.codepipeline.arn  pipeline_type = "V2"  artifact_store { location = aws_s3_bucket.artifacts.bucket type  = "S3"  }  stage { name = "Source" action {name = "Source"category= "Source"owner= "AWS"provider= "CodeStarSourceConnection"version = "1"output_artifacts = ["source_output"]configuration = {  ConnectionArn = aws_codestarconnections_connection.github.arn  FullRepositoryId = "${var.github_org}/${var.github_repo}"  BranchName = var.branch_name} }  }  stage { name = "Build" action {name = "Build"category= "Build"owner= "AWS"provider= "CodeBuild"version = "1"input_artifacts  = ["source_output"]output_artifacts = ["build_output"]configuration = {  ProjectName = aws_codebuild_project.main.name} }  }  stage { name = "Deploy" action {name= "Deploy"category  = "Deploy"owner  = "AWS"provider  = "CodeDeploy"version= "1"input_artifacts = ["build_output"]configuration = {  ApplicationName  = aws_codedeploy_app.main.name  DeploymentGroupName = aws_codedeploy_deployment_group.main.deployment_group_name} }  }  tags = { Environment = var.environment ManagedBy= "terraform"  }}

AWS CLI

# パイプライン一覧確認aws codepipeline list-pipelines \  --query "pipelines[].{Name:name,Created:created,Updated:updated}" \  --output table# パイプライン詳細確認aws codepipeline get-pipeline \  --name "${PROJECT}-pipeline" \  --query "pipeline.{Name:name,Type:pipelineType,Role:roleArn}" \  --output json# 最新の実行状況確認aws codepipeline list-pipeline-executions \  --pipeline-name "${PROJECT}-pipeline" \  --max-results 5 \  --query "pipelineExecutionSummaries[].{ID:pipelineExecutionId,Status:status,Trigger:trigger.triggerType}" \  --output table

コンソール操作

1. AWS コンソール → [Developer Tools] → [CodePipeline] → [Pipelines]2. [Create pipeline] → [Pipeline name] に任意名 → [Pipeline type: V2] を選択3. [Service role] → [New service role] または既存ロールを選択4. [Artifact store] → [Default location] または既存 S3 バケットを指定5. [Add source stage] → [Source provider: GitHub (via GitHub App)] → Connection ARN を指定6. [Repository name] と [Branch name] を入力7. [Add build stage] → [Build provider: AWS CodeBuild] → [Project name] を入力8. [Add deploy stage] → [Deploy provider: AWS CodeDeploy] → Application / Deployment group を指定9. 設定内容を確認 → [Create pipeline]10. 初回実行が自動トリガーされるため、[Succeeded] になるまで確認

CodePipeline V2 公式ドキュメント

7. 移行ガイド (CodeCommit/Star/Catalyst廃止後の対応)

2024年以降、AWS Code* ファミリーの中で CodeCommit (新規停止) / CodeStar (廃止) / CodeCatalyst (非推奨) の 3 サービスが使用不可・非推奨となった。既存環境を持つチームは下表を参考に移行パスを選択すること。

7-1. CodeCommit → GitHub/GitLab 移行

背景

AWS は 2024年7月25日をもって CodeCommit の新規リポジトリ作成を停止した。
既存リポジトリの読み書きは継続利用可能だが、新規プロジェクトへの採用は推奨されない。
CodeCommit は長らく AWS Native のプライベート Git ホスティングとして使われてきたが、
GitHub / GitLab のエコシステムの充実により、外部 Git サービスへの移行が事実上の選択となった。

git push –mirror による完全移行

# 1. 既存 CodeCommit リポジトリをローカルにミラークローンgit clone --mirror \  https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/my-repo \  my-repo.gitcd my-repo.git# 2. 移行先 (GitHub) にリモートを追加git remote add github https://github.com/my-org/my-repo.git# 3. 全ブランチ・タグ・履歴を GitHub にプッシュgit push --mirror github# 4. ミラークローンを削除し通常クローンで再取得cd ..rm -rf my-repo.gitgit clone https://github.com/my-org/my-repo.git

CodePipeline のソース変更

CodeCommit をソースにしていた CodePipeline を GitHub + Code Connections に切り替える差分を示す。

# Before (CodeCommit)# stage {#name = "Source"#action {#  provider = "CodeCommit"#  configuration = {# RepositoryName = "my-repo"# BranchName  = "main"#  }#}# }# After (GitHub via Code Connections)stage {  name = "Source"  action { name = "Source" category= "Source" owner= "AWS" provider= "CodeStarSourceConnection" version = "1" output_artifacts = ["source_output"] configuration = {ConnectionArn = aws_codestarconnections_connection.github.arnFullRepositoryId = "my-org/my-repo"BranchName = "main" }  }}

移行後の確認ポイント:
– CodeCommit の AWSCodeCommitPowerUser ポリシーは不要 → IAM Role から削除する
– CodePipeline の Source Provider を変更するだけで既存の Build / Deploy ステージは再利用可能
– CodeBuild の buildspec.yml は変更不要

7-2. CodeStar 廃止後の代替構成

CodeStar は 2024年7月に完全廃止された。
CodeStar が提供していた「プロジェクト管理 + CodePipeline + CodeBuild 自動セットアップ」の機能は、
CodePipeline V2 + CloudFormation で個別に構築することになる。

module "ci_cd_pipeline" {  source = "./modules/codepipeline"  project= var.project  environment  = var.environment  github_org= var.github_org  github_repo  = var.github_repo  branch_name  = "main"  connection_arn  = aws_codestarconnections_connection.github.arn  codebuild_role  = aws_iam_role.codebuild.arn  pipeline_role= aws_iam_role.codepipeline.arn  artifact_bucket = aws_s3_bucket.artifacts.bucket}

CodeStar が自動生成していた IAM ロール (CodeStar-*) や CodeBuild プロジェクトは、
Terraform で明示的に定義することで同等の構成を再現できる。
チームのアクセス管理は IAM + AWS Organizations で行う。
CodeStar で作成された既存の CloudFormation スタック (awscodestar-*) は、CodeStar 廃止後も残存するため、
不要なリソースを整理する際は aws cloudformation list-stacks --query でスタック一覧を確認してから削除すること。

7-3. CodeCatalyst 移行パス

CodeCatalyst は AWS が提供する統合開発環境 (IDE + CI/CD + プロジェクト管理) だが、
新規採用は非推奨となっている。
GA 発表後もエコシステムの拡大が進まず、2026 年 4 月時点では AWS 社内でも新規プロジェクトへの採用は推奨されていない。
既存の CodeCatalyst ユーザーは以下の移行パスを検討すること。

CI/CD ワークフロー移行の判断軸:

AWS Deep Integration が必要 (ECR / ECS / Lambda Canary など) であれば CodePipeline V2 + CodeBuild を選ぶ。
外部 SaaS 連携・マルチクラウド・OSS エコシステム活用が必要であれば GitHub Actions が有利だ。
CodeCatalyst の .codecatalyst/workflows/*.yaml は CodePipeline の Terraform HCL や GitHub Actions の .github/workflows/*.yaml に書き直す必要があり、
1ワークフローあたり 2〜4 時間の変換作業を見込むこと。

移行の優先順位:
1. まず CI/CD ワークフローを移行し、ビルド・デプロイパイプラインを再稼働させる
2. 次に Dev Environment を移行し、開発者の日常作業に影響が出ないようにする
3. Issues / プロジェクト管理は最後に移行する (既存データのエクスポートを事前に行うこと)

7-4. 3点セット: CodeCommit 移行完了確認

Terraform HCL

# CodeCommit リポジトリ残存確認用 (移行完了確認後に削除)data "aws_codecommit_repository" "legacy_check" {  count  = var.check_legacy_codecommit ? 1 : 0  repository_name = var.legacy_repo_name}output "legacy_repo_clone_url" {  value = var.check_legacy_codecommit ? data.aws_codecommit_repository.legacy_check[0].clone_url_http : "skip"  description = "CodeCommit 残存リポジトリの確認 (移行完了後は削除)"}

AWS CLI

# CodeCommit リポジトリ残存確認aws codecommit list-repositories \  --query "repositories[].{Name:repositoryName,ID:repositoryId}" \  --output table# CodePipeline のソースプロバイダーが全て GitHub 移行済みか確認for pipeline in $(aws codepipeline list-pipelines --query "pipelines[].name" --output text); do  provider=$(aws codepipeline get-pipeline --name "${pipeline}" \ --query "pipeline.stages[?name=='Source'].actions[0].actionTypeId.provider" \ --output text)  echo "${pipeline}: ${provider}"done# Code Connections 接続確認 (AVAILABLE であること)aws codeconnections list-connections \  --query "Connections[?ConnectionStatus=='AVAILABLE'].{Name:ConnectionName,Provider:ProviderType}" \  --output table

コンソール操作

1. AWS コンソール → [Developer Tools] → [CodeCommit] → [Repositories]→ リポジトリ一覧が空または移行済み確認2. [Developer Tools] → [CodePipeline] → 各パイプライン → [Source ステージ]→ [CodeStarSourceConnection (GitHub)] になっていることを確認3. [Developer Tools] → [Settings] → [Connections]→ 接続ステータスが [Available] であることを確認

CodeCommit 公式ドキュメント (移行情報含む)

8. まとめ + Vol2予告 + よくある選定ミス10選

8-1. Vol1 の要点まとめ

本記事 Vol1 では AWS Code* ファミリー全体を「採用判断できる」レベルまで解説した。§1〜§7 の内容を 3 つのポイントに集約する。

① 現役 5 サービスと廃止 3 サービスの整理完了

CodeBuild / CodePipeline V2 / CodeDeploy / CodeArtifact / CodeGuru の現役 5 サービスの役割・境界・連携パターンを一覧整理した。
あわせて CodeCommit（2024-07 新規停止）/ CodeStar（2024-07 廃止）/ CodeCatalyst（新規採用非推奨）の移行パスを明示した。
新規プロジェクトでこれらの廃止サービスを採用しないための最新の判断軸が、本記事 1 本で揃う。

② GHA vs Code* / ecspresso vs CodeDeploy の選定基準明確化

GitHub Actions + OIDC との 7 軸比較（コスト / 権限 / 監査 / Runner 速度 / 保守性 / AWS 統合度 / 学習コスト）と、
ecspresso vs CodeDeploy の ECS Blue/Green 選択軸を体系的に整理した。「AWS 深統合・長時間ビルド・監査証跡が必要」なら Code*、
「外部 SaaS 統合・短時間ジョブ・OSS エコシステム優先」なら GHA が有利というシンプルな判断軸を把握できた。
Lambda Canary については CodeDeploy が唯一の公式サポートオプションであり、この 1 点だけで採用決定できるシナリオも多い。

③ Terraform 基盤（Code Connections + IAM Role）の実装完了

Vol1 の Terraform 範囲（aws_codestarconnections_connection / IAM Role for CodeBuild・CodePipeline）を
Terraform HCL + AWS CLI + コンソール の 3 点セットで解説した。Code Connections の初回 OAuth 認証がコンソール手動必須である点や、
IAM Role の最小権限設計（codebuild.amazonaws.com / codepipeline.amazonaws.com 信頼ポリシー）の注意点を明示した。
Vol2〜4 で各サービスの詳細 HCL に展開するための基盤がここで整った。

選定クイックリファレンス

8-2. よくある選定ミス 10 選

8-3. Vol2〜Vol4 予告

Vol2 では CodeBuild 完全活用 を解説する。buildspec.yml の高度な記述（アーティファクト / キャッシュ / 環境変数 / フェーズ制御）、
VPC 内ビルド（PrivateLink 経由のプライベートリソースアクセス）、S3 / CodeArtifact との Artifact 統合、
Lambda compute モードによる高速ビルドまで、実践的なユースケースを体系的に深掘りする予定だ。
本記事 Vol1 の Terraform 基盤（aws_codestarconnections_connection / IAM Role）を前提に、aws_codebuild_project の HCL 完全実装まで踏み込む。

Vol3 では CodePipeline V2 + CodeDeploy 本番運用 として、V2 の並列実行・条件分岐・変数サポート機能と
ECS Blue/Green・Lambda Canary の本番デプロイ設計を解説する。Vol4 では CodeArtifact + CodeGuru 補完運用 として、
パッケージセキュリティスキャンと AI コード品質分析の実践ユースケースを扱う予定だ。

Vol2: CodeBuild 完全活用 (buildspec / VPC / Artifact / Lambda compute)

8-4. シリーズ構成ナビ

8-5. 参考文献・公式ドキュメント

AWS Code* の各サービスは継続的にアップデートされる。最新の制限値・API 仕様・料金体系は公式ドキュメントで確認することを推奨する。

AWS CodeBuild 公式ドキュメント

AWS CodePipeline V2 User Guide

AWS CodeDeploy User Guide

関連記事: GitHub Actions + OIDC 完全ガイド

関連記事: ecspresso で ECS デプロイ実践