導入
前のレッスンのDR戦略を実現するには、複数リージョンにトラフィックとデータをどう配るかという具体的な仕組みが必要です。ここでは「振り分け」と「データ複製」の2つの柱を見ます。
説明
Amazon Route 53 はDNSサービスですが、SAAでは フェイルオーバールーティング の役割が重要です。プライマリリージョンのヘルスチェックが失敗すると、Route 53は自動的にセカンダリリージョンへトラフィックを振り向けます。
flowchart TD
U["利用者"] --> R53["Route 53<br/>（ヘルスチェック監視）"]
R53 -->|"正常時"| Primary["プライマリリージョン"]
R53 -.->|"障害検知時に切替"| Secondary["セカンダリリージョン"]
トラフィックを切り替えても、そのリージョンにデータがなければ意味がありません。そこで各サービスにはリージョンをまたいだデータ複製の仕組みが用意されています。
| サービス | 複製の仕組み | 特徴 |
|---|---|---|
| S3 | クロスリージョンレプリケーション（CRR） | バケット間でオブジェクトを自動複製 |
| Aurora | Aurora Global Database | プライマリリージョンへの書き込みを1秒未満のレイテンシーで他リージョンへ複製、読み取り専用リージョンを複数持てる |
| DynamoDB | グローバルテーブル（Global Tables） | 複数リージョンでマルチマスター（どのリージョンでも書き込み可能）の完全マネージドレプリケーション |
flowchart LR
subgraph Region1["東京リージョン"]
S3a["S3バケット"]
Auroraa["Auroraプライマリ"]
end
subgraph Region2["大阪リージョン"]
S3b["S3バケット"]
Aurorab["Aurora読み取りレプリカ"]
end
S3a -- "CRR" --> S3b
Auroraa -- "Global Database" --> Aurorab
これらを組み合わせることで、「リージョン障害が起きてもRoute 53で切り替え、データも複製済みなのですぐ使える」という、レッスン48の高度なDR戦略（ウォームスタンバイ以上）を実現できます。
具体例
「東京リージョンが全滅しても止まらない」構成を設計する会社を例に、よくある片手落ちの失敗から考えましょう。
ある担当者は、Route 53のフェイルオーバーだけを設定しました。「東京が落ちたら大阪へ切り替わる」と満足していましたが、いざ切り替わった大阪リージョンにはデータが1バイトもありませんでした。トラフィックだけ流れても、データがなければ何も表示できません。
正しい設計は、「振り分け」と「データ複製」の両輪です。
- 振り分け … Route 53のフェイルオーバールーティング＋ヘルスチェックで、東京異常時に大阪へ自動切り替え
- データ複製 … S3はCRRで大阪へ、AuroraはGlobal Database（1秒未満の遅延）で大阪に読み取りレプリカを、DynamoDBはGlobal Tablesでマルチマスター複製
この両方が揃って初めて「切り替え先に、使えるデータがある」状態になり、ウォームスタンバイ以上のDRが成立します。SAAで「リージョン障害に備えたい」と来たら、選択肢に振り分けとデータ複製の両方が含まれているかを必ず確認します。片方だけは不十分です。
読んでみよう
「リージョン全体の障害に備えたい」という問題文が出たら、「トラフィックの切替（Route 53フェイルオーバー）」と「データの複製（CRR / Global Database / Global Tables）」の両方がセットで揃っているか確認しましょう。片方だけでは災害対策として不十分です。