Elastic Beanstalk 設計パターン5選｜SAA-C03 頻出 デプロイ戦略・Worker 環境・サービス選択を完全攻略
AWS SAA-C03 で頻出の Elastic Beanstalk 設計を完全整理。All-at-once・Rolling・Immutable・Blue/Green の4つのデプロイ戦略、SQS 連携 Worker 環境、RDS デカップリング、Beanstalk vs ECS vs App Runner の選択軸を体系化。試験シナリオを即断できる粒度まで分解する。
「Elastic Beanstalk はただの PaaS ではない。SAA-C03 の設計問題では、デプロイ戦略の選択ミスがダウンタイムに直結し、Worker 環境を知らないと非同期処理問題で確実に失点する。Beanstalk・ECS・App Runner の3サービスを比較できない受験者は、サービス選択問題でも崩れる」 — 本記事では SAA-C03 頻出の Elastic Beanstalk 設計パターン5選を体系化し、デプロイ戦略の選択軸から Worker 環境・RDS デカップリング・サービス比較まで、試験シナリオを即断できる粒度まで分解する。
※ 本記事はアフィリエイト広告（Amazon アソシエイト等）を含みます
📑 目次
- 結論：Elastic Beanstalk の選択軸
- Elastic Beanstalk の基本アーキテクチャ
- パターン1：デプロイ戦略4選（All-at-once / Rolling / Immutable / Blue/Green）
- パターン2：Worker 環境（SQS 連携 非同期バックグラウンド処理）
- パターン3：マルチコンテナ Docker 環境
- パターン4：RDS デカップリング設計（DB を環境外に出す）
- パターン5：Beanstalk vs ECS vs App Runner 選択ガイド
- 試験頻出シナリオ → 解法パターン早見表
- 次のアクション チェックリスト
- 関連記事
- 関連サイト
1. 結論：Elastic Beanstalk の選択軸
Elastic Beanstalk は「コードをアップロードするだけで EC2・ELB・Auto Scaling を自動構築する PaaS」だ。だが SAA-C03 が問うのは「どのデプロイ戦略を選ぶか」「非同期処理をどう構成するか」「いつ ECS や App Runner に乗り換えるか」の判断力だ。
Elastic Beanstalk が最適なシナリオ：
| シナリオ | 理由 |
|---|---|
| インフラを意識せず Web アプリを素早くデプロイしたい | EC2/ELB/ASG を自動構築 |
| ダウンタイムなしのデプロイ戦略が必要 | Immutable / Blue/Green が使える |
| SQS を使ったバックグラウンド処理を Web と分離したい | Worker 環境が専用サポート |
EC2 に SSH したり .ebextensions でカスタムしたい | EC2 へのアクセス権がある |
2. Elastic Beanstalk の基本アーキテクチャ
Elastic Beanstalk の環境は「Web サーバー環境」と「Worker 環境」の2種類で構成される。
[ユーザー]
│ HTTP(S)
▼
[ALB / ELB]
│
▼
[EC2 Auto Scaling グループ] ←── Web サーバー環境
│ （Node.js / Python / Java 等）
│ 長時間タスクをキュー投入
▼
[Amazon SQS]
│ メッセージをポーリング
▼
[EC2 Auto Scaling グループ] ←── Worker 環境
│ （バックグラウンド処理）
▼
[RDS / S3 / その他バックエンド]Beanstalk は裏側で CloudFormation スタックを自動生成し、EC2・ELB・Auto Scaling・セキュリティグループを一元管理する。インフラを見えなくするが、削除せず EC2 に SSH することも可能。
3. パターン1：デプロイ戦略4選
SAA-C03 で最も頻出のトピック。4つのデプロイ戦略の違いを「ダウンタイム」「コスト」「ロールバック速度」で整理する。
3-1. All-at-once（一斉更新）
全インスタンスを同時に停止→新バージョン起動。最速・最安だが、デプロイ中は全インスタンスが停止するため ダウンタイムが発生する。
- 用途：開発・検証環境（本番では非推奨）
- ロールバック：再デプロイが必要（時間がかかる）
3-2. Rolling（ローリング更新）
インスタンスをバッチ単位で順番に更新。デプロイ中は旧バージョンと新バージョンが混在する。
- 用途：本番環境でダウンタイムを最小化したい場合
- 注意：バッチ処理中は容量が一時的に減少する（例：4台構成でバッチ2台ずつ更新→デプロイ中は稼働2台）
3-3. Rolling with additional batch（追加バッチ付きローリング）
追加インスタンスを起動してからローリング更新。デプロイ中も容量が100%維持される。
- 用途：本番環境でゼロダウンタイム + キャパシティ維持が必要な場合
- コスト：追加インスタンス分の一時的なコスト増
3-4. Immutable（イミュータブル更新）
全く新しい Auto Scaling グループ（ASG）に新バージョンのインスタンスを起動し、ヘルスチェック通過後に切り替える。旧インスタンスは完全に残る。
- 用途：本番環境でロールバックを瞬時に行いたい場合
- ロールバック：旧 ASG に戻すだけで即時
- コスト：デプロイ中は一時的に2倍のインスタンスが稼働
3-5. Blue/Green（ブルーグリーン）
Beanstalk 固有の実装は CNAME スワップで行う。独立した2つの環境（Blue=現行、Green=新バージョン）を用意し、DNS レベルで切り替える。
- 用途：完全なゼロダウンタイムデプロイ + 即時ロールバック
- CNAME スワップ：
Swap Environment URLs機能で DNS を切り替え - 注意：DNS TTL があるため、切り替え後も一部のクライアントが旧環境を参照する可能性がある
| 評価項目 | All-at-once | Rolling | Immutable | Blue/Green |
|---|---|---|---|---|
| ダウンタイム | あり | なし | なし | なし |
| デプロイ中の容量 | 0%（全停止） | 一時減少 | 100%維持 | 100%維持 |
| ロールバック速度 | 遅い（再デプロイ） | 遅い（再デプロイ） | 速い（旧 ASG へ戻す） | 即時（CNAME 戻し） |
| コスト | 最安 | 低 | 中（一時2倍） | 高（2環境分） |
| 本番推奨度 | × | △ | ◎ | ◎ |
4. パターン2：Worker 環境（SQS 連携 非同期処理）
Elastic Beanstalk は Web サーバー環境と Worker 環境の2層アーキテクチャをネイティブサポートする。
構成のポイント
- Web 環境：ユーザーリクエストを受け付け、重い処理は SQS に投入
- Worker 環境：SQS のメッセージを自動ポーリングして処理（デーモンプロセスが常駐）
- デーモン（sqsd）：Beanstalk Worker 環境には
sqsdデーモンが自動インストールされ、SQS からメッセージを取得してローカルの HTTP エンドポイントに POST する
Web 環境 ──[SQS キュー]── Worker 環境
│ │
└─ ユーザーから注文受付 └─ 注文確認メール送信・PDF生成・バッチ集計SAA-C03 で狙われるポイント
- 「ユーザーリクエストのレスポンスタイムを短縮」＋「重い処理を非同期化」 → Web + Worker + SQS の組み合わせを選ぶ
- Worker 環境のスケーリングは SQS キューの深さ（ApproximateNumberOfMessagesVisible）に基づく CloudWatch アラームで実現
- Worker 環境は外部からの直接アクセス不可（ELB なし）
5. パターン3：マルチコンテナ Docker 環境
Elastic Beanstalk は Amazon ECS を裏側に使ったマルチコンテナ Docker 環境をサポートする。Dockerrun.aws.json v2 ファイルでコンテナ構成を定義する。
いつ使うか
- 単一コンテナ（nginx + アプリの2コンテナ等）→ Beanstalk マルチコンテナで十分
- 複雑なオーケストレーション（サービス間通信・高度なスケーリング）→ ECS に移行
6. パターン4：RDS デカップリング設計
Elastic Beanstalk 環境に RDS を内包した場合、環境を削除すると DB も削除される。これは試験・実務の両方で重大なアンチパターンだ。
本番推奨構成：RDS を環境外に出す
[Beanstalk 環境（Web + Worker）]
│
│ DB 接続（環境変数で渡す）
▼
[RDS / Aurora] ←── Beanstalk 環境とは独立して存在- RDS を Beanstalk 外部で作成し、接続文字列を環境変数（
DB_HOST,DB_PASSWORD等）で渡す - Beanstalk 環境を削除・再作成しても RDS は影響を受けない
- Multi-AZ RDS / Aurora の場合は自動フェイルオーバーで可用性を確保
7. パターン5：Beanstalk vs ECS vs App Runner 選択ガイド
SAA-C03 のサービス選択問題でよく比較される3サービスの使い分けを整理する。
| 評価項目 | Elastic Beanstalk | ECS (Fargate) | App Runner |
|---|---|---|---|
| インフラ管理 | EC2 あり（SSH 可） | サーバーレス | フルマネージド（不可視） |
| コンテナ対応 | ◎（単一・マルチ） | ◎（高度なオーケストレーション） | ◎（コンテナ or ソースコード） |
| デプロイ戦略 | 4種類（Rolling/Immutable/Blue-Green） | 個別設定が必要 | 組み込みの自動デプロイ |
| Worker 非同期処理 | ◎（ネイティブサポート） | △（SQS Lambda 等と自分で組む） | ×（非対応） |
| スケーリング | Auto Scaling（EC2） | 柔軟な Fargate スケール | トラフィックベースで自動 |
| 学習コスト | 低 | 高 | 最低 |
| 向いているケース | 既存 Web アプリを早く動かしたい | マイクロサービス・大規模コンテナ | MVP・シンプルなコンテナ公開 |
選択フロー
コンテナ？
├─ NO → Elastic Beanstalk（コード zip をアップするだけ）
└─ YES → インフラをゼロ管理したい？
├─ YES → App Runner（ソースまたは ECR から即デプロイ）
└─ NO → 高度なオーケストレーション or マイクロサービス？
├─ YES → ECS Fargate
└─ NO → Elastic Beanstalk（マルチコンテナ Docker）8. 試験頻出シナリオ → 解法パターン早見表
| シナリオのキーワード | 正解パターン |
|---|---|
| 「ダウンタイムなし・旧インスタンスを残したい・即時ロールバック」 | Immutable または Blue/Green |
| 「コストを抑えてダウンタイムなしでデプロイ」 | Rolling または Rolling with additional batch |
| 「開発環境・速さ優先・ダウンタイム許容」 | All-at-once |
| 「Blue/Green で DNS を切り替える」 | Swap Environment URLs（CNAME スワップ） |
| 「Web アプリのレスポンスが遅い・重い処理を非同期化」 | Worker 環境 + SQS |
| 「Beanstalk 環境を削除したら DB のデータが消えた」 | RDS デカップリング（環境外に移動） |
| 「最小の管理コストで Node.js コンテナを公開」 | App Runner |
| 「マイクロサービス間通信・サービスディスカバリが必要」 | ECS Fargate |
| 「EC2 に SSH したい・.ebextensions でカスタムしたい」 | Elastic Beanstalk（App Runner/Fargate は不可） |
| 「SQS キューのメッセージ数でスケール」 | Worker 環境 + CloudWatch アラーム |
9. 次のアクション チェックリスト
- 4つのデプロイ戦略（All-at-once / Rolling / Immutable / Blue/Green）をダウンタイム・ロールバック・コストで即答できる
- Blue/Green = Swap Environment URLs（CNAME スワップ）を覚えた
- Worker 環境は SQS をポーリングして HTTP POST で処理することを理解した
- RDS を Beanstalk 環境内に入れると環境削除で DB も消えることを理解した
- Beanstalk / ECS / App Runner の使い分け3択問題を解ける
- .ebextensions でインフラカスタマイズが可能なことを覚えた
10. 関連記事
- Elastic Beanstalk 基礎解説（概要・デプロイ方法・料金）
- ECS・コンテナ設計パターン（SAA-C03 頻出）
- Auto Scaling・ELB 設計パターン（SAA-C03 頻出）
- CloudFormation・CDK 設計パターン（SAA-C03 頻出）
- RDS・Aurora 設計パターン（SAA-C03 頻出）