【AWSサービス 基礎編】AWS CodePipeline と CodeBuild でアップロードから自動デプロイする

概要

アプリケーションを更新するたびに、ソースを手元でビルドし、できあがったファイルを手作業でサーバーやストレージに置いていると、手順の抜け漏れや「誰のどの版を置いたのか分からない」といった事故が起こりやすくなります。変更のたびにビルド・テスト・デプロイを自動で流す仕組みが CI/CD（継続的インテグレーション / 継続的デリバリー）です。

AWS では、リリースまでの流れを定義して自動で動かす AWS CodePipeline と、ビルドやテストを実行するフルマネージドのビルドサービス AWS CodeBuild を組み合わせて CI/CD を組めます。デプロイを担う AWS CodeDeploy、Git リポジトリの AWS CodeCommit とあわせて、CLF では「どのサービスが何を担うか」が問われます。

本記事では、CI/CD の考え方、CodePipeline のステージ・アクション・アーティファクト、CodeBuild の buildspec.yml とビルド環境を解説したうえで、バージョニングを有効にした S3 バケットに zip を置くとパイプラインが動き出し、CodeBuild でビルドした成果物が別の S3 バケットに展開されるところまでを体験します。最後に zip を差し替えて、パイプラインが自動で再実行されることも確かめます。

クラウドおさる

バナナを倉庫に入れたら、勝手に房を分けて、勝手に各猿の棚まで届けてくれる仕組みでござろうか。弊猿、zip を 1 つ置くだけで最後まで流れるか、この目で確かめてみるでござる！

この記事のメリット

• CI（継続的インテグレーション）と CD（継続的デリバリー）の違いを説明できる
• CodeCommit・CodeBuild・CodeDeploy・CodePipeline がそれぞれ何を担うかを整理できる
• CodePipeline のパイプライン・ステージ・アクション・アーティファクトの関係を理解できる
• CodeBuild の buildspec.yml の基本構造（phases と artifacts）を読み書きできる
• S3 をソースにしたパイプラインを作成し、ソースの更新で自動的に再実行される流れを体験できる

執筆者とキャラクター紹介

執筆者：土肥（とひ）

株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。

クラウドおさる

クラウドおさる

はじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。

クラウドおさる

基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。

クラウドおさる

猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。

技術解説

CI/CD とは

クラウドおさる

とひさん、「CI/CD」という言葉をよく聞くでござる。いったい何の略でござるか？

土肥

CI は Continuous Integration（継続的インテグレーション）、CD は Continuous Delivery（継続的デリバリー）の略だよ。どちらも「人の手でやっていたリリースまでの作業を自動化して、何度も小さく回す」ための考え方なんだ。

クラウドおさる

継続的に統合……何と何を統合するのでござるか？

土肥

チームのメンバーが書いた変更を、共通の場所（メインのブランチなど）に頻繁にまとめていくことだよ。まとめるたびに自動でビルドして検証するから、「混ぜたら動かなくなった」っていう統合のエラーをできるだけ早く見つけられるんだ。

クラウドおさる

では CD のほうは、その先の話でござるな？

土肥

そう！ 継続的デリバリーは、ビルド・テストに加えて本番に出す準備までを自動化する考え方なんだ。変更はいつでも本番にリリースできる状態になっているけど、最終的に本番へ出す判断は人やビジネスのルールが下す、っていうのがポイントだよ。

クラウドおさる

なるほど！ 猿山でいえば、採ってきたバナナをこまめに倉庫へ入れて、入れるたびに傷みがないか当番が自動で検品するのが CI。検品済みのバナナはいつでも各猿に配れる状態にしておいて、配るかどうかは長老会が決めるのが CD でござるな。

土肥

ははは、その例えはわかりやすいね。その「自動の検品と配る準備」を AWS で組み立てるのが、今日の CodePipeline と CodeBuild なんだ。

AWS の CI/CD サービスの役割分担

クラウドおさる

AWS には「Code」で始まるサービスがたくさんあって、弊猿、名前がごちゃごちゃになるでござる……。

土肥

役割で分けると覚えやすいよ。まとめるとこんな感じだね。

クラウドおさる

CodeCommit は新しく使えなくなったと、どこかで聞いた気がするでござるが……。

土肥

