outputAWSマルチリージョン設計入門｜グローバル展開と高可用性を実現するアーキテクチャパターン完全ガイド

東京リージョン1つで運用してきたシステムが、大規模障害で数時間止まった。そのとき初めて「マルチリージョンにすべきだったか」と考えるエンジニアは少なくない。しかし実際に設計しようとすると、Active-ActiveとActive-Passiveのどちらを選ぶべきか、データベースはどう複製するか、コストはどこまで膨らむのかが見えずに手が止まってしまう。

オンプレ環境では「DR拠点を別データセンターに用意する」のが一般的だったが、AWSのマルチリージョン設計はそれをはるかに超える柔軟性を持っている。単なる障害対策にとどまらず、グローバルユーザーへの低レイテンシ配信や、GDPR等の規制に対応したデータ所在地管理にも活用できる。

この記事では、AWSマルチリージョン設計の2大パターンから、データ複製の具体的な実装方法、フェイルオーバーの自動化、コスト管理の実践まで、オンプレ経験者にもわかりやすく解説する。

なぜマルチリージョンが必要か——シングルリージョンの限界

AWSには33を超える地理的リージョンがあり（2026年3月時点）、それぞれが独立したインフラとして設計されている。東京リージョン（ap-northeast-1）でマルチAZ構成を組めば、AZ単位の障害からは守られる。しかし、リージョン全体に影響が及ぶ障害が起きたとき、マルチAZでは対応できない。

過去にはAWS東部リージョン（us-east-1）で発生した大規模障害が記憶に新しい。現在はAWSが世界中のサービスの基盤となっているため、リージョン障害は自社システムだけの問題ではなく、エンドユーザーへの直接的な影響につながる。

シングルリージョン構成の主な限界は3点だ。

・リージョン障害への無防備: マルチAZで守れるのはAZ単位の障害まで。リージョン規模の障害には対応できない
・グローバルユーザーへのレイテンシ: 東京リージョンのみで運用すると、北米や欧州のユーザーへのレスポンスタイムが物理的に大きくなる
・データ所在地の規制: GDPRや金融規制など、データを特定の地理的領域に保存することを求める法規制に対応できない場合がある

マルチリージョン設計の2大パターン

1. Active-Passive（アクティブ・パッシブ）

プライマリリージョンがすべてのトラフィックを処理し、セカンダリリージョンは待機状態を保つ構成だ。オンプレのDRサイトに相当するイメージで、障害発生時にセカンダリがプライマリの役割を引き継ぐ。

・RTO（目標復旧時間）: フェイルオーバーの実行・確認に数分から数十分かかる
・RPO（目標復旧時点）: データ複製の遅延（ラグ）によって決まる。非同期複製の場合、最新トランザクションが一部失われる可能性がある
・コスト: セカンダリ側を最小限のリソースで待機させられるため、Active-Activeより低コストで実現できる

業務システム・社内ツール・バックオフィスアプリなど、「数分程度の停止は許容できるが、データは確実に守りたい」という要件のシステムに向いている。

2. Active-Active（アクティブ・アクティブ）

複数のリージョンが同時にトラフィックを処理する構成だ。どちらのリージョンで障害が発生しても、残りのリージョンがすべてのリクエストを引き受けるため、RTOは秒単位に近づく。

・RTO: DNS切り替えに依存するが、適切に設定すれば秒単位のフェイルオーバーが可能
・RPO: データ同期がほぼリアルタイムであれば、ほぼゼロに近づく
・コスト: 両リージョンで本番相当のリソースを常時稼働させるため、コストは2倍以上になりやすい

グローバルサービス・Eコマース・金融系アプリケーションなど、ダウンタイムの損失がインフラコストをはるかに上回るシステムに向いている。

データ複製の設計——サービス別の選び方

マルチリージョン設計の最大の難所はデータの扱いだ。ステートレスなアプリサーバーは複数リージョンにデプロイするだけでいいが、データベースや状態を持つコンポーネントはそう単純にはいかない。

3. Amazon RDS Cross-Region Read Replica

RDSのマルチリージョン構成では、クロスリージョンリードレプリカを使う。プライマリインスタンスへの更新が非同期でセカンダリリージョンのレプリカに複製される。

# クロスリージョンリードレプリカを作成する例（AWS CLI）
# プライマリ: 東京リージョン（ap-northeast-1）のRDSを複製先へ
aws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica-singapore \
  --source-db-instance-identifier \
    arn:aws:rds:ap-northeast-1:123456789012:db:mydb-primary \
  --db-instance-class db.r6g.large \
  --region ap-southeast-1

フェイルオーバー時には手動または自動でレプリカを「昇格（Promote）」し、書き込み可能なスタンドアロンインスタンスへ変換する。Aurora グローバルデータベースを使えば、RPO 1秒以下・RTO 1分以内のフェイルオーバーを実現できる。通常のRDSよりコストはかかるが、RPO要件が厳しいシステムではAuroraグローバルデータベースを選ぶ価値がある。

