DVA-C02 D3 デプロイ 徹底解説（2025）｜CI/CD・SAM・canary/blue-green/rolling

1. D3「デプロイ」とは — SAAにない開発者視点の独自ドメイン

本記事は「AWS DVA-C02試験対策」シリーズの Vol3 です。
全体像は Vol0 ロードマップ、開発の基礎は Vol1、セキュリティは Vol2 で解説しています。

ここから扱うのは試験の第3ドメイン、D3「デプロイ（Deployment）」 です。
公式試験ガイドにおける出題比率は 24% で、採点50問換算なら約12問を占めます。

DVA-C02 の D3 が他の資格と大きく異なる点は、SAA-C03 に対応ドメインがないことです。
SAA はアーキテクチャ設計を問いますが、DVA の D3 は「作ったコードをどう安全・確実に本番へ届けるか」という 開発者の実務視点 が問われます。
IaC（Infrastructure as Code）の選択、CI/CDパイプラインの組み方、デプロイ手法の使い分け――これらは SAA では出題されない、DVA 独自の試験領域です。

D3 の出題範囲を一望する

D3 の 97問は、大きく次の6テーマで整理できます。

D3 で最も問われる本質は 「どのデプロイ手法をどの要件で選ぶか」 という判断軸です。
ダウンタイム許容の有無、即時ロールバックの要否、コスト制約――これら3軸を押さえることが D3 攻略の第一歩です。

2. IaC の選択 — SAM / CloudFormation / CDK の使い分け

インフラをコードで管理する IaC は D3 の土台です。
AWS には SAM・CloudFormation・CDK の3つのアプローチがあり、それぞれ適した用途が異なります。

CloudFormation — AWS IaC の基盤

CloudFormation は AWS が提供する最も基本的な IaC サービスです。
YAML または JSON で テンプレート を記述し、スタック として管理します。

Resources:
  MyBucket:
 Type: AWS::S3::Bucket
 Properties:
BucketName: my-app-bucket
VersioningConfiguration:
  Status: Enabled

CloudFormation の重要概念は次のとおりです。

変更セット は試験頻出です。
本番への影響を事前にプレビューするため aws cloudformation create-change-set を実行し、確認後に execute-change-set で適用します。
変更セットなしで直接更新すると予期せぬリソース削除を招く恐れがあるため、本番環境の必須プラクティスとして押さえてください。

SAM — サーバーレス特化の IaC

AWS Serverless Application Model（SAM）は CloudFormation の上位変換（Transform）として動作するサーバーレス特化の IaC フレームワークです。

Transform: AWS::Serverless-2016-10-31
Globals:
  Function:
 Timeout: 30
 Runtime: python3.12

Resources:
  MyFunction:
 Type: AWS::Serverless::Function
 Properties:
Handler: app.handler
Events:
  Api:
 Type: Api
 Properties:
Path: /hello
Method: get

SAM の主な特徴と試験ポイントを整理します。

sam local コマンドによるローカルテストは D3 の頻出出題ポイント です。
本番へデプロイする前に Lambda とAPI Gateway の動作を開発者環境で確認できる点が DVA で重視されます。

CDK — プログラミング言語で IaC を記述

AWS Cloud Development Kit（CDK）は TypeScript・Python・Java・C# 等のプログラミング言語で CloudFormation テンプレートを生成するフレームワークです。

import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigateway from 'aws-cdk-lib/aws-apigateway';

const fn = new lambda.Function(this, 'MyFunction', {
  runtime: lambda.Runtime.PYTHON_3_12,
  handler: 'app.handler',
  code: lambda.Code.fromAsset('src'),
});
const api = new apigateway.LambdaRestApi(this, 'MyApi', { handler: fn });

CDK の cdk synth で CloudFormation テンプレートを出力し、cdk deploy でデプロイします。
試験では「コードの再利用・型安全性が必要な場合に CDK を選択する」という判断軸を押さえてください。

IaC 選択の判断フロー

3. CI/CDパイプライン — Code兄弟の役割と連携

