Amazon DVA-C02: デプロイと CI/CD (CodePipeline, CodeBuild, CodeDeploy, Elastic Beanstalk, Containers) — 学習ガイド

By Laurynas Brazys · 28 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Developer Associate DVA-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

CodePipelineとCodeBuildによるCI/CDの基礎: パターン、API、そしてよくある落とし穴

パイプラインは、ソース、ビルド、テスト、承認、デプロイ、デプロイ後検証といった明確なステージで設計します。CodePipelineはこれらのステージを調整します。最小限のスコープ付き権限を付与するパイプラインロールを使用し、サードパーティ統合のためにはアクションロールを設定します。パイプラインは、CodeCommitのwebhookや、プログラムによる起動のためのStartPipelineExecution (AWS SDK: codepipeline.startPipelineExecution) を介してトリガーします。ビルドには、フェーズ (install, pre_build, build, post_build) を定義するbuildspec.ymlを持つCodeBuildプロジェクトの使用を推奨します。アドホックビルドやバッチビルドが必要な場合は、StartBuildまたはStartBuildBatchで直接ビルドを呼び出します。イメージビルドでは、pre_buildフェーズでaws ecr get-login-passwordをdocker loginにパイプし、その後ECRにdocker build/pushを行い、イメージダイジェストをキャプチャして不変のアーティファクト参照を生成します。「latest」のようなフローティングタグの使用は避けてください。代わりに、デプロイが決定論的になるように、イメージダイジェストを参照するタスク定義やマニフェストファイルを出力します。よくある落とし穴に注意してください: 長時間実行されるスクリプトでのECR認証トークンの期限切れ、ECRへのプッシュやAWS API呼び出しに対するCodeBuildのIAMポリシーの権限不足、ARNのハードコーディングなどです。ビルドを計装してアーティファクトをS3またはパイプラインのアーティファクトストアにアップロードし、機密性の高い実行時のみの値には、ビルドアーティファクトにシークレットを焼き込むのではなく、環境変数やParameter Store/Secrets Managerを使用します。

デプロイ戦略: CodeDeploy、Lambdaエイリアス、Elastic Beanstalkの設定選択肢

リスク許容度とロールバックのニーズに合ったデプロイモデルを選択します。Lambdaでは、バージョンとエイリアスを使用します。バージョンを公開し (lambda.publishVersion)、Lambdaアプリケーションとデプロイメントグループを参照するデプロイを作成 (codedeploy.createDeployment) することで、CodeDeployを介してトラフィックシフトのルールでエイリアスを更新します。CodeDeployDefault.LambdaCanary10Percent5MinutesのようなCodeDeployの組み込み設定や、正確なカナリアまたはリニアシフトのためのカスタムトラフィックルーティングを使用します。EC2およびオンプレミスのアプリでは、CodeDeployは、トラフィック前の検証のためのライフサイクルフックと、ヘルスチェック失敗時の自動ロールバックを備えたブルー/グリーンをサポートします。Elastic Beanstalkは複数のポリシーを提供します: All at Once (高速だがリスキー)、Rolling、Rolling with Additional Batch (より安全)、Immutable (最も安全) です。これらは、eb deployまたはupdate-environment APIでDeploymentPolicyとOptionSettingsを指定して変更します。開発者が陥りがちな罠には、自動的なトラフィック切り替えを妨げるアプリケーションヘルスチェック (ALBターゲットグループのヘルス、EBのヘルスレポート) の設定忘れや、CodeDeployがLambdaを呼び出したりECSを更新したりするためのIAM権限の不足などがあります。データベースを利用するリリースでは、コードとスキーマを同じトランザクションで結合させないように、後方互換性のあるスキーマ変更やデプロイ前のフィーチャートグルを検討してください。

コンテナパイプライン、ECR、ECS/Fargate、EKS: ビルド、デプロイ、不変参照

堅牢なコンテナパイプラインは、CodeBuildでイメージをビルドし、ECRにプッシュし、ECS、Fargate、またはEKSへのデプロイをトリガーします。CodeBuildで、aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com を実行し、次に docker build -t repo:tag .、docker push を行い、docker inspect –format=’{{index .RepoDigests 0}}’ image を介してイメージダイジェストをキャプチャします。ECS/Fargateでは、containerDefinitionsにイメージダイジェストを含む新しいタスク定義を登録し (ecs.registerTaskDefinition)、次にサービスを更新して (ecs.updateService) 新しいタスク定義を使用するか、forceNewDeploymentを設定して置換をトリガーします。ALBレベルでのトラフィックシフトを伴うECSのブルー/グリーンデプロイにはCodeDeployを使用します。EKSでは、Kubernetesマニフェストを更新してイメージダイジェストを参照し、kubectl set imageを適用するか、宣言的なGitOpsツールを使用します。CodeBuildはaws eks update-kubeconfigやkubectlコマンドを実行できます。典型的な落とし穴: 古いデプロイを引き起こすミュータブルなタグの使用、ECSが新しいイメージをデプロイできなくなるタスク定義の更新忘れ、FargateタスクのCPU/メモリまたはENI制限の不足、プッシュされたイメージを読み取るためのecr:BatchGetImage権限をCodeBuildに付与し忘れることなどです。