4. Amazon DynamoDB Global Tables

DynamoDBのグローバルテーブルは、Active-Active のマルチリージョン複製を実現するマネージドサービスだ。複数リージョンで同時に書き込みが可能で、変更は数秒以内に他リージョンへ伝播する（最終的整合性）。

# グローバルテーブルに新しいリージョンを追加する例（AWS CLI）
aws dynamodb update-table \
  --table-name MyGlobalTable \
  --replica-updates '[{"Create": {"RegionName": "us-east-1"}}]' \
  --region ap-northeast-1

オンプレのRDBに慣れているエンジニアが陥りやすいのが「コンフリクト問題」だ。同じキーに対して2つのリージョンが同時に書き込んだ場合、DynamoDBは「最後の書き込みが勝つ（last-write-wins）」ポリシーで解決する。在庫管理やポイント残高のようなビジネスロジックでは、アプリケーション側でコンフリクト検知と補正ロジックの設計が別途必要になる。

5. Amazon S3 Cross-Region Replication（CRR）

S3のオブジェクトをリージョン間で非同期複製する機能だ。画像・ドキュメント・ログファイルなどの静的コンテンツのDR対策として使う。

・設定方法: S3バケットの「管理 → レプリケーションルール」から有効化する
・コスト: 複製データのGB単位のレプリケーション料金＋リージョン間データ転送料金がかかる（2026年3月時点でレプリケーション料金は$0.015/GB）
・注意点: CRR有効化後に作成したオブジェクトが対象となる。既存オブジェクトはS3 Batch Operationsを使って別途複製する必要がある

トラフィックルーティングの設計

6. Amazon Route 53 フェイルオーバーポリシー

Route 53はDNSベースのルーティングでマルチリージョンのフェイルオーバーを実現する中核サービスだ。Active-Passive 構成では「フェイルオーバールーティングポリシー」を使い、プライマリのヘルスチェックが失敗した際にDNSを自動でセカンダリへ向ける。

# Route 53 フェイルオーバー設定の概念フロー（コンソール操作）
#
# 1. プライマリレコードを作成
#    ルーティングポリシー: フェイルオーバー
#    フェイルオーバーレコードタイプ: PRIMARY
#    ヘルスチェック: 東京リージョン（ap-northeast-1）のALBエンドポイントを監視
#
# 2. セカンダリレコードを作成
#    ルーティングポリシー: フェイルオーバー
#    フェイルオーバーレコードタイプ: SECONDARY
#    ヘルスチェック: 大阪リージョン（ap-northeast-3）のALBを監視

重要な注意点として、DNS の TTL（Time to Live）がある。TTL を3600秒（1時間）に設定したままにすると、フェイルオーバーが発生してもキャッシュが残っている間は旧IPに向き続ける。フェイルオーバー対象のレコードはTTLを60秒以下に設定すること。

Active-Active 構成では「レイテンシールーティングポリシー」を使う。ユーザーの接続元から最も応答時間が短いリージョンへ自動的にルーティングされるため、グローバルユーザーへのレイテンシを最小化できる。

7. Amazon CloudFront でのマルチオリジン設定

静的・動的コンテンツのエッジキャッシュには Amazon CloudFront を組み合わせる。複数のオリジン（リージョンごとのALBやS3バケット）を設定し、「オリジンフェイルオーバー」を有効化することで、プライマリオリジンが異常になった際にセカンダリオリジンへ自動で切り替わる仕組みを作れる。

姉妹サイトLinuxMaster.JPのLinuxサーバー基礎と組み合わせると、クラウド上のLinux環境でのマルチリージョン運用への理解がさらに深まる。

フェイルオーバー自動化の設計

フェイルオーバーを手動で実行していては、RTOの短縮に限界がある。以下のAWSサービスを組み合わせて自動化を実現する。

・Route 53 ヘルスチェック: エンドポイントの死活を30秒間隔で監視し、異常検知時にDNSを自動切り替えする
・Amazon EventBridge: RDSフェイルオーバーイベントやEC2インスタンス停止イベントをトリガーに、AWS LambdaやStep Functionsを自動実行する
・AWS Systems Manager Automation: フェイルオーバー手順をランブックとして定義し、承認フロー付きで自動実行する

自動化設計で注意すべきは「スプリットブレイン」問題だ。ネットワーク分断で2つのリージョンが互いに相手の障害と誤認した場合、両方がプライマリとして動作してしまう。DynamoDB Global Tables のようなマネージドサービスはAWS側がこの問題を処理してくれるが、RDBをActive-Active構成で自前設計する場合は難易度が大幅に上がる。

多くの現場では、まずActive-Passiveから始めてフェイルオーバー自動化を確立させ、事業要件が固まってからActive-Activeへの移行を検討するのが現実的なアプローチだ。

