AWS CodeDeploy vs Elastic Beanstalk：徹底比較ガイド

このブログはこんな人向け

本番環境でのデプロイ戦略を設計する方
ゼロダウンタイムデプロイを実現したい方
デプロイの自動化とCI/CDパイプラインを構築する方
複数のデプロイサービスから最適解を選びたい方
高可用性と障害復旧を考慮したアーキテクチャを設計する方

この記事で得られること

本番環境におけるデプロイ戦略の使い分け（Blue/Green、Canary、Rolling、Immutable）
デプロイ失敗時の自動ロールバック設定のベストプラクティス
CloudWatchとの統合によるモニタリング設計
トラフィックシフティングとヘルスチェックの設定方法
IAMロールとセキュリティ設定の違い
大規模運用時のトラブルシューティング手法

目次

はじめに
サービスの基本的な違い
詳細比較：機能と特徴
選択基準：どちらを使うべきか
まとめ
参考リンク

1. はじめに

AWS CodeDeployとElastic Beanstalkは、どちらもアプリケーションのデプロイに使用されるAWSサービスですが、その役割と設計思想は大きく異なります。

このブログでは、両サービスの違いを徹底的に比較し、プロジェクトに最適な選択ができるようにガイドします。

最も重要な違い

Elastic Beanstalk：

PaaS（Platform as a Service）
インフラ全体を管理してくれる
アプリをアップロードするだけでデプロイ完了

CodeDeploy：

デプロイ専用ツール
既存のインフラにアプリをデプロイする
インフラは別途用意する必要がある

2. サービスの基本的な違い

CodeDeployとは

ひとことで: 「既存のインフラにアプリケーションをデプロイする専門ツール」

役割

デプロイのみに特化したサービス
インフラ（EC2、Lambda、ECS）は自分で用意する
デプロイ戦略（ブルー/グリーン、ローリングなど）を柔軟に選択可能

主な特徴

┌─────────────────────────────────────┐
│      既存のインフラ（自分で管理）      │
│  ┌──────┐  ┌──────┐  ┌──────┐       │
│  │ EC2  │  │ EC2  │  │ EC2  │       │
│  └──────┘  └──────┘  └──────┘       │
│       ↑        ↑        ↑           │
│       │        │        │           │
│       └────────┴────────┘           │
│              │                      │
│         CodeDeploy                  │
│      （デプロイのみ実行）             │
└─────────────────────────────────────┘

Elastic Beanstalkとは

ひとことで: 「インフラ構築からデプロイまで全部やってくれるPaaS」

役割

フルマネージドなアプリケーション実行環境
インフラ（EC2、ELB、Auto Scaling）を自動構築
デプロイ、スケーリング、監視をすべて管理

主な特徴

┌─────────────────────────────────────┐
│      Elastic Beanstalk              │
│    （すべてを自動管理）               │
│  ┌──────────────────────────────┐   │
│  │  ELB（自動作成）              │   │
│  └──────────────────────────────┘   │
│  ┌──────┐  ┌──────┐  ┌──────┐       │
│  │ EC2  │  │ EC2  │  │ EC2  │       │
│  │(自動)│  │(自動) │  │(自動)│       │
│  └──────┘  └──────┘  └──────┘       │
│  ┌──────────────────────────────┐   │
│  │  Auto Scaling（自動設定）     │   │
│  └──────────────────────────────┘   │
└─────────────────────────────────────┘

3. 詳細比較：機能と特徴

3-1. 基本的な違い

項目	CodeDeploy	Elastic Beanstalk
サービス分類	デプロイツール	PaaS（Platform as a Service）
インフラ管理	❌ 自分で管理	✅ 自動構築・管理
学習曲線	中程度	初心者向け
柔軟性	高い（自由に構成可能）	中程度（制約あり）
初期セットアップ	複雑（EC2、IAM、LBなど手動）	簡単（アプリアップロードのみ）

3-2. デプロイ戦略の詳細比較

デプロイ戦略マトリクス

