AWSのCode系(Pipeline/Build/Deploy)で最初のデプロイ — CodeCommitの今とGitHub連携の始め方

AWSのCode系サービスは4つあり、それぞれ役割が違います。まずは「GitHub → CodeBuild → ECS」の最小3ステージで、最初のデプロイを通すところまでを一気に整理します。

AWSでCI/CDを組もうとすると、まず名前が似た4つのサービスに出会います。CodePipeline・CodeBuild・CodeDeploy・CodeCommitです。役割を分けて理解すれば難しくありません。この記事は、SIerや情シスの方が「この流れで作れば最初のデプロイは通る」と確信できることをゴールに、最小構成を一本通します。IaC側のパイプライン設計はインフラのCI/CDパイプライン設計で扱っているので、本記事はアプリのデプロイに寄せて書きます。

014つのサービスの役割を先に分ける

最初にやるべきは、4つを混同しないことです。それぞれの守備範囲はきれいに分かれています。

• CodePipeline：CI/CDのオーケストレーション。Source→Build→(承認)→Deploy というステージを繋いで、コミットからデプロイまでの流れを自動で走らせる「指揮者」です。
• CodeBuild：ビルド。buildspec.ymlにコマンドを書き、テスト・成果物生成・Dockerイメージのビルドとレジストリ(ECR)へのpushなどを実行します。
• CodeDeploy：デプロイ。EC2(in-place または blue-green)/オンプレ(in-placeのみ)をappspec.ymlで定義、ECS(blue-green)、Lambda(canary/linear)に対応します。
• CodeCommit：マネージドなGitリポジトリ。GitHubのAWS版と考えるとイメージしやすいです(後述のとおり、新規利用の扱いに歴史的な経緯があります)。

ECS/Fargate上のコンテナを動かしている読者が多いはずなので補足すると、ECSへのデプロイには2通りあります。CodePipelineの「Amazon ECS」デプロイアクション(ローリング更新)を使う手軽な方法と、CodeDeployを噛ませてECSの blue/green を行う方法です。まずは前者で十分です。

02CodeCommitの現在地 — 「新規非対応」から「再開」まで

ここは正確に押さえてください。過去の記事や社内Wikiには古い情報が残りがちな箇所です。時系列はこうです。

• 2024年7月25日：AWSはCodeCommitを新規顧客(new customers)向けに提供終了しました。既存でリポジトリを持つアカウントは継続利用・追加作成できるが、新規アカウントでは新しいリポジトリを作れない、という扱いです。同時期にCloud9なども同様の措置となり、告知の乏しさが議論を呼びました。
• 2025年11月24日：AWSはCodeCommitを新規顧客に再開しました。公式ブログ「The Future of AWS CodeCommit」で「CodeCommit is open to new customers again」と明言され、コンソール/CLI/APIから新規リポジトリを作成できる状態に戻っています(発表時点で29リージョン、Git LFS対応などロードマップも提示)。

つまり2026年時点では、新規アカウントでもCodeCommitのリポジトリを作れます。ただしEMWとしての現実的な整理はこうです。「すでにCodeCommitを使っているなら、そのまま継続で問題ありません。これから新しく始めるチームは、無理にCodeCommitを選ばず、普段使っているGitHub/GitLab/Bitbucketを接続するのが素直です」。一度は新規停止した経緯があること、そして開発者の多くがGitHubに慣れていることを踏まえると、新規はGitHub連携を第一候補に置くのが穏当だと考えています。

03ソースの繋ぎ方 — CodeConnections(旧CodeStar Connections)

新規でGitHub/GitLab/Bitbucketを使う場合、CodePipelineのSourceステージにこれらを繋ぐ仕組みがCodeConnectionsです。2024年3月29日にCodeStar Connectionsから改称されました。名称はAPI・CLI・SDK・ドキュメントで切り替わっており、既存の接続はそのまま動きますが、新しいリソースのARNやIAMのサービスプレフィックスはcodeconnections系になります。

• やることはシンプルです。コンソールで接続(Connection)を作成し、GitHub側でAWS Connector for GitHubアプリを承認して、対象リポジトリへのアクセスを許可します。
• この方式の良いところは、OAuthトークンやパスワードをパイプラインに埋め込まずに済むこと。個人のPAT(Personal Access Token)を配線する運用から卒業できます。
• IAMポリシーを手書きしている場合、古いcodestar-connectionsプレフィックスのままだと新リソースで権限が噛み合わないことがあります。新規はcodeconnectionsで書くのが安全です。

ブランチ戦略をどう乗せるかはGitHub Flow / GitLab Flow / Trunk Basedの記事が参考になります。どの流儀でも、CodeConnectionsで拾うブランチを決めるだけでSourceステージは組めます。

04最小構成 — GitHub → CodeBuild → ECS の3ステージ

「とりあえずデプロイできる」ラインは、3ステージで十分に引けます。コンテナをECS(Fargate)で動かす前提で、次の流れを作ります。

Buildステージの中身はbuildspec.ymlで決まります。骨子はこれだけです。pre_buildでECRにログインし、buildでDockerイメージをビルド、post_buildでECRへpushして、Deployに渡すimagedefinitions.jsonを出力します。