CodePipeline — パイプラインのオーケストレーター

CodePipeline はソースから本番デプロイまでの ステージ（Stage）とアクション（Action） を定義し、CI/CDを自動化するオーケストレーションサービスです。

代表的なパイプライン構成は次のとおりです。

Source(CodeCommit/S3/GitHub) → Build(CodeBuild) → Test(CodeBuild) → Approve(Manual) → Deploy(CodeDeploy/ECS/CloudFormation)

手動承認アクション は DVA 頻出テーマです。
本番デプロイ前に承認者がコンソールまたは SNS 通知経由で承認・拒否できます。
承認タイムアウト（デフォルト7日）内に応答がない場合、パイプラインは失敗扱いになります。

CodePipeline の主要な試験ポイントを整理します。

CodeBuild — マネージドビルド環境

CodeBuild はサーバーレスのビルド実行環境です。
ビルド手順は buildspec.yml に定義します。

version: 0.2
phases:
  install:
 runtime-versions:
python: 3.12
  pre_build:
 commands:
- pip install -r requirements.txt
- python -m pytest tests/unit/
  build:
 commands:
- sam build
  post_build:
 commands:
- sam package --s3-bucket $ARTIFACT_BUCKET --output-template-file packaged.yaml
artifacts:
  files:
 - packaged.yaml
cache:
  paths:
 - /root/.cache/pip/**/*

buildspec.yml の phases の順序（install→pre_build→build→post_build）は試験で問われます。
cache を使うと依存パッケージをキャッシュしてビルド時間を短縮できます。

CodeDeploy — デプロイの実行エンジン

CodeDeploy は EC2・Lambda・ECS に対するデプロイを自動化するサービスです。
試験で最も問われるのは デプロイ設定（Deployment Configuration） と ライフサイクルフック です。

EC2/オンプレミスの主要ライフサイクルフック

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

Lambda デプロイ設定（試験頻出）

Canary は2段階移行、Linear は均等増加、AllAtOnce は即時全量切替です。
「段階的に移行してアラームで自動ロールバックしたい」要件は Canary または Linear を選択します。

CodeArtifact — プライベートパッケージリポジトリ

CodeArtifact は npm・pip・Maven・NuGet 等に対応するプライベートパッケージリポジトリです。
開発チームが内製したライブラリを共有したり、外部パッケージ（PyPI・npmjs.com）をキャッシュして供給安定性を高めたりする用途で使います。

アップストリーム設定 が試験ポイントです。
CodeArtifact ドメイン内のリポジトリを連鎖させることで、「まず社内リポジトリを検索→なければ外部 PyPI から取得」という階層的な解決ができます。
CodeBuild から CodeArtifact を使う場合は aws codeartifact get-authorization-token でトークンを取得し、pip の設定に渡します。

4. デプロイ手法の比較 — canary/blue-green/rolling/in-place

D3 で最も問われるのが 4つのデプロイ手法の使い分け です。
判断軸は「ダウンタイム許容」「即時ロールバックの要否」「コスト」の3軸です。

In-Place（インプレース）

既存のサーバーに直接新バージョンをインストールします。
追加インフラが不要でコストは最小ですが、デプロイ中は一時的に旧バージョンが停止します。

Rolling（ローリング）

インスタンスを バッチ単位 で順次更新します。
Elastic Beanstalk では Rolling デプロイポリシーとして設定できます。
全インスタンスを同時更新しないため部分的にサービスは維持されますが、新旧バージョンが混在する期間を含みます。

Blue/Green（ブルーグリーン）

旧環境（Blue）と新環境（Green）を並列で稼働させ、ロードバランサーのトラフィックを切り替えます。

Blue/Green は「即時ロールバック」が最大のメリットです。
問題発生時に DNS またはロードバランサーの向き先を旧環境に戻すだけで復旧できます。
Lambda のトラフィック分割（後述）も Blue/Green の一形態として試験で問われます。

Canary（カナリア）

新バージョンへのトラフィックを 一部の割合（例: 10%）から開始し、問題がなければ全量へ移行します。