デプロイ戦略	CodeDeploy	Elastic Beanstalk	本番推奨度	ダウンタイム	ロールバック速度
In-Place（ローリング）	✅ 対応	✅ 対応	⭐⭐⭐	無	中
Blue/Green	✅ 対応（ネイティブ）	✅ 対応（環境スワップ）	⭐⭐⭐⭐⭐	無	高速
Canary	✅ 対応（10%/50%など）	⚠️ Traffic Splitting（限定的）	⭐⭐⭐⭐⭐	無	高速
Linear	✅ 対応（10%ずつなど）	❌ 非対応	⭐⭐⭐⭐	無	中
All-at-once	✅ 対応	✅ 対応	⭐	有	高速
Immutable	❌ 非対応	✅ 対応	⭐⭐⭐⭐	無	中

CodeDeployのデプロイ設定（Deployment Configuration）

本番環境で利用される主要なデプロイ設定：

EC2/オンプレミス向け

OneAtATime: 1台ずつデプロイ（最も安全、時間かかる）- リスク最小、速度最遅、少数のインスタンスやクリティカルなシステムに推奨
HalfAtATime: 半数ずつデプロイ - リスク中、速度中、バランス重視
AllAtOnce: 全インスタンス同時デプロイ - リスク高（本番非推奨）、速度最速、開発環境専用
カスタム設定: MinimumHealthyHostsで稼働維持するインスタンスの割合を指定可能（例：75%）

Lambda向けトラフィックシフティング

Canary10Percent5Minutes: 10%のトラフィックを5分間新バージョンに流し、問題なければ残り90%を切り替え
Canary10Percent30Minutes: より慎重な本番デプロイに推奨
Linear10PercentEvery10Minutes: 10分ごとに10%ずつトラフィックをシフト、合計100分で完全移行
AllAtOnce: 開発環境専用（本番では非推奨）

Beanstalkのデプロイポリシー

Rolling: バッチごとに更新、バッチサイズを指定可能
Rolling with additional batch: 追加インスタンスを起動してキャパシティを維持しながらデプロイ（本番推奨）
Immutable: 全インスタンスを新規作成、最も安全だがコストが一時的に2倍
Traffic splitting: カナリアデプロイ、トラフィックの割合と評価時間を設定可能

3-3. デプロイ対象

デプロイ先	CodeDeploy	Elastic Beanstalk
EC2	✅ 対応	✅ 対応（自動構築）
Lambda	✅ 対応（トラフィックシフト）	❌ 非対応
ECS（コンテナ）	✅ 対応	✅ 対応（Dockerプラットフォーム）
オンプレミス	✅ 対応	❌ 非対応
複数リージョン	✅ 対応（手動設定）	❌ リージョンごとに別環境

3-4. インフラ管理とIAM設定

IAMロール設計（本番環境での推奨構成）

CodeDeployで必要なIAMロール

CodeDeployサービスロール: CodeDeployサービスがAWSリソースにアクセスするために必要
- AWSCodeDeployRole（EC2/オンプレミス用）
- AWSCodeDeployRoleForLambda（Lambda用）
- AWSCodeDeployRoleForECS（ECS用）
EC2インスタンスロール（重要）: デプロイ先のEC2インスタンスに必要
- S3からデプロイアーティファクトを取得する権限（s3:GetObject、s3:ListBucket）
- CloudWatchにメトリクスとログを送信する権限

Beanstalkで必要なIAMロール

Beanstalkサービスロール: Beanstalkがリソースを管理するために必要
- AWSElasticBeanstalkEnhancedHealth
- AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy
EC2インスタンスプロファイル: 自動でアタッチされる
- AWSElasticBeanstalkWebTier（Web環境）
- AWSElasticBeanstalkWorkerTier（Worker環境）
- AWSElasticBeanstalkMulticontainerDocker（Docker）
- 必要に応じてカスタムポリシーを追加（DynamoDB、S3、SQSなど）

インフラ管理比較表