• phases.pre_build：aws ecr get-login-passwordでログイン、タグ(コミットハッシュ等)を決める。
• phases.build：docker buildでイメージを作る。ここにテストやlintも入れられます。
• phases.post_build：docker pushし、imagedefinitions.json(コンテナ名とイメージURIの対応)を生成する。
• artifacts.files：imagedefinitions.jsonを成果物として指定。これをECSデプロイアクションが読み、タスク定義のイメージを差し替えます。

このimagedefinitions.jsonが、BuildとDeployをつなぐ橋です。ここさえ出力できていれば、CodePipelineのECSデプロイアクションが新しいイメージでサービスを更新してくれます。

05EC2/オンプレなら appspec.yml と CodeDeployエージェント

コンテナではなく、EC2やオンプレのサーバーに直接デプロイする構成もまだ多くあります。その場合はCodeDeployの出番です。デプロイ先にCodeDeployエージェントを導入し、リポジトリ(または成果物)のルートにappspec.ymlを置きます。appspec.ymlには、どのファイルをどこへ配置するか(files)と、停止・インストール・起動・ヘルスチェックといったライフサイクルフック(hooks)で走らせるスクリプトを書きます。in-place(既存インスタンスを入れ替え)と blue-green(新しいインスタンス群に切り替え)がありますが、blue-green を選べるのはEC2(多くはAuto Scalingグループが前提)で、オンプレは in-place のみです。

ECSはimagedefinitions.json、EC2/オンプレはappspec.yml。デプロイ先によって「Deployに渡す設定ファイル」が変わる、と覚えておけば迷いません。

06最初に用意するもの — IAMと箱

パイプラインを回す前に、いくつか器を用意します。難しくはありませんが、権限まわりでつまずきやすいので先に挙げます。

• CodePipelineのサービスロール：各ステージを起動し、S3のアーティファクトやCodeConnectionsを扱うためのロール。
• CodeBuildのサービスロール：ECRへのpush、CloudWatch Logsへの出力、必要ならSecrets Manager/Parameter Storeの読み取り権限。
• 成果物用のS3バケット：ステージ間で成果物を受け渡す箱。パイプライン作成時に自動で用意されることも多いです。
• CodeConnectionsの接続：GitHub等を繋ぐ接続を1つ作成し、承認しておく。
• 承認アクション(任意)：本番デプロイ前に人のGOを挟みたい場合、Approvalステージを1つ入れる。SNSで通知も飛ばせます。

ロールの権限は、最初から絞りすぎると動かず、緩めすぎると事故のもとです。この塩梅はIAM最小権限の現実で扱っています。アカウントを新設した直後であればAWSアカウント初期設定も合わせてご覧ください。

07Code系 と GitHub Actions/GitLab CI の使い分け

「そもそもCode系を使うべきか、GitHub Actionsで良いのか」は正当な問いです。どちらも良いツールで、優劣ではなく相性で選ぶのが正解です。

Code系の強みは、AWSネイティブであること。ビルドとデプロイの権限をIAMロールで一元管理でき、ランナー(実行基盤)をこちらで管理する必要がありません。閉域やVPC内でのビルドもやりやすく、監査境界をAWS側に寄せたいエンタープライズと相性が良いです。一方GitHub Actionsは、Marketplaceの豊富さと普及度、そしてPRと同じ画面で完結する開発体験が魅力で、OIDCを使えば長期のアクセスキーを持たずにキーレスでAWSへデプロイできます。実際の現場では、CIはGitHub Actions、AWS内部の込み入ったデプロイはCodeDeploy/CodePipeline、と併用する構成も珍しくありません。IaC側での使い分けはインフラのCI/CDパイプライン設計にも通じます。

—まとめ

最初の一本は、器を難しく考えないことが近道です。役割を「Pipeline=指揮、Build=ビルド、Deploy=デプロイ」と分け、ソースは使い慣れたGitHubをCodeConnectionsで繋ぎ、ECSならimagedefinitions.json、EC2/オンプレならappspec.ymlを出力する。これで「GitHub → CodeBuild → ECS」の3ステージは通ります。CodeCommitは2024年に一度新規停止しましたが2025年11月に新規受付を再開しており、既存利用なら継続、新規はGitHub連携が素直、という整理で十分です。あとは承認ゲートや通知、権限の絞り込みを段階的に足していけば、最初のデプロイから“運用に耐えるパイプライン”へ育てられます。仕様や対応リージョンは変わるため、着手前に公式で最新をご確認ください。EMWでは事例のとおり、大手SIerやエンタープライズの本番パイプライン構築を数多く支援しています。

—参考(一次情報)

• The Future of AWS CodeCommit(2025年11月24日、新規顧客への再開を明言) — aws.amazon.com
• Introducing AWS CodeConnections, formerly known as AWS CodeStar Connections(2024年3月の改称告知) — aws.amazon.com
• AWS CodePipeline ユーザーガイド(公式) — docs.aws.amazon.com
• AWS CodeBuild ユーザーガイド / buildspec リファレンス — docs.aws.amazon.com
• AWS CodeDeploy ユーザーガイド / appspec リファレンス — docs.aws.amazon.com
• Developer Tools console — Connections rename(改称の詳細と移行) — docs.aws.amazon.com