0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@naoto_tech_AI

【DOP-C02/SAP-C02】Codeシリーズ徹底解説：概要・主要機能・試験で問われるポイント

0
Posted at

この記事の位置づけ

AWS 認定 DevOps Engineer – Professional（DOP-C02）と Solutions Architect – Professional（SAP-C02）の両方で頻出する 3 領域を、「概要 → 主要機能 → 試験で問われるところ」 の順に深掘りする全 3 回シリーズの第 1 回です。

回 テーマ
第 1 回（本記事） Code シリーズ（CodePipeline / CodeBuild / CodeDeploy / CodeArtifact / CodeCommit / CodeConnections ほか）
第 2 回 CloudFormation
第 3 回 Control Tower

試験の基本情報は両試験とも共通です（DOP 公式ページ、SAP 公式ページ、各試験ガイド）。

項目 DOP-C02 / SAP-C02
問題数 75 問（採点対象 65 問 + 採点対象外 10 問）
時間 180 分
合格ライン 750 / 1000
受験料 300 USD

SAP-C02 → SAP-C03 の切り替えに注意
SAP の公式ページには「更新版（SAP-C03）の登録受付は 2026 年 10 月 27 日に開始、現行 SAP-C02 の最終受験日は 2026 年 11 月 16 日」と掲示されています（2026-10-20 時点）。本記事は SAP-C02 の試験ガイド に基づいています。SAP-C03 の試験ガイドが公開されたら、出題範囲の差分を必ず確認してください。

本文の仕様は公式ドキュメント（2026 年 10 月時点）で確認し、出典 URL を付けています。確認しきれなかった記述は末尾の「確認しきれなかった記述」にまとめました。サービス仕様は改定されるので、受験前に最新のドキュメントで最終確認をしてください。

0. 試験ガイドでの位置づけ

DOP-C02

分野 配分 Code シリーズとの関係
1. SDLC の自動化 22% 本丸。 1.1 CI/CD パイプラインの実装、1.2 自動テストの統合、1.3 アーティファクトの構築と管理、1.4 インスタンス／コンテナ／サーバーレス向けのデプロイ戦略
2. 構成管理と IaC 17% CodePipeline + CloudFormation / CDK / SAM の組み合わせ
3. 回復性のあるクラウドソリューション 15% デプロイ戦略と可用性
4. モニタリングとロギング 15% パイプライン／ビルドのイベント通知
5. インシデントとイベントへの対応 14% 失敗時のロールバック
6. セキュリティとコンプライアンス 17% パイプラインへのセキュリティチェック組み込み

試験ガイドの対象サービス一覧（Developer Tools）は AWS CLI / AWS CDK / CloudShell / CodeArtifact / CodeBuild / CodeDeploy / CodeGuru / CodePipeline / CodeStar / FIS / SDKs / X-Ray の 12 項目で、Code 系で載っているのは CodeArtifact / CodeBuild / CodeDeploy / CodeGuru / CodePipeline / CodeStar です（DOP-C02 対象サービス一覧）。CodeCommit は一覧に載っていません（一覧は「網羅的ではない」と注記）が、問題文には「Git リポジトリ」として普通に登場します。

SAP-C02

分野 配分 Code シリーズとの関係
1. 組織の複雑さに対応する設計 26% マルチアカウントのパイプライン
2. 新しいソリューションのための設計 29% 2.1 ビジネス要件を満たすデプロイ戦略の設計（Blue/Green、カナリア、IaC、CI/CD）
3. 既存ソリューションの継続的改善 25% 運用の自動化、デプロイの改善
4. ワークロードの移行とモダナイゼーション 20% コンテナ／サーバーレス化に伴うパイプライン

SAP の対象サービス一覧（Developer Tools）は CodeArtifact / CodeBuild / CodeDeploy / CodeGuru / CodePipeline / X-Ray です（SAP-C02 対象サービス一覧）。SAP では「どのサービスを使うか」より 「どのデプロイ戦略を選ぶか（ダウンタイム・ロールバック速度・コスト）」 が問われます。

1. Code シリーズの全体像と現在のステータス

まず「どのサービスが何を担当するか」と「2024〜2025 年に大きく動いたサービスのステータス」を押さえます。試験問題は数年前に作られているため、試験上の正解と現在の推奨が食い違う箇所 があります。

サービス 役割 ステータス（2026-10 時点）
CodePipeline CI/CD のオーケストレーション（ステージ・アクションの流れを定義） 現役。V2 タイプが機能追加の主軸
CodeBuild ビルド・テストの実行（フルマネージド） 現役。Lambda コンピューティング、予約キャパシティ、GitHub Actions ランナーなど拡張中
CodeDeploy EC2／オンプレ・Lambda・ECS へのデプロイ 現役。ECS は 2025 年から ECS ネイティブ Blue/Green も選択肢
CodeArtifact パッケージ（npm / PyPI / Maven / NuGet など）のプライベートリポジトリ 現役
CodeCommit マネージド Git リポジトリ 2024-07-25 に新規受付停止 → 2025-11-25 に新規受付を再開し完全 GA（The Future of AWS CodeCommit、ドキュメント履歴）
CodeConnections（旧 CodeStar Connections） GitHub / GitLab / Bitbucket との接続 現役。2024-03-29 に改称（改称のお知らせ）
CodeStar Notifications Code 系サービスの通知ルール 現役
CodeGuru Reviewer ML によるコードレビュー 2025-11-07 以降は新しいリポジトリの関連付け不可（メンテナンス）（AWS Service Availability Updates、提供状況の変更）
CodeGuru Security 静的解析（SAST） 2025-11-20 にサポート終了（CLI リファレンスの告知）
CodeCatalyst 統合 DevOps サービス 2025-11-07 以降は新規受付停止（メンテナンス）（同上）
CodeStar（プロジェクト管理） プロジェクトのテンプレート作成 2024-07-31 で終了（公式ドキュメントと製品ページは撤去済み。中国リージョン版 API ドキュメントの告知）
Proton テンプレートベースのプラットフォーム管理 2025-10 にサンセット告知（12 か月以内の移行を推奨、同上）
OpsWorks Stacks Chef ベースの構成管理 2024-05-26 に EOL。Systems Manager への移行が案内されている（移行ブログ）
Cloud9 クラウド IDE 2024-07-25 に新規受付停止（移行ブログ）

