デプロイ戦略が試験で混乱しやすい理由
Blue/GreenとRollingは、どちらも「止めずに更新したい」という目的に見えるので、試験でも実務でも混同しがちです。ですが、両者の本質はまったく違います。
- Blue/Green：新しい“環境（または同等の受け皿）”を用意して、トラフィックを切り替える
- Rolling：今動いている環境の中身を、少しずつ置き換える
ここを押さえるだけで、設問の読み方が変わります。SAA-C03では「どのサービスで実現するか」より先に、「その戦略が何を保証し、何を犠牲にするか」を問われやすいです。たとえば、切り戻しのしやすさ、デプロイ中の容量低下、コスト、テストのしやすさ、切り替え時のリスクなどです。
このあと、AWS公式ドキュメントで使われている表現に寄せながら、戦略の芯を整理します。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
Blue/Greenとは何かをAWSの言葉で押さえる
Blue/Greenは、現在稼働中の環境（Blue）とは別に、新バージョンの環境（Green）を用意し、十分に確認してから本番トラフィックを切り替える手法です。AWSのホワイトペーパーやガイドでも、2つの環境間でトラフィックを移す考え方として説明されています。
Blue/Greenの強み
- 切り戻しが速い：切替を戻すだけで元に戻せる（「戻すために再デプロイ」が不要になりやすい）
- 事前検証がしやすい：本番相当のGreenで動作確認してから切替できる
- 切替タイミングを制御しやすい：リリースの“瞬間”を設計できる
Blue/Greenのコストと注意点
- 二重に環境を持つコスト：同等の受け皿を用意するため、リソースが増えやすい
- 切替時の設計が要：ロードバランサのリスナー/ターゲットグループ、接続先、セッション、キャッシュなど「切替で一気に変わる」ものを意識する必要がある
AWSでの典型実装イメージ（ECS + CodeDeploy）
Amazon ECSでは、Blue/GreenデプロイをCodeDeployと組み合わせて行う構成が整理されています。要点は「置き換え用のタスクセットを作り、ロードバランサで本番トラフィックを新しい側へルーティングする」という流れです。
また、テスト用リスナー（任意）を用意し、切替前に新しいタスクセットへテストトラフィックを流す考え方もドキュメントに出てきます。
Rollingとは何かをAWSの言葉で押さえる
Rollingは、旧バージョンを動かしながら、新バージョンへ段階的に置き換えるデプロイ戦略です。AWSのホワイトペーパーでは「前のバージョンのアプリケーションを、新しいバージョンにゆっくり置き換える」戦略として整理されています。
Rollingの強み
- 追加コストを抑えやすい：基本的に“同じ環境”の中で順次入れ替える
- 段階的に進められる：バッチ（単位）で入れ替える、進行を見ながら調整できる
Rollingの注意点
- デプロイ中は新旧が混在する：互換性（DBスキーマ、API、セッション、キャッシュ）が弱いと事故りやすい
- 切り戻しが「切替」にならないことが多い：元に戻すには、追加のローリング更新が必要になるケースがある（後述）
Elastic Beanstalkの“ローリング”がわかりやすい
Elastic Beanstalkには「Rolling」「Rolling with additional batch（追加バッチ）」「Immutable」などデプロイポリシーがあり、ローリングの現実がイメージしやすいです。
- Rolling：既存インスタンスをバッチで順に更新
- Rolling with additional batch：先に追加バッチを立てて総容量を維持しながら更新
- Immutable：新しいグループへデプロイして切替に近い挙動（失敗時のロールバックが簡単になりやすい）
このあたりは、問題文に「容量を落とせない」「デプロイ中も性能を維持したい」と書かれていたときに、思考の助けになります。
どう使い分けるか：要件からの判断表と具体例
ここは暗記よりも「要件→戦略」の変換ができるようになるのが狙いです。
判断表（試験の設問に合わせた観点）
| 観点 | Blue/Green | Rolling |
|---|---|---|
| ダウンタイム最小化 | 得意（切替で制御） | 可能だが設計次第 |
| 事前検証 | 得意（Greenで検証→切替） | 一部だけ先行確認は難しめ |
| 切り戻し速度 | 得意（トラフィックを戻す発想） | 追加の更新が必要になりがち |
| 追加コスト | 増えやすい（二重環境） | 抑えやすい |
| 新旧混在 | 原則しない（切替前に隔離） | する（互換性が重要） |
| 実装の複雑さ | ルーティング/リスナー等が増える | オーケストレーション設定中心 |
具体例でイメージする
例A：ECサイトのAPIを更新。リリース前に“本番相当”でテストしたい
- 選びやすい：Blue/Green
新環境で動作確認してから切り替えられるからです。ECSならCodeDeployのBlue/Green構成がドキュメント化されています。
例B：バッチ処理アプリを更新。多少時間がかかってもよいがコスト増は避けたい
- 選びやすい：Rolling
段階的置き換えで追加リソースを抑えやすい。ECSの“rolling update”も、サービス内のタスクを順に差し替える考え方です。
例C：絶対に容量を落とせないが、Blue/Greenほど二重投資はしたくない
- 中間の発想：Rolling with additional batch
Elastic Beanstalkの追加バッチの考え方が近いです（総容量を維持しながら段階更新）。
「完全な二重環境」ではないが、「更新中の容量低下」を避ける、という読解ができます。
AWSサービス別の実装イメージと、試験でのつまずきポイント
実装の言葉に引きずられて混乱しやすいので、「どのサービスで、どんな“挙動”になるか」を短く整理します。
CodeDeploy：In-placeとBlue/Greenを混同しない
CodeDeploy自体は大きく in-place（その場更新） と blue/green の2つのデプロイタイプを提供しています。
ここで重要なのは、in-placeは“ローリング”と同義ではない点です。in-placeは「同じインスタンス上のアプリを止めて入れ替え、検証して戻す」タイプで、ロードバランサで対象を一時的に外す運用も説明されています。
試験では、「別環境を用意する」か「同じ環境で入れ替える」かを読んで分類するのが安定です。
ECS：Rolling updateとBlue/Greenの両方が出てくる
ECSはサービスのデプロイ戦略としてRolling updateとBlue/Greenの両方を扱います。
- Blue/Green：CodeDeploy連携で、タスクセットを置き換えてトラフィックを切替
- Rolling update：サービス内で段階的に入れ替える（旧タスク→新タスクへ順次）
「Blue/GreenからRollingへ移行」「RollingからBlue/Greenへ移行」などのガイドもあり、AWSとしても両者が明確に別物として整理されていることがわかります。
Elastic Beanstalk：Rolling、Immutable、Traffic splitting
Beanstalkはデプロイポリシー名がそのまま戦略の学習材料になります。Rolling系・Immutable・Traffic splittingなどが並び、特にImmutableは「ローリング失敗時は追加ローリングが必要になり得る」対比で説明されています。
設問に「安全に構成変更を適用したい」「失敗時の復旧を単純にしたい」が出てきたら、この考え方がヒントになります。
Canaryは“Blue/Greenの慎重版”として捉える
AWSのホワイトペーパーでは、CanaryはBlue/Greenの一種で、トラフィックを段階的に移す（最初は少量、問題なければ全面）発想として説明されています。
「一気に切り替えるのが怖い」「まずは小さく試したい」という文脈が出たら、Blue/Green単体よりもCanary寄りの読み方ができます。
迷いを減らすための“読み替え”メモ
問題文のキーワードを、頭の中でこう読み替えると事故が減ります。
- 「新環境を作って確認してから切替」→ Blue/Green
- 「段階的に入れ替える」「バッチで更新」→ Rolling
- 「デプロイ中も容量を落としたくない」→ 追加バッチ / 余力を持たせたRolling
- 「失敗時にすぐ元へ」→ Blue/Green（切替で戻せる）
- 「新旧混在が許容されない」→ Blue/Green or 互換性を確保したRolling
- 「DB変更が絡む」→ Rollingだと互換性設計が必須（先に拡張→あとで切替、など）
Udemy講座のおすすめ（体系的に学べる教材の一例）
デプロイ戦略は、用語だけ覚えるより「サービスごとの挙動の違い」をまとめて理解したほうが早いです。
Udemyでも、ECS/CodeDeploy/Elastic Beanstalkを横断してデプロイ戦略を扱うコース（CI/CDやIaCを含むもの）があり、図解で整理したい人には相性が良いです。
SAA-C03対策で評価の高いUdemy講座をまとめて確認できます。👇
まとめ
Blue/GreenとRollingの違いは、「止めずに更新する」という表面ではなく、どこに“切替の境界”があるかで整理すると一気に分かれます。Blue/Greenは新しい受け皿（Green）を用意して検証し、トラフィックを切り替える発想。Rollingは同じ環境の中で段階的に入れ替え、新旧が一時的に混在し得る発想です。
AWS公式ドキュメントでも、ECSのBlue/Green（CodeDeploy連携）とRolling update、Elastic BeanstalkのRolling系ポリシーやImmutableなど、戦略ごとの挙動が明確に分けて整理されています。
SAA-C03対策としては、サービス名を丸暗記するより、問題文の要件（事前検証したい、切り戻しを速くしたい、コストを抑えたい、デプロイ中の容量低下を避けたい）を読んで、戦略の性質に当てはめる練習が効果的です。そうすると、見慣れない構成図が出ても「これは切替型か、段階置換型か」という軸で落ち着いて判断できます。
