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 構成の詳細はこちら

1-5. 本記事の読み方ガイド

チームの状況に応じた推奨読み順を示す。

AWS Developer Tools 公式ドキュメント

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

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

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

CodeBuild は、ソースコードのビルド・テスト・パッケージングを実行するマネージドサービスだ。
Docker コンテナ上で実行され、Linux (Amazon Linux 2023 / Ubuntu) および Windows Server 2019 環境に対応している。
インフラ管理不要の完全マネージド型で、buildspec.yml に実行ステップを定義するだけで動作する。
VPC 内実行・カスタムイメージ利用・S3/ローカルキャッシュによる高速化も可能だ。
GitHub Actions の self-hosted Runner に相当するが、AWS リソースへのネイティブ統合 (IAM ロールによる認証・VPC ネットワーク統合) が強みとなる。
特に ECR への Docker イメージプッシュや、Systems Manager Parameter Store からの設定値取得を IAM ロールだけで完結できる点は GHA+OIDC より設定が簡潔だ。

CodePipeline V2 は、CI/CD の全フェーズをオーケストレーションするサービスだ。
GitHub / Bitbucket / S3 などを Source ステージとして取り込み、CodeBuild・CodeDeploy と連携してパイプラインを構成する。
EventBridge 経由のトリガー (GitHub push / スケジュール / 手動実行) に対応しており、V2 では V1 にはなかった並列ステージ・パイプライン変数・条件分岐が使えるようになった。
複数のビルドステージを並列実行することでパイプライン所要時間を短縮できる。
GUI または Terraform の aws_codepipeline リソースで宣言的に管理できるため、GHA の YAML 複雑性よりもシンプルに大規模パイプラインを定義できる。

CodeDeploy は、ECS・Lambda・EC2 へのデプロイを担うサービスだ。
ECS では ALB のターゲットグループを切り替える Blue/Green デプロイ、Lambda では段階的にトラフィックを移行する Canary デプロイをネイティブサポートしている。
特に Lambda の Canary デプロイは CodeDeploy 以外では実現が難しく、Serverless 本番運用での唯一性がある。
AppSpec.yaml でデプロイライフサイクルフック (BeforeInstall / AfterInstall / ValidateService 等) をカスタマイズでき、CloudWatch Alarm と連動した自動ロールバックも設定できる。
ECS の場合は ALB + ターゲットグループ 2 つ (Blue/Green) の事前準備が必要だが、ゼロダウンタイムの確実なデプロイを実現できる。

CodeArtifact は、npm / pip / Maven / NuGet のパッケージレジストリをマネージドで提供するサービスだ。
プライベートリポジトリとしての利用に加え、npmjs.org / PyPI / Maven Central などのパブリックレジストリをアップストリームとして透過的にプロキシできる。
この透過的プロキシ機能により、外部パッケージを CodeArtifact 経由でキャッシュして取得速度向上とサプライチェーン攻撃リスクの低減が同時に実現できる。
IAM によるアクセス制御・KMS による暗号化が標準で提供されており、GitHub Packages や JFrog Artifactory と比較して AWS ネイティブ統合の観点で有利だ。

CodeGuru は、ML ベースのコードレビューとランタイムパフォーマンス分析を提供するサービスだ。
CodeGuru Reviewer は PR に対して自動的にコードレビューコメントを生成し、セキュリティ脆弱性・パフォーマンス問題・ベストプラクティス違反を指摘する。
CodeGuru Profiler はランタイムのホットスポット (CPU 消費が高いメソッド・メモリリークの可能性) を可視化するプロファイリングツールだ。
Java / Python で最も効果的で、GitHub / Bitbucket との統合も可能。
CodePipeline V2 のステージにレビュー結果をブロッキング条件として組み込むことで、品質基準を満たさない PR のデプロイを自動で防止できる。

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点セット形式で解説する。