コストのリアル——マルチリージョンはいくら上乗せになるか

マルチリージョン設計のコスト増加は主に3つの要因から来る。

コストとRTOのバランスを取るための代表的なアプローチが、スタンバイ形式の段階的な選択だ。

・コールドスタンバイ: セカンダリ側はAMIやスナップショットのみを保持し、障害時にEC2を起動する。コストは最小だがRTOが10分以上になる
・ウォームスタンバイ: セカンダリ側を最小構成（本番の1/4スケール程度）で常時稼働させる。RTO数分、コストは中程度
・ホットスタンバイ（Active-Active）: セカンダリも本番スケールで常時稼働。RTOは秒単位、コストは最大

予算が限られている場合は、まずコールドスタンバイから始めてDR手順を確立し、事業の成長に合わせてウォームスタンバイへ移行するのが現実的だ。

よくあるトラブルと対処法

8. DNS TTLを長く設定していてフェイルオーバーが遅い

Route 53のレコードにTTL 3600秒を設定したままにすると、フェイルオーバーを開始しても1時間は古いIPに向き続けるリスクがある。フェイルオーバー対象のAレコードやCNAMEレコードはTTLを60秒以下に設定すること。TTLを短くするとDNSの問い合わせが増えてRoute 53の料金がわずかに増えるが、フェイルオーバー品質に比べれば無視できる水準だ。

9. RDS Read Replicaが昇格されず読み取り専用のまま

クロスリージョンのリードレプリカは、フェイルオーバー時に自動で書き込み可能なインスタンスへ昇格しない（RDSのデフォルト動作）。事前にSystems Manager AutomationのランブックやLambdaで昇格を自動化しておかないと、フェイルオーバー後もセカンダリが読み取り専用のまま運用されてしまう。Auroraグローバルデータベースを選択すれば、このフェイルオーバーがより管理しやすくなる。

10. Active-Activeのコンフリクトに気づかないまま運用

DynamoDBグローバルテーブルで2つのリージョンから同じアイテムを同時更新した場合、last-write-winsポリシーで一方の更新が上書きされる。アプリケーションログで追わないと、データが静かに消えていることに気づかないまま運用してしまう。DynamoDB Streamsを有効化してコンフリクト発生を検知する仕組みを最初から組み込んでおくことを推奨する。

11. リージョン間データ転送料金が予想を大幅に超える

マルチリージョン構成を導入した直後から、月次のデータ転送料金が急増するケースがある。事前にAWS Cost Explorerでリージョンごとのデータアウトバウンドをチェックし、AWS Cost Anomaly Detectionでアラートを設定しておくと早期に異常を検知できる。

よくある質問（FAQ）

Q. 東京リージョンと大阪リージョンの組み合わせで問題ないか？
大阪リージョン（ap-northeast-3）は東京（ap-northeast-1）と同じ国内に位置するため、国内法規制への対応や日本語コンテンツのレイテンシ最小化に有利だ。ただし、大規模な自然災害など国内全体に影響が及ぶリスクへの備えとしては、海外リージョンとの組み合わせが望ましい場合もある。要件に応じて判断すること。

Q. Aurora Global DatabaseとRDS Cross-Region Read Replicaはどちらを選ぶべきか？
RPOが1秒以下・RTOが1分以内という要件があるならAurora Global Database一択だ。コストはRDSのクロスリージョンレプリカより高いが、フェイルオーバーの信頼性と速度が段違いに高い。「数分のRPO/RTOで構わない」という要件であれば、コストを抑えたRDS Cross-Region Read Replicaが現実的な選択肢になる。

Q. マルチリージョン設計は最初から必要か、後から追加できるか？
アプリケーションをステートレスに設計し、データはマネージドサービスに任せる構成を最初から取っていれば、後からマルチリージョン化は比較的容易だ。しかし、DB直接接続や固定IPを多用したモノリシックな構成だと、後からの対応コストが非常に高くなる。最初から「マルチリージョンに移行できる設計」を意識しておくことが重要だ。

Q. Route 53のヘルスチェックはどこに設置すべきか？
Route 53のヘルスチェックはAWSのグローバルインフラから実行されるため、ユーザーが実際にアクセスするエンドポイント（ALBのDNS名やCloudFrontのディストリビューションドメイン）に設定するのが基本だ。EC2インスタンスのプライベートIPを直接指定することはできないので注意が必要だ。

本記事のまとめ

オンプレのDR設計と比べると、AWSのマルチリージョン設計ははるかに柔軟で迅速に構築できる。ただし、柔軟性の裏にはデータ整合性の管理とコスト膨張という新たな課題がある。まずActive-Passive＋コールドスタンバイで小さく始め、フェイルオーバー手順を確立してから段階的にスケールアップしていくアプローチが現場に合っている。