よく覚えてたね！ 2024 年 7 月 25 日に、CodeCommit は新規のお客さんには使えなくなったんだ。でもその後、2025 年 11 月 25 日に新しいお客さんも再び使えるようになったよ。古い情報のままだと勘違いしやすいところだね。

クラウドおさる

CodeDeploy はどんなふうにデプロイするのでござるか？

土肥

EC2 / オンプレミスなら、今あるインスタンスの上でアプリを止めて更新して再開する「インプレース」と、新しい環境を用意して切り替える「Blue/Green」が選べるよ。Lambda と ECS は Blue/Green で、トラフィックを少しずつ新しい版に移していけるんだ。今日の実践はデプロイ先が S3 なので、CodeDeploy は使わずに CodePipeline の「Amazon S3 デプロイアクション」でファイルを置くよ。

クラウドおさる

「置き場所は CodeCommit、ビルドは CodeBuild、配るのは CodeDeploy、段取りは CodePipeline」でござるな！

CodePipeline の構成要素

クラウドおさる

その段取り係の CodePipeline は、中身がどうなっているのでござるか？

土肥

パイプラインは、変更がリリースまでの道のりをどう進むかを表したワークフローで、いくつかの「ステージ」が順に並んでいるんだ。ステージの中には 1 つ以上の「アクション」があって、実際の作業はアクションがするよ。

クラウドおさる

アーティファクトというのは、ステージからステージへ渡されるバトンのようなものでござるか？

土肥

そうそう、まさにバトンだね！ アクションが受け取るのが「入力アーティファクト」、作業の結果として出すのが「出力アーティファクト」。Source アクションの出力が Build アクションの入力になって、Build の出力が Deploy の入力になる。この受け渡しは、いったんアーティファクトストアの S3 バケットを経由するんだ。

クラウドおさる

最初のステージには、何を置いてもよいのでござるか？

土肥

最初のステージはソースアクションだけで構成するルールになっているよ。「どこから材料を持ってくるか」がパイプラインの入口になるわけだね。

クラウドおさる

猿山のバナナ出荷でいえば、収穫・房分け・配達がステージで、運ばれていくバナナの籠がアーティファクト、籠を一時置きする小屋がアーティファクトストアでござるな！

CodeBuild と buildspec.yml

クラウドおさる

ビルドを担当する CodeBuild は、どこでビルドしているのでござるか？ 弊猿、ビルド用のサーバーを用意した覚えはないでござる。

土肥

そこが CodeBuild のいいところで、ビルドサーバーを自分で用意したり、パッチを当てたり、台数を増やしたりする必要がないんだ。ビルドのたびに AWS が用意したビルド環境でコマンドを実行してくれて、料金は使ったビルドの時間（分）に対してだけかかるよ。

クラウドおさる

ビルド環境というのは、どういうものでござる？

土肥

ビルドを実行するための OS や言語のランタイム、ツールが入った環境のことだよ。よく使われる言語やツール向けにあらかじめ用意された環境（マネージド型イメージ）があって、普通はそれを選ぶだけでいいんだ。独自のツールを入れた環境を使うこともできるよ。

クラウドおさる

その環境で、何を実行するかはどう伝えるのでござるか？

土肥

「buildspec」っていうビルドの手順書を YAML で書くんだ。ファイル名は既定で buildspec.yml、置き場所はソースのルートディレクトリだよ。中身はこんな構造になっているんだ。

土肥

たとえば今日の実践では、build フェーズで HTML の中の目印をビルド番号と日時に置き換えて dist ディレクトリに出力して、artifacts で dist の中身を成果物にするよ。ビルド番号は、CodeBuild がビルド環境に用意してくれる環境変数 CODEBUILD_BUILD_NUMBER から取れるんだ。

クラウドおさる

buildspec.yml は、当番の猿に渡す作業手順書でござるな。手順書をバナナ（ソース）と同じ籠に入れておけば、当番は籠を開けて書いてあるとおりに作業してくれるのでござる！

S3 をソースにするときのポイント

クラウドおさる

今日はソースに S3 を使うと聞いたでござる。何か気をつけることはあるのでござるか？

土肥

