MENU
試験勉強のメモ
  1. ホーム
  2. AWS Certified Cloud Practitioner
  3. 【AWS Certified Cloud Practitioner】CodeCommit・CodeBuild・CodeDeploy・CodePipelineを中心に開発支援サービスをやさしく整理

【AWS Certified Cloud Practitioner】CodeCommit・CodeBuild・CodeDeploy・CodePipelineを中心に開発支援サービスをやさしく整理

AWS Certified Cloud Practitioner

AWS Certified Cloud Practitioner対策：CodeCommit・CodeBuild・CodeDeploy・CodePipelineを中心に開発支援サービスをやさしく整理

AWS Certified Cloud Practitioner（CLF-C02）では、開発者向けサービスの細かな設定値よりも、「そのサービスは何を担当するのか」を高いレベルで説明できることが重要です。特に、CodeCommit、CodeBuild、CodeDeploy、CodePipelineのような開発支援サービスは、名前が似ていて役割を混同しやすいため、試験前に整理しておく価値があります。

この記事では、CI/CDの基本の流れと、関連するAWSサービスの違いを初心者向けに整理します。AWS公式の試験案内と各サービスの公式ドキュメントをもとに、Cloud Practitioner試験で押さえやすい形に絞って解説します。試験全体の案内はAWS公式の認定ページと試験ガイドを確認してください。https://aws.amazon.com/jp/certification/certified-cloud-practitioner/ / https://docs.aws.amazon.com/pdfs/aws-certification/latest/cloud-practitioner-02/cloud-practitioner-02.pdf

目次

まず覚えたい：CI/CDとは何か

CI/CDは、ソフトウェアの変更をできるだけ安全かつ素早く本番環境へ反映する考え方です。

  • CI（Continuous Integration / 継続的インテグレーション）：コードを頻繁に統合し、自動テストやビルドを回して不具合を早く見つける考え方
  • CD（Continuous Delivery または Continuous Deployment）：テスト済みの変更を継続的にリリースしやすくする考え方

初心者向けには、次の流れで覚えると分かりやすいです。

  1. コードを保存する
  2. 自動でビルドやテストをする
  3. 配布できる形にまとめる
  4. 本番環境へデプロイする
  5. 全体の流れを自動化する

AWSでは、この流れを複数のサービスで分担します。

最重要4サービスの役割を先に整理

サービス主な役割初心者向けの一言試験での見分け方
AWS CodeCommitソースコードの保管AWS上のGitリポジトリ「コードをどこに置くか」
AWS CodeBuildビルドとテスト自動でコンパイル・テストする「ソースから成果物を作る」
AWS CodeDeployデプロイEC2やLambdaなどへ配る「本番へ反映する」
AWS CodePipeline工程全体の自動化一連の流れをつなぐ司令塔「ソース→ビルド→デプロイを自動化」

この4つは、Cloud Practitionerで最も区別しやすくしておきたい組み合わせです。

1. AWS CodeCommit：コードを安全に置く場所

AWS CodeCommitは、AWSがホストするバージョン管理サービスです。公式ドキュメントでは、プライベートなGitリポジトリをクラウド上で保存・管理できるサービスとして説明されています。https://docs.aws.amazon.com/ja_jp/codecommit/latest/userguide/welcome.html

要するに、「開発中のコードを保管する場所」です。GitHubやGitLabを使ったことがあるなら、そのAWS版と考えると理解しやすいでしょう。

例えば、ECサイトの開発チームが商品一覧ページの修正を行うとします。修正したコードをCodeCommitへpushすると、その変更をきっかけに次のCodeBuildやCodePipelineを動かせます。

試験でのポイントは、CodeCommit自体はビルドやデプロイを行うサービスではないことです。あくまでコードの保存・管理が役割です。

2. AWS CodeBuild：ビルドとテストを自動で実行する

AWS CodeBuildは、クラウド上のフルマネージドなビルドサービスです。公式ドキュメントでは、ソースコードのコンパイル、単体テストの実行、デプロイ可能なアーティファクトの生成を行うサービスと説明されています。https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/welcome.html

ここでいうビルドとは、ソースコードから実行可能な形や配布可能な形を作ることです。Javaならjarファイル、フロントエンドなら圧縮済みファイル群、コンテナならイメージ作成前の処理などがイメージしやすい例です。

例えば、開発者がコードを更新したら、CodeBuildが自動で次の処理を行います。

  • 依存関係の取得
  • テストの実行
  • アプリのビルド
  • 成果物の出力

初心者が覚えるべき本質は、「ビルドサーバーを自分で管理しなくてよい」ことです。CodeBuildはフルマネージドなので、専用サーバーの用意や運用を減らせます。