CodeCommit から GitHub への移行手順概要: 既存の CodeCommit リポジトリを git clone --mirror でローカルに取得し、GitHub 側に空リポジトリを作成した後 git push --mirror でプッシュするだけで移行が完了する。その後、CodePipeline の Source アクションの接続先を CodeCommit から Code Connections (GitHub) に変更する。移行完了後は IAM ポリシーで CodeCommit リポジトリへのアクセス権限を削除し、不要なリポジトリを段階的にアーカイブすることを推奨する。ブランチ保護ルールや PR レビュー要件は GitHub 側で再設定が必要だ。

CodeStar リソースの移行手順概要: CodeStar はプロジェクト内の IAM ロール・CodePipeline・CodeBuild プロジェクト・CloudFormation スタックを一元管理していた。廃止後は CodeStar が生成した IAM ロールを個別に Terraform または CloudFormation テンプレートに取り込み、パイプライン定義を CodePipeline V2 で再作成する。aws codestar list-projects で既存プロジェクトの構成を確認し、各リソースを個別管理に移行する。

CodeCatalyst の新規プロジェクト利用禁止について: 現時点で CodeCatalyst が停止の方向性で動いているため、新規プロジェクトへの採用は避けることを推奨する。既に CodeCatalyst を利用中の場合は、Dev Environment (クラウド IDE) を VS Code Remote Tunnels または GitHub Codespaces に移行し、パイプライン定義を CodePipeline V2 + CodeBuild に再構築するロードマップを策定すること。移行期間中の並行運用コストに注意が必要だ。

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 のスコープ設計ミス (過剰権限付与) は本番環境でのインシデント原因になりやすいため、最小権限の原則に基づいた設計が最優先事項となる。

Code* ファミリーを中心とした典型的な連携パターンを整理する:

これらの連携において IAM ロールの設計は特に重要だ。各サービスが実行する操作の権限を最小限に絞ることで、万一のインシデント時の影響範囲を制限できる。具体的な注意点は以下の通りだ:

• CodeBuild ロール: ビルド対象の S3 バケット ARN・対象 ECR リポジトリ ARN・特定の Parameter Store キー ARN を明示的に指定し、ワイルドカード権限 (arn:aws:s3:::* 等) を避ける
• CodePipeline ロール: パイプラインが呼び出すアクション (CodeBuild / CodeDeploy / CloudFormation) ごとの最小権限に絞る。全アカウント全リージョンの CodeBuild を呼び出せる権限は不要
• CodeDeploy ロール: ECS Blue/Green では ALB のリスナールール変更権限 (elasticloadbalancing:ModifyListener) が必要だが、ALB の作成・削除権限まで付与してしまうケースが散見される

IAM ロール設計の完全な Terraform 例は §6 で解説する。

2-4. 現役5サービス 詳細スペック比較

各サービスの詳細なスペック・ユースケース・制限事項を整理する。採用判断の一次情報として活用してほしい。

2-5. サービス選定の早見表

採用フェーズ別のサービス利用パターンを整理する。詳細な選定判断ツリーは §5 で解説する。

Code* サービスは単独で採用するよりも組み合わせで使うことで価値が最大化される。典型的な採用パターンは以下の3種類だ:

パターン A (最小構成): CodeBuild + CodePipeline V2 + Code Connections。GitHub push をトリガーにビルド・テストを自動実行するシンプルな CI 基盤。CodeDeploy を追加しない場合は、ビルド後のデプロイは ECS タスク定義の更新や S3 同期で対応する。

パターン B (標準構成): CodeBuild + CodePipeline V2 + CodeDeploy + Code Connections。ECS/Lambda の本番デプロイに Blue/Green または Canary を組み込んだフルパイプライン。大多数の本番環境で採用される基本構成だ。

パターン C (フル構成): パターン B に CodeArtifact + CodeGuru を追加。パッケージ管理のセキュリティ強化と ML コードレビューを組み合わせた高品質な CI/CD 基盤。Java / Python チームで規模が大きい場合に投資対効果が高い。

2-6. よくある詰まりポイント

Code* ファミリー全体に共通する実装上の詰まりポイントを把握しておくことで、後続の §3〜§7 の実装章をよりスムーズに進められる。