大事なのは 2 つ。1 つは、ソースにする S3 バケットはバージョニングを有効にしておく必要があること。CodePipeline はオブジェクトのバージョンを「どの版のソースで動いたか（ソースリビジョン）」として扱うんだ。もう 1 つは、ソースのファイルは 1 つの zip にまとめてアップロードすること。zip ではないファイルを置くこともできるけど、zip を前提にしている後続のアクションは失敗するよ。

クラウドおさる

zip を置き直したことに、パイプラインはどうやって気づくのでござる？

土肥

推奨されているのは、Amazon EventBridge（旧 CloudWatch Events）のルールでアップロードを検知して、パイプラインを起動する方法だよ。コンソールでパイプラインを作ると、このための EventBridge ルールと AWS CloudTrail の証跡を自動で設定してくれるんだ。昔ながらの「CodePipeline が定期的にソースを見に行く（ポーリング）」方法もあるけど、イベントで検知するのが推奨だね。

クラウドおさる

見張りの猿が倉庫を何度も見に行くのではなく、バナナが入ったら鐘が鳴る仕組みでござるな。

パイプラインタイプ（V1 と V2）と料金

クラウドおさる

パイプラインには種類があるのでござるか？

土肥

V1 と V2 の 2 つのタイプがあるよ。構造は同じで、V2 にはトリガーやリリースの安全性のための設定が追加されているんだ。機能の違いの一部をまとめるとこうなるよ。

クラウドおさる

料金も違うのでござるか？

土肥

タイプによって料金の考え方が違うんだ。V2 は、アクションが実行された時間（分）に対して課金されて、単価は 1 分あたり 0.002 USD だよ。ただし手動承認（Approval）アクションなど、課金対象外のアクションもあるんだ。V1 を含めた料金の詳細は CodePipeline の料金ページで確認してね。

クラウドおさる

CodePipeline の V2 はアクションが動いた分数、CodeBuild はビルドした分数で料金がかかるのでござる。ソースのバケットに zip を置くたびにパイプラインが動くので、試しにアップロードを繰り返すときは回数に気をつけるでござるぞ。

デプロイ先の S3 を公開する場合の注意

クラウドおさる

デプロイ先の S3 バケットをそのまま Web サイトとして公開することはできるのでござるか？

土肥

S3 の静的ウェブサイトホスティングを使えばできるよ。ただし、そのためにはオブジェクトを誰でも読める（パブリック読み取り）ようにする必要があって、バケットの「ブロックパブリックアクセス」の設定を無効にしてバケットポリシーで公開を許可することになるんだ。それに、ウェブサイトエンドポイントは HTTP だけで、HTTPS には対応していないよ。

クラウドおさる

誰でも読めるようにするのは、少し怖いでござるな……。

土肥

そうなんだ。公開してはいけないファイルまで同じバケットに置くと、それも誰でも読めてしまう。だから AWS も、ウェブサイトのホスティング以外ではパブリックアクセスをブロックする既定の設定を保つように案内しているよ。HTTPS で公開したいなら、S3 を直接公開せずに CloudFront の後ろに置いて、オリジンアクセスコントロール（OAC）で CloudFront からだけ読めるようにする構成がよく使われるんだ。今日の実践では、デプロイ先のバケットは公開せずに、展開されたファイルを CloudShell から確認するよ。

クラウドおさる

倉庫の扉を開け放つのではなく、門番（CloudFront）を通した猿だけに見せるのでござるな。全体像がつかめたでござる！

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

• ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
• ✓未経験から入社した社員の声を含む社員アンケートを掲載
• ✓応募フォームから 1 分で応募できます

採用ページを見る

実践

ハンズオンガイド9 ステップ画面 8 枚

コンソールの横に開いて、チェックしながら進めましょう。

ガイドを開く

別タブで開きます。チェックはこのブラウザに保存されます。

バージョニングを有効にしたソース用の S3 バケットと、成果物を展開するデプロイ先の S3 バケットを作成します。CloudShell で buildspec.yml と src/index.html を zip にまとめてソース用バケットにアップロードし、Source（Amazon S3）→ Build（AWS CodeBuild）→ Deploy（Amazon S3）の 3 ステージのパイプラインを作成します。パイプラインの実行結果と展開されたファイルを確認したあと、zip を差し替えてパイプラインが自動で再実行されることを確認します。

前提条件