3. AWS CodeDeploy：作ったものを実行環境へ配る

AWS CodeDeployは、アプリケーションのデプロイを自動化するサービスです。公式ドキュメントでは、Amazon EC2、オンプレミスインスタンス、AWS Lambda、Amazon ECSなどへのデプロイを自動化できると説明されています。https://docs.aws.amazon.com/ja_jp/codedeploy/latest/userguide/welcome.html

デプロイとは、作成したアプリケーションを実際に動かす環境へ配置・反映することです。

たとえば、ビルドが成功して新しいWebアプリのパッケージができた後、その新バージョンをEC2へ配布してサービスを切り替えるのがCodeDeployの役割です。

Cloud Practitionerでは、CodeBuildとの違いが頻出です。

  • CodeBuild：作る・テストする
  • CodeDeploy：配る・反映する

この違いを明確にしておくと、選択肢で迷いにくくなります。

4. AWS CodePipeline：全工程を自動でつなぐ

AWS CodePipelineは、ソフトウェアリリースに必要な各ステップをモデル化・可視化・自動化する継続的デリバリーサービスです。AWS公式ドキュメントでは、ソフトウェア変更を継続的にリリースするためのステップを自動化できるサービスとして説明されています。https://docs.aws.amazon.com/ja_jp/codepipeline/latest/userguide/welcome.html

分かりやすく言うと、「CodeCommit、CodeBuild、CodeDeployなどを順番につなぐ仕組み」です。

例えば次のような流れを自動化できます。

  1. CodeCommitにコードがpushされる
  2. CodeBuildがテストとビルドを実行する
  3. 承認ステップを挟む
  4. CodeDeployが本番へ反映する

このサービスは、単独でビルドやデプロイそのものを行うというより、工程全体の流れを管理するサービスとして理解すると整理しやすくなります。

5. CodeArtifact：パッケージや依存ライブラリの保管庫

AWS CodeArtifactは、ソフトウェアパッケージを保存・共有するためのマネージドなアーティファクトリポジトリサービスです。AWS公式ドキュメントでは、npm、Maven、pip、NuGetなどの一般的なツールと連携できると説明されています。https://docs.aws.amazon.com/ja_jp/codeartifact/latest/ug/welcome.html

初心者向けには、「ライブラリやパッケージの保管庫」と捉えると分かりやすいです。

例えば、自社専用のJavaライブラリやPythonパッケージを各チームで共有したい場合、CodeArtifactに置けば、安全に配布しやすくなります。

試験では、CodeArtifactはCodeCommitのようなソースコード管理や、CodeDeployのような本番配布とは別物である点が重要です。

6. AWS AppConfig：設定値や機能フラグを安全に切り替える

AWS AppConfigは、機能フラグや動的設定を使って、本番環境のアプリケーション動作をフルデプロイなしで安全に調整するためのサービスです。AWS公式ドキュメントでは、リリース頻度の向上やアプリケーションのレジリエンス向上に役立つと説明されています。https://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/what-is-appconfig.html

例えば、新しい検索機能を全ユーザーへ一気に公開するのではなく、まずは一部ユーザーだけ有効にし、問題がなければ徐々に広げる、といった使い方ができます。

これは試験ではそこまで深掘りされにくいものの、「設定変更や機能のON/OFFを安全に行うサービス」として覚えておくと整理しやすくなります。

7. AWS CloudShell：ブラウザからすぐ使えるコマンド環境

AWS CloudShellは、AWSマネジメントコンソールから直接起動できるブラウザベースの認証済みシェル環境です。AWS CLIコマンドを、ローカルにCLIをインストールしなくても実行できます。https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/welcome.html

例えば、S3バケット一覧を確認したいときに、自分のPCへCLIを入れなくてもCloudShell上でコマンドを試せます。

Cloud Practitionerでは、「ブラウザから使えるCLI環境」という理解で十分です。

8. AWS Cloud9：クラウドIDEだが、新規利用には注意

AWS Cloud9はクラウドベースの統合開発環境（IDE）です。ただし、AWS公式ドキュメントでは、新規顧客はAWS Cloud9を利用できず、既存顧客は継続利用できると案内されています。https://docs.aws.amazon.com/cloud9/latest/user-guide/history.html

そのため、参考書や古い教材にCloud9が普通に登場していても、現在のAWSの位置付けは少し変わっています。

ただし、Cloud Practitionerの学習では、Cloud9を見かけたら「クラウド上の開発環境」と理解できれば十分です。

9. AWS X-Ray：アプリの中で何が遅いのかを追跡する