機能	CodeDeploy	Elastic Beanstalk
EC2プロビジョニング	❌ Terraform/CFnで管理	✅ 自動（Launch Template使用可）
ロードバランサー設定	❌ 手動（ALB推奨）	✅ 自動（ALB/NLB/CLB選択可）
Auto Scaling設定	❌ 手動設定	✅ 自動（時刻ベース/メトリクスベース）
IAMロール管理	⚠️ Service Role + Instance Role	✅ 自動作成（カスタマイズ可）
セキュリティグループ	❌ 手動設計	✅ 自動作成（カスタマイズ推奨）
VPC設定	❌ 事前準備必要	✅ 既存VPC/サブネット指定
RDS統合	❌ 環境変数で接続情報管理	✅ 環境プロパティで統合
インスタンスプロファイル	⚠️ 必須（手動アタッチ）	✅ 自動アタッチ

3-5. 監視とロギング戦略

本番環境でのモニタリング設計

CodeDeployのモニタリング

監視すべき主要メトリクス：

デプロイメトリクス: DeploymentId、DeploymentGroupName、InstanceCount
ステータスメトリクス: Succeeded、Failed、Stopped、Ready
ライフサイクルイベント: ApplicationStop、BeforeInstall、AfterInstall、ApplicationStart、ValidateService
CloudWatch Logs統合: ログの保持期間設定（推奨30日以上）
SNS通知設定: デプロイ成功/失敗時の通知

実践的なアラート設定のポイント

デプロイ失敗率の監視（閾値：20%以上）
Lambda関数のエラー率監視（Canaryデプロイ用、閾値：5%以上）
レイテンシとCPU使用率の監視

Beanstalkの拡張ヘルスレポート

主要な設定項目：

拡張ヘルスレポート: 5つのヘルス要素（リクエスト、CPU、ロードバランサー、アプリケーション、インスタンス）を監視
CloudWatch Logs統合: ログの自動ストリーミングと保持期間設定
カスタムメトリクス: アプリケーション固有のメトリクスを追加可能
ヘルスチェックエンドポイント: DB接続、外部API接続、メモリ使用率などをチェック

監視比較表

機能	CodeDeploy	Elastic Beanstalk
リアルタイム監視	✅ CloudWatch統合	✅ コンソールダッシュボード
デプロイライフサイクル追跡	✅ 詳細なイベントログ	⚠️ 概要レベル
アプリケーションログ	⚠️ 別途設定必須	✅ 自動収集
拡張ヘルスチェック	❌ ELBに依存	✅ 5つのヘルス要素
CloudWatchアラーム連携	✅ 自動ロールバック可能	⚠️ 通知のみ
X-Ray統合	⚠️ 手動設定	✅ 簡単に有効化
カスタムメトリクス	✅ 自由に設定	✅ .ebextensionsで設定

3-6. ロールバックと障害対策

自動ロールバックの詳細設定

CodeDeployの自動ロールバック条件

デプロイグループ設定で以下のイベントを指定可能：

DEPLOYMENT_FAILURE: デプロイ失敗時に自動ロールバック
DEPLOYMENT_STOP_ON_ALARM: CloudWatchアラーム発火時に自動ロールバック（重要）
DEPLOYMENT_STOP_ON_REQUEST: 手動停止時に自動ロールバック

CloudWatchアラーム連携のポイント

エラー率監視（HighErrorRate）
レイテンシ監視（HighLatency）
CPU使用率監視（CPU_Utilization）
ignorePollAlarmFailureをfalseに設定すると、アラームの取得失敗時もデプロイを停止

Beanstalkのロールバック設定

主要な設定項目：

デプロイポリシー: RollingWithAdditionalBatch推奨（キャパシティ維持）
バッチサイズ: 一度に更新するインスタンス数
タイムアウト: デプロイの最大待機時間（推奨600秒）
ヘルスチェック: 必須、IgnoreHealthCheckはfalseに設定
拡張ヘルスレポート: SystemTypeをenhancedに設定
ヘルスチェック詳細: パス、間隔、タイムアウト、正常/異常の判定回数を設定

ロールバック比較表

項目	CodeDeploy	Elastic Beanstalk
自動ロールバック条件	デプロイ失敗、CloudWatchアラーム	デプロイ失敗、ヘルスチェック失敗
CloudWatch連携	✅ 詳細設定可能	⚠️ 限定的
ロールバック実行	前リビジョンを再デプロイ	前バージョンに環境再構築
ロールバック時間	高速（数分）	中速（10-15分）
トラフィック制御	✅ 段階的に戻す	✅ All-or-nothing
手動介入	✅ API/コンソールで可能	✅ コンソールで可能