• リージョン: ap-northeast-1（東京）
• AWS マネジメントコンソールにログイン済みであること
• S3・CodePipeline・CodeBuild の操作と、IAM ロール（CodePipeline・CodeBuild のサービスロール）の作成ができる権限があること
• AWS CloudShell が使えること

S3 のバケットとオブジェクトの基本は「Amazon S3 でバケットを作成しオブジェクトを管理する」で解説しています。

作成するリソース一覧

S3 のバケット名は全世界で一意にする必要があるため、名前の末尾に自分の AWS アカウント ID（12 桁）を付けます。以降の <アカウントID> は自分のアカウント ID に置き換えてください。

ステップ1: ソース用とデプロイ先の S3 バケットを作成する

• AWS マネジメントコンソールにログインし、リージョンが ap-northeast-1（東京）であることを確認します
• 画面右上のアカウント名をクリックし、表示されたアカウント ID（12 桁）を控えます
• 上部の検索バーに S3 と入力し、表示された「S3」を選択します
• 左側ナビゲーションの「汎用バケット」を選択し、「バケットを作成」をクリックします
• 以下を設定します
• バケット名前空間: グローバル名前空間（デフォルトのまま）
• バケット名: cicd-handson-source-<アカウントID>
• このバケットのブロックパブリックアクセス設定: 「パブリックアクセスをすべてブロック」にチェックが入ったまま
• バケットのバージョニング: 有効にする
• その他の項目はデフォルトのままにし、ページ下部の「バケットを作成」をクリックします

• もう一度「バケットを作成」をクリックし、以下を設定します
• バケット名前空間: グローバル名前空間（デフォルトのまま）
• バケット名: cicd-handson-deploy-<アカウントID>
• このバケットのブロックパブリックアクセス設定: 「パブリックアクセスをすべてブロック」にチェックが入ったまま
• バケットのバージョニング: デフォルト（無効にする）のまま
• その他の項目はデフォルトのままにし、「バケットを作成」をクリックします
• バケット一覧に 2 つのバケットが表示されることを確認します

ステップ2: CloudShell でソースの zip を作成してアップロードする

• コンソール上部のツールバーにある CloudShell のアイコンをクリックし、CloudShell を起動します（リージョンが ap-northeast-1 のままであることを確認します）
• アカウント ID とバケット名を変数に入れます

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SRC_BUCKET=cicd-handson-source-${ACCOUNT_ID}
DEPLOY_BUCKET=cicd-handson-deploy-${ACCOUNT_ID}
echo ${SRC_BUCKET} ${DEPLOY_BUCKET}

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
SRC_BUCKET=cicd-handson-source-${ACCOUNT_ID}
DEPLOY_BUCKET=cicd-handson-deploy-${ACCOUNT_ID}
echo ${SRC_BUCKET} ${DEPLOY_BUCKET}

• 作業用のディレクトリを作り、ビルドの手順書 buildspec.yml を作成します。build フェーズで src/index.html の目印（__BUILD_NUMBER__ と __BUILD_TIME__）をビルド番号とビルド日時（UTC）に置き換えて dist/index.html に出力し、artifacts で dist の中身を成果物にします

mkdir -p ~/cicd-handson/src && cd ~/cicd-handson
cat > buildspec.yml <<'EOF'
version: 0.2

phases:
  build:
    commands:
      - echo "Build number ${CODEBUILD_BUILD_NUMBER}"
      - mkdir -p dist
      - BUILD_TIME=$(date -u '+%Y-%m-%d %H:%M:%S')
      - sed -e "s/__BUILD_NUMBER__/${CODEBUILD_BUILD_NUMBER}/" -e "s/__BUILD_TIME__/${BUILD_TIME}/" src/index.html > dist/index.html
      - cat dist/index.html

artifacts:
  base-directory: dist
  files:
    - '**/*'
EOF

mkdir -p ~/cicd-handson/src && cd ~/cicd-handson
cat > buildspec.yml <<'EOF'
version: 0.2

phases:
  build:
    commands:
      - echo "Build number ${CODEBUILD_BUILD_NUMBER}"
      - mkdir -p dist
      - BUILD_TIME=$(date -u '+%Y-%m-%d %H:%M:%S')
      - sed -e "s/__BUILD_NUMBER__/${CODEBUILD_BUILD_NUMBER}/" -e "s/__BUILD_TIME__/${BUILD_TIME}/" src/index.html > dist/index.html
      - cat dist/index.html

