AWS CodeDeploy

AWS CodeDeploy は、アプリケーションの新しいバージョンを実行環境へ配布し、本番トラフィックを安全に切り替えるまでの一連の手順を自動化するマネージドサービスです。配布先として EC2 インスタンスやオンプレミスのサーバー、Amazon ECS、AWS Lambda をサポートし、いずれも共通のデプロイ概念で扱える点が特徴です。

解決する課題

アプリケーションの更新は、新しい成果物を各サーバーへ配り、サービスを止め、入れ替え、起動して動作確認する、という多段の手順から成ります。これを手作業や場当たりのスクリプトで行うと、台数が増えるほど抜け漏れや順序ミスが起きやすく、更新中のダウンタイムや、不具合時の切り戻しの遅れが障害につながります。

CodeDeploy はこのデプロイ工程を宣言的に定義し、複数のインスタンスやコンテナ、関数バージョンに対して順序立てて自動適用します。トラフィックを一度に切り替えるのではなく段階的に移行させ、ヘルスチェックやアラームで異常を検知したら自動的に切り戻すことで、更新に伴うリスクを抑えながら配布の信頼性と再現性を高められます。

主要概念と用語

• アプリケーション: デプロイ対象をまとめる論理的な入れ物。EC2 とオンプレ、ECS、Lambda のいずれを対象にするかを示すコンピューティングプラットフォームを持つ。
• デプロイグループ: 実際にデプロイを行う対象の集合。EC2 ならタグや Auto Scaling グループで対象を特定し、ECS や Lambda なら対象のサービスや関数を指定する。
• デプロイ設定: トラフィックをどのくらいの速さ・割合で切り替えるかを定義したルール。一度に全切り替え、線形（一定割合ずつ）、カナリア（最初に少量、残りを後でまとめて）などがある。
• リビジョン: デプロイするアプリケーションの特定バージョン。EC2 やオンプレでは S3 または GitHub 上の成果物、ECS や Lambda では対象定義を指す。
• AppSpec ファイル: デプロイ手順を記述する宣言ファイル。EC2 やオンプレでは配置先やライフサイクルフックで実行するスクリプトを、ECS や Lambda では対象や切り替え方法を定義する。
• ライフサイクルフック: デプロイの各段階（停止前、インストール後、トラフィック許可後など）で任意のスクリプトを実行できる仕掛け。
• CodeDeploy エージェント: EC2 やオンプレのサーバー上で動作し、指示を受けて成果物の配置とフックの実行を担う常駐プロセス。ECS と Lambda では不要。

仕様・制限・クォータ

• 対応するコンピューティングプラットフォームは EC2 とオンプレミスのサーバー、Amazon ECS、AWS Lambda の 3 系統で、それぞれデプロイの仕組みやサポートする方式が異なる。
• EC2 とオンプレへのデプロイにはサーバー上で動く CodeDeploy エージェントが必須。一方、ECS と Lambda はコントロールプレーン側で切り替えるためエージェントは不要。
• EC2 やオンプレでは成果物を S3 または GitHub から取得し、AppSpec はファイル配置やフックの実行手順を記述する。ECS と Lambda の AppSpec は切り替え対象や移行方法を指定する内容になる。
• 同時実行できるデプロイ数やアプリケーション数などにはアカウント・リージョン単位の上限（クォータ）がある。具体的な数値はリージョンや時期で変わり得るため、最新値はサービスクォータの管理画面で確認するのが確実。
• CodeDeploy のサービス利用自体は無料で、課金は連携する S3 のストレージや EC2、データ転送など実際に使ったリソースに対して発生する（プラットフォームにより無料の範囲が異なる）。

内部の仕組み

EC2 やオンプレへのインプレースデプロイでは、各サーバー上の CodeDeploy エージェントが新しいリビジョンを取得し、AppSpec に記述されたライフサイクルフックを順番に実行します。たとえば既存プロセスの停止、成果物の配置、依存関係のインストール、サービスの起動、ヘルスチェック、といった段階ごとにスクリプトを差し込めるため、停止と入れ替えの手順をきめ細かく制御できます。デプロイ設定に従って一度に更新するインスタンス数を制限することで、全台が同時に落ちる事態を避けられます。

Blue/Green デプロイでは、現行（Blue）とは別に新バージョン用の環境（Green）を用意し、ヘルスチェックに合格した Green へトラフィックを切り替えます。EC2 では新しいインスタンス群を立ち上げてロードバランサーの向き先を入れ替え、ECS では新しいタスクセットを起動してリスナーのルーティングを移し、Lambda ではエイリアスが指す関数バージョンの重みを変えることで実現します。ECS と Lambda では、線形やカナリアといったデプロイ設定により、トラフィックの一部だけを新バージョンへ流して様子を見てから残りを移す段階移行が行えます。切り替え後も一定時間は旧環境を保持できるため、問題があれば素早く元へ戻せます。

設計パターン / ベストプラクティス