試験での扱い方
試験ガイドに載っている以上、CodeStar や Proton、OpsWorks が選択肢に出ることはあります。ただし正解になるのはほぼ「CodePipeline + CodeBuild + CodeDeploy」「CloudFormation / SAM / CDK」の組み合わせで、終了・メンテナンス中のサービスは消去法の対象と考えて差し支えありません。CodeCommit は「終了した」と思い込んでいると選択肢の判断を誤ります。現役サービス として扱ってください。

2. CodePipeline

概要

CodePipeline は リリースの流れ（ステージとアクション）を定義し、ソース変更を検知して自動で流す オーケストレーションサービスです。ビルドやデプロイそのものは行わず、CodeBuild / CodeDeploy / CloudFormation などの「アクションプロバイダ」を呼び出します（CodePipeline の概念）。

  • パイプライン：ステージを直列に並べたワークフロー。最初のステージは必ず Source
  • ステージ：アクションの集まり。ステージ間の トランジション を無効化すると、次のステージへ進むのを止められる（本番デプロイの凍結に使う）
  • アクション：Source / Build / Test / Deploy / Approval / Invoke / Compute のカテゴリがある。runOrder で同一ステージ内の直列・並列を制御
  • 実行（execution）：1 つのソースリビジョン（コミットなど）がパイプラインを通る単位
  • アーティファクト：アクション間で受け渡すファイル。リージョンごとの S3 アーティファクトバケット に置かれ、KMS で暗号化される

主要機能

アクションカテゴリと代表プロバイダ

カテゴリ 代表的なプロバイダ
Source CodeCommit、S3、ECR、CodeConnections 経由の GitHub / GitHub Enterprise Server / GitLab / Bitbucket
Build CodeBuild、Jenkins
Test CodeBuild、Device Farm、サードパーティ
Deploy CodeDeploy、CloudFormation、CloudFormation StackSets、ECS（ローリング）、ECS（Blue/Green、CodeDeploy 経由）、Elastic Beanstalk、S3、Service Catalog、AppConfig のほか、EKS（2025-02 追加）、EC2（2025-02 追加）、Lambda（2025-05 追加）の直接デプロイアクション
Approval 手動承認（SNS 通知は任意）
Invoke Lambda、Step Functions、CodePipeline（別パイプラインの起動、2025-03 追加）
Compute Commands（任意のシェルコマンドを実行、V2 のみ）

一覧は アクション構造リファレンス に、追加時期は ドキュメント履歴 にあります（ECRBuildAndPublish と InspectorScan アクションは 2024-11、Commands アクションは 2024-10、ステージのロールバックは 2024-04、PARALLEL / QUEUED モードは 2024-02）。

実行モード（SUPERSEDED / QUEUED / PARALLEL）

パイプライン実行の仕組み より。

モード 挙動 条件
SUPERSEDED（既定） ステージ待ちの古い実行を新しい実行が追い越す V1 / V2
QUEUED キューに入れた順に 1 つずつ処理 V2 のみ
PARALLEL 実行同士が独立して同時に走る V2 のみ。ステージのロールバック不可

V1 と V2 の違い

どのタイプのパイプラインが適切か の比較表を要約します。

機能 V1 V2
アクションレベル変数 ○ ○
パイプラインレベル変数（実行時に値を渡す） × ○
QUEUED / PARALLEL 実行モード × ○
ステージのロールバック × ○
ソースリビジョンの上書き（特定コミットで実行） × ○
ステージ条件（entry / on-failure / on-success） × ○
トリガーとフィルター（Git タグ・PR・ブランチ・ファイルパス） × ○
Commands アクション × ○
失敗時の自動リトライ × ○

料金も異なります。V1 は「アクティブなパイプライン 1 本あたり月 1 USD（作成後 30 日間は無料）」、V2 は「アクション実行 1 分あたり 0.002 USD（手動承認とカスタムアクションは無料）」です（料金ページ）。

ソース変更の検知

  • CodeConnections（GitHub / GitLab / Bitbucket）：V2 のトリガーで Git タグ、ブランチ、プルリクエスト（open / update / close）、ファイルパスのフィルターが使える
  • CodeCommit：EventBridge ルールがパイプラインを起動する（ポーリングは非推奨）
  • S3：コンソールで作ると EventBridge ルールと CloudTrail 証跡が作られる。CLI では CloudTrail なしで EventBridge だけを使う構成も可能（S3 ソースと EventBridge / CloudTrail）
  • ECR：イメージのプッシュで起動（EventBridge）

変数

アクションの出力変数（例：CodeCommit の CommitId、CodeBuild の exported-variables）を #{namespace.variable} の形式で後続アクションに渡せます。V2 では パイプラインレベル変数 を宣言し、実行開始時に値を上書きできます（同じパイプラインを環境ごとに使い回すときに便利）。

手動承認

手動承認アクション の設定項目は「SNS トピックへの通知」「レビュー用 URL」「承認者向けコメント」の 3 つで、いずれも任意です。承認・却下には codepipeline:PutApprovalResult 権限が要ります。応答がないまま 既定で 7 日 経つと失敗扱いになります。このタイムアウトはアクション単位で 5 分〜86,400 分（60 日）に変更できます（クォータ）。

クロスアカウント・クロスリージョン

クロスアカウントパイプライン で必要なもの。

  1. アーティファクトバケットを カスタマーマネージド KMS キー で暗号化する（AWS マネージドキーは他アカウントと共有できない）
  2. バケットポリシーとキーポリシーでターゲットアカウントを許可する
  3. ターゲットアカウントに、パイプラインアカウントを信頼する IAM ロールを作り、アクションの roleArn に指定する
  4. パイプラインのサービスロールにそのロールの sts:AssumeRole を許可する