artifacts:
  base-directory: dist
  files:
    - '**/*'
EOF

• 元になる src/index.html を作成します

cat > src/index.html <<'EOF'
<!DOCTYPE html>
<html lang="ja">
<head><meta charset="UTF-8"><title>CI/CD Handson</title></head>
<body>
  <h1>Hello CodePipeline v1</h1>
  <p>Build number: __BUILD_NUMBER__</p>
  <p>Built at (UTC): __BUILD_TIME__</p>
</body>
</html>
EOF

cat > src/index.html <<'EOF'
<!DOCTYPE html>
<html lang="ja">
<head><meta charset="UTF-8"><title>CI/CD Handson</title></head>
<body>
  <h1>Hello CodePipeline v1</h1>
  <p>Build number: __BUILD_NUMBER__</p>
  <p>Built at (UTC): __BUILD_TIME__</p>
</body>
</html>
EOF

• 2 つのファイルを site.zip にまとめます。buildspec.yml が zip のルートに来るように、作業ディレクトリの中で zip を作ります

zip -r site.zip buildspec.yml src
unzip -l site.zip

zip -r site.zip buildspec.yml src
unzip -l site.zip

• unzip -l の結果に buildspec.yml と src/index.html が表示されることを確認し、ソース用バケットにアップロードします

aws s3 cp site.zip s3://${SRC_BUCKET}/site.zip

aws s3 cp site.zip s3://${SRC_BUCKET}/site.zip

ステップ3: パイプラインを作成する（パイプラインの設定とソースステージ）

• 上部の検索バーに CodePipeline と入力し、表示された「CodePipeline」を選択します
• 「パイプラインを作成する」をクリックします
• 「Step 1: 作成オプションを選択する」で「カスタムパイプラインを構築する」を選択し、「次に」をクリックします
• 「Step 2: パイプラインの設定を選択する」で以下を設定し、「次に」をクリックします
• パイプライン名: cicd-handson-pipeline
• サービスロール: 新しいサービスロール（ロール名は自動で入力されたままにします）
• その他の項目はデフォルトのままにします（実行モードは既定の キュー）。パイプラインタイプを選ぶ項目は無く、V2 のパイプラインとして作成されます
• 「Step 3: ソースステージを追加」で以下を設定します
• ソースプロバイダー: Amazon S3
• バケット: 入力欄をクリックし、候補から cicd-handson-source-<アカウントID> を選択します
• S3 オブジェクトキー: site.zip
• 「ソースの変更を自動的に検出する EventBridge ルールを作成」: チェックが入ったまま（site.zip の更新を EventBridge ルールで検知してパイプラインを起動します）
• 「ステージ障害時の自動再試行を有効にする」はデフォルトのままにします
• 「次に」をクリックします

ステップ4: ビルドステージで CodeBuild プロジェクトを作成する

• 「Step 4: ビルドステージを追加する」で、ビルドプロバイダーの「その他のビルドプロバイダー」を選択し、AWS CodeBuild を選びます（既定の「コマンド」は、CodeBuild のプロジェクトを作らずにパイプラインの中でコマンドを実行する方式です。今回は buildspec.yml を使うので CodeBuild を選びます）
• リージョンが アジアパシフィック (東京) であることを確認し、「プロジェクト名」の横の「プロジェクトを作成する」をクリックします
• 別ウィンドウで CodeBuild のプロジェクト作成画面が開くので、以下を設定します
• プロジェクト名: cicd-handson-build
• 環境イメージ: マネージド型イメージ（オペレーティングシステムやイメージなど、環境のその他の項目はデフォルトのまま）
• サービスロール: 新しいサービスロール（ロール名は自動で入力されたまま）
• ビルド仕様: buildspec ファイルを使用する（Buildspec 名は空欄のまま。ソースのルートにある buildspec.yml が使われます）
• その他の項目はデフォルトのままにします

• 画面下部の「CodePipeline に進む」をクリックします。ウィンドウが閉じ、パイプラインの作成画面に「プロジェクト名」として cicd-handson-build が入ります
• その他の項目（ビルドタイプ 単一ビルド、入力アーティファクト SourceArtifact）はデフォルトのままにし、「次に」をクリックします
• 「Step 5: テストステージを追加」は「テストステージをスキップ」をクリックします（確認ダイアログが表示された場合は「スキップ」をクリックします）

