大地震のような大規模な自然災害が発生した場合、 1 つのリージョンのすべてのゾーンで障害が発生する可能性があります。
このような広域災害が発生した場合に備えて、一般的には事業継続計画（BCP : Business Continuity Plan）と呼ばれるシステムの復旧計画についても立案する必要があります。
システムの性質によっては、災害時にすぐに必要とせず、メイン リージョンの復旧を待つことができるものもあります。災害時における全体的な優先度や、スタンバイ システムにかかる維持コストを考慮して、必要性を検討することが重要です。
また、システムだけでなく、災害発生時に誰がどのような手順で対応するか、より広範囲な復旧計画を立てる必要があります。
ここでは、アプリケーションの設計に関するポイントに触れますが、全般的な障害復旧計画については解説しません。障害復旧計画の詳細については、下記のドキュメントを参照ください。

• 障害復旧計画ガイド
  広域災害発生時の復旧方式は、システムの性質に大きく依存します。特に、求められる目標復旧時間（RTO : Recovery Time Objective）と目標復旧時間目標（RPO : Recovery Point Objective）、およびアプリケーションの実装によります。以下に主要な障害復旧の方法を３つ示します。これらの選択肢の中から適切なものを選択してください。

復旧時にリソースを作成

スタンバイ システムを作成せず、復旧作業が必要となる際に、1 からクラウド リソースを作成する方法です。いつ利用するかわからないスタンバイ システムにかかるコストを削減できます。Config Connector や DevOps ツールを導入し、復旧作業を自動化します。災害発生時の混乱の中、迅速な対応や属人的なミスを防ぐためにも自動化は重要となります。 データベースなど業務データを持つアプリケーションの場合、データの復旧もあわせて必要となります。そのため、復旧時に 1 からリソースを作成する場合においても、データに関しては別途バックアップを取得し、セカンダリ リージョンに保管する必要があります。 Compute Engine の VM インスタンスのスナップショットは、異なるリージョンに保存することもできます。災害発生時には、セカンダリ リージョンに保存されたスナップショットより仮想マシンを復旧します。

セカンダリ リージョンにあらかじめスタンバイ環境を構築

セカンダリ リージョンにあらかじめ環境を作成し、復旧作業時に立ち上げ、切り替える方法です。災害発生時にリソースを作成するよりも、比較的混乱なく作業を進めることができます。 Compute Engine などは、未使用時にシャットダウンすることでコストを削減することができますが、ディスクなどの一部のリソースはシステムのスタンバイ時にも課金されます。 データベースなど、業務データを持つアプリケーションの場合、データの復旧もあわせて必要となります。データに関しては、バックアップし、セカンダリ リージョンに保管する必要があります。

セカンダリ リージョンにアクティブな環境を構築

目標復旧時間が非常に短い時間で、スタンバイ システムを立ち上げる方式では対応できない場合、複数のリージョンでアクティブ・アクティブの構成を取る必要があります。 また、求められる目標復旧時間が非常に短い時間でバックアップ データの転送方式では対応できない場合、プライマリ リージョンのデータベースとセカンダリ リージョンのデータベース間で、レプリケーションの構成を行うことが求められます。レプリケーションの方法は、製品によって異なります。マルチリージョンに対応した Cloud Spanner を採用することで、データベース間のレプリケーションを完全に自動化することも可能です。 

いずれの方法においても、実際に障害が発生した場合に想定どおりに復旧することができるか、計画の実効性を確認するために、定期的にテストを行う必要があります。