クロスリージョンアクションは、アクションに region を指定し、そのリージョンにもアーティファクトバケットを用意 します（コンソールなら自動作成、CodePipeline がアーティファクトを複製）。

ステージのロールバック・条件・自動リトライ（V2）

  • ロールバック：そのステージで最後に成功した実行のソースリビジョンと変数を使って「ロールバック実行」を新規に起こす。手動と自動（失敗時）がある。Source ステージには設定できず、PARALLEL モードでは使えない（ステージのロールバック、自動ロールバックの設定）
  • ステージ条件：entry 条件（CloudWatch アラーム、Lambda、変数チェック、デプロイウィンドウなど）で入口を制御し、on-failure で「ロールバック」、entry で「スキップ」といった結果を返せる
  • 自動リトライ：失敗したステージ（またはアクション）を自動で再実行する

通知と監査

パイプライン／ステージ／アクションの状態変化は EventBridge に流れ、CodeStar Notifications のルールで SNS やチャットに通知できます。操作履歴は CloudTrail に残ります。

試験で問われるところ

問題文のシナリオ 正解の方向
本番デプロイ前に責任者の承認を挟みたい 手動承認アクション（SNS で通知、PutApprovalResult 権限を承認者に付与）
CloudFormation の変更内容を人が確認してから適用したい CHANGE_SET_REPLACE → 手動承認 → CHANGE_SET_EXECUTE の 3 アクション構成
特定のブランチ／タグ／ディレクトリの変更だけで起動したい V2 トリガーのフィルター（CodeConnections ソース）
本番環境は別アカウントにデプロイしたい クロスアカウント構成（カスタマーマネージド KMS + バケットポリシー + ターゲット側ロール）
複数リージョンへ同じリリースを流したい クロスリージョンアクション（各リージョンにアーティファクトバケット）
デプロイ失敗時に前回の成功版へ自動で戻したい ステージの自動ロールバック（V2）、または CodeDeploy の自動ロールバック
リリースを順番通りに処理し、追い越しを禁止したい QUEUED モード
複数のリリースを同時に独立して流したい PARALLEL モード（ロールバックは諦める）
アラーム発生中はデプロイを始めたくない ステージの entry 条件（CloudWatch アラーム）
S3 に置いた成果物の更新で自動起動させたい EventBridge（コンソール経由なら CloudTrail 証跡も作成）
GitHub と安全に連携したい CodeConnections（旧 OAuth／Webhook 方式の GitHub v1 ではなく）
パイプラインの途中でカスタム処理（通知、外部 API 呼び出し）を入れたい Invoke アクション（Lambda / Step Functions）または Commands アクション
一時的に本番デプロイを止めたいが、パイプラインは残したい ステージ間トランジションの無効化
同じパイプラインで環境ごとにパラメータを変えたい パイプラインレベル変数（V2）

引っかけ

  • 手動承認は 既定 7 日 で失効し、失敗扱いになる（アクション単位で最長 60 日まで延長可）。「承認待ちで無期限に止めておく」は成り立たない
  • クロスアカウントで AWS マネージド KMS キーは使えない。カスタマーマネージドキーが必須
  • PARALLEL モードではロールバックできない。「同時実行」と「失敗時ロールバック」を両立させる選択肢は誤り
  • V1 のまま「トリガーのフィルター」「パイプライン変数」「ロールバック」を使う選択肢は誤り。V2 への更新が前提
  • CodePipeline 自体はビルドもデプロイもしない。「CodePipeline でビルドする」は CodeBuild の読み替え
  • 承認アクションへの SNS 通知は任意。ただし「承認者にメールで通知」とあれば SNS トピックの設定が正解

3. CodeBuild

概要

CodeBuild は ソースを取得し、ビルド環境（コンテナ）を起動して buildspec に書かれたコマンドを実行し、成果物を S3 に置く フルマネージドのビルド・テストサービスです。課金はビルド時間（EC2 コンピューティングは分単位、Lambda コンピューティングは秒単位の切り上げ。料金）で、サーバーの管理やスケーリングは不要です。CodePipeline の Build / Test アクションの標準プロバイダであり、単体でも Webhook や EventBridge から起動できます。

ビルドプロジェクト が設定の単位で、ソース、環境（イメージ・コンピューティング・環境変数・サービスロール）、buildspec、アーティファクト、ログ、キャッシュ、VPC、タイムアウトなどを持ちます。

主要機能

buildspec

buildspec リファレンス の要点です。既定ではソースのルートにある buildspec.yml が使われ、プロジェクト設定で別名・別パス・インライン定義に差し替えられます。

version: 0.2
env:
  variables:
    APP_ENV: production
  parameter-store:
    DB_HOST: /myapp/db/host
  secrets-manager:
    DB_PASSWORD: myapp/db:password
  exported-variables:
    - BUILD_TAG
phases:
  install:
    runtime-versions:
      nodejs: 20
  pre_build:
    commands:
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI
  build:
    on-failure: ABORT
    commands:
      - docker build -t $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION .
      - export BUILD_TAG=$CODEBUILD_RESOLVED_SOURCE_VERSION
    finally:
      - echo "build phase finished"
  post_build:
    commands:
      - docker push $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION
      - printf '[{"name":"app","imageUri":"%s"}]' $ECR_URI:$CODEBUILD_RESOLVED_SOURCE_VERSION > imagedefinitions.json
reports:
  unit-tests:
    files:
      - 'reports/junit/*.xml'
    file-format: JUNITXML
artifacts:
  files:
    - imagedefinitions.json