ステップ5: デプロイステージを設定してパイプラインを作成する

• 「Step 6: デプロイステージを追加する」で以下を設定します
• デプロイプロバイダー: Amazon S3
• リージョン: アジアパシフィック (東京)
• 入力アーティファクト: BuildArtifact（自動で入っています）
• バケット: 入力欄をクリックし、候補から cicd-handson-deploy-<アカウントID> を選択します
• デプロイパス – オプショナル: 空欄のまま（バケットのルートに展開されます）
• 「デプロイする前にファイルを抽出する」: チェックを入れる（ビルドの成果物は zip でアーティファクトストアに保存されているため、展開してからデプロイ先に置きます）
• 「ステージ障害時の自動ロールバックを設定」はデフォルトのままにします
• 「次に」をクリックします

• 「Step 7: レビュー」で設定内容を確認し（パイプラインタイプが V2 になっています）、「パイプラインを作成する」をクリックします

ステップ6: 実行結果と展開されたファイルを確認する

パイプラインを作成すると、ソース用バケットにある site.zip を使って最初の実行が自動で始まります。

• パイプラインの詳細画面で、Source → Build → Deploy の順に各ステージが進むのを待ちます（数分かかることがあります）
• 3 つのステージがすべて「すべてのアクションが成功しました。」になったことを確認します

• Build ステージのアクションの「詳細を表示」をクリックし、ビルドログに buildspec.yml の cat dist/index.html の出力（ビルド番号と日時が入った HTML）が表示されていることを確認します
• CloudShell に戻り、デプロイ先のバケットに展開された index.html の中身を表示します

aws s3 ls s3://${DEPLOY_BUCKET}/
aws s3 cp s3://${DEPLOY_BUCKET}/index.html -

aws s3 ls s3://${DEPLOY_BUCKET}/
aws s3 cp s3://${DEPLOY_BUCKET}/index.html -

Hello CodePipeline v1 の見出しと、__BUILD_NUMBER__ が 1 に、__BUILD_TIME__ がビルドした日時に置き換わった HTML が表示されれば、S3 に置いた zip が CodeBuild でビルドされ、デプロイ先のバケットに展開されたことが確認できます。

クラウドおさる

zip の中の buildspec.yml が当番の手順書になって、成果物はデプロイ先の倉庫に房をほどいて並べられたのでござる。弊猿が手を動かしたのは、zip を置いたところまででござるな。

ステップ7: zip を更新して自動で再実行されることを確認する

• CloudShell で src/index.html の見出しを v2 に書き換え、zip を作り直してアップロードします

cd ~/cicd-handson
sed -i 's/Hello CodePipeline v1/Hello CodePipeline v2/' src/index.html
rm site.zip
zip -r site.zip buildspec.yml src
aws s3 cp site.zip s3://${SRC_BUCKET}/site.zip

cd ~/cicd-handson
sed -i 's/Hello CodePipeline v1/Hello CodePipeline v2/' src/index.html
rm site.zip
zip -r site.zip buildspec.yml src
aws s3 cp site.zip s3://${SRC_BUCKET}/site.zip

• CodePipeline のコンソールに戻り、パイプライン cicd-handson-pipeline の詳細画面を開きます。手動で「変更をリリースする」をクリックしなくても、新しい実行が始まることを確認します（始まるまで少し時間がかかることがあります）
• 上部の「実行」タブ（または左側ナビゲーションの「履歴」）を選択して「実行履歴」を開き、2 つ目の実行のステータスが「成功しました」になったことを確認します。トリガーが CloudWatchEvent（EventBridge ルール）になっていて、zip のアップロードで自動的に始まったことが分かります。「ソースリビジョン」には S3 オブジェクトのバージョン ID が記録されています

• CloudShell で、デプロイ先の index.html を再度表示します

aws s3 cp s3://${DEPLOY_BUCKET}/index.html -

aws s3 cp s3://${DEPLOY_BUCKET}/index.html -

見出しが Hello CodePipeline v2、ビルド番号が 2 に変わっていれば、ソースの更新をきっかけにパイプラインが自動で再実行され、新しい成果物がデプロイされたことが確認できます。