Code Connections の手動承認ステップ: Code Connections (旧 CodeStar Connections) は Terraform 等で接続リソースを作成しても「保留中」状態のままになる。AWS コンソールで「接続を更新」を選択し、GitHub/GitLab 側の OAuth 認証を手動で完了させるまでパイプラインは起動しない。この手動ステップは自動化できないため、初回セットアップ時の作業手順に必ず含めること。

CodeBuild サービスロールの権限不足: CodeBuild の buildspec.yml で ECR イメージプッシュや Systems Manager Parameter Store 読み取りを行う場合、CodeBuild サービスロールに対応する IAM ポリシーを明示的に追加する必要がある。デフォルトで生成されるサービスロールには ecr:GetAuthorizationToken や ecr:BatchCheckLayerAvailability が含まれないため、buildspec で docker push すると即座にアクセス拒否エラーが発生する。最小権限の観点から ECR 操作は対象リポジトリの ARN を条件に絞った専用ポリシーを作成することを推奨する。

CodePipeline V2 移行時の Terraform state 処理: 既存の V1 パイプラインを V2 に移行する際、pipeline_type = "V2" への書き換えによるインプレース変更は意図しない差分やステート不整合が発生することがある。安全な移行方法は V2 パイプラインを新規リソースとして作成した後、V1 パイプラインを別途削除するアプローチだ。terraform state mv を使った移行は複雑なステート操作が必要なため避けることを推奨する。

CodeArtifact トークンの有効期限管理: aws codeartifact login で取得するアクセストークンのデフォルト有効期限は 12 時間だ。長時間ビルドや夜間バッチでトークン期限切れが起きる場合は --duration-seconds 43200 で最大値に設定するか、buildspec の各フェーズ先頭でトークンを再取得するロジックを組み込む。CI/CD 外で手動利用する場合も定期的な再ログインが必要になる。

CodeDeploy ECS Blue/Green デプロイのロールバック条件: CodeDeploy の ECS Blue/Green ではデプロイグループに設定した CloudWatch Alarm がトリガーされると自動ロールバックが起動する。ただし Alarm の評価期間とデプロイのトラフィック切り替えタイミングがずれると、エラーが発生していてもロールバックが発動しないケースがある。本番運用では Alarm の EvaluationPeriods を短く設定し、AlarmActions に CodeDeploy のロールバックが連動するよう確認した上でデプロイ設定を行うことを推奨する。デプロイ失敗後のタスク定義のロールバックは自動だが、ALB のターゲットグループ切り替え状態は手動で確認が必要なケースがある。

CodeGuru Reviewer の初回スキャン待ち時間: CodeGuru Reviewer を GitHub リポジトリに初めて接続すると、既存コードのフルスキャン (ベースラインスキャン) が数時間〜数日かかる場合がある。このスキャン中は PR へのコメントが届かないため「連携が機能していない」と誤解されやすい。初期スキャンの完了は AWS コンソールの CodeGuru Reviewer → 「コードレビュー」タブで進捗を確認できる。対応言語が Java / Python に限定されているため、TypeScript / Go メインのプロジェクトでは効果が限定的となる点も事前に把握しておく必要がある。

この採用判断スナップショットと組み合わせて使うべき情報が §3〜§5 に続いている。
§3 では GitHub Actions+OIDC との詳細な 7 軸比較を、§4 では ecspresso との ECS デプロイ選定を、§5 ではチーム規模・ワークロード・コンプライアンス要件ごとの判断ツリーを解説する。
本章で Code* ファミリーの全体像を把握した後、自チームの課題に直結する章に直接進むことを推奨する。
読み方ガイドで示したルート (§1-5 の推奨読み順) を参考に、必要な情報にたどり着いてほしい。

3. vs GitHub Actions + OIDC 比較

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 の漏洩リスクがない点もセキュリティ上の利点となる。

OIDC Trust Policy 設計鉄則

GHA から AWS へのアクセス権を OIDC で付与する際、Trust Policy の Condition 設計が不十分だと意図しないリポジトリや PR からの AssumeRole を許してしまう。以下の 4 鉄則を必ず実装すること。

鉄則 1: StringLike のワイルドカードを最小限に絞る