カナリアデプロイは CloudWatch アラームと連動した自動ロールバック が設定できます。
エラーレートが閾値を超えた際に CodeDeploy が自動で旧バージョンへ切り戻します。
これが「SLA を維持しながら新バージョンを安全に展開する」要件への回答です。

4手法の比較まとめ

5. Lambda versions & aliases によるトラフィック制御

Lambda のバージョンとエイリアスは D3 の頻出テーマです。
「コードを変更しても本番への影響をゼロにしつつ段階的にリリースする」仕組みとして機能します。

バージョン（Versions）

Lambda 関数を 発行（Publish） すると番号付きの不変スナップショット（例: arn:...:function:MyFunc:3）が作成されます。
$LATEST は常に最新の未発行コードを指す特殊バージョンです。

aws lambda publish-version コマンドでバージョンを発行します。
試験では「発行済みバージョンのコードは変更できない」という不変性が問われます。

エイリアス（Aliases）

エイリアスはバージョンへの名前付きポインタです（例: prod, staging, v3）。

prod エイリアス → バージョン 5 (90%) + バージョン 6 (10%)

エイリアスの主な特徴は次のとおりです。

トラフィック分割によるカナリアデプロイ

aws lambda update-alias \
  --function-name MyFunction \
  --name prod \
  --function-version 5 \
  --routing-config '{"AdditionalVersionWeights": {"6": 0.1}}'

この設定で prod エイリアスへのリクエストは 10% がバージョン6、90% がバージョン5に振り分けられます。
新バージョン（v6）の動作が問題なければウェイトを 100% に更新し、切り替えを完了します。

6. API Gateway ステージとステージ変数

ステージ（Stage）とデプロイメント（Deployment）

API Gateway では デプロイメント を ステージ に紐付けて公開します。
ステージは dev・staging・prod のように環境を分けるために使います。

API → デプロイメント → ステージ（dev/staging/prod）

ステージ変数（Stage Variables） は各ステージ固有の設定値を保持する Key-Value です。

# stagingステージ
TABLE_NAME: "my-table-staging"
LAMBDA_ALIAS: "staging"

# prodステージ
TABLE_NAME: "my-table-prod"
LAMBDA_ALIAS: "prod"

ステージ変数は API Gateway の統合設定内で ${stageVariables.TABLE_NAME} として参照します。
これにより 1つの API 定義で複数環境に対応 できます。試験では「同じAPIで dev/prod を切り分けるには何を使うか」という設問で問われます。

カナリアリリース（Canary Release on API Gateway）

API Gateway ステージ自体にもカナリアリリース設定があります。
ステージを更新する際に「新デプロイメントへのトラフィック割合（%）」を指定し、段階的に移行できます。

aws apigateway update-stage \
  --rest-api-id xxxx \
  --stage-name prod \
  --patch-operations \
 op=replace,path=/canarySettings/percentTraffic,value=10

問題なければ aws apigateway create-deployment で全量適用します。

スロットリング設定

ステージおよびメソッドレベルでリクエストレート（RPS）とバースト上限を設定できます。

クォータを超えたリクエストは HTTP 429 Too Many Requests が返されます。
クライアントは指数バックオフ + ジッターで再試行するのが DVA 推奨パターンです（D1 の冪等性とも連動）。

7. AppConfig による機能フラグ管理

AWS AppConfig はアプリケーションの設定と機能フラグを本番コード変更なしに動的に更新するサービスです。
DVA では「コードを再デプロイせずに機能を有効/無効にしたい」要件への回答として AppConfig を選択します。

AppConfig の概念構造

Application（アプリ）
  └── Environment（dev / prod）
  └── Configuration Profile（設定プロファイル）
  └── Deployment Strategy（デプロイ戦略）

デプロイ戦略の種類

Lambda 拡張による取得

Lambda 関数から AppConfig の最新設定を取得するには、AWS AppConfig Lambda 拡張を使います。
Lambda 拡張がサイドカーとしてローカルキャッシュ（TTL 秒）を管理するため、毎回 API を呼び出すよりも低レイテンシ・低コストで設定を参照できます。

