SAA学習：Route 53のルーティングと可用性を要件から判断する

Route 53のルーティングポリシーを覚えても、「障害時に切り替えたい」「一部だけ新環境へ送りたい」「世界中の利用者の応答を速くしたい」という要件から、適切な構成を選べるとは限りません。

この記事では、何を選び、何を根拠にその方式を選ぶのかを整理します。DNS・ホストゾーン・レコード・TTLなどの機能自体を先に確認したい場合は、下記の記事を参照してください。

Amazon Route 53とは？できること・各機能・動作の仕組みを解説 Route 53の役割と用語、名前解決や回答選択の仕組みを基礎から確認する

SAA-C03の出題範囲とこの記事の関係

AWS公式のSAA-C03試験ガイドでは、Route 53は試験範囲内のサービスに含まれています。

特に、ドメイン2・タスク2.2には、Route 53、フェイルオーバー戦略、RTO/RPO、リージョンやAZをまたぐ高可用性の設計が挙げられています。ドメイン3・タスク3.4では、ネットワーク構成や負荷分散方式の選択が扱われています。

ここから先の比較軸とシナリオは、公式ドキュメントをもとに学習用に整理したものです。公式問題の転載や、各機能の出題頻度を示すものではありません。

最初に、要件を4つに分けて読む

サービス名を探す前に、次の4点を言葉にしてみます。

判断すること	要件から拾う情報	判断への影響
名前解決か、実際の通信か	DNS名で接続するか、固定IPへ接続するか。HTTPのパスやセッションも見るか	Route 53で解決できる部分と、ロードバランサーなどが必要な部分を分ける
公開範囲はどこか	インターネット、VPC内、社内ネットワークとの相互接続	パブリック／プライベートホストゾーンやDNS転送を検討する
接続先を何で選ぶか	正常性、割合、遅延、地理的位置	ルーティングポリシーを比較する
切替後にサービスを継続できるか	許容停止時間、待機先の能力、データ・セッションの扱い	DNS以外に必要な冗長化や復旧を洗い出す

たとえば「東京リージョンの障害時に、大阪リージョンへ切り替える」という要件には、DNSの回答を変える判断に加え、大阪側で注文処理を続けられるかという別の判断があります。

判断1：ALBを独自ドメインで公開したい

要件を具体化する

ネットショップを example.com で公開したいとします。Webアプリケーションの入口はALBで、ALBのIPアドレスは自分で固定管理しません。

この場合、Route 53のAレコードでAliasを有効にし、ALBを参照する構成が候補になります。IPv6の名前解決も必要なら、参照先の対応を確認したうえでAAAAのAliasも検討します。

なぜこの方式を選ぶのか

ALBのIPアドレスを調べて通常のAレコードへ固定すると、サービス側のアドレス変更を追従する仕組みを自分で持つ必要があります。対応するAWSリソースへのAliasなら、そのリソースを参照できます。

また、ホストゾーンの頂点にある example.com にはCNAMEを作れません。www.example.com のような配下の名前と、ゾーン頂点では選べる方式が異なります。

Aliasは任意のドメインへ使える汎用的な別名ではない点も確認します。参照先は対応するAWSリソースなどに限定されます。AliasとCNAMEの比較が根拠です。

条件が変わったら

www.example.com を、外部サービスが指定する service.example.net へ対応させたい場合は、CNAMEが候補になります。そのサービスが必要とするドメイン設定や証明書の条件も確認します。

このように、名前がゾーン頂点か、参照先が何かを確認してからレコードを選びます。

判断2：主系の障害時に待機系へ切り替えたい

通常時と障害時の使い方を決める

通常は東京側だけを使い、障害時に大阪側へ切り替えるなら、アクティブ・パッシブ構成です。Route 53では主系と待機系を持つフェイルオーバールーティングが候補になります。

両リージョンを通常時から使いたい場合はアクティブ・アクティブ構成です。遅延や重みで回答を選び、正常性も考慮する方式を検討します。「複数リージョン」という条件だけではポリシーを一つに決められません。

どの故障を検知する必要があるか

異常を判断する条件は、守りたい処理に合わせます。

サーバーが起動していても、注文を保存できないならショップとしては利用できない可能性があります。一方、すべての依存先の異常で切り替えると、両系で共有している依存先の障害まで切替の原因になります。どの処理を正常性の判断に含めるかを決めます。

通常のレコードなら、適切なエンドポイントのヘルスチェックを関連付けます。ALBを指すAliasなら、Evaluate Target Healthによる評価を検討します。参照先の正常性評価が、業務上必要な正常性を十分に表すかも確認します。

設定の違いはヘルスチェックを使ったレコード選択に記載されています。

DNSの切替と復旧時間を結び付ける

**RTO（Recovery Time Objective）**は、障害発生後にどれくらいの時間でサービスを復旧したいかという目標です。DNSで待機先を回答できても、全利用者が即座に接続し直すとは限りません。

切替時間を考えるときは、次の時間や状態を確認します。

ヘルスチェックが障害を検知するまでの時間
リゾルバーや端末に残っているDNSキャッシュ
アプリケーションの再問い合わせや再接続の動作
待機先の起動・増強と、データを利用可能にするまでの時間

TTLを60秒に設定できるレコードでも、「障害から必ず60秒以内に全利用者の通信が切り替わる」とは説明できません。AWSリソースへのAliasでは参照先のTTLを使うため、自由に短縮できるとも限りません。

また、切替直前にTTLを短くしても、以前のTTLでキャッシュされた回答は残ります。計画的な変更では、古いキャッシュが失効する時間も考えます。DNSのベストプラクティスを参照してください。

全接続先が異常な場合も考える

主系と待機系の両方にヘルスチェックがあり、両方とも異常と判断された場合、フェイルオーバーの回答は主系へ戻ります。異常なら必ずDNS回答から除外され続ける、と一律に考えないことが必要です。

待機系にヘルスチェックも参照先の正常性評価も設定しなければ、主系が異常なときには待機系が実際に動いていなくても回答され得ます。障害を検知する設定と、切替先が利用可能であることの両方を確認します。主系・待機系の回答条件に具体的な挙動があります。

データと処理能力を確認する

**RPO（Recovery Point Objective）**は、どれくらい前の時点までのデータ損失を許容するかという目標です。Route 53はDNSの回答を切り替えますが、データの複製、注文の重複防止、ログイン状態の引継ぎまでは行いません。

待機先のデータ同期方法、切替時の整合性、処理能力やサービスクォータも含めて、RTO/RPOを満たせるかを判断します。

判断3：新しい環境へ少しずつ移行したい

旧環境を残しながら新環境へ段階的に移すなら、加重ルーティングが候補です。同じ名前・タイプのレコードに相対的な重みを付けます。

たとえば旧環境の重みを90、新環境を10とすると、Route 53が回答を選ぶ際の割合の目安は、旧環境が90%、新環境が10%になります。

ただし、これはWebリクエストを100件ずつ数えて10件だけ新環境へ渡す仕組みではありません。同じDNS回答を多数の利用者が再利用する場合があり、アクセス数の割合は偏ります。セッションの固定やHTTPリクエスト単位の制御が必要なら、その条件を満たすアプリケーションやロードバランサーの機能も検討します。

重み0も、正常性の設定によっては絶対に回答されないことを保証しません。正の重みを持つ接続先がすべて異常なら、0の接続先が検討対象になる場合があります。接続先を完全に退役させる要件では、この例外も確認します。加重ルーティングの仕様が根拠です。

条件が「平常時は常に旧環境、障害時だけ待機環境」に変わったなら、段階移行の割合より主系・待機系の区別が中心になるため、フェイルオーバールーティングを比較します。

判断4：複数リージョンから、何を基準に選ぶか

「近いところへ送る」という表現だけでは、地理的位置なのか、通信の遅延なのかが分かりません。要件の目的を具体化します。

要件	候補	選択理由
利用者の応答時間を短くしたい	レイテンシールーティング	AWSの遅延データに基づいてリージョンを選ぶ
国や大陸ごとに接続先を指定したい	位置情報ルーティング	DNS問い合わせ元の地理的位置に対応するルールで選ぶ
リソースの所在地とバイアスで受け持つ範囲を調整したい	地理的近接性ルーティング	リソースの地理的位置を基準に回答範囲を調整する
特定の送信元IPアドレス範囲に接続先を対応させたい	IPベースルーティング	CIDR（IPアドレス範囲の表記）をまとめたコレクションを基準にする

レイテンシーは、単純に地図上で最寄りのリージョンを選ぶ方式ではありません。Route 53が持つ遅延データを使うため、ネットワーク状況が変われば回答先も変わり得ます。アプリケーションの処理時間まで含めた最速を、常に測定・保証するものでもありません。レイテンシールーティングで判断基準を確認できます。

位置情報ルーティングでは、位置を判定できない問い合わせや、該当する地域のレコードがない場合に備え、デフォルトのレコードも検討します。デフォルトがなければ、それらの問い合わせへ回答が得られない場合があります。

また、DNSの位置判定を利用者本人の厳密な所在地の証明として扱うことはできません。データ保管地域や利用権限の要件は、保存先やアプリケーションの認可も含めて満たします。位置情報ルーティングの説明が基礎になります。

判断5：内部向けの名前を、どこから解決するか

VPC内だけで使う名前

関連付けたVPC内のアプリケーションから内部向けの名前を解決するなら、プライベートホストゾーンが候補です。VPCのDNS設定や、クライアントが利用するDNSサーバーも確認します。

パブリックとプライベートで同じドメイン名を管理する構成もあります。ただし、VPC内で一致するプライベートゾーンがあり、求めた名前・タイプのレコードがなければ、公開ゾーンへ自動的に探し直すとは限りません。公式のプライベートゾーンの考慮事項では、この場合にNXDOMAINが返ることが説明されています。

「外部では引けるのに、VPC内では引けない」という状況では、どのゾーンが問い合わせに適用されているかを確認します。

社内ネットワークとVPCの間でも使う名前

VPCと社内のネットワークがVPNやDirect Connectでつながっていても、DNSの問い合わせ先が自動的に適切になるとは限りません。

DNS問い合わせの向き	検討する構成
社内からAWSの内部向けの名前を解決する	VPC Resolverのインバウンドエンドポイントと、社内DNS側の条件付き転送
AWSから社内DNSが持つ名前を解決する	アウトバウンドエンドポイントと、対象ドメインの転送ルール

インバウンド／アウトバウンドは、VPCを基準としたDNS問い合わせの向きです。回答が戻る向きで名前を判断しないようにします。VPC Resolverの構成で両方向の流れを確認できます。

なお、内部向けの名前を作ることと、プライベートIPの接続先を正常性監視できることは別に設計します。Route 53のエンドポイントヘルスチェッカーはVPCの外から動くため、内部の状態を伝えるCloudWatchメトリクスなどが候補になります。プライベートDNSのフェイルオーバーを参照してください。

条件を変えて、選択理由を説明してみる

次はこの記事独自の学習例です。各機能名を答えるだけでなく、条件が変わったら何を見直すかを説明してみてください。

場面	最初の判断	条件を変えたときの見直し
2リージョンを通常時から使い、応答時間を改善したい	レイテンシーを比較し、正常性も考慮する	国ごとに接続先を指定する目的なら、位置情報ルーティングへ判断軸を変える
新版の環境へ少しずつ移行したい	加重ルーティングを比較する	利用者をセッション中同じ環境に固定するなら、DNSだけで要件を満たせるか再検討する
主系が失敗したら待機系で処理を続けたい	フェイルオーバーと正常性評価を比較する	待機先のデータが古いなら、RPOを満たす複製方法も選ぶ

要件の読み方を確認する資料として、AWS公式のSAA-C03サンプル問題PDFも利用できます。たとえば問題3では、接続に使うプライベートIPアドレスという条件が方式選択を制約します。DNS名を引き直さずIPアドレスへ直接接続するクライアントには、DNS回答の変更だけでは対応できません。これは、サービス名を先に決めず、接続方法の条件から読む練習になります。

構成を説明するときの確認事項

設計案を選んだら、次の問いに一文ずつ答えてみます。

クライアントは何という名前を、どのDNSリゾルバーで解決するか。
どの条件に基づいて接続先を回答するか。
何を監視し、どの故障で切り替えるか。
TTLや再接続を含め、要求された復旧時間を満たせるか。
切替先のデータ・処理能力・通信経路は用意できているか。

Route 53を選ぶ理由と、Route 53以外で実現する部分まで説明できれば、ルーティングポリシーの暗記から、要件に応じて構成を判断する学習へつなげられます。用語や各機能の動作を振り返りたい場合は、下記の記事を参照してください。

Amazon Route 53とは？できること・各機能・動作の仕組みを解説ホストゾーン、レコード、TTLなどの用語と、それらが組み合わさる動作を振り返る

参考資料

2026-10-21にAWS公式資料を確認しました。試験ガイドが改訂された場合は、対象範囲とこの記事の対応を見直します。