cache:
  paths:
    - '/root/.npm/**/*'
  • phases：install → pre_build → build → post_build の順。各フェーズに on-failure: ABORT | CONTINUE、finally（失敗しても実行）、run-as（実行ユーザー）を指定できる
  • env：variables（平文）、parameter-store、secrets-manager の 3 種。秘密情報は後者 2 つを使う。exported-variables で CodePipeline の後続アクションへ値を渡す
  • reports：JUnit XML、NUnit、Cucumber JSON、TestNG、Visual Studio TRX などのテストレポートと、JaCoCo / Cobertura / Clover / SimpleCov などのカバレッジをレポートグループに集約できる（テストレポート）
  • artifacts：出力ファイル、base-directory、secondary-artifacts（複数の出力）
  • cache：S3 キャッシュに保存するパス
  • version: 0.1 では各コマンドが別シェルで実行される（環境変数の引き継ぎができない）ため、0.2 を使う

ビルド環境とコンピューティング

  • イメージ：AWS 管理イメージ（Amazon Linux 2023、Ubuntu、Windows）か、ECR / Docker Hub などのカスタムイメージ
  • 特権モード（privileged mode）：ビルド内で Docker デーモンを動かす（Docker イメージのビルド）ときに必要
  • コンピューティング（ビルド環境のコンピューティングタイプ）
    • EC2 オンデマンド：ビルドごとにマシンを起動し、終了後に破棄（既定）。x86 / Arm / GPU / Windows
    • Lambda コンピューティング：起動が速く小さなビルド向け。最長 15 分でタイムアウトは変更不可、ローカルキャッシュ・バッチビルド・Docker イメージビルドは非対応（Lambda コンピューティングの発表ブログ）
    • 予約キャパシティフリート：専用インスタンスを常時確保し、キュー待ちとプロビジョニング時間を削る。常時課金。macOS やカスタム AMI もここで使う（予約キャパシティフリート）
  • タイムアウト：ビルドタイムアウトは既定 60 分。キュー待ちのタイムアウトも別に設定できる
  • フェーズの遷移：BUILD フェーズが失敗しても UPLOAD_ARTIFACTS フェーズは必ず試行される（ビルドフェーズの遷移）。失敗時に後続フェーズを止めたいときは on-failure: ABORT や環境変数 CODEBUILD_BUILD_SUCCEEDING で制御する
  • VPC：VPC 内のリソース（RDS、ElastiCache、内部 API など）にアクセスする場合はサブネットとセキュリティグループを指定する。ビルドにパブリック IP は付かないので、インターネットへは NAT ゲートウェイ経由、AWS サービスへは VPC エンドポイントを用意する（VPC サポート）
  • ログ：CloudWatch Logs と S3 の両方に出力できる

キャッシュ

ビルドのキャッシュ には 2 種類あります。

種類 内容 向き
S3 キャッシュ cache.paths のファイルを S3 に保存。ビルドホストが変わっても使える 依存パッケージ（npm、pip、Maven）
ローカルキャッシュ ビルドホスト上に保持。SOURCE（Git メタデータ）、DOCKER_LAYER（Docker レイヤー）、CUSTOM（任意パス）の 3 モード 同じホストに当たったときだけ効く。Docker イメージの再ビルド

バッチビルド

バッチビルド で 1 回の起動から複数ビルドを並列・依存付きで走らせます。build-graph（依存関係）、build-list（並列リスト）、build-matrix（OS × ランタイムなどの組み合わせ）、build-fanout（テストのシャーディング）の 4 形式です。

起動方法

  • CodePipeline のアクションとして
  • Webhook：GitHub / GitLab / Bitbucket のイベント（push、PR）でフィルター（EVENT、HEAD_REF、FILE_PATH、ACTOR_ACCOUNT_ID など）を使って起動
  • EventBridge のスケジュール、StartBuild API
  • セルフホストランナー：GitHub Actions / GitLab / Buildkite のランナーとして CodeBuild を使う。Webhook のイベントタイプ WORKFLOW_JOB_QUEUED でジョブごとにビルドが起動する（GitHub Actions ランナー）

セキュリティ

  • ビルドはプロジェクトの サービスロール の権限で動く（ECR プッシュ、S3、CodeArtifact などの権限はここに付ける）
  • 秘密情報は Secrets Manager / Parameter Store 経由で渡す（ログでマスクされる）
  • アーティファクトとキャッシュは KMS で暗号化できる
  • CodeArtifact を使う場合は pre_build で aws codeartifact login を実行する（パッケージマネージャの向き先を切り替える）

試験で問われるところ

問題文のシナリオ 正解の方向
Docker イメージをビルドして ECR へプッシュしたい 特権モードを有効化、pre_build で ECR ログイン、サービスロールに ECR 権限
ビルドが VPC 内の DB に接続する統合テストを実行する プロジェクトに VPC 設定（サブネット・SG）。インターネットが要るなら NAT
パスワードやトークンを buildspec に書きたくない env.secrets-manager / env.parameter-store
依存パッケージのダウンロードでビルドが遅い S3 キャッシュ（cache.paths）、Docker レイヤーはローカル DOCKER_LAYER キャッシュ
テスト結果とカバレッジを可視化・推移を追いたい reports セクション + レポートグループ
複数のランタイム／OS の組み合わせでテストしたい バッチビルド build-matrix
ビルド失敗を Slack やメールに通知したい EventBridge（Build State Change）→ SNS / チャット、または CodeStar Notifications
GitHub Actions のワークフローを AWS 内のランナーで実行したい CodeBuild のセルフホストランナー（WORKFLOW_JOB_QUEUED）
ビルドの起動待ちをなくしたい、固定の実行環境が欲しい 予約キャパシティフリート
小さなビルドを安く速く回したい Lambda コンピューティング（15 分、Docker 不可を許容できる場合）
ビルド結果の値（イメージタグなど）をデプロイアクションに渡したい exported-variables + CodePipeline の変数参照
ビルドエラーの原因を調べたい CloudWatch Logs / S3 ログ、フェーズごとの失敗箇所

