本連載を通じて、AWS Active-Active マルチリージョン構成の設計思想から、アーキテクチャの全体像、フェイルオーバー試験の記録、さらには構築の現場で直面した実装上の課題や本番導入に向けた改善ポイントまで、幅広く詳細に記録してきました。

本章は締めくくりとして、これまでの知見を俯瞰する形でまとめます。ご自身のプロジェクトにおける「本番導入の判断材料」として活用いただければさいわいです。

1. 本件を通じて得られた主な知見

知見1: Pilot Light と Active-Active は「コストのトレードオフ」ではなく「設計思想の違い」

「Active-Active は高いが、Pilot Light はコストを抑えられる」という比較は一面的です。Pilot Light 構成には、普段停止している環境が障害時に確実に起動することを保証し続けるコストが隠れています。起動スクリプトのメンテナンス、定期的な起動試験、バージョン乖離の管理……これらは「稼働していないから安い」とは言い切れない運用負荷を生み出します。

一方、Active-Active 構成は「常時稼働していること」が逆にシンプルさの源泉になる側面もあります。両リージョンが常にトラフィックを処理し続けているため、フェイルオーバーが「切り替え」ではなく「重みの変更」として完結し、稼働確認も日常的なトラフィック監視の中で行われます。

どちらが優れているかではなく、RTO/RPO の要件、予算規模、チームのインフラ習熟度によって判断することが重要です。

知見2: Aurora Write Forwarding の可能性と実運用に向けた留意点

本環境において、大阪リージョンから記事を投稿するといった WordPress の基本的な書き込み操作は、Write Forwarding を通じて東京プライマリへ転送され、期待通りに機能することを確認できました。

この結果は、マルチリージョン構成における Write Forwarding の実用性を裏付ける結果となります。ただし、実際の導入にあたっては、個別のワークロードに応じた負荷試験や、aurora_replica_read_consistency 等のセッション変数のチューニングを設計段階から織り込んでおくことで、システム全体の信頼性を高めることができるでしょう。

知見3: EFS レプリケーションの昇格に「手動介入」が必要なことこそが RTO のネック

本構成における EFS の昇格（レプリケーション設定の削除）のプロセスでは、状況の判断や手動オペレーションといった「人的要因」が所要時間に大きく影響します。これは、純粋なシステム上の切り替え時間とは別に、運用フローとしてのリードタイムを考慮する必要があることを示唆しています。

より本質的な課題は、EFS Replication の昇格には標準の自動化手段が存在しないという点にあります。Route 53 のヘルスチェックに基づくフェイルオーバーや、Aurora の自動フェイルオーバー機能と比較すると、EFS のストレージ昇格だけが「人間の判断と操作」を必要とするボトルネックとして残ります。ファイルストレージの RTO をどこまで短縮・自動化するかは、要件定義の段階で明確にしておく必要があります。

知見4（最大の教訓）: ドキュメントには書かれていない「実装上の壁」に向き合うことの価値

本連載の第4章で詳述したように、マルチリージョン構成の構築において最も多くの時間を費やすのは、AWS の公式ドキュメントを読んでも事前に想定できない「実装上の壁」です。

• VPC の DNS 解決属性のデフォルト値を把握していなければ、PHZ（プライベートホストゾーン）との接続が無言で失敗し続ける
• ALB の HTTPS 終端が PHP アプリケーションの $_SERVER 変数に与える影響は、フレームワークの動作を熟知していなければ気づきにくい
• AMI の参照不一致は、起動時にエラーを出さないまま古いイメージで稼働し続ける

このような問題は、いずれも「実機でフェイルオーバー試験を実際に動かす」ことで初めて表面化しました。理想的なアーキテクチャを設計することと、それを動かし続けることの間には、こうした実装上の確認プロセスが不可欠です。

2. Active-Active 構成の採用判断軸

これまでの内容を踏まえ、Active-Active 構成の採用が適しているケースと、そうでないケースを整理します。

採用が適しているケース

• RTO が数分以内という厳しい可用性要件がある
• トラフィックが地理的に分散しており、最寄りのリージョンへのルーティングによるレイテンシ改善の効果が見込める
• 常時2リージョン分の稼働コストを吸収できるビジネス規模がある
• マルチリージョンの複雑な構成を設計・維持できるチームのインフラ習熟度がある

慎重な検討が必要なケース

• トラフィックが特定リージョンに集中しており、Active-Active の恩恵が薄い
• 運用人員が限られており、複雑な構成の中でミスが見落とされやすい環境
• 障害時に数十分の復旧時間が許容されており、コスト優先度が高い（Pilot Light 構成で要件を満たせる）

コストの現実

本環境の試算では、常時稼働する EC2 インスタンスの追加、Aurora Global DB の利用料、2リージョン分のデータ転送コスト等により、Pilot Light 構成と比較してインフラ費用が相応に増加します。スペックや構成にもよりますが、その差は無視できないレベルになるため、ビジネス上の可用性要件とのバランスで判断することになります。

コラム: 管理リソース（コントロールプレーン）のDRはどう考えるべきか

アプリケーション本体の冗長化は入念に設計されていても、「それを管理するインフラ自体のDR」が抜け落ちているケースは少なくありません。

本件においても、EC2 ゴールデンイメージのビルドを担う EC2 Image Builder パイプラインや、構築時に使用した管理スクリプト群は、東京リージョンにのみ存在しています。東京リージョンで長期的な障害が発生した場合、アプリケーション自体のトラフィックは大阪へ切り替わりますが、「新しいゴールデンイメージをビルドする」「インスタンスを増やす」といったオペレーションは一時的に実行不能になります。

この問題を整理するひとつの切り口として、「ランタイム」と「コントロールプレーン」の可用性要件を分けて考えるという視点があります。

多くの場合、コントロールプレーンが停止しても、既存のインスタンスが動いている間はエンドユーザーへの影響は発生しません。そのため、コントロールプレーンはシングルリージョン構成を許容しつつ、IaC やドキュメントによる「再構築の容易さ」を確保する方向に投資するのが現実的なアプローチです。

具体的には、IaC コード（Terraform / CloudFormation）を Git リポジトリで管理し、Terraform のステートファイルは S3 + DynamoDB で管理したうえで S3 のクロスリージョンレプリケーションで保護しておくことで、別リージョンへの再構築コストを大幅に低減できます。

おわりに

本連載を最後までお読みいただき、ありがとうございました。

本連載でお伝えしたかったことは、AWS マルチリージョン Active-Active 構成の「正解の手順」ではありません。理想的なアーキテクチャを設計することと、それを実際に動かし続けることの間には、公式ドキュメントには載っていない数多くの「実装上の確認プロセス」が存在します。本連載で記録した試行錯誤の跡が、「徹底したテストと実践的なトラブルシューティング」の価値を示せていればさいわいです。

弊社では、今回のような技術的な取り組み（Proof of Concept）やインフラ設計の技術確認を、クラウド・ネットワーク・セキュリティなど様々な領域で日常的に行っています。「机上の空論」では終わらせない、実際に手を動かして技術的な壁を乗り越えてきた『生きた知見（実践知）』をもって、お客様の課題に全力で向き合います。

「インフラの可用性向上に課題を抱えている」「マルチリージョン化を検討しているが最初の一歩が踏み出せない」という方は、ぜひ一度弊社へご相談ください。