---
title: "Blue/Greenデプロイとは？仕組み・カナリアとの違いとKubernetes・AWS・RDSでの実装"
url: "https://www.issoh.co.jp/tech/details/4040/"
published: 2024-11-05
updated: 2026-10-28
categories: ["CI/CD"]
publisher: "株式会社一創"
---

# Blue/Greenデプロイとは？仕組み・カナリアとの違いとKubernetes・AWS・RDSでの実装

Blue/Greenデプロイ（ブルーグリーンデプロイメント、B/Gデプロイ）は、本番と同じ構成の環境を2系統用意し、稼働中の旧環境（Blue）と新バージョンを入れた環境（Green）を並べたうえで、ロードバランサーなどの向き先を一度に切り替えてリリースする手法です。不具合が出たら向き先をBlueへ戻せば旧版での処理を再開できるので、停止メンテナンスを伴う上書き型のデプロイよりダウンタイムとリスクを小さくできます（データベースへの書き込みなど、外部に出た変更までは戻りません）。その代わり、2系統分のリソースと、新旧バージョンが同じデータベースを共有するための後方互換の設計が要ります。

この記事では、仕組みと名前の由来、カナリア・ローリングなど他方式との違い、採用すべきでない場面を整理したうえで、切り替えの瞬間に処理中のリクエストを落とさないための設定値、データベースの扱い（アプリ側の後方互換とAmazon RDSのブルー/グリーンデプロイ）、Kubernetes・Argo Rollouts・AWS・Azureでの実装例をコードで示します。

## まとめ：Blue/Greenデプロイの要点と判断軸

- 同じ構成の環境を2系統並べ、**向き先を一括で切り替えてリリースし、戻すときも向き先を戻すだけ**。段階的に比率を上げるのがカナリア、台数単位で入れ替えるのがローリング。
- 向くのは、停止が売上や信頼に直結し、切り戻しの速さを最優先したいサービス。更新が年に数回で可用性要件も緩い社内システムでは、2系統のコストに見合わない。
- 事故が起きやすいのは切替機構よりデータ層。スキーマ変更は expand-contract で複数リリースに分け、旧バージョンに戻しても読み書きできる状態を保つ。
- 「向き先を変えた瞬間」にも穴がある。ロードバランサーの登録解除の遅延（ALBの既定は300秒）、Kubernetesの反映遅延、DNSのTTLの間は旧環境にリクエストが届くので、Blueをすぐ落とさない。
- Amazon RDSのブルー/グリーンデプロイはDBのバージョンアップ用で、切替後は複製が止まる。アプリのBlue/Greenと違い、向き先を戻すロールバックの手段ではない。

## Blue/Greenデプロイの仕組みと名前の由来