引っかけ

  • buildspec の既定の置き場所は ソースのルート。サブディレクトリに置くならプロジェクト設定で明示する
  • Lambda コンピューティングは タイムアウト変更不可（15 分固定）、Docker ビルド不可。「Docker イメージを Lambda コンピューティングで」は誤り
  • VPC 設定をしたビルドは パブリック IP を持たない。外部パッケージの取得には NAT ゲートウェイが必要
  • ローカルキャッシュは 同じビルドホストに当たったときしか効かない。確実に効かせたいなら S3 キャッシュ
  • 特権モードは Docker デーモンを動かすときだけ必要。通常のビルドで有効化する選択肢は過剰
  • version: 0.1 はコマンドごとに別シェル。環境変数が引き継げない問題は 0.2 へ

4. CodeDeploy

概要

CodeDeploy は EC2 / オンプレミス、Lambda、ECS にアプリケーションをデプロイするサービスです（CodeDeploy とは）。構成要素は次のとおりです。

構成要素 内容
アプリケーション デプロイ対象の名前と コンピューティングプラットフォーム（EC2/オンプレ、Lambda、ECS）
デプロイグループ 対象（EC2 タグ・Auto Scaling グループ・オンプレタグ、ECS サービス、Lambda 関数）、デプロイ設定、ロードバランサー、アラーム、自動ロールバックなどの設定
デプロイ設定 一度に何台（何 %）に配るか、トラフィックをどう移すか
リビジョン デプロイする中身。EC2 では AppSpec ファイル（appspec.yml）+ ファイル一式（S3 または GitHub）。Lambda / ECS では AppSpec（YAML / JSON）が中心
デプロイ リビジョンをデプロイグループへ適用する 1 回の操作

主要機能

プラットフォーム別のデプロイタイプ

プラットフォーム インプレース Blue/Green
EC2 / オンプレミス ○（各インスタンス上で停止→入替→起動。CodeDeploy エージェント が必要） ○（EC2 のみ。新しいインスタンス群を用意し、ELB で切り替え。オンプレ不可）
Lambda × ○（エイリアスのトラフィックを新バージョンへ移す。Canary / Linear / AllAtOnce）
ECS × ○（新タスクセットを作り、ALB / NLB のリスナーで切り替え。テスト用リスナーも設定可）

Lambda と ECS は Blue/Green のみ です。EC2 の Blue/Green では、置き換え環境を「Auto Scaling グループのコピー」で自動作成するか、既存インスタンスをタグで指定します。元のインスタンスはデプロイ後に終了するか残すかを選べ、トラフィック切り替えを「自動で続行」か「手動で切り替えるまで待つ」かも選べます。

AppSpec とライフサイクルフック

AppSpec の hooks セクション より。プラットフォームごとにフックが異なり、EC2 ではシェルスクリプト、Lambda / ECS では Lambda 関数 を呼びます。

EC2 / オンプレ（インプレース） の実行順：

ApplicationStop → DownloadBundle → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService

DownloadBundle と Install はエージェント専用でスクリプトは書けません。Blue/Green では置き換え環境に BeforeAllowTraffic / AllowTraffic / AfterAllowTraffic、元の環境に BeforeBlockTraffic / BlockTraffic / AfterBlockTraffic が加わります。

ApplicationStop は「前回成功したリビジョン」の AppSpec とスクリプトで実行される（新しいリビジョンはまだダウンロードされていないため）。古い ApplicationStop スクリプトのバグでデプロイが失敗し続ける場合は、--ignore-application-stop-failures を付けて再デプロイする（CodeDeploy FAQ）。

Lambda：BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic（検証用の Lambda 関数を指定。失敗を返すとロールバック）

ECS：BeforeInstall → Install → AfterInstall → AllowTestTraffic → AfterAllowTestTraffic → BeforeAllowTraffic → AllowTraffic → AfterAllowTraffic（AfterAllowTestTraffic でテストリスナー経由の検証をしてから本番トラフィックを切り替える）

デプロイ設定

デプロイ設定 の定義済み設定です。

EC2 / オンプレ

設定 挙動 成功判定
CodeDeployDefault.AllAtOnce できるだけ多くのインスタンスに同時にデプロイ 1 台でも成功すれば成功
CodeDeployDefault.HalfAtATime 最大で半数（端数切り捨て）ずつ 半数以上（端数切り上げ）に成功すれば成功
CodeDeployDefault.OneAtATime 1 台ずつ 全台成功で成功。ただし最後の 1 台だけ失敗しても成功扱い

カスタム設定では「最小正常インスタンス数」を台数（HOST_COUNT）か割合（FLEET_PERCENT）で指定します。複数 AZ に AZ 単位で順番にデプロイ する ゾーン設定（zonal configuration） はカスタム設定でのみ使えます（AZ ごとの最小正常台数、AZ 間の待機時間を設定。ゾーン設定）。

Lambda

設定 挙動
LambdaCanary10Percent5Minutes（10 / 15 / 30 分版あり） 10% を新バージョンへ → 指定時間後に残り全部
LambdaLinear10PercentEvery1Minute（2 / 3 / 10 分版あり） 指定間隔ごとに 10% ずつ増やす
LambdaAllAtOnce 一括切り替え

ECS

設定 挙動
ECSCanary10Percent5Minutes / ECSCanary10Percent15Minutes 10% → 指定時間後に全部
ECSLinear10PercentEvery1Minutes / ECSLinear10PercentEvery3Minutes 指定間隔ごとに 10% ずつ
ECSAllAtOnce 一括切り替え

自動ロールバック

ロールバックと再デプロイ より。ロールバックは 「前回の正常リビジョンを新しいデプロイとして再デプロイする」 動作です。自動ロールバックのトリガーは 3 種類です。

イベント 内容
DEPLOYMENT_FAILURE デプロイ失敗時
DEPLOYMENT_STOP_ON_ALARM デプロイグループに関連付けた CloudWatch アラーム（最大 10 個）が ALARM になったとき
DEPLOYMENT_STOP_ON_REQUEST 手動で停止したとき

Lambda の場合、SAM の DeploymentPreference で Alarms と Hooks を書けば、CodeDeploy のカナリア／リニアとアラームロールバックが設定されます。

Auto Scaling との連携

