2025/11/15更新

2025/11/14に、Blue/GreenデプロイメントがAurora Global Databaseをサポートするようになりました。
本記事は、それ以前にこういうことを考えていたのか、という視点でご確認ください。
Global DatabaseでのBlue/Greenデプロイメントについての構成と、AWSの公開情報を記載しておきます。

2025/11/14に公開されたアップデート情報はこちらです。

また、ブログで構成も説明されていました。
プライマリクラスター/セカンダリクラスターの双方にGreen環境が構築されるようです。
詳細はAWSブログをご確認ください。

2025/3/5更新

2025/3/1に開催されたJAWS DAYS 2025のTrack：A-7にて本記事の内容も含むテーマで登壇しましたので、登壇スライド資料も掲載します。

セッション：Global Databaseで実現するマルチリージョン自動切替とBlue/Greenデプロイ

はじめに

AWSでMySQL、PostgreSQLを利用している方は、Auroraを利用している方が多いのではないでしょうか。

そして、Auroraをマルチリージョンで運用するために、Global Databaseを利用している方や、利用を検討している方も多いのではないでしょうか。

そんなAuroraですが、RDSでも提供されている、メンテナンス（バージョンアップなど）による停止時間の極小化や、パラメータの変更を事前にGreen（ステージング）環境で確認したのちに切り替えが可能なBlue/Greenデプロイ機能も提供されています。

ただし、本記事執筆時点においては、Blue/Greenデプロイ機能はGlobal Database構成では利用できないなど、以下の機能はサポートされていません。

ブルー/グリーンデプロイは、以下の機能ではサポートされていません。
・Amazon RDS Proxy
・クロスリージョンリードレプリカ
・Aurora Serverless v1 DBクラスター
・Aurora Global Databaseの一部であるDBクラスター
・AWS CloudFormation

それでもBlue/Greenデプロイしたい

Global DatabaseでもBlue/Greenデプロイできる選択肢を持てないかな、から考えてみました。

本記事では、Global Database（マルチリージョン）構成で運用しつつ、バージョンアップなどのメンテナンス作業時において停止時間を極小化するBlue/Greenデプロイを実現する方式について紹介します。

なお、本記事は以下のブログからBlue/Greenデプロイについて抜粋し、一部内容を追加したものとなります。

Blue/Greenデプロイだけではなく、Global Databaseを利用した自動切り替えについて、RPO：0秒/RTO：5分を実現した事例や、3種類あるGlobal Databaseの切り替え方式の違いやユースケースを紹介していますので、興味を持たれた方はご確認いただければと思います。

Global Database構成とBlue/Greenデプロイ機能の併用

以下の流れで実現可能です。

1.　通常はGlobal Database構成（Blue/Greenなし）で運用しつつ、プライマリリージョン内でのメンテナンス対応時は一時的に手動フェールオーバーによりGlobal Database構成を解除することで、Blue/Green構成に変更

2.　メンテナンスを実施したGreen環境への切り替え後に、再度Global Database構成とする（Green環境への切り替え後は、Blue/Green構成ではなくなっているため、Global Databaseを再構築することが可能）

概要図と合わせて、もう少し細かい動作を見ていきます。

①通常時はGlobal Database構成で運用

②手動フェールオーバー（remove-from-global-cluster）することで、Global Database構成を解除

③Blue/Green構成とし、Green環境でメンテナンスを実施、Green環境へ切り替え（Blue/Green構成の解除）

④切り替えが完了しBlue/Green構成ではなくなったタイミング以降で、Global Database再構築

一度Global Databaseを解除した場合、もともとのセカンダリクラスターであった既存のインスタンスを再度Global Database構成に組み込むことや、再同期はできません。インスタンス、ストレージから新規に再構築が必要となります

手動フェールオーバー、Blue/Green構成への変更、再構築時におけるプライマリクラスターへの影響はありません。
影響は、Green環境への切り替え時の1分程度の通信断のみとなります。

メンテナンス時間はどれだけ変わる？

例えば、Global Database構成でマイナーVerupを行う場合は通信断が発生してしまうので、無影響で作業を行う場合は、サービスを閉塞するまでAuroraに対する作業を実施することはできません。
サービス閉塞後の静止断面でスナップショットを取得しておきたいという要望もあるでしょう。

マイナーVerupは、①Global Databaseのセカンダリクラスター　→　②プライマリクラスターの順に適用され、1時間程度は時間がかかります。

Verup後、打鍵確認を行い閉塞解除とする場合、少なくとも2時間程度はサービスを閉塞する必要があると考えられます。

一方、Blue/Green構成としておき、Green環境のVerup、打鍵確認がサービス閉塞前に可能な場合は、サービス閉塞後に1分あればVerupされたGreen環境への切り替えが可能となります。
打鍵確認も済んでいるので即時閉塞解除も可能であり、メンテナンス時間を極小化できると考えられます。

なお、マルチリージョン構成とするため、Global Databaseの再構築は必要となりますが、無影響で実施が可能です。
再構築にかかるAWS利用料が気になる方もいらっしゃるかもしれませんが、インスタンス利用料以外ですと、リージョン間のデータ転送料のみとなります（東京-大阪間の場合は、USD 0.09/GBです。仮にデータ量が2TBとすると、$180程度の料金となります）。

さいごに

Global Database構成を解除し再構築が完了するまでの間は、DBはマルチリージョン構成ではなく、別リージョンへのデータ同期ができていない時間帯が発生しますが、様々な要件に応えるための選択肢のひとつとできるのでは、と考えます。

Global Databaseを利用している方、これから検討、提案しようと考えている方や、特にGlobal DatabaseでもBlue/Greenできればなと思っていた方の参考に少しでもなればと思います。

なお、Aurora PostgreSQLについては、Blue/Green構成にするためには論理レプリケーション (rds.logical_replication) が有効となっている必要があること、rds.logical_replicationなどのパラメータを有効にするには、Writerインスタンスの再起動が必要となることなど、いくつか制約があるので注意しましょう。