考え方を広めたのはMartin Fowler氏が2010年3月1日に公開した[bliki「BlueGreenDeployment」](https://martinfowler.com/bliki/BlueGreenDeployment.html)です。できるだけ同じに作った本番環境を2つ持ち、片方（例としてBlue）が稼働している間に、もう片方（Green）で新リリースの最終テストを行い、問題がなければルーターを切り替えて全リクエストをGreenへ送る、という手順が書かれています。

### デプロイから切り替え・待機までの4段階

流れは「Greenへデプロイ → Greenで検証 → 向き先をGreenへ切り替え → Blueを待機させる」の4段階です。Greenは本番トラフィックを受けないまま、ヘルスチェックとスモークテストを済ませられます。切替後に異常が出たら、向き先をBlueへ戻せば復旧します。上書き型のように壊れた本番を直しながら復旧するのではなく、「直す」代わりに「戻す」で対処できるのが構造上の強みです。

Fowler氏は、Greenが安定したら空いたBlueを次回リリースのステージングに使い、次は逆向きに切り替える運用も示しています。2系統が「稼働中」「切り戻し用」「次版の準備」を順に回るので、切替の手順そのものがホットスタンバイへの切替訓練にもなります。

### 名前の由来とBlue・Greenの役割が入れ替わる理由

同じblikiには、この呼び名は Daniel Terhorst-North 氏と Jez Humble 氏の2人から生まれたと書かれています（どちらの発案かは「foggy combination」とぼかされています）。Jez Humble氏とDave Farley氏の書籍『Continuous Delivery』の一節が紹介のきっかけです。色そのものに「Blueが旧・Greenが新」という固定の意味はなく、2系統を区別するラベルにすぎません。切り替えるたびに役割は入れ替わり、次のリリースでは現在のGreenが稼働側になります。

## カナリア・ローリング・In-Place・Immutableとの違い

デプロイ方式は「何を単位に切り替えるか」「戻すのにどれだけかかるか」「追加でどれだけリソースが要るか」の3つで比べると違いがはっきりします。

| 方式                   | 切り替えの単位         | ダウンタイム | 戻し方      | 追加リソース |
| -------------------- | --------------- | ------ | -------- | ------ |
| Blue/Green           | 全量を一括           | ほぼなし   | 向き先を戻す   | 大（2系統） |
| カナリア                 | トラフィックの比率       | なし     | 比率を0に戻す  | 中      |
| ローリング                | 台数・Pod数         | なし     | 逆向きに入れ替え | 小      |
| Immutable（Beanstalk） | 同じ環境内の新規インスタンス群 | なし     | 新規分を破棄   | 一時的に大  |
| In-Place             | 稼働中サーバーを上書き     | 構成次第   | 旧版を再デプロイ | なし     |

### カナリアリリースとの違いと使い分け

カナリアは新バージョンへまず数％だけ流し、指標を見ながら比率を上げていく方式です。Blue/Greenが「0％か100％か」で切り替えるのに対し、カナリアは実ユーザーの一部で本番検証しながら影響範囲を絞ります。検証はGreenで済ませて一気に切り替え、戻す速さを優先するならBlue/Green、本番の実トラフィックでしか出ない不具合を少人数で先に捕まえたいならカナリアです。両者は排他ではなく、Blue/Greenの2系統の間で比率を刻む構成も組めます（後述のCodeDeployやIstio）。段階リリースの実装と判断は[カナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説](/tech/details/13592/)で扱っています。

### ローリング・In-Place・Immutableとの違い

ローリングは稼働中のサーバー群を少しずつ新バージョンへ置き換えるので、追加リソースは小さく済みますが、更新中は新旧が混在し、戻すときも逆向きの置き換えに時間がかかります。入れ替え幅の決め方は[ローリングアップデートとは？仕組みとKubernetes・ECSの設定値・採用判断を解説](/tech/details/16189/)を参照してください。In-Placeは稼働中のサーバーへ直接上書きする方式で、追加環境は要らない一方、更新中の対象サーバーは止まり（ロードバランサーから1台ずつ外せば全体は止まらないが、1台構成なら全体が止まる）、失敗すると壊れた環境の復旧が必要です（[インプレースアップグレードの意味とリスク](/tech/details/14688/)）。Immutableは「稼働中のサーバーを書き換えず、新しいサーバーを作って入れ替える」という作り方の原則で、2系統の向き先を切り替えるBlue/Greenとは比べる軸が違い、両立もします。たとえばElastic Beanstalkのimmutable更新は、[同じ環境のロードバランサーの後ろに一時的な2つ目のAuto Scalingグループ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environmentmgmt-updates-immutable.html)を作って新インスタンスと入れ替え、Blue/Greenは別の環境を作って環境URLをスワップします。

## Blue/Greenを選ぶべき場面と採用すべきでない場面

最大の利点は、本番と同じ環境で最終確認を済ませてから切り替えられることと、再デプロイせずに向き先を戻すだけで切り戻せることです。切り戻しが怖くてリリースをまとめてしまうチームでは、デプロイの頻度を上げる足場になります。代償は2系統分のリソースです。コンテナで一時的にGreenを立て、切替後の監視期間が過ぎたらBlueを縮小する構成なら、常時2倍にはなりません。

次のどれかに当てはまるなら、Blue/Greenを第一候補にしないほうが無難です。

- **後方互換にできないスキーマ変更を含むリリース**：Blueへ戻してもデータベースは戻らず、戻す利点が消える。データ移行を別リリースに分けるか、メンテナンス時間を取る。
- **更新が年数回で、可用性要件も緩い社内システム**：2系統の費用と運用手順に見合わない。ローリングかIn-Placeで足りる。
- **大きな状態をローカルに持つアプリ**：インメモリキャッシュの暖機やローカルファイルの同期にGreenが時間を取られ、「すぐ切り替えられる」前提が崩れる。

## 切り替えの瞬間に処理中のリクエストを落とさない設計

Blue/Greenの説明では「向き先を変えれば一瞬で切り替わる」とされがちですが、実際には切替の直後もしばらく旧環境にリクエストが届きます。ここでBlueを止めると、無停止のはずのリリースでエラーが出ます。どこで遅れが生じるかは、切り替えに使う仕組みごとに違います。

| 切り替えの仕組み             | 旧環境に届き続ける理由          | 既定値・目安              |
| -------------------- | -------------------- | ------------------- |
| AWS ALB              | 登録解除の遅延中は処理中の要求を待つ   | 300秒                |
| Kubernetes Service   | 各ノードのiptables更新の反映遅延 | Argo Rolloutsは30秒待つ |
| Kubernetes Pod終了     | SIGTERM後の終了猶予        | 30秒                 |
| DNS（Beanstalkのスワップ等） | クライアントやリゾルバーのキャッシュ   | 旧レコードのTTL           |

### ロードバランサーの登録解除の遅延とDNSのTTL

AWSのApplication Load Balancerは、登録解除中のターゲットに新しいリクエストを送らず、処理中のリクエストが終わるのを既定で300秒待ちます（[ターゲットグループ属性の公式ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-target-group-attributes.html)）。短いAPIだけなら `deregistration_delay.timeout_seconds` を下げて切替を早め、ファイルのアップロードや長いレポート生成があるなら、その最長処理時間より長く取ります。

DNSで切り替える構成は、TTLが切れるまで旧環境のアドレスを使い続けるクライアントが残ります。Elastic Beanstalkの環境URLのスワップについて、AWSの[公式手順](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)は、DNSの変更が伝わり旧レコードの期限が切れるまで旧環境を終了しないよう注意しています。自分で管理するDNSレコードで切り替えるなら、現在のTTL以上前にTTLを短くしておき、古いキャッシュが切れてから切り替えます。

### KubernetesのService切り替えとPodの終了猶予

KubernetesでServiceのselectorを書き換えても、全ノードのiptablesに反映されるまでの間は旧Podへパケットが送られます。[Argo Rolloutsのドキュメント](https://argo-rollouts.readthedocs.io/en/stable/features/bluegreen/)はこの反映遅延を理由に、切替後すぐ旧ReplicaSetを縮小せず `scaleDownDelaySeconds`（既定30秒）待つ設計にしています。手作業で切り替える場合も、selectorを変えてすぐ旧Deploymentを0台にしてはいけません。30秒は反映遅延の目安にすぎないので、長いリクエストや接続を持つアプリなら、その最長処理時間と旧Podへのリクエストが止んだことをメトリクスで確かめてから縮小します。

Podの側は、終了が決まってから強制終了されるまでの猶予（`terminationGracePeriodSeconds`）が既定30秒です（[Pod Lifecycle](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/)）。preStopフックで数秒待ってからSIGTERMを受けるようにすると、反映が遅れたノードから来たリクエストも受け切れます。ただし[猶予のカウントはpreStopの実行前に始まる](https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/)ので、preStopの時間も猶予に含まれます。下の例では60秒のうち10秒をpreStopが使い、アプリの終了処理に使えるのは残りの約50秒です。preStopの `sleep` はKubernetes 1.34でGAになったので、イメージにsleepコマンドが無くても使えます。停止順序の詳細は[グレースフルシャットダウンとは？SIGTERM受信後の停止順序と猶予時間の設計](/tech/details/16202/)で扱っています。

```
spec:
  terminationGracePeriodSeconds: 60
  containers:
    - name: web
      image: registry.example.com/web:2.0.0
      lifecycle:
        preStop:
          sleep:
            seconds: 10   # 反映が遅れたノードからの要求を受け切ってから終了処理へ
```

セッションをアプリのメモリに持っていると、BlueからGreenへ移った利用者はログアウトされます。セッションはRedisやデータベースなど外部ストアに置き、新旧どちらのバージョンでも読める形式にしておきます（[セッション管理の実装と保存先選定](/tech/details/16366/)）。2系統を持たずに無停止を成り立たせる条件は[ゼロダウンタイムデプロイとは？無停止を壊す発生源と設定順序・計測方法](/tech/details/16200/)にまとめています。

## データベースの後方互換とexpand-contract

新旧バージョンが同じデータベースを共有する以上、Greenの新コードが書いたデータをBlueが読めない状態になると、向き先を戻しても復旧しません。Fowler氏のblikiも2015年の追記で、スキーマ変更をアプリの更新と分けてデプロイするよう勧めています。定石は、1回のリリースで破壊的な変更を完結させず「拡張（expand）→両対応→収縮（contract）」に分けることです。

```
-- 例: 旧カラム is_verified を新カラム email_verified へ移す
-- リリース1（expand）: NULL許容で新カラムを足すだけ。アプリは旧カラムだけを読み書きする
ALTER TABLE users ADD COLUMN email_verified boolean;

-- リリース2（両書き）: アプリは両カラムへ書き、読むのは旧カラムのまま。
-- 全インスタンスが両書きの版になってから既存行を埋める（差分のある行も対象）
UPDATE users SET email_verified = is_verified
 WHERE email_verified IS NULL OR email_verified <> is_verified;

-- リリース3（読み替え）: 新カラムを読む版へ切り替える。書き込みは両カラムのまま

-- リリース4（contract）: 旧カラムへの読み書きをアプリ・バッチ・切り戻し対象の版から外し、
-- その版より前へ戻す必要が無くなってから削除する
ALTER TABLE users DROP COLUMN is_verified;
```

リリース3でGreenに問題が出ても、Blue（リリース2）は両カラムへ書き続けているので、向き先を戻すだけで済みます。リリース1の版まで戻した場合は、その間に旧カラムだけが更新されるため、改めてリリース2へ進めたあとに上のUPDATEをもう一度流して差分を埋めます。カラム名や型の変更を1本の `ALTER` で済ませると、この逃げ道が無くなります。キャッシュのキー設計がバージョン間で変わる場合も、名前空間を分けて新旧が互いを汚さないようにします。

## Amazon RDS ブルー/グリーンデプロイはデータベースの更新用

「ブルーグリーン」で検索すると、アプリのリリース手法とは別に、Amazon RDSの同名機能が並びます。こちらはデータベースそのもののメジャー・マイナーバージョンアップやパラメータ変更を、本番を止めずに準備するための機能です。[公式の概要](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html)によると、RDSの対象はRDS for MariaDB・MySQL・PostgreSQLで、AuroraでもAurora MySQL・Aurora PostgreSQLで使えます（Aurora用の別ガイドがあります）。本番（ブルー）を複製したステージング（グリーン）を作り、レプリケーションで同期させたうえで切り替えます。

- RDSでは、グリーン側のDBインスタンスは**既定で読み取り専用**。テスト中に書き込むと複製の衝突を招く。
- 切替（スイッチオーバー）の停止は**通常1分未満**だが、負荷によって延びる。タイムアウトは30〜3,600秒で指定でき、**既定は300秒**。超えると変更は取り消される。
- 切替後はグリーン側が本番の名前とエンドポイントを引き継ぐのでアプリの接続先は変えなくてよい。旧ブルーは `mydb-old1` のような名前になり、**両環境の間のレプリケーションは止まる**。
- マスターユーザーのパスワードをAWS Secrets Managerで管理している構成、クロスリージョンのリードレプリカ、Multi-AZ DBクラスター、CloudFormationからの操作には対応しない（[制限事項](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-considerations.html)）。

```
# グリーン環境を作る（エンジンのバージョンとパラメータグループを指定）
aws rds create-blue-green-deployment \
  --blue-green-deployment-name mydb-upgrade \
  --source arn:aws:rds:ap-northeast-1:123456789012:db:mydb \
  --target-engine-version 8.4.7 \
  --target-db-parameter-group-name mydb-84-params

# 検証が済んだら切り替える（タイムアウト秒数は既定300）
aws rds switchover-blue-green-deployment \
  --blue-green-deployment-identifier bgd-xxxxxxxxxxxxxxxx \
  --switchover-timeout 600
```

判断の要点は、**切替後に「戻す」操作が無い**ことです。旧ブルーは残りますが、複製が止まるので切替後に本番へ書かれたデータは入っていません。アプリのBlue/Greenのつもりで「問題があれば戻せる」と考えると、その間の書き込みを失います。DBの更新はRDSの機能で、アプリの更新は向き先の切替で、と分けて計画し、同じ日に重ねないのが安全です。RDS全般の構築手順は[Amazon RDSとは？仕組み・対応エンジン・料金とAWS CLIでの構築手順](/tech/details/15426/)、Aurora MySQL 8.4への移行での使い方は[Aurora MySQL 8.4のアップグレード手順と非互換の確認方法](/tech/details/12354/)を参照してください。

## KubernetesでのBlue/Green実装

### 2つのDeploymentとServiceのselectorによる切り替え

追加のツールを入れない最小構成は、同じアプリのDeploymentを `version: blue` と `version: green` の2つ用意し、Serviceのselectorでどちらへ流すかを決める方法です。以下は、selectorがblueを指して稼働中の環境を、Greenへ切り替える例です。Greenを適用してPodがReadyになったのを確かめてから、selectorを書き換えます。Readyが「要求を処理できる」ことを意味するのは、GreenのDeploymentにreadinessProbeを設定している場合だけです。設定していなければ、切替前にスモークテストを別に流します。基礎から確認したい場合は[Kubernetes（クバネティス）とは？仕組み・メリット・デメリットとDockerとの違い](/tech/details/2928/)を参照してください。

```
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
    version: green   # blue から green へ書き換えて切り替え
  ports:
    - port: 80
      targetPort: 8080
```

```
# Greenを適用し、Readyになるまで待つ
kubectl apply -f deploy-green.yaml
kubectl rollout status deployment/web-green

# 向き先をGreenへ
kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"green"}}}'

# 戻すときはBlueへ（旧Deploymentは反映遅延を見込んで残しておく）
kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"blue"}}}'
```

### Argo RolloutsのblueGreen戦略による昇格と縮小の自動化

手作業のselector書き換えを、昇格前の検証と旧版の縮小まで含めて宣言的に書けるのが[Argo Rollouts](https://github.com/argoproj/argo-rollouts/releases)（2026年10月12日公開のv1.10.1が最新）です。Deploymentの代わりに `Rollout` リソースを使い、本番用の `activeService` と確認用の `previewService` の2つのServiceを指定します。新しいReplicaSetはまずpreviewServiceにだけつながり、昇格するとactiveServiceの向き先が切り替わります。

```
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: registry.example.com/web:2.0.0
  strategy:
    blueGreen:
      activeService: web-active     # 本番トラフィックを受けるService
      previewService: web-preview   # 昇格前の確認用Service
      autoPromotionEnabled: false   # 既定はtrue。falseで昇格前に一時停止
      scaleDownDelaySeconds: 30     # 旧ReplicaSetを縮小するまでの待ち（既定30秒）
```

`autoPromotionEnabled` を書かないと既定のtrueになり、新しいReplicaSetが使える状態になった時点で自動で昇格します。確認を挟みたいならfalseにして、プレビューで検証してから `kubectl argo rollouts promote web` で昇格させます。`prePromotionAnalysis` を設定すると、昇格前にメトリクスの分析を走らせ、失敗したら昇格させずに止められます。Argo CDと組み合わせたGitOpsの構成は[ArgoCDとは？GitOpsの仕組みとインストール・Sync設定](/tech/details/15438/)で扱っています。

比率を刻んで移したい場合は、IstioのVirtualServiceなどサービスメッシュの重み付けルーティングでblueとgreenへの比率を指定します。AWSのALBでも、リスナールールのforwardアクションに2つのターゲットグループを並べ、それぞれに0〜999の重みを付けて配分できます（[ルールのアクション種別](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/rule-action-types.html)）。Blue/Greenの2系統を土台に、まず数％だけGreenへ流す運用が組めます。

## AWS・AzureでのBlue/Green実装

### CodeDeployのトラフィック移行設定

AWS CodeDeployのBlue/Greenは、ECSではロードバランサーのリスナーの向き先を新しいタスクセットへ、Lambdaではエイリアスの向き先を新しいバージョンへ切り替えます。ECS向けの事前定義の設定は次の5種類で、いずれも `CodeDeployDefault.` が頭に付きます（[デプロイ設定の公式一覧](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)）。

| 設定名                             | 移し方              |
| ------------------------------- | ---------------- |
| ECSAllAtOnce                    | 全量を一度に移す         |
| ECSLinear10PercentEvery1Minutes | 毎分10％ずつ          |
| ECSLinear10PercentEvery3Minutes | 3分ごとに10％ずつ       |
| ECSCanary10Percent5Minutes      | 10％を流し5分後に残り90％  |
| ECSCanary10Percent15Minutes     | 10％を流し15分後に残り90％ |

Network Load Balancerを使う場合に選べるのは `ECSAllAtOnce` だけです。自動ロールバックは移行設定とは別に、デプロイグループ（またはデプロイ）で「デプロイ失敗時」や「CloudWatchアラームのしきい値到達時」に戻すよう設定したときに働きます（[ロールバックの公式説明](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)）。段階移行と組み合わせると、全量を移す前に異常を捕まえられます。CodeDeploy全体の仕組みと料金は[AWS CodeDeployとは？In-Place・Blue/Greenデプロイと料金・採用判断](/tech/details/15597/)を参照してください。

### ECSネイティブBlue/Greenの提供時期と採用判断

Amazon ECSは2025年7月から、CodeDeployを使わずにサービスの設定だけでBlue/Greenを行える機能を提供しており、2025年10月にリニア・カナリアにも対応しました。新しく組むECSのBlue/Greenは、CodeDeployのアプリケーションやデプロイグループを別に管理しなくて済むこちらが第一候補です。ライフサイクルフックやCodeDeployからの移行は[ECSネイティブBlue/Greenデプロイの設定手順｜ライフサイクルフック・ロールバック・CodeDeploy移行](/tech/details/7858/)で扱っています。

### Elastic BeanstalkのURLスワップとAzure App Serviceのスロット

Elastic Beanstalkでは、新バージョンを別の環境へデプロイし、環境URLをスワップ（Swap environment URLs）して切り替えます。DNSのCNAMEを入れ替える仕組みなので、前述のとおりTTLが切れるまで旧環境を残します（[AWS Elastic Beanstalkとは？](/tech/details/15610/)）。Azure App Serviceでは、ステージング用のデプロイスロットへデプロイしてから本番スロットとスワップします。[Microsoftのドキュメント](https://learn.microsoft.com/en-us/azure/app-service/deploy-staging-slots)のとおり、スロットを使えるのはApp Serviceプランが **Standard・Premium・Isolated** の場合で、Basic以下では使えません。AKS上ならKubernetesと同じくServiceやIngressで切り替えます（[AKS（Azure Kubernetes Service）とは](/tech/details/7272/)）。

## CI/CDへの組み込みとロールバックの自動化

Blue/Greenは手作業でも成り立ちますが、切替の判断をパイプラインに組み込むと、定義した手順の実行漏れを減らせます。ビルドとテストの後にGreenへデプロイし、ヘルスチェックが通ってから向き先を切り替える流れをワークフローに書きます。

```
# GitHub Actions：Greenへデプロイ → Ready確認 → 向き先の切り替え
- name: Deploy green
  run: kubectl apply -f deploy-green.yaml
- name: Wait for rollout
  run: kubectl rollout status deployment/web-green --timeout=300s
- name: Switch traffic to green
  run: kubectl patch service web -p '{"spec":{"selector":{"app":"web","version":"green"}}}'
```

戻す判断は、切替前に数値で決めておきます。5xx応答率、p99レイテンシ、エラーログの件数などのしきい値を決め、切替後の監視で超えたら自動でBlueへ戻す仕組みにします。CodeDeployやECSネイティブはCloudWatchアラームと連動した自動ロールバックを持ち、Argo Rolloutsは分析（AnalysisTemplate）の失敗で昇格を止められます。人が判断してから戻していると、その数分の間に被害が広がります。CI/CDツールの選び方は[CI/CDツール比較｜主要11製品の無料枠・料金と選び方](/tech/details/1834/)を参照してください。

## 自社にBlue/Greenを導入すべきかの判断基準

判断は、2系統分の費用と運用の手間を、停止と切り戻しの遅れで失うものと比べて行います。効果が大きくなりやすいのは、停止が売上や信頼に直結するサービスと、切り戻しの怖さからリリースをまとめてしまっているチームです。そのうえで、スキーマ変更を後方互換で設計する運用を続けられることが、成り立たせるための前提条件になります。

費用を左右するのは、切替後に旧環境を何時間残すかです。戻す判断に必要な監視期間（ピーク時間帯を1回通過するまで、など）を先に決め、その間だけ2系統分を払う運用にすれば、常時2倍の費用にはなりません。

導入でつまずくのは切替機構より、既存のデータベースと外部連携を壊さずに後方互換へ寄せる設計と、戻す判断を数値で自動化する運用づくりです。株式会社一創では、こうした上流設計から本番運用までを[AWSを中心としたクラウドインフラ構築・運用支援](https://www.issoh.co.jp/service/system/aws/)で支援しています。CodeDeployとECSネイティブのどちらから始めるか、共有DBの移行をどう段階に分けるか、という判断の段階から相談できます。

## よくある質問

### Blue/Greenデプロイのデメリットは何ですか？

本番と同じ環境を2系統持つ費用と、新旧バージョンが同じデータベースを共有するための後方互換の設計が要ることです。切替直後もロードバランサーの登録解除の遅延やDNSのTTLの間は旧環境にリクエストが届くため、旧環境をすぐには止められません。

### ブルーグリーンという名前の由来は何ですか？

Martin Fowler氏のbliki（2010年3月1日）によると、名前はDaniel Terhorst-North氏とJez Humble氏が付けたものです。色に新旧の意味は無く、2つの環境を区別するラベルにすぎません。切り替えるたびに役割が入れ替わります。

### AWSでBlue/Greenデプロイをするにはどの方法がありますか？

ECSならECSネイティブのBlue/Green（2025年7月提供開始）かCodeDeploy、LambdaならCodeDeploy、Elastic Beanstalkなら環境URLのスワップです。データベースのバージョンアップにはRDSのブルー/グリーンデプロイを使いますが、これは切替後に複製が止まり、アプリのように向き先を戻す使い方はできません。

### Blue/Greenとカナリアリリースの違いは何ですか？

Blue/Greenは全トラフィックを一度に切り替え、カナリアは数％から比率を上げていきます。戻す速さを優先するならBlue/Green、本番の実トラフィックで影響を絞って検証したいならカナリアが向きます。2系統の間で比率を刻む折衷も組めます。

### KubernetesでBlue/Greenをする最小構成は何ですか？

`version: blue` と `version: green` の2つのDeploymentと、片方を指す1つのServiceです。selectorをgreenへ書き換えれば切り替わり、blueへ戻せば元に戻ります。昇格前の確認や旧版の縮小まで自動化するならArgo Rolloutsの `blueGreen` 戦略を使います。

## 関連記事

- [ECSネイティブBlue/Greenデプロイの設定手順｜ライフサイクルフック・ロールバック・CodeDeploy移行【2026年版】](/tech/details/7858/)
- [カナリアリリースとは？段階リリースの仕組み・他方式との違い・実装と採用判断を実装視点で解説](/tech/details/13592/)
- [ローリングアップデートとは？仕組みとKubernetes・ECSの設定値・採用判断を解説](/tech/details/16189/)
- [ゼロダウンタイムデプロイとは？無停止を壊す発生源と設定順序・計測方法を実装者目線で解説](/tech/details/16200/)
- [AWS CodeDeployとは？In-Place・Blue/Greenデプロイと料金・採用判断を実装者目線で解説](/tech/details/15597/)

---

出典: [Blue/Greenデプロイとは？仕組み・カナリアとの違いとKubernetes・AWS・RDSでの実装](<https://www.issoh.co.jp/tech/details/4040/>)（株式会社一創）