Auto Scaling との統合 より。デプロイグループに Auto Scaling グループを関連付けると、CodeDeploy が ライフサイクルフック を登録し、スケールアウトで起動した新インスタンス（Pending:Wait 状態）に 最後に成功したリビジョンを自動でデプロイ してから CONTINUE / ABANDON を返します。

デプロイ中にスケールアウトが起きると、新インスタンスには「進行中のリビジョン」ではなく「直前に成功したリビジョン」が配られ、一時的に バージョンの混在 が起きます。現在は CodeDeploy が最初のデプロイの直後に フォローオンデプロイを自動で開始 して古いインスタンスを更新します（既定で有効。古いリビジョンのまま残す設定も可能）。以前はこの場面で再デプロイが必要でした。デプロイ中のスケールアウト自体を抑止したい場合は、ロードバランサー連携用のサンプルスクリプト common_functions.sh で HANDLE_PROCS=true を設定すると AZRebalance / AlarmNotification / ScheduledActions / ReplaceUnhealthy のプロセスが自動で一時停止されます（CodeDeployDefault.OneAtATime のみ対応）。1 つの Auto Scaling グループを複数のデプロイグループに関連付けるのは混乱の元になります。

エージェントとオンプレミス

  • EC2 / オンプレではインスタンスに CodeDeploy エージェント が必要。Systems Manager のディストリビューター（エージェント 2.0.x 以降は AWSCodeDeployAgentV2、1.8.x 以前は AWSCodeDeployAgent）で配布・更新できる（SSM でのインストール）
  • インスタンスプロファイル（EC2）には リビジョンを置いた S3 バケットの読み取り権限 が必要。読めないと DownloadBundle で失敗する
  • オンプレミスは IAM ロール（STS）または IAM ユーザーで登録し、タグでデプロイグループに含める
  • エージェントのログは /var/log/aws/codedeploy-agent/、スクリプトの出力は /opt/codedeploy-agent/deployment-root/ 配下

ECS ネイティブ Blue/Green との関係

2025 年 7 月に ECS 自体が Blue/Green デプロイとライフサイクルフックをサポート し（発表）、同年 10 月にカナリア／リニアも追加されて CodeDeploy と同等になりました（CDK での選び方ブログ）。現行の試験問題は CodeDeploy 前提で作られているため、「ECS の Blue/Green」= CodeDeploy（ECS Blue/Green） と読んで正解を選べます。実務では ECS ネイティブも検討対象です。

試験で問われるところ

問題文のシナリオ 正解の方向
EC2 でダウンタイムなし、問題があればすぐ戻したい Blue/Green（元の環境を一定時間残す）+ 自動ロールバック
コスト最優先、短時間の停止は許容 インプレース AllAtOnce（または HalfAtATime）
常に半数以上を稼働させたままデプロイ HalfAtATime またはカスタム設定で最小正常 50%
Lambda の新バージョンを 10% だけ先に流し、問題なければ全体へ LambdaCanary10Percent5Minutes など + CloudWatch アラームでロールバック
段階的に少しずつ移したい Linear 系（Lambda / ECS）
AZ ごとに順番にデプロイし、AZ 単位で影響を抑えたい カスタムデプロイ設定のゾーン設定
デプロイ後にエラー率が上がったら自動で戻す デプロイグループに CloudWatch アラームを関連付け、DEPLOYMENT_STOP_ON_ALARM
デプロイ前に設定ファイルを復号、デプロイ後にヘルスチェック BeforeInstall / ValidateService（EC2）、AfterAllowTraffic（Lambda / ECS）
ECS でテスト用リスナーから検証してから本番に流す CodeDeploy ECS Blue/Green + AfterAllowTestTraffic フック
Auto Scaling の新インスタンスにも自動で最新版を入れたい デプロイグループに Auto Scaling グループを関連付け
デプロイ中にスケールアウトした台だけ古い CodeDeploy が自動でフォローオンデプロイを行う（無効化している場合は再デプロイ）
オンプレのサーバーも同じ仕組みで配りたい EC2/オンプレプラットフォーム + エージェント + IAM ロールで登録
エージェントがバンドルを取得できない インスタンスプロファイルの S3 権限、S3 VPC エンドポイント
ApplicationStop で毎回失敗する 前回リビジョンのスクリプトが原因。--ignore-application-stop-failures で再デプロイ
CodePipeline から ECS Blue/Green を行う ECS（Blue/Green）デプロイアクションに taskdef.json / appspec.yaml / imageDetail.json を渡す

引っかけ

  • Lambda と ECS にインプレースはない。EC2 の Blue/Green には ELB が必須、オンプレに Blue/Green はない
  • ロールバックは「元に戻す魔法」ではなく 旧リビジョンの再デプロイ。前回のデプロイで追加されたファイルは残ることがある
  • AllAtOnce は 1 台成功で「成功」。OneAtATime は最後の 1 台失敗でも「成功」。成功判定の違いを問う問題がある
  • 定義済み設定では ゾーン設定は使えない（カスタム設定が必要）
  • Auto Scaling グループを 複数のデプロイグループ に関連付けると、どのリビジョンが配られるか予測できなくなる
  • CodeDeploy エージェントは EC2 / オンプレにだけ必要。Lambda / ECS には不要

5. CodeArtifact

概要

CodeArtifact は npm / PyPI / Maven / NuGet / RubyGems / Swift / Cargo / 汎用 のパッケージを保管するフルマネージドのアーティファクトリポジトリです（CodeArtifact とは）。社内パッケージの共有と、公開レジストリのプロキシ（キャッシュ）の両方を担います。