デプロイ前の検証、ロールバック、可観測性：テスト、フック、および運用のセーフガード

自動化された単体テスト、統合テスト、スモークテストをパイプラインのステージに統合します。CodeBuildを使用してテストを実行し、トレースと構造化ログにはAWS X-RayまたはCloudWatch Logsを使用します。SDKのPutAnnotationでX-Rayトレースにアノテーションを付け、後続のクエリでユーザーやリクエスト属性によるフィルタリングを可能にします。デプロイ前には、CodePipelineの手動承認アクションや自動検証ステップを利用します。CodeBuild経由でデプロイされたエンドポイントをテストするカナリアチェックを実行するか、CloudWatch SyntheticsのCanaryを呼び出してスクリプト化された検証を実行します。CodeDeployのライフサイクルフック（BeforeAllowTraffic、AfterAllowTraffic）を使用して、ヘルスチェックや登録/登録解除ロジックを実行します。自動ロールバックトリガーを実装します。CodeDeployを設定して、デプロイステータスがゼロ以外の場合やアラームが失敗した場合（デプロイグループにアタッチされたCloudWatchアラーム）にロールバックするようにします。また、Lambdaの場合は、エイリアスを以前のバージョンを指すように更新することで迅速なロールバックを可能にするため、トラフィックシフトを伴うエイリアスを使用します。開発者が陥りやすい罠には、タイムアウトの不一致（LambdaのタイムアウトがSQSの可視性タイムアウトより短い）、ECS/CodeDeploy用のAppSpecフックの正しい設定忘れ、ランタイムの動作を検証せずにデプロイAPIコールの成功に依存することなどがあります。デプロイメントをメトリクスとアラートで計測し、トレーサビリティのためにアーティファクトにイミュータブルな識別子を使用します。

実践的な問題：ユースケースシナリオ

シナリオ：ExampleRetail社は、開発/テスト/本番アカウントにまたがって、AWSでマイクロサービスのストアフロントを運営しています。ソース管理にCodeCommit、CIにCodePipeline/CodeBuild、イメージにECR、ALBの背後にあるサービスにECS/Fargate、非同期ワーカーにLambdaを使用しています。

課題：開発者は、カナリアトラフィックシフトと、失敗時にロールバックする自動化されたデプロイ前検証を備えた、新しいチェックアウトサービスコンテナをデプロイするための、安全で自動化されたパイプラインを追加する必要があります。

推奨アプローチ：

Dockerイメージをビルドし、単体テストを実行し、ECRにログインし（aws ecr get-login-password | docker login –username AWS –password-stdin ${ACCOUNT}.dkr.ecr.${REGION}.amazonaws.com）、イメージをプッシュし、イメージダイジェストを含むJSONアーティファクトを出力するCodeBuildプロジェクトを作成します。
CodePipelineで、イメージダイジェストを参照してecs.registerTaskDefinition経由で新しいECSタスク定義を登録し、次に新しいタスク定義とカナリア用に設定されたdeploymentConfig（例：CodeDeployDefault.ECSCanary10Percent5Minutes）をバインドするAppSpecを使用してcodedeploy.createDeploymentを呼び出すことでCodeDeploy ECSデプロイメントを作成する、デプロイステージを追加します。
デプロイ後のテストとして、重要なチェックアウトエンドポイントを呼び出してレスポンスを検証する、CodeBuildベースの検証アクションまたはCloudWatch SyntheticsのCanaryを追加します。パイプラインが検証の成功を待つようにします。
CodeDeployのロールバックオプションと、デプロイグループに関連付けられたCloudWatchアラーム（例：5xxエラー率やレイテンシー）を設定し、しきい値を超えた場合に自動的に中止およびロールバックするようにします。

理由：イミュータブルなイメージをビルドし、明示的なイメージダイジェストでタスク定義を登録し、CodeDeployのトラフィックシフトと自動検証を併用することで、デプロイの再現性と可観測性を確保しつつ、安全なカナリアリリースと迅速で自動化されたロールバックを実現します。

← CloudFormation と Infrastructure as Code (SAM · すべてのドメイン · セキュリティ、IAM、KMS とシークレット管理 (Cognito →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →