Amazon Route 53 は AWS の DNS サービス で、複数のルーティングポリシーを提供します。フェイルオーバールーティングは DR / 高可用性設計の中核です。本記事では Route 53 のルーティングポリシーと DR 設計を SAA / SAP 両面から整理します。

SAA レベル：基礎概念

Route 53 の 6 つのルーティングポリシー

Route 53 は 6 つのルーティングポリシー を提供します。この分類は SAA の超頻出です。

ポリシー	説明	ユースケース
シンプル (Simple)	単一リソースへルーティング	単純な DNS 解決
加重 (Weighted)	重み付きで複数リソースに分散	カナリアリリース、A/B テスト
レイテンシ (Latency)	最小レイテンシのリージョンへ	グローバルパフォーマンス最適化
フェイルオーバー (Failover)	プライマリ異常でセカンダリへ	DR / 高可用性
地理位置 (Geolocation)	ユーザーの地理でルーティング	データ主権、地域別コンテンツ
複数値回答 (Multivalue Answer)	複数 IP をランダム返却	簡易ロードバランシング

SAA レベル：基礎概念

Route 53 の 6 つのルーティングポリシーを一言で：

シンプル: 1 つへ
加重: 重みで複数へ
レイテンシ: 最速リージョンへ
フェイルオーバー: 障害時に切り替え
地理位置: 国/地域で切替
複数値回答: 複数 IP をランダムにこの分類と用途が SAA の基礎です。

フェイルオーバールーティングの基本

フェイルオーバールーティングは プライマリ異常でセカンダリへ DNS 切替 します。

Route 53: example.com
  ├── プライマリレコード (東京 ALB)
  │     ヘルスチェック: 東京 ALB を監視
  │     → Green ならプライマリを返す
  │
  └── セカンダリレコード (バージニア ALB)
        → プライマリ異常時にセカンダリを返す

SAA 試験のポイント

フェイルオーバールーティングは 「プライマリのヘルスチェックが連続 N 回失敗したらセカンダリへ切替」 です。ヘルスチェックは必須で、これが無いとフェイルオーバーできません。 SAA では「DR の DNS 切替」= フェイルオーバールーティング、が定番の正解です。

ヘルスチェック (Health Check)

Route 53 のヘルスチェックは エンドポイントの死活を監視 します。

監視対象: 外部エンドポイント、CloudWatch アラーム、他のヘルスチェック
監視間隔: 10 秒 or 30 秒
失敗閾値: 連続 N 回失敗で異常と判定
監視ロケーション: 全球の Route 53 チェッカーから監視

SAA 頻出

ヘルスチェックの閾値設計 は SAA で頻出です。

「連続 3 回失敗で異常」: 誤検知少ないが、検知に時間がかかる
「連続 1 回失敗で異常」: 検知速いが、一時的なネットワーク問題で誤切替リスク SAA では「連続 N 回」のトレードオフが問われます。

加重ルーティングの応用

加重ルーティングは 重み付きで複数リソースに分散 します。

カナリアリリース: 新バージョンに 5% だけ流す
A/B テスト: 2 つのバージョンを 50/50 で比較
段階的移行: 旧 → 新へ重みを徐々に移行

example.com
  ├── 旧 ALB (重み 90)
  └── 新 ALB (重み 10)
  → 90% が旧、10% が新にルーティング

SAP レベル：高度な設計シナリオ

フェイルオーバー + 加重の組み合わせ

SAP では 複数のルーティングポリシーを組み合わせる 設計が求められます。

SAP レベル：高度な設計シナリオ

SAP の DR 設計定石は 「フェイルオーバー + 加重」の組み合わせ です。

平時: 加重で 80% プライマリ / 20% セカンダリ（両方アクティブ）
障害時: ヘルスチェックでプライマリを除外、全トラフィックがセカンダリへこれで「マルチサイト (アクティブ・アクティブ)」を実現しつつ、段階移行も可能。

example.com (加重 + フェイルオーバー)
  ├── プライマリレコード (重み 80, ヘルスチェック付き)
  └── セカンダリレコード (重み 20, ヘルスチェック付き)
  → 平時: 80/20 で分散
  → プライマリ異常: 全トラフィックがセカンダリへ

レイテンシルーティングによるグローバル最適化

レイテンシルーティング は ユーザーから最も低レイテンシのリージョンへ誘導 します。

[ユーザー (東京)]
  ↓ Route 53 (レイテンシ評価)
  ├── 東京リージョン (レイテンシ 10ms) ← 選択
  ├── バージニアリージョン (150ms)
  └── シンガポールリージョン (50ms)