repo:your-org/*:* のように組織全体を許可する設定は、組織内の他リポジトリが侵害された場合に同じ IAM Role を AssumeRole できてしまう。特定リポジトリに限定できる場合は StringEquals を優先し、ワイルドカードを使う範囲を明示的に最小化する。

鉄則 2: pull_request イベントへのデプロイ権限付与を避ける

外部フォークからの PR は sub claim が repo:your-org/your-repo:pull_request となる。フォーク元の不審なコードが実行される環境でデプロイ用 IAM Role を AssumeRole できると、AWS クレデンシャル窃取・リソース破壊のリスクが生じる。Condition の sub 値にデプロイ権限を必要とするブランチ・タグのみを列挙し、pull_request を含むパターンは除外することが鉄則だ。

鉄則 3: aud Claim を必ず検証する

OIDC Identity Provider を設定する際に aud (Audience) Condition を省略すると、他のサービス向けに発行された JWT トークンが転用されるリスクが残る。"token.actions.githubusercontent.com:aud": "sts.amazonaws.com" を Trust Policy の Condition に明示的に追加することで、GitHub Actions 専用のトークンのみ受け付ける構成を徹底できる。

鉄則 4: 環境別に IAM Role を分離する

本番・ステージング・開発環境で同一の IAM Role を共用するアンチパターンは避ける。各環境の Role にはそれぞれの sub Condition を設定し (ref:refs/heads/main → 本番、ref:refs/heads/develop → ステージング)、環境をまたぐ AssumeRole を構造的に防ぐ。

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 パターンを整理する。

スタートアップ・小規模チーム (10 名以下)

開発スピードと学習コストを最優先するフェーズでは GHA が有利だ。GitHub リポジトリとの自然な統合・豊富な公式 Action・無料枠の大きさが初速を支える。AWS リソースへのアクセスは OIDC を正しく設定すれば十分に安全に実現できる。将来的に CodeBuild への移行が必要になった際も、buildspec.yml は GHA のステップ定義と概念が近く学習コストは低い。CI/CD 基盤への投資コストを抑えながら MVP 開発を加速するフェーズでの第一選択として適している。

エンタープライズ・金融・医療 (コンプライアンス重視)

SOC2・PCI-DSS・FISC 対応など監査証跡の完全性が求められる環境では AWS Code が有利だ。すべての CI/CD 操作が CloudTrail に自動記録され、AWS Config ルールで設定変更の検出・通知ができる。外部 SaaS に依存する GHA では GitHub 側の Audit Log と AWS 側の CloudTrail を突合するオーバーヘッドが生じるため、AWS 内部完結の Code が監査対応コストを大幅に削減する。IAM Identity Center を組み合わせることで、開発者の操作履歴を組織単位で一元管理できる点もエンタープライズ環境での採用理由として挙げられることが多い。

マルチアカウント・大規模組織 (AWS Organizations 環境)

AWS Organizations + Control Tower 環境で複数 AWS アカウントにまたがるデプロイが必要な場合、IAM Role の Cross-Account AssumeRole と CodePipeline の Cross-Account アクション機能が強力だ。GHA でも OIDC + Cross-Account AssumeRole は実現できるが、アカウントごとに Trust Policy と OIDC プロバイダーの管理が分散する手間が生じる。CodePipeline ではパイプライン定義内でアカウント間のアクションを宣言的に管理でき、アカウント数が増えるほど AWS Code* の運用優位性が大きくなる。S3 アーティファクトバケットの KMS 暗号化とクロスアカウント共有も CodePipeline ネイティブの機能で設定できるため、鍵管理の複雑さも軽減される。

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 比較 + 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 アプリ担当) がしやすい利点がある。

ecspresso deploy の内部処理フロー:
ecspresso deploy を実行すると、内部では以下のステップが順次実行される。

1. タスク定義の登録: 指定の ecs-task-def.json を元に register-task-definition API を呼び出し、新リビジョンのタスク定義を ECS に登録する
2. サービス更新: update-service API でタスク定義の ARN を新リビジョンに更新する。deploymentController が CODE_DEPLOY の場合は CodeDeploy API を経由する
3. ヘルスチェック待機: 新タスクセットが ALB ヘルスチェックを通過するまで ecspresso が自動で進捗を監視する
4. 旧タスク終了: Rolling Update では旧タスクが DRAINING 状態に移行し、接続が切れた後に STOPPED となる

ecspresso は --dry-run フラグでデプロイ内容を実行前にプレビューできる。本番環境への適用前に差分を確認する運用が推奨される。

# デプロイ前の差分プレビュー
ecspresso deploy --dry-run

# 失敗時自動ロールバック付きデプロイ
ecspresso deploy --rollback-events DEPLOYMENT_FAILURE

# タスク定義変更なしで強制再デプロイ (環境変数更新後など)
ecspresso deploy --force-new-deployment

ecspresso vs CodeDeploy: 運用コスト・設定複雑度の比較:

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.0
Resources:
  - myLambdaFunction:
Type: AWS::Lambda::Function
Properties:
  Name: myLambdaFunction
  Alias: live
  CurrentVersion: "1"
  TargetVersion: "2"
Hooks:
  - BeforeAllowTraffic: beforeTrafficHookFunction
  - AfterAllowTraffic: afterTrafficHookFunction

Pre/Post Traffic Hook 実装パターン詳細:

実践でよく使われる 3 つのフックパターンを整理する。

BeforeAllowTraffic フックの実装では、フック Lambda が codedeploy:PutLifecycleEventHookExecutionStatus で Succeeded / Failed を返すことで、CodeDeploy がデプロイ続行か自動ロールバックかを判断する。

import json
import boto3

codedeploy = boto3.client('codedeploy')

def handler(event, context):
 deployment_id = event['DeploymentId']
 hook_execution_id = event['LifecycleEventHookExecutionId']

 # 新バージョンの Lambda をテスト呼び出し
 lambda_client = boto3.client('lambda')
 response = lambda_client.invoke(
  FunctionName=event.get('FunctionName', 'my-function'),
  Payload=json.dumps({"httpMethod": "GET", "path": "/health"})
 )
 payload = json.loads(response['Payload'].read())
 status = 'Succeeded' if payload.get('statusCode') == 200 else 'Failed'

 codedeploy.put_lifecycle_event_hook_execution_status(
  deploymentId=deployment_id,
  lifecycleEventHookExecutionId=hook_execution_id,
  status=status
 )

Canary デプロイ中の CloudWatch Alarm 連動設定:
エラーレートが閾値を超えた際に自動ロールバックを発動させるには、CloudWatch Alarm を alarm_configuration に紐づける。

resource "aws_codedeploy_deployment_group" "lambda_canary" {
  app_name= aws_codedeploy_app.lambda_app.name
  deployment_group_name  = "my-lambda-canary-group"
  deployment_config_name = "CodeDeployDefault.LambdaCanary10Percent5Minutes"
  service_role_arn = aws_iam_role.codedeploy.arn

  alarm_configuration {
 alarms  = [aws_cloudwatch_metric_alarm.lambda_errors.name]
 enabled = true
  }

  auto_rollback_configuration {
 enabled = true
 events  = ["DEPLOYMENT_FAILURE", "DEPLOYMENT_STOP_ON_ALARM"]
  }
}

このように 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: コンプライアンス要件

ワークロード別 詳細判断ポイント:

軸2 のワークロード区分をさらに深掘りする。

コンプライアンス要件別 対応ポイント:

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

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

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

以下の Mermaid フローチャートは、上記の判断ツリーをチーム規模・ワークロード・コンプライアンス要件の3軸で整理したものだ。
上から下へ順に条件を確認することで、自チームに最適な構成を導き出せる。

flowchart TD
 A[CI/CD 選定開始] --> B{コンプライアンス要件}
 B -->|厳格: PCI-DSS / HIPAA / FISC| C[Code* フルスタック確定]
 B -->|標準 / 緩やか| D{開発ハブ}
 D -->|GitHub 中心 + 外部 SaaS 連携| E{Lambda Canary が必要か}
 D -->|AWS 完結型 / オンプレ Git| F{Lambda Canary が必要か}
 E -->|Yes| G[CodeDeploy + CodePipeline V2]
 E -->|No| H{ECS のみか}
 F -->|Yes| G
 F -->|No| H
 H -->|Yes: Terraform 分業 · OSS 活用| I[ecspresso]
 H -->|Yes: AWS Native 監査ログ必須| J[CodeDeploy ECS Blue/Green]
 H -->|No: マルチサービス ECS+Lambda+EC2| G
 C --> K[CodePipeline V2 + CodeBuild + CodeDeploy]
 G --> L[段階的移行パスへ]
 I --> L
 J --> L
 K --> L

チーム規模別 具体的構成推奨:

規模感ごとの現実的な選択肢をさらに具体化する。

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

• ミス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 を指定してサービスを作成する
• ミス6: CodePipeline のアーティファクトバケットをリージョンまたぎで設定する → CodePipeline V2 のアーティファクト S3 バケットとデプロイ先 (ECS / Lambda) は同一リージョンに置く必要がある。別リージョンのバケットを指定するとデプロイが FAILED になる。回避策: Terraform で region 引数を明示し、CodePipeline と同一リージョンの S3 バケットを指定する
• ミス7: IAM ロールに AdministratorAccess をアタッチして「あとで絞る」と先送りにする → CodeBuild / CodeDeploy の IAM ロールに広すぎる権限を付与すると、サプライチェーン攻撃や誤操作のリスクが高まる。本番環境では絞り込みを先送りにするケースが多い。回避策: 最小権限 IAM ポリシーを設計フェーズで策定し、Terraform aws_iam_policy_document で管理する
• ミス8: チーム全員が同一の CodePipeline IAM ロールで実行する → 開発者・QA・SRE が同一ロールでパイプラインを実行すると、変更承認・デプロイ実行・本番ロールバックを誰でもできてしまい、職務分離が崩れる。回避策: CodePipeline の Manual Approval ステージで承認者を別 IAM エンティティ (グループまたは SSO 権限セット) に限定し、デプロイ実行と承認の権限を分離する

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 への統合を検討

構成別コスト試算 (月額目安 東京リージョン):
どの構成を選ぶかによって月額コストは大きく異なる。以下は中規模 ECS 構成 (1日 50 デプロイ) での試算だ。

コスト増加の大部分は CodeDeploy の ECS デプロイ課金と CodeBuild の実行時間が占める。
スタートアップ期は GHA + OIDC に留め、コンプライアンス要件や Lambda Canary が必要になった段階で段階的に Code* を導入することでコストと利便性を最適化できる。

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.project
Environment = var.environment
ManagedBy= "terraform"
 }
  }
}

6-5-1. マルチアカウント拡張パターン

エンタープライズ環境では、Tools アカウント (CodePipeline / CodeBuild が稼働) から Workload アカウント (Dev / Staging / Prod) へ Cross-Account デプロイするパターンが標準だ。
CodeBuild の IAM ロールに sts:AssumeRole 権限を付与し、各 Workload アカウントに受信側の信頼ポリシーを持つデプロイロールを配置する。

# Tools アカウント: CodeBuild に Cross-Account AssumeRole 権限を追加
data "aws_iam_policy_document" "codebuild_cross_account" {
  statement {
 sid  = "CrossAccountDeploy"
 effect  = "Allow"
 actions = ["sts:AssumeRole"]
 resources = [
"arn:aws:iam::${var.dev_account_id}:role/${var.project}-deploy-role",
"arn:aws:iam::${var.staging_account_id}:role/${var.project}-deploy-role",
"arn:aws:iam::${var.prod_account_id}:role/${var.project}-deploy-role",
 ]
  }
}

# Workload アカウント側: Tools アカウントの CodeBuild ロールからの AssumeRole を許可
data "aws_iam_policy_document" "deploy_role_trust" {
  statement {
 effect  = "Allow"
 actions = ["sts:AssumeRole"]
 principals {
type  = "AWS"
identifiers = ["arn:aws:iam::${var.tools_account_id}:role/${var.project}-codebuild-role"]
 }
  }
}

buildspec.yml 内で aws sts assume-role を実行し、取得した一時クレデンシャルを環境変数に展開してから各環境へデプロイする。
Cross-Account デプロイでは Workload アカウント側の ECR / S3 / CodeDeploy へのアクセス権限もデプロイロールに付与する必要がある。

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 公式ドキュメント

CodePipeline V2 + CodeBuild + CodeDeploy + Lambda Canary の統合フローを示す。Source から Lambda Canary の段階デプロイまで、Vol1 で解説した全コンポーネントの連携を一覧できる。

flowchart LR
  GH["GitHub / GitLab\n(Code Connections)"] -->|push trigger| SRC["CodePipeline V2\nSource Stage"]
  SRC --> BLD["CodePipeline V2\nBuild Stage"]
  BLD --> CB["CodeBuild\nbuildspec.yml"]
  CB --> ECR["Amazon ECR\nイメージ保存"]
  BLD --> DEP["CodePipeline V2\nDeploy Stage"]
  DEP -->|"ECS Blue/Green"| CD_ECS["CodeDeploy\nECS Traffic Shift"]
  DEP -->|"Lambda Canary"| CD_LAM["CodeDeploy\nLambda 10%→100%"]
  CD_ECS --> ECS["ECS Service\n(Green へ切替)"]
  CD_LAM --> LAM["Lambda 関数\n(新バージョン昇格)"]

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

cd 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.git
git 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.arn
FullRepositoryId = "my-org/my-repo"
BranchName = "main"
 }
  }
}

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

CodeCommit → GitHub 移行完了チェックリスト

複数リポジトリの移行を進める場合、以下のチェックリストで進捗と完了基準を管理する。

移行完了後は CodeCommit リポジトリをアーカイブ状態 (読み取り専用) に設定し、3ヶ月間のモニタリング後に削除することを推奨する。

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 / プロジェクト管理は最後に移行する (既存データのエクスポートを事前に行うこと)

CodeCatalyst ワークフロー → CodePipeline V2 変換ポイント

CodeCatalyst の .codecatalyst/workflows/*.yaml を CodePipeline V2 の Terraform HCL に変換する際の主要マッピングを示す。1ワークフローあたり 2〜4 時間の変換作業を見込むこと。

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 に展開するための基盤がここで整った。

Vol1 完走後の次のステップ

本記事を読み終えた読者が「次に何をすべきか」を読者層別に整理する。

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

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

選定ミスの共通パターンと根本原因:

上記 10 選を俯瞰すると、3 つの共通パターンに帰着する。

1. 廃止サービス継続利用 (ミス1・2): 2024年の廃止ラッシュに対するキャッチアップ遅延が原因。社内のナレッジベースや IaC テンプレートを定期的に棚卸しする仕組みが必要。

2. IAM 権限の先送り (ミス8・10): 「開発中はとりあえず広い権限で進める」という慣習が根本原因。Terraform aws_iam_policy_document で最小権限ポリシーを設計フェーズで策定し、コードレビューで権限過多を検知する。

3. サービス固有制約の見落とし (ミス3〜7・9): Lambda Canary の appspec.yml 必須、Code Connections の手動 OAuth、CodePipeline V2 への移行推奨など、各サービスのドキュメントに明記されているが現場で見落とされやすい制約。Vol2〜4 でサービスごとに詳解する。

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)

Vol3: CodePipeline V2 + CodeDeploy 本番運用 (ECS Blue/Green / Lambda Canary 完全実装)

Vol4: CodeArtifact + CodeGuru 補完運用 (npm・PyPI プロキシ / AI コード品質分析)

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

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

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

AWS CodeBuild 公式ドキュメント

AWS CodePipeline V2 User Guide

AWS CodeDeploy User Guide

AWS CodeArtifact User Guide

AWS CodeGuru Reviewer User Guide

AWS Code Connections API Reference

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

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

関連記事: CodePipeline × ECR × Fargate AWS Native CI/CD 基礎

関連記事: ECS Blue/Green デプロイ CodeDeploy × ALB 無停止切替 Terraform

8-6. AWS 本番運用シリーズ 全軸クロスリンクナビ