クラウドおさる

パイプラインはソースのバケットを見張り続けているので、site.zip を置き直すたびに動き出して、CodePipeline と CodeBuild の料金がかかるのでござる。それに今回、コンソールは CloudTrail の証跡やアーティファクト用のバケットも作っているでござる。試し終わったら、これらが残っていないかも確かめるでござるぞ。

まとめ

• CI（継続的インテグレーション）は変更を頻繁に統合して自動でビルド・検証する考え方、CD（継続的デリバリー）はリリースの準備までを自動化し、本番へ出す最終判断を人やルールに委ねる考え方
• AWS では、CodeCommit がソースの置き場所、CodeBuild がビルド・テスト、CodeDeploy が EC2 / オンプレミス・Lambda・ECS へのデプロイ、CodePipeline が全体の流れの自動化を担う。CodeCommit は 2024 年 7 月に新規受付を停止したが、2025 年 11 月に新規のお客様も再び利用できるようになった
• CodePipeline のパイプラインはステージの並びで、ステージの中のアクションが作業を行う。アクションの間はアーティファクトで受け渡し、アーティファクトはアーティファクトストア（S3 バケット）を経由する
• CodeBuild はビルドサーバーの管理が不要なフルマネージドのビルドサービスで、使ったビルド時間に対して課金される。ビルドの手順は buildspec.yml（version・phases・artifacts）に書き、既定ではソースのルートに置く
• S3 をソースにする場合はバケットのバージョニングを有効にし、ソースを 1 つの zip にまとめる。変更の検知は EventBridge のルールを使う方法が推奨
• パイプラインタイプには V1 と V2 があり、V2 はアクションの実行時間（分）に対して課金される
• S3 の静的ウェブサイトホスティングで公開するにはパブリック読み取りが必要になる。公開しないファイルを混ぜない、HTTPS が必要なら CloudFront と OAC を使う、といった点に注意する

関連記事:

• Amazon S3 でバケットを作成しオブジェクトを管理する
• CloudFront Origin Access Control（OAC）によるS3オリジン保護：OAIからの移行と推奨構成

参照先

• 継続的デリバリーと継続的インテグレーション
• CodePipeline の概念
• パイプラインのタイプ
• 適切なパイプラインのタイプの選択
• Amazon S3 ソースアクションリファレンス
• Amazon S3 デプロイアクションリファレンス
• イベントに対して有効にしたソースを使用して Amazon S3 ソースアクションに接続する
• Amazon S3 ソースに対する EventBridge ルールを作成する (コンソール)
• チュートリアル: シンプルなパイプラインを作成する (S3 バケット)
• チュートリアル: Amazon S3 をデプロイプロバイダとして使用するパイプラインを作成する
• AWS CodeBuild とは
• CodeBuild のビルド仕様に関するリファレンス
• ビルド環境の環境変数
• CodeDeploy とは
• AWS CodeCommit ユーザーガイドのドキュメント履歴
• Amazon S3 を使用して静的ウェブサイトをホスティングする
• AWS CloudShell コンピューティング環境: 仕様とソフトウェア

キャリア相談

独学の先に、AWS の仕事がある ── ジュニアおさるのキャリア相談

CLF には受かったけれど、次に何をすればいいのか分からない。独学で AWS を学ぶジュニアおさるの相談に、株式会社ジェニュイン代表の土肥が答えています。

• ✓資格はゴールか、CLF の次に何から手を付けるか
• ✓EC2 の次に作ってみる構成と、IaC・コスト管理
• ✓実務経験ゼロでも、面接で話せる「これまで」の作り方

相談を読む

新卒・未経験の方へ

AWS を仕事にしたい方へ ── 新卒・未経験から

この記事を書いているのは、AWS の設計・構築を仕事にしている現役エンジニアです。運営元の株式会社ジェニュインでは、新卒・未経験の方も募集しています。異業種や文系からインフラエンジニアになり活躍しているメンバーもいます。

• ✓システム開発・WEB エンジニア / インフラ構築などの職種で、未経験から応募できます
• ✓未経験から入社した社員の声を含む社員アンケートを掲載
• ✓応募フォームから 1 分で応募できます

採用ページを見る