グローバルパフォーマンス最適化: ユーザー体験向上
マルチリージョン展開: 各リージョンのアプリがローカルユーザーにサービス
データ同期: アプリ層でデータレプリケーション設計が必須

レイテンシルーティングの前提

レイテンシルーティングは 「各リージョンに同じアプリが稼働」 が前提です。 DB は Aurora Global DB / DynamoDB Global Tables で同期が必要。 SAP では「レイテンシルーティング + マルチリージョン DB 同期」のセット設計が論点です。

地理位置ルーティング

地理位置ルーティング は ユーザーの国/地域でルーティング先を決定 します。

ユーザー国	ルーティング先	ユースケース
日本	東京リージョン	日本向けコンテンツ
EU	アイルランドリージョン	GDPR 準拠 (EU データ保持)
米国	バージニアリージョン	米国法規制対応

地理ルーティングとデータ主権

データ主権要件（GDPR 等）がある場合、地理ルーティングで「EU ユーザーは EU リージョンへ」 を強制できます。これをしないと EU ユーザーデータが米国リージョンに保存され規制違反リスク。 SAP では「地理ルーティング = データ主権の実現手段」として頻出します。

複数値回答ルーティング

複数値回答 は 複数の IP をランダムに返却 します。

簡易ロードバランシング: ELB を使わずに複数 EC2 へ分散
ヘルスチェック付き: 異常 IP は返却から除外
ELB との違い: ELB ほど高機能ではない（スティッキーセッション等は不可）

複数値回答 vs ELB

「ELB の方がロードバランシングとして高機能 で、複数値回答は簡易版です。複数値回答は「ELB を置けない特殊ケース」や「コスト最小化」向け。 SAP では「ELB が使えるなら ELB を推奨、複数値回答は簡易用途」と判断します。

トラフィックフロー (Traffic Flow)

Route 53 Traffic Flow は複雑なルーティングを 視覚的に設計 する機能です。

グラフィカルエディタ: ドラッグ&ドロップでルーティング設計
複数ポリシーの組み合わせ: 加重 + レイテンシ + フェイルオーバー等
バージョン管理: ルーティング設定の変更履歴管理
大規模環境向け: 数十のエンドポイントを管理

Traffic Flow の活用場面

「複数リージョン + 加重 + フェイルオーバー」等の複雑なルーティングは、 Traffic Flow で視覚的に設計 しないと管理が困難です。 SAP ではグローバル展開アプリで Traffic Flow の活用が論点です。

DNS キャッシュとフェイルオーバー遅延

DNS フェイルオーバーの 最大の敵は DNS キャッシュ です。

要因	影響	対策
TTL	クライアントが古い IP をキャッシュ	TTL を短く (60 秒以下)
リゾルバキャッシュ	ISP の DNS サーバーがキャッシュ	TTL 値の尊重設定
アプリの DNS キャッシュ	アプリが IP をキャッシュ	TTL を尊重する実装

DNS キャッシュの落とし穴

TTL を長く設定するとフェイルオーバーが遅延 します。 TTL = 1 時間だと、フェイルオーバー後も最長 1 時間は古い IP にアクセスし続ける。 SAP では「DR 用 DNS は TTL 60 秒以下」が定石です。

ヘルスチェックの高度な設計

SAP では ヘルスチェックの設計 がフェイルオーバー精度を決定づけます。

設計要素	推奨	理由
監視対象	ELB ヘルスチェックエンドポイント	アプリ実状を反映
監視間隔	10 秒	高速検知
失敗閾値	連続 3 回	誤検知と検知速度のバランス
文字列マッチ	HTTP レスポンスの特定文字列	アプリ論理死を検知
計算ヘルスチェック	複数ヘルスチェックの AND/OR	複合条件での判定

計算ヘルスチェックの活用

計算ヘルスチェック (Calculated Health Check) で「DB ヘルスチェック AND アプヘルスチェック」等の複合条件を定義できます。DB は生きているがアプリが死んでいるケースも検知可能。 SAP では「単純な TCP チェックよりアプリ論理レベルのチェック」が推奨されます。

CloudFront と Route 53 の連携

CloudFront + Route 53 でグローバル DR を設計します。

Route 53: example.com
  ├── プライマリ: CloudFront (プライマリオリージnl: 東京 ALB)
  └── セカンダリ: CloudFront (セカンダリオリジン: バージニア ALB)

CloudFront がフェイルオーバー: オリジン障害でセカンダリオリジンへ
Route 53 がフェイルオーバー: CloudFront 自体の障害で別 CloudFront へ
多層フェイルオーバー: CloudFront レベル + Route 53 レベル