3-7. カスタマイズ性

項目	CodeDeploy	Elastic Beanstalk
デプロイスクリプト	✅ appspec.ymlで詳細制御	✅ .ebextensions/フックスクリプト
インフラカスタマイズ	✅ 完全にカスタマイズ可能	⚠️ 制限あり（.ebextensionsで拡張）
OS選択	✅ 自由	⚠️ プラットフォーム依存
ミドルウェア選択	✅ 完全に自由	⚠️ プラットフォームに制約

4. 選択基準：どちらを使うべきか

4-1. Elastic Beanstalkを選ぶべき場合

✅ こんなケースにおすすめ

迅速にアプリを公開したい
- インフラ構築に時間をかけたくない
- とにかく早くデプロイしたい
インフラの知識が少ない
- EC2、ELB、Auto Scalingの設定に不慣れ
- マネージドサービスで運用負荷を減らしたい
標準的なWeb アプリケーション
- Node.js、Python、Java、.NET、PHP、Rubyなど
- 特殊なインフラ要件がない
小〜中規模のプロジェクト
- スタートアップやMVP開発
- 少人数チームでの開発
フルスタック開発者
- インフラよりアプリ開発に集中したい
- DevOpsチームがいない

具体例

✓ スタートアップのWebアプリ（Rails、Django）
✓ 社内向けダッシュボード
✓ REST API（Express.js、Flask）
✓ プロトタイプ・MVP開発
✓ 学習用プロジェクト

4-2. CodeDeployを選ぶべき場合

✅ こんなケースにおすすめ

既存のインフラがある
- すでにEC2やECSクラスタが稼働中
- インフラは別のツール（Terraform、CloudFormation）で管理
複雑なデプロイ戦略が必要
- 高度なカナリアデプロイ
- 複数リージョンへの段階的デプロイ
- Lambda関数のトラフィックシフト
マイクロサービスアーキテクチャ
- 複数のサービスを個別にデプロイ
- サービスごとに異なるデプロイ戦略
オンプレミスとの混在環境
- ハイブリッドクラウド
- オンプレミスサーバーへのデプロイも必要
完全な制御が必要
- インフラの細かい設定をカスタマイズ
- 特殊な要件（セキュリティ、コンプライアンス）

具体例

✓ 大規模なマイクロサービス基盤
✓ Lambda関数の本番デプロイ
✓ ECSクラスタへのコンテナデプロイ
✓ 既存システムのクラウド移行
✓ 複数チームで異なるサービスを開発

4-3. 選択フローチャート

アプリケーションデプロイが必要
        │
        ↓
  既存のインフラがある？
   ┌────┴────┐
 Yes         No
   ↓           ↓
CodeDeploy  インフラ構築から必要？
   │         ┌────┴────┐
   │       Yes         No
   │         ↓           ↓
   │    Beanstalk   既存EC2を使う
   │         │           ↓
   │         │      CodeDeploy
   │         │
   └─────────┴──────────┘
            │
         適切な選択

5. まとめ

5-1. 重要なポイント

観点	Elastic Beanstalk	CodeDeploy
本質	PaaS	デプロイツール
インフラ	自動構築・管理	既存インフラを使用
対象ユーザー	インフラ初心者〜中級者	インフラ中級者〜上級者
ベストユースケース	迅速なWeb アプリ公開	複雑なデプロイ戦略
学習コスト	低い	中程度
柔軟性	中	高

5-2. 選択のゴールデンルール

迷ったらBeanstalkから始める
- 後でCodeDeployに移行可能
- 初期段階では複雑さを避ける
インフラをコード化したいならCodeDeploy
- Terraform/CloudFormation使用者向け
- Infrastructure as Codeの思想に合致
両方使っても良い
- それぞれの強みを活かす
- 段階的な移行も可能

6. 参考リンク

公式ドキュメント

関連ブログ

ベストプラクティス