import urllib.request

def get_config():
 url = 'http://localhost:2772/applications/MyApp/environments/prod/configurations/FeatureFlags'
 with urllib.request.urlopen(url) as response:
  return response.read()

AppConfig はデプロイ中に CloudWatch アラームを監視 し、エラーレートが上昇した場合に設定変更を自動ロールバックする機能も備えています。

8. ロールバック戦略の設計

デプロイに問題が発生したときの迅速な復旧も D3 の重要テーマです。

CloudFormation のロールバック

CloudFormation はデプロイ失敗時に自動でロールバックしますが、変更セット（Change Set） を使った事前確認でリスクを減らします。

# 変更セット作成（差分プレビュー）
aws cloudformation create-change-set \
  --stack-name my-stack \
  --change-set-name my-change-set \
  --template-body file://template.yaml

# 内容確認後に適用
aws cloudformation execute-change-set \
  --stack-name my-stack \
  --change-set-name my-change-set

ロールバックトリガー では CloudWatch アラームを指定し、スタック更新後のモニタリング期間中にアラームが発火した場合に自動でロールバックさせることができます。

CodeDeploy の自動ロールバック

CodeDeploy のデプロイグループに次の設定を追加することで、問題発生時に自動ロールバックします。

Lambda のカナリアデプロイでも同様に CloudWatch アラームと連動したロールバックが設定できます。

Elastic Beanstalk のロールバック

Elastic Beanstalk では Swap Environment URLs 機能を使って Blue/Green 環境の URL を入れ替えます。
問題発生時は再度 Swap することで旧環境へ即時切り戻しできます。

また Rolling with additional batch デプロイポリシーでは、バッチ更新が失敗した場合にそのバッチのみロールバックが発生します。

手法別ロールバック速度比較

9. Amplify / Copilot / SAMによるアプリデプロイ

SAM — サーバーレスアプリのライフサイクル管理

§2 で触れた SAM ですが、デプロイ観点でさらに重要な機能があります。

sam pipeline init コマンドは CodePipeline・CodeBuild・CodeDeploy を使った CI/CD パイプラインの設定ファイルを自動生成します。
ステージ（beta/prod 等）ごとに IAM ロールと設定を分離した構成を生成するため、セキュリティベストプラクティスに沿ったパイプラインを素早く構築できます。

SAM で定義したサーバーレスアプリケーションの SAM CLI と CodePipeline の組み合わせは DVA の標準的なサーバーレス CI/CD パターンとして押さえてください。

Amplify — フルスタックアプリのデプロイ

AWS Amplify は React・Next.js・Vue・Angular 等のフロントエンドフレームワークと AWS バックエンドを統合してデプロイするプラットフォームです。

Amplify ホスティングは ブランチ = 環境 という1対1対応が特徴です。
main ブランチへのマージで本番に自動デプロイするという GitHub Actions ライクなワークフローを AWS 完結で実現します。

Copilot — ECS アプリのデプロイ

AWS Copilot は ECS（Fargate）へのアプリデプロイを CLI で簡略化するツールです。

copilot app init my-app
copilot env init --name prod
copilot svc init --name api --svc-type "Load Balanced Web Service"
copilot svc deploy --env prod

Copilot のサービスタイプは試験で問われることがあります。

Copilot は内部的に CloudFormation スタックを生成するため、既存の IaC パイプラインとも統合できます。

10. CertTrend LMS で400問チェック

DVA-C02 D3「デプロイ」は試験問題数が97問と多く、CodeDeploy の設定・Lambda バージョン/エイリアス・デプロイ手法の使い分けは毎回複数問出題されます。
概念理解だけでなく 問題文の状況から最適解を選ぶ練習 が合否を分けます。

11. 実務で深掘り — D3デプロイの本番運用記事

試験対策で習得した CI/CD・デプロイ設計を実務レベルに引き上げるための本番運用解説記事です。