はじめに

この記事は Japan AWS Top Engineers Advent Calendar 2025 の 3 日目の記事です。

先日の記事ではシステムを構成するアセットを管理する AWS CodeCommit について投稿しましたが、今回は作成されたソースコードやシステム構成をデプロイする際に利用されるCodeDeployについて投稿します。

↓ Japan AWS Top Engineers Advent Calendar 2025 はこちら

↓前回の AWS CodeCommitの記事

↓ この記事の海外向け版はこちら

AWS CodeDeploy とは

CodeDeployはAmazonEC2やLambdaなどのAWSサービスのデプロイを自動化するサービスです。
AWS CodeDeployを利用することにより、より安全なデプロイを可能にするため、段階的にデプロイするカナリアデプロイやブルーグリーンデプロイのようなデプロイ戦略の実現が容易になります。

デプロイ戦略例

ブルーグリーンデプロイ

既存バージョンと新バージョンを同時に稼働させます。
新バージョンに100％のトラフィックを流しながら、新バージョンで動作確認を行い、新バージョンに問題がなければ100％のトラフィックを新バージョンに流れるように設定します。
新バージョンの稼働を一定時間監視し、問題があれば既存バージョンにトラフィックを戻し、問題がなければ既存バージョンを廃止します。
素早いロールバックができますが、新バージョンの不具合があった際は一時的に100%のトラフィックに影響してしまうことが特徴になります。

カナリアデプロイ

ブルーグリーンデプロイと似たデプロイですが、100%でのトラフィック切り替えをせず、10%ずつなど一定の比率で徐々にトラフィックを移行します。
新バージョンの不具合があった際の影響範囲が限定できますが、デプロイ完了(100％のトラフィックが新バージョンに移行する)までに比較的時間がかかることが特徴です。
例：1分間に10％ずつトラフィックを移すと、合計10分必要

リニアデプロイ

こちらもブルーグリーンデプロイと似たデプロイですが、まず初回は10%などのごく一部のトラフィックを新バージョンに移行し、一定時間に問題発見されなければ残りの90パーセントも新バージョンに移行する方法です。
新バージョンの不具合の影響範囲が限定でき、デプロイ完了もリニアデプロイと比較して早くできます。その反面、最初の新バージョンの検証がごく一部のトラフィックになってしまうため、発生確率の低い特殊なトラフィックのパターンなどで不具合の発生を見逃す可能性があることが特徴です。

↓AIにイメージ図を描いてもらったらこんな感じの絵を出してくれました

AWS CodeDeploy の構成要素

アプリケーション

設定例

AAWS CodeDeployのコンソール画面の左メニューで「アプリケーション」を選択します。
アプリケーションの作成を選択してアプリケーション作成画面を表示します。

アプリケーション作成時には、アプリケーション名とコンピューティングプラットフォームを設定します。
アプリケーションプラットフォームは「EC2/オンプレミス」「AWS Lambda」「Amazon ECS」から選択できます。

デプロイグループ

設定例

アプリケーションを作成した後は、それに紐づけるデプロイグループを作成します

デプロイグループ作成時にはデプロイグループ名とサービスロール、デプロイ設定を設定します。
サービスロールでは事前に作成したロールを選択しますが、デプロイ対象となるサービスに関する操作権限を持つロールを選択します。

デプロイ設定では作成済みの設定である「AllAtOnce」や、既定のパーセンテージで実行されるリニアデプロイやカナリアデプロイを選択できます。
※今回は1分ごとに10パーセントずつ新バージョンにトラフィックを移すリニアデプロイを選択しました。

選択肢のパーセンテージの選択肢に適切なものがない場合はデプロイ設定の作成で詳細なデプロイ方法(どの感覚のどの比率でデプロイを進めるか)を設定できます

詳細設定はオプションですが、アラーム設定やロールバックの有無などが設定可能です
デプロイ中に更新されたLambda関数がエラーを発生させた場合にロールバックしたい場合などはこれを設定します。
例えば、Lambda関数のエラーが発生した際にCloudWatchアラームが発生するようにアラーム設定を行い、そのアラームをこのデプロイグループの画面のアラームに設定します。

デプロイメント

デプロイについてはAWSコンソールでのデプロイでも行えますが、実際の現場ではIaCコードを使ってデプロイする際にデプロイ戦略を実現する方法がよく採用されます。
AWSコンソールでのデプロイの設定とIaCコードでのデプロイ設定について解説します。

AWSコンソールでのデプロイ

デプロイ対象のLambda関数の作成

デプロイ対象となるLambda関数と、新バージョンとなるエイリアスの作成を行います。
既存バージョンとして作成したLambda関数は「Hello from Lambda!」とメッセージを返すだけの関数になっています。

Lambda関数のバージョンの作成

現在のLambda関数のバージョンを作成します。

※少し事前に試していたのでバージョンが「3」になっています

エイリアスの作成

バージョンごとのトラフィックを制御するエイリアスを作成します。

Lambda関数の更新

コードを更新した後にこのバージョンを新しく作成します
コードはメッセージを「Hello from Lambda V2!」としています

新バージョン作成

新しいバージョンを作成しました(一度検証外で試したのでバージョンが5になっています)

CodeDeployを使ったデプロイの実行

すでに作成しているデプロイグループの詳細画面で「デプロイの作成」を行います。

デプロイグループのロール
今回はLambdaを扱うデプロイを行うため、デプロイグループにLambda操作に関するポリシーを追加します
↓このロールにLambdaを操作するポリシーを追加する

デプロイ設定の入力欄にはLambda関数の名前とエイリアス名、トラフィックを移行するLambda関数の現行バージョンと新バージョンを指定します。
今回の例ではLambda関数のバージョンを3から5にバージョンアップさせる際のトラフィックを段階的に移行させます。

↓今回の設定内容

version: 0.0
Resources:
  - myLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "qiita-naolambda-2025"
        Alias: "qiitaLambdaDeployTest"
        CurrentVersion: "3"
        TargetVersion: "5"

デプロイが実行されるタイミング
AWSコンソールからの操作では、デプロイの作成を実行したと同時にデプロイが開始されます。

AWS CodeDeployの画面でデプロイの進捗を確認できます。今回はデプロイグループで1分ごとに10％ずつトラフィックが映るように設定したので、その設定どおりに進捗していることが確認できます。

この時にAWS Lambdaのエイリアスの画面でも、各バージョンにトラフィックが分散していることを確認できます。

最後までデプロイが進むと新バージョンに全てのトラフィックが割り当てられ、デプロイ完了になります。

IaCコードでのデプロイ

AWSコンソールからCodeDeployを使用してデプロイは可能ですがIaCコードにデプロイ設定を記載することもできます。
システム運用の実際の現場ではIaCコードでの構成管理やCI/CDを活用することによりシステム構成の反映とデプロイ戦略の実行を自動化していることが多いです。
私の過去の記事ではCDKとCodeDeployを利用したデプロイ戦略の実現についても記載しているので、そちらもご覧下さい。
※時間があればこの記事にも改めて追記します。

↓過去のデプロイ戦略の記事

#さいごに
AWS CodeDeployにより段階的なデプロイと、問題が発生した時の素早い自動ロールバックが容易になります。
どのデプロイ戦略が適切かはプロジェクトによって異なりますが、どのデプロイ戦略でも対応できるようにAWSCodeDeployの利用方法を学んでみてください。

参考

↓ AWS CodeDeploy の公式ドキュメント

↓ AWS CodeDeploy のBlackBelt資料(日本語)