• 本番の切り替えは Blue/Green を基本とする。新環境で十分に検証してから切り替えれば、問題発生時に旧環境へ即座に戻せるため、インプレース方式よりダウンタイムと切り戻しリスクを下げられる。
• ECS や Lambda ではカナリアや線形のデプロイ設定を選び、まず少量のトラフィックで新バージョンを検証してから全面展開する。
• CloudWatch アラームをデプロイグループに関連付け、エラー率やレイテンシの悪化を検知したら自動ロールバックが走るように構成する。
• AppSpec のライフサイクルフックでデプロイ後のスモークテストや検証用 Lambda（ECS や Lambda の場合）を実行し、トラフィックを本格的に流す前に健全性を確かめる。
• パイプライン（ソース取得、ビルド、デプロイ）の最終段として CodeDeploy を組み込み、成果物のビルドからデプロイまでを一貫して自動化する。

運用・監視

デプロイの進行状況は CodeDeploy のコンソールや API で確認でき、各インスタンスやフックの成功・失敗、全体のステータスを追跡できます。デプロイの開始・成功・失敗といったイベントは通知として送れるため、SNS と連携してチームへ知らせたり、EventBridge 経由で後続処理を起動したりできます。

EC2 やオンプレではエージェントのログ、ECS や Lambda では対象サービス側のログとメトリクスが状況把握の中心になります。デプロイグループに CloudWatch アラームを紐づけておくと、デプロイ中またはデプロイ後の指標悪化を検知して自動ロールバックの判断材料にできます。失敗時にどう振る舞うか（自動で切り戻すか、停止して人が判断するか）を明確に設定しておくことが安定運用の鍵です。

コスト

CodeDeploy のサービス利用そのものに対する課金体系はプラットフォームによって異なり、基本的なデプロイ機能は追加料金なしで利用できる範囲が広いのが特徴です。費用が発生するのは主に、デプロイに使う成果物を保管する S3 のストレージや、デプロイ対象となる EC2 インスタンス、データ転送など、連携する実リソースに対してです。

コストを抑えるには、不要になった古いリビジョンを S3 に溜め込まないようライフサイクルで整理する、Blue/Green で一時的に倍増するインスタンスを切り替え後すみやかに終了させる、といった一般的な最適化が有効です。具体的な料金はリージョンや構成、連携サービスによって変わるため、見積もりは料金計算ツールで確認してください。

セキュリティ

CodeDeploy の権限は IAM で制御します。CodeDeploy 自身が対象リソースを操作するためのサービスロールと、EC2 やオンプレのサーバーが S3 などから成果物を取得するためのインスタンス側のロールがあり、いずれも最小権限の原則に従って必要な権限だけを付与します。デプロイを誰がどのアプリケーションやデプロイグループに対して実行できるかも、IAM ポリシーで限定するのが基本です。

成果物を置く S3 バケットは暗号化とアクセス制御を施し、デプロイ中に扱う機密情報はソースや AppSpec に平文で埋め込まず、パラメータストアやシークレット管理サービスから取得する設計が望ましいです。オンプレミスのサーバーを対象にする場合は、エージェントに渡す認証情報の管理と、サーバー登録時の権限範囲に特に注意します。

Well-Architected の観点

運用上の優秀性の観点では、デプロイ手順を AppSpec としてコード化し、複数環境へ再現性高く適用できる点が強みです。デプロイの状態が可視化され、SNS や EventBridge と連携して通知・自動化できるため、リリース運用の負荷とヒューマンエラーを下げられます。

信頼性の面では、段階的なトラフィック移行とヘルスチェック、CloudWatch アラーム連動の自動ロールバックにより、更新が原因の障害を早期に封じ込められます。Blue/Green と複数アベイラビリティーゾーン構成を組み合わせれば、切り替え時もサービス継続性を保ちやすくなります。セキュリティは IAM の最小権限とシークレット管理で、コスト最適化は古いリビジョンの整理と一時リソースの早期解放で担保します。

試験で問われるポイント

関連サービス・比較

混同されやすいのが、コードをアップロードするだけで実行環境一式を自動構成する Elastic Beanstalk との違いです。CodeDeploy は既存のインフラに対してデプロイと安全な切り替えだけを担う専用サービスであり、インフラそのものを生成・管理する Elastic Beanstalk とは役割が異なります。

ハンズオン / CLI例

以下は、アプリケーションとデプロイグループを作成し、S3 に置いたリビジョンをデプロイする基本的な流れの例です。実際の値（ロール名やバケット名など）は環境に合わせて置き換えてください。

# アプリケーションを作成（EC2/オンプレ向け）
aws deploy create-application \
  --application-name my-app \
  --compute-platform Server

# デプロイグループを作成（対象をタグで特定し、サービスロールを指定）
aws deploy create-deployment-group \
  --application-name my-app \
  --deployment-group-name prod \
  --service-role-arn arn:aws:iam::123456789012:role/CodeDeployServiceRole \
  --ec2-tag-filters Key=Env,Value=prod,Type=KEY_AND_VALUE \
  --deployment-config-name CodeDeployDefault.OneAtATime

# S3 上のリビジョンをデプロイ
aws deploy create-deployment \
  --application-name my-app \
  --deployment-group-name prod \
  --s3-location bucket=my-artifacts,key=my-app.zip,bundleType=zip

# デプロイの進行状況を確認
aws deploy get-deployment --deployment-id d-XXXXXXXXX \
  --query "deploymentInfo.{Status:status,Config:deploymentConfigName}"