主要機能

  • ドメイン：リポジトリをまとめる単位。KMS キーでの暗号化や、組織内の複数アカウントからの共有（ドメインポリシー）をここで設定する
  • リポジトリ：パッケージの置き場。アップストリーム（別リポジトリ。直接のアップストリームは最大 10 個）と 外部接続（npmjs、PyPI、Maven Central、NuGet Gallery、RubyGems、crates.io などの公開レジストリ。リポジトリあたり 1 つ）を設定できる（アップストリーム、外部接続）
  • 取得時の保持：アップストリーム経由で取得したパッケージは、要求元のリポジトリにも保持される（公開レジストリが落ちても再取得できる）
  • パッケージオリジン制御：パッケージ単位で「アップストリームからの取得（upstream）」と「直接の公開（publish）」を ALLOW / BLOCK できる。社内パッケージ名と同名のパッケージが公開レジストリに登録される依存関係の混乱（dependency confusion） を防ぐ（パッケージオリジン制御）
  • パッケージグループ：名前空間（例：@mycompany/*）でまとめてオリジン制御を適用する（パッケージグループのオリジン制御）
  • 認証：aws codeartifact get-authorization-token で取得するトークン（既定 12 時間、15 分〜12 時間。トークン認証）を使う。aws codeartifact login が npm / pip / twine / NuGet などの設定を書き換える
  • アクセス制御：ドメインポリシーとリポジトリポリシー（リソースベース）で他アカウントに許可。VPC エンドポイント経由のプライベートアクセスも可能

試験で問われるところ

問題文のシナリオ 正解の方向
社内ライブラリを複数チーム・複数アカウントで共有したい CodeArtifact ドメイン + リポジトリポリシーでクロスアカウント許可
公開レジストリへの直接アクセスを禁止し、承認済みパッケージだけ使わせたい 外部接続付きリポジトリを経由させる（CodeBuild は login で向き先を変更）
社内パッケージ名の乗っ取り（依存関係の混乱）を防ぎたい パッケージオリジン制御で upstream: BLOCK、パッケージグループで名前空間ごとに適用
チームごとのリポジトリから共通リポジトリを参照したい アップストリーム構成
CodeBuild の pip install を CodeArtifact 経由にしたい pre_build で aws codeartifact login --tool pip、サービスロールに codeartifact:GetAuthorizationToken と sts:GetServiceBearerToken
長時間ビルドでトークンが切れる トークンの有効期限は最大 12 時間

6. CodeCommit / CodeConnections / 通知

CodeCommit

マネージドの Git リポジトリです。2024 年 7 月 25 日に新規受付を停止しましたが、2025 年 11 月 25 日に 新規受付を再開して完全 GA に復帰 しています（Git LFS 対応と追加リージョンの計画も公表。The Future of AWS CodeCommit）。試験で問われる機能は次のとおりです。

  • 認証：IAM の HTTPS Git 認証情報、SSH キー、git-remote-codecommit（IAM ロール・フェデレーションで使える）
  • ブランチ保護：IAM ポリシーの条件キー codecommit:References で特定ブランチへの push / merge を拒否（ブランチの制限）
  • 承認ルールテンプレート：プルリクエストに必要な承認数と承認者プールを設定（承認ルールテンプレート）
  • トリガー：push やブランチ作成・削除で SNS / Lambda を呼ぶ（リポジトリあたり最大 10 個。トリガー）。プルリクエストやコメントのイベントは EventBridge で拾う
  • 暗号化：保存時は KMS、転送時は HTTPS / SSH。VPC エンドポイント（インターフェイス）で Git アクセスを閉域化
  • クロスアカウント：リポジトリのあるアカウントのロールを他アカウントから引き受け、git-remote-codecommit で操作
問題文のシナリオ 正解の方向
main へ直接 push させたくない IAM ポリシーで codecommit:References 条件の Deny、PR と承認ルールテンプレート
コードレビューを必須にしたい 承認ルールテンプレート（承認数・承認者プール）
push を Lambda で検証・通知したい リポジトリトリガー（SNS / Lambda）
別アカウントの開発者にリポジトリを使わせたい クロスアカウントロール + git-remote-codecommit
GitHub から移行したい／GitHub を使い続けたい 移行なら CodeCommit、使い続けるなら CodeConnections で連携

CodeConnections（旧 CodeStar Connections）

GitHub（Cloud / Enterprise Server）、GitLab（SaaS / セルフマネージド）、Bitbucket、Azure DevOps（2025-08 追加）と AWS を接続する仕組みです。CodePipeline のソースアクション、CodeBuild、CloudFormation の Git 同期などが共通で使います。2024 年 3 月 29 日に CodeStar Connections から改称され、codeconnections API と新しい ARN 形式になりました（旧 ARN も引き続き有効。改称のお知らせ）。

  • 接続はコンソールで「保留中（Pending）」から ハンドシェイクを完了 して初めて使える（CloudFormation / CLI で作った接続は必ずコンソールで完了させる）
  • GitHub Enterprise Server やセルフマネージド GitLab など VPC 内のサーバーには ホスト を作成して接続する

通知

  • CodeStar Notifications：CodeCommit / CodeBuild / CodeDeploy / CodePipeline のイベントを通知ルールで SNS やチャットアプリに送る
  • EventBridge：すべての状態変化イベントが流れる。ルールで Lambda / SNS / Step Functions などを起動
  • CloudTrail：API 操作の監査

7. 周辺サービス（試験ガイドに載っているもの）

サービス 何をするか 試験での位置づけ
CodeGuru Reviewer ML でコードレビュー（セキュリティ・性能の指摘） 「自動コードレビュー」の選択肢。2025-11-07 以降は新規受付停止
CodeGuru Profiler 本番アプリの CPU / レイテンシのプロファイリング 「本番で最もコストの高いコード行を特定」の選択肢（受付停止の告知は見つからず、現役扱い）
CodeGuru Security 静的解析（SAST） 2025-11-20 にサポート終了。正解になりにくい
X-Ray（SAP の対象一覧） 分散トレーシング デプロイ後の性能劣化の追跡
CodeCatalyst 統合 DevOps（リポジトリ・ワークフロー・Issue） 2025-11-07 以降は新規受付停止。正解になりにくい
CodeStar プロジェクトテンプレート 2024-07-31 終了。消去法の対象
Proton プラットフォームチームがテンプレートを配る仕組み 2025-10 サンセット告知。正解になりにくい
OpsWorks Stacks（DOP） Chef による構成管理 2024-05-26 に EOL。Systems Manager（Run Command / State Manager）へ読み替え
Service Catalog（DOP / SAP） 承認済みテンプレートの配布 「開発者に承認済み構成だけを使わせる」の正解。Control Tower の Account Factory の基盤

8. 横断シナリオ：代表的なパイプライン構成

試験では個々のサービスより「組み合わせ」を問われます。頻出の 5 パターンを整理します。

パターン A：コンテナ（ECS）の Blue/Green

CodeConnections（GitHub）→ CodeBuild（docker build → ECR push → imageDetail.json 出力）→ 手動承認 → CodeDeploy ECS Blue/Green（taskdef.json + appspec.yaml、AfterAllowTestTraffic でテスト、CloudWatch アラームで自動ロールバック）

パターン B：サーバーレス（Lambda）

CodeBuild（sam build / sam package）→ CloudFormation アクション（CHANGE_SET_REPLACE → 承認 → CHANGE_SET_EXECUTE）。テンプレートの AutoPublishAlias と DeploymentPreference（Canary10Percent10Minutes、Alarms、Hooks）で CodeDeploy のカナリアとロールバックが有効になる。

パターン C：マルチアカウント

ツール用アカウントにパイプラインを置き、開発・本番アカウントへクロスアカウントデプロイ。カスタマーマネージド KMS、アーティファクトバケットのポリシー、各アカウントのデプロイ用ロール、本番前の手動承認。組織全体への配布は CloudFormation StackSets アクション。

パターン D：EC2（Auto Scaling）

  • ランタイム構成：CodeDeploy インプレース／Blue/Green で Auto Scaling グループへ。新インスタンスへはライフサイクルフックで自動デプロイ
  • イミュータブル：EC2 Image Builder で AMI を焼き、起動テンプレートの更新 + Auto Scaling のインスタンスリフレッシュ（または CloudFormation の AutoScalingReplacingUpdate）。SAP ではこちらが問われやすい

パターン E：パイプラインへのセキュリティ組み込み（DOP 分野 6）

目的 組み込み方
IaC の静的チェック CodeBuild で cfn-lint / CloudFormation Guard / cdk-nag を実行して失敗させる
コンテナイメージの脆弱性 ECR の Inspector スキャン結果をチェックしてから Deploy へ進める
秘密情報の管理 Secrets Manager / Parameter Store。リポジトリや buildspec に書かない
成果物の改ざん防止 アーティファクトの KMS 暗号化、Signer によるコード署名
権限の最小化 パイプライン・ビルド・デプロイのサービスロールを分離し、承認者と実行者を分ける
監査 CloudTrail、EventBridge → Security Hub / SNS

デプロイ戦略の比較（SAP 2.1 で頻出）

戦略 ダウンタイム ロールバック コスト 実現手段
インプレース（一括） あり 再デプロイ（遅い） 最小 CodeDeploy AllAtOnce
ローリング ほぼなし（容量低下） 再デプロイ 低 CodeDeploy HalfAtATime / OneAtATime、ECS ローリング、CloudFormation AutoScalingRollingUpdate
Blue/Green なし 即時（切り戻し） 一時的に 2 倍 CodeDeploy Blue/Green（EC2 / ECS / Lambda）、CloudFormation AutoScalingReplacingUpdate
カナリア なし 即時（影響は一部） 低〜中 CodeDeploy Canary（Lambda / ECS）、ALB の重み付けターゲットグループ、Route 53 加重ルーティング
リニア なし 即時 低〜中 CodeDeploy Linear（Lambda / ECS）
イミュータブル なし 即時（旧 AMI に戻す） 一時的に 2 倍 Image Builder + Auto Scaling インスタンスリフレッシュ、Elastic Beanstalk Immutable

横断の引っかけ

  • 「最もコスト効率が良い」でも、要件（ダウンタイムゼロ、即時ロールバック）を満たさない選択肢は誤り。先に制約を読む
  • 「運用負荷が最小」なら自前の Jenkins サーバーより CodeBuild、自前スクリプトより CodeDeploy
  • 「Blue/Green」とあって EC2 なら ELB が前提。ELB がない構成の Blue/Green 選択肢は誤り
  • 「Lambda のトラフィックを段階的に」は CodeDeploy（SAM DeploymentPreference）。API Gateway のステージ変数で代用する選択肢は遠回り
  • 「ECS のデプロイ失敗で自動停止」は CodeDeploy の自動ロールバックか ECS のデプロイサーキットブレーカー（ローリングの場合）

9. 確認しきれなかった記述

本文で断定を避けた、または一次資料を再取得できなかった箇所です。受験前に公式で確認してください。

  • CodeStar の終了日（2024-07-31）は、公式ドキュメントと製品ページが撤去済みのため一次資料を再取得できず、中国リージョン版 API ドキュメントの告知文のみで確認しています
  • CodeBuild のフェーズ遷移のうち「BUILD が失敗しても UPLOAD_ARTIFACTS は試行される」はドキュメントで確認しましたが、「BUILD 失敗時に POST_BUILD が実行される」「INSTALL / PRE_BUILD の失敗では後続フェーズが実行されない」は図（画像）でのみ示されており、本文で確認できませんでした
  • CodeGuru Profiler の新規受付状況は、停止の告知が見つからないため「現役」として扱っています
  • 試験ガイドの対象サービス一覧は 2026 年 10 月時点の版で確認しました。SAP-C03 では変わる可能性があります

おわりに

Code シリーズは「サービスの名前を覚える」より 「どの要件にどの機能で応えるか」 を問われます。本記事の「試験で問われるところ」の表を、問題文の制約（ダウンタイム、ロールバック、アカウント分離、コスト、運用負荷）から逆引きできるようにしておくと、DOP の分野 1 と SAP の分野 2 はかなり安定します。第 2 回は CloudFormation、第 3 回は Control Tower を同じ構成で解説します。

📩 AWS認定の学習Tips・「試験に出ないが現場で必須」の知識をX（naoto@クラウドエンジニア）で毎日発信中 👉 https://x.com/naoto_tech_AI

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?