AWS X-Rayは、アプリケーションが処理するリクエストのデータを収集し、表示・分析するためのサービスです。AWS公式ドキュメントでは、リクエストだけでなく、下流のAWSリソース、マイクロサービス、データベース、Web APIへの呼び出しも含めて詳細を確認できると説明されています。https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/aws-xray.html

例えば、「画面表示が遅い」という問題が起きたとき、どのAPIやどのデータベース呼び出しがボトルネックになっているかを調べるのに役立ちます。

初心者は、「アプリの処理経路を見える化して原因調査に使う」サービスと覚えるとよいでしょう。

10. AWS CodeStar：古い資料を読むときの注意点

AWS CodeStarは、もともと開発プロジェクトを素早く始めるためのクラウドベースの開発サービスとして提供されていました。AWS公式FAQには、CodeStarが開発・ビルド・デプロイに必要なツールを素早く設定できるサービスだったことが説明されています。https://aws.amazon.com/jp/codestar/faqs/

ただし、現在はそのまま覚えると誤解しやすい部分があります。そこで、ここは不確かな点を整理しておきます。

(1) 確実に言えること

  • AWS公式FAQでは、2024年7月31日をもってAWS CodeStarプロジェクトの作成と閲覧のサポートが終了したと案内されています。
  • 同FAQでは、CodeStarによって作成されたリソース自体は引き続き機能すると説明されています。
  • また、AWS CodeStar Connectionsは別扱いで、名称変更により現在はAWS CodeConnectionsとして案内されています。https://aws.amazon.com/about-aws/whats-new/2024/03/aws-codeconnections-formerly-codestar-connections/

(2) 推測

Cloud Practitioner向けの古い参考書やノートでは、CodeStarを「開発ツール一式をまとめて始めるサービス」として説明している可能性が高いです。これは過去の説明としては大筋で正しいですが、現在の提供状況とは一致しない場合があります。根拠は、AWS公式FAQでCodeStarプロジェクトの終了が明示されている一方、旧資料はその前に作成されていることが多いためです。

(3) 不明点

手元の教材がいつ時点のAWS情報を反映しているかは、教材ごとに確認が必要です。学習中にCodeStarが出てきた場合は、まずその教材の発行日を確認し、必要に応じてAWS公式FAQで現行情報を確認すると安全です。

CodeCommit・CodeBuild・CodeDeploy・CodePipelineを1つの例でまとめる

4サービスの違いは、実際の開発の流れに当てはめると一気に覚えやすくなります。

例として、会社のWebアプリに「お気に入り登録機能」を追加するとします。

  1. 開発者がコードを書いてCodeCommitへ保存する
  2. 変更をきっかけにCodeBuildが自動でテストとビルドを実行する
  3. 必要ならパッケージや依存ライブラリをCodeArtifactで管理する
  4. 問題がなければCodeDeployがEC2やLambdaへ新バージョンを反映する
  5. この一連の流れ全体をCodePipelineが自動でつなぐ

このように、似た名前でも担当範囲が違います。

試験直前に見返したい暗記ポイント

  • CodeCommit ＝ Gitリポジトリ
  • CodeBuild ＝ ビルド・テスト
  • CodeDeploy ＝ デプロイ
  • CodePipeline ＝ 一連の流れの自動化
  • CodeArtifact ＝ パッケージ管理
  • AppConfig ＝ 設定値や機能フラグの安全な変更
  • CloudShell ＝ ブラウザからCLI
  • Cloud9 ＝ クラウドIDE（現在は新規利用に注意）
  • X-Ray ＝ リクエスト経路の追跡と原因調査
  • CodeStar ＝ 古い資料では出るが現在は状況が変わっている

公式情報の確認先

まとめ

Cloud Practitionerで重要なのは、開発支援サービスを細部まで設定できることではなく、役割の違いを説明できることです。特に、CodeCommit・CodeBuild・CodeDeploy・CodePipelineの4つは、次の順番で頭に入れると整理しやすくなります。

  1. CodeCommitでコードを置く
  2. CodeBuildでビルド・テストする
  3. CodeDeployで実行環境へ反映する
  4. CodePipelineで全体を自動化する

この4つを核として、CodeArtifact、AppConfig、CloudShell、Cloud9、X-Ray、CodeStarの位置付けを周辺知識として押さえると、試験でも実務イメージでも理解しやすくなります。

AWS Certified Cloud Practitioner
AppConfig aws AWS Certified Cloud Practitioner AWS CodeStar AWS X-Ray CI/CD Cloud9 CloudShell CodeArtifact CodeBuild CodeCommit CodeDeploy CodePipeline
よかったらシェアしてね！
  • URLをコピーしました！
  • URLをコピーしました！
目次