NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

トップ > Technology > 歴史・年表でみるAWSサービス(Amazon Route 53編) －機能一覧・概要・アップデートのまとめ・入門－

歴史・年表でみるAWSサービス(Amazon Route 53編) －機能一覧・概要・アップデートのまとめ・入門－

Technology Technology - AWS Technology - AWS - Route 53 歴史

小西秀和です。
前回は「歴史・年表でみるAWSサービス(AWS Systems Manager編) －機能一覧・概要・アップデートのまとめ・SSM入門－」の記事でAWS Systems Manager(SSM)の機能一覧や機能統合の変遷などを紹介しました。
今回はクラウド上でドメインネームシステム(DNS)をはじめ、様々な関連機能を提供するAmazon Route 53について歴史年表を作成してみました。
今回もAmazon Route 53の誕生から機能追加やアップデートを追いながら主要機能を現在のAmazon Route 53の機能一覧と概要としてまとめています。
これらが、各AWSサービスの機能概要に加えてコンセプトや変わらないもの、変わってきたものを知る手がかりとなればと考えています。
今回の記事の内容は次のような構成になっています。

Amazon Route 53歴史年表の作成経緯と方法

今回、Amazon Route 53の歴史年表を作成した経緯は、Amazon Route 53がAWSの歴史の中でも早い段階でAPIによる操作と様々なルーティングやヘルスチェックなどの機能を提供してきたため、次のアプローチでAmazon Route 53の情報を整理したいと考えたからです。

  • Amazon Route 53の歴史を追いながら、アップデートの変遷を整理する
  • Amazon Route 53の機能一覧と特徴をまとめる

この年表は主に次のブログやドキュメント履歴のAmazon Route 53に関する内容を参考にしています。

年表の日付は参考にした資料によってアナウンスや記事投稿のタイミングが違う場合もあったため若干のブレがあります。
掲載している内容は現在のAmazon Route 53と関係している主要な機能と概要説明に必要なものに限定しています。
つまり、ここの年表にあるものがAmazon Route 53の機能のアップデートの全てではなく、あくまで私がピックアップした代表的なアップデートであることにご注意ください。

Amazon Route 53歴史年表(2010年12月05日～2022年06月01日までのアップデート)

さて、ここからがAmazon Route 53の機能に関する年表になります。
Amazon Route 53の歴史は本記事執筆時点で11年を超えており、年表もかなり長くなっていますので必要に応じてスクロールを早めてください。

※テーブルは項目名クリックでソートできます。

年月日 概要
2010/12/05 Amazon Route 53がアナウンス
2011/05/24 Amazon Route 53がGAになる
2011/11/16 AWSマネジメントコンソールからAmazon Route 53が使用できるようになる。
2011/12/21 ドメイン指定でもZone Apex(Naked Domain、Root Domain)をサポートするエイリアスコードがElastic Load Balancing(Classic Load Balancer)に対して使用できるようになる。
2012/03/21 レイテンシーコードがサポートされ、レイテンシーベースルーティング(Latency Routing)ポリシーが使用可能になる。
2013/02/11 ヘルスチェック機能とフェイルオーバー機能がサポートされる。
2013/05/30 ELBに関連づいたEC2インスタンスのヘルスチェックをサポートする。
2013/06/11 エイリアスコードがAmazon CloudFormationをサポートする。
2013/06/26 Amazon Route 53ヘルスチェックのモニタリングをAmazon CloudWatchがサポートする。
2013/08/14 BIND形式ゾーンファイルのインポートをサポート
2014/01/07 ヘルスチェックのレスポンス文字列表示をサポート
2014/02/18 ヘルスチェックの間隔、フェイルオーバーしきい値をサポート
2014/04/09 ヘルスチェックの正常性を割合で評価できるようになる。
2014/04/18 HTTPS、ポート指定のヘルスチェックをサポート
2014/04/30 ヘルスチェックでドメイン指定をサポート
2014/07/02 ヘルスチェックのタグ付、ヘルスチェックカウントの取得をサポート
2014/07/31 Amazon Route 53でドメイン登録ができるようになる。位置情報ルーティング(Geolocation Routing)ポリシーをサポート。
2014/11/05 VPCの内部ドメインを管理するプライベートDNS、ネームサーバーの委任セットの再利用、ヘルスチェックの失敗理由をサポート。
2014/11/25 ホストゾーンのコメント編集をサポート
2015/01/22 Amazon Route 53のドメイン登録で国際化ドメイン名をサポート
2015/02/05 マネジメントコンソールからドメインの連絡先情報を更新できるようになる
2015/02/11 Amazon Route 53とAWS CloudTrailの統合。マネジメントコンソールでヘルスチェックの一日のステータス状況の簡易表示ができるようになる。ヘルスチェック作成時の1分間隔Amazon CloudWatchアラーム同時作成をサポート。ゾーンとドメインにタグ付けができるようになる。
2015/02/26 Amazon Route 53 APIでホストゾーンの一覧取得、ホストゾーン数の取得をサポート
2015/03/03 ホワイトラベルネームサーバー(バニティネームサーバー、プライベートネームサーバー) を構成できるようになる。
2015/09/15 他のヘルスチェックのステータスを元にステータスが決まるヘルスチェックの作成をサポート。ヘルスチェックのレイテンシー測定をサポート。ヘルスチェックダッシュボードの更新をサポート
2015/10/19 Amazon Registrarが「.com」「.net」のトップレベルドメイン(TLD) ICANN認定レジストラになる。「.com」「.net」ドメインのプライバシー保護機能をサポート。
2015/12/03 トラフィックフローのルーティングポリシー構成や関連付けができるビジュアルエディタをサポート
2016/01/19 エイリアスコードがAWS Elastic Beanstalkをサポートする。
2016/01/27 100を超えるトップレベルドメイン(TLD)のドメイン登録をサポート
2016/02/23 エンドポイントに対するTLSネゴシエーション中の「client_hello」メッセージのホスト名送信をサポートし、SSL/TLS証明書を使用してHTTPSリクエストに応答できるようになる。
2016/04/05 CloudWatchメトリクスに基づくヘルスチェック、ヘルスチェックのリージョン選択をサポート。プライベートホストゾーンのエイリアスコード、フェイルオーバーをサポート。
2016/05/26 ドメイン登録料金の請求レポートをサポート。新たに.college、.consulting、.host、.name、.online、.republican、.rocks、.sucks、.trade、.website、.ukのドメイン登録に対応。
2016/07/07 ドメイン登録期間の手動延長をサポート(ジェネリックTLDや多くの国別コードTLDで最大10年)。
2016/08/09 Amazon Route 53のドメイン登録でDNSSECをサポート。
2016/08/11 エイリアスコードがElastic Load Balancing(Application Load Balancer)に対して使用できるようになる。
2016/08/30 NAPTRレコードタイプをサポート。DNSクエリテストツールが使えるようになる。
2016/11/21 ヘルスチェックでIPv6アドレスを使用するエンドポイントをサポート
2017/04/10 Amazon Route 53へのドメイン移管で関連付けるネームサーバーが選択可能になる。
2017/06/21 最大8レコードまでの複数値回答ルーティング(Multivalue Answer Routing)ポリシーをサポート
2017/08/21 認証局承認(CAA)レコードをサポート。
2017/09/01 地理的近接性ルーティング(Geoproximity Routing Policy)ポリシーをサポート
2017/09/07 パブリックホストゾーンでパブリックDNSクエリログをサポート
2017/09/11 エイリアスコードがElastic Load Balancing(Network Load Balancer)に対して使用できるようになる。
2017/10/03 Amazon Route 53がHIPAA適格サービスになる。
2017/12/05 インスタンスに対してDNS名の自動作成・自動削除ができるAmazon Route 53 Auto Naming API(自動命名API)をサポート(後にAWS Cloud Mapとなる)
2018/02/06 Amazon Route 53 Auto Namingでエイリアスコード、CNAMEレコードをサポート。
2018/03/09 Amazon Route 53 Auto NamingのIAMマネージドポリシーが追加される。
2018/03/13 Amazon Route 53 Auto Namingでサードパーティヘルスチェッカーによる正常性評価をサポート
2018/10/18 ヘルスチェックの一時停止をサポート
2018/11/07 地理的近接性ルーティング(Geoproximity Routing Policy)ポリシーによるエンドユーザーのルーティング効果を地図で可視化できるようになる。
2018/11/19 AWS Direct Connect、VPN接続を介したAmazon VPCとオンプレミス間のDNS名前解決をするAmazon Route 53 Resolverが使用できるようになる。
2018/11/28 Amazon Route 53 Auto Naming APIがAWS Cloud Mapの機能の一部となる。
2018/12/20 エイリアスレコードがAPI Gateway API、Amazon VPCインターフェイスエンドポイントに対して使用できるようになる。
2020/09/01 Amazon Route 53 ResolverでResolverクエリログが使用できるようになる。
2020/12/17 Amazon Route 53 ResolverのDNSSEC署名とDNSSEC検証をサポート
2021/03/31 VPCからのアウトバウンドDNS要求を保護するAmazon Route 53 Resolver DNSファイアウォールが使用できるようになる。
2021/07/27 準備状況チェックとルーティング制御によってフェイルオーバーを管理・調整するAmazon Route 53 Application Recovery Controllerが使用できるようになる。
2021/10/26 デフォルトの逆引きDNSルールを無効にし、逆引きDNS名前空間のクエリを外部サーバーに転送できるようになる。
2022/03/16 プライベートホストゾーンで位置情報ルーティング(Geolocation Routing)ポリシーとレイテンシーベースルーティング(Latency Routing)ポリシーをサポート。
2022/06/01 IPルーティング(IP-based Routing)ポリシーをサポート。
2022/09/06 エイリアスレコードがAWS App Runnerに対して使用できるようになる。
2022/09/21 パブリックまたはプライベートホストゾーンのDNSレコードセットのグループに対してIAMポリシーによるアクセス許可をサポート。
2023/03/10 Amazon Route 53 ResolverエンドポイントがIPv6をサポート。

Amazon Route 53は登場から数年の間に他のDNSサービスが提供するような一般的なホストゾーンやレコードを登録する機能だけでなく、ヘルスチェック、フェイルオーバー、DNSルーティングといったDNSクエリに対する返却値を条件によって変更することでトラフィックをコントロールする機能が提供され、今までにその機能を強化するアップデートが数多くされてきています。
こうした機能はAWSサービスに親和性の高いDNSサービスを提供するだけでなく、オンプレミスとAWSの間でフェイルオーバーするハイブリッド環境の構築に代表されるようなクラウドをまたいだDR(Disaster Recovery)も可能にしました。
このようにAmazon Route 53のヘルスチェック、フェイルオーバー、DNSルーティングにはAWSだけではなくオンプレミスや他のクラウド環境のIPアドレスを設定して使用できるものもあるため、その活用の幅は非常に広いサービスです。

現在のAmazon Route 53の機能一覧と概要

ここからは現在(本記事執筆時点)のAmazon Route 53の機能一覧と概要を紹介します。
Amazon Route 53の機能は大別すると、ドメイン管理、DNSサービス、ヘルスチェック、リゾルバーがあります。
このうち、リゾルバーは主にAmazon VPC内部の名前解決機能、Inbound Endpoint・Outbound EndpointといったAmazon VPCおよびオンプレミスが相互に名前解決をする手段、アウトバウンドのDNSクエリを制御するDNS Firewallを提供します。
そして、DNSサービス、ヘルスチェックは相互に関連づいてフェイルオーバーなどの条件に応じたDNSルーティングを提供します。
このDNSルーティングはフェイルオーバー構成の準備状態のモニタリングと指定したルールに基づく状態の条件に応じたルーティング制御を提供するAmazon Route 53 Application Recovery Controllerを使用することでダウンタイムの低減や信頼性の向上のための高度で柔軟な設定ができます。

ドメイン管理

Amazon Route 53ではドメインの登録(新規取得)・更新・移管などのドメイン管理サービスが使用できます。
ここではAmazon Route 53のドメイン登録・更新・移管の特徴について記載します。

ドメインの登録

Amazon Route 53のドメイン登録は本記事執筆時点で汎用最上位ドメイン(.comなど)と地理的最上位ドメイン(.jp)など合わせて300種類以上のドメインをサポートしています。
サポートしているドメインとドメイン登録料金については次を参照してください。
Domains that you can register with Amazon Route 53
※Amazon Route 53のドメイン登録および更新料金にはAWSクレジット(キャンペーンやプロモーション等で入手したクーポン)は使用できない点に注意が必要です。

ドメイン登録には住所、メールアドレス、電話番号などの連絡先情報が必要ですが、WHOISクエリに対して連絡先情報を非表示にするプライバシー保護設定もあります。
また、一般的に登録したドメインにはホストゾーンのネームサーバーを設定することで利用可能になりますが、Amazon Route 53のホストゾーンで作成される4つのネームサーバー以外のネームサーバーも登録できます。
つまり、Amazon Route 53で登録したドメインはAWSサービスだけでなく他のクラウドやオンプレミスのDNSサービスで用意したネームサーバーを設定して使用することも可能です。

登録したドメインには別のレジストラへの許可のない移管を防ぐための移管のロックやTLDレジストリがサポートしていればDNSSECを使用(ドメインのTLDレジストリに対するパブリックキーの追加・削除)することもできます。

ドメインの更新

Amazon Route 53のドメイン有効期限は通常1年間であるため、1年ごとに更新が必要ですが自動更新設定をすることもできます。
また、ドメイン有効期限は料金を先払すれば本記事執筆時点で1年から最大10年まで延長可能です。
ただし、Amazon Route 53のドメイン登録および更新料金にはAWSクレジット(キャンペーンやプロモーション等で入手したクーポン)は使用できない点に注意が必要です。

ドメインの移管

Amazon Route 53のドメイン移管には次のパターンがあります。

他のレジストラからAmazon Route 53へのドメイン移管

他の移管元レジストラからAmazon Route 53にドメイン移管するための要件には次のものが挙げられます。

  • 移管先レジストラ(この場合、Amazon Route 53)で移管するドメインの最上位ドメインがサポートされている
  • 移管元レジストラにドメインが登録済である
  • 移管元レジストラに移管されてきた場合は少なくとも移管後60日以上経過している
  • 移管元レジストラで有効期限切れから復元した場合は少なくとも復元後60日以上経過している
  • 移管元レジストラでドメイン名のステータスコードが次に該当しない
    pendingDelete、pendingTransfer、redemptionPeriod、clientTransferProhibited、serverTransferProhibited
  • 移管元レジストラでドメイン移管のロックが解除されている
  • 移管元レジストラでDNSSECが無効になっている
  • 移管元レジストラでドメイン登録者の連絡先が最新である
  • 一部の最上位ドメインでは所有者情報の変更が完了している必要がある
  • 一部の地理的最上位ドメインは移管後有効期限が自動更新されないため、移管中に有効期限切れにならないよう有効期限を延長しておく

移管の流れの概要は次のようになります。
1. DNSサービス(ホストゾーン設定など)をAmazon Route 53または他のDNSサービスに移行する(予め設定を再現しておく)
2. Amazon Route 53以外のDNSサービスを使用する場合はネームサーバー情報を取得する
3. 移管元レジストラから認証コードを取得する(一部の最上位ドメインは不要)
4. Amazon Route 53コンソールから移管をリクエストする(前述の認証コードの入力、使用するDNSサービスのネームサーバーの設定、プライバシー保護の設定など)
5. 移管リクエスト確認メールの承認リンクなどから移管承認手続きを実施する
6. ドメイン移管処理の待機(汎用最上位ドメイン：最大7日、地理的最上位ドメイン：最大10日)
7. Amazon Route 53でドメイン設定(自動更新設定、移管ロック、DNSSECなど)をする

Amazon Route 53から別のAWSアカウントへの移管

現在のAWSアカウントのAmazon Route 53から別のAWSアカウントへの移管する方法には、 Amazon Route 53 API(AWS CLI、AWS SDK)を使用する方法とAWSサポートに支援してもらう方法があります。
ここではAWS CLIを使用した別AWSアカウントへの移管コマンド例を紹介します。

  • 移管元でのAWS CLIコマンド例(移管リクエスト)
# aws route53domains transfer-domain-to-another-aws-account --domain-name ＜移管するドメイン名＞ --account-id ＜移管先AWSアカウントID＞
{
    "OperationId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxx",
    "Password": "＜移管コマンド実行結果のパスワード＞"
}
  • 移管先でのAWS CLIコマンド例(移管受け入れ)
# aws route53domains accept-domain-transfer-from-another-aws-account --domain-name ＜移管するドメイン名＞ --password ＜移管コマンド実行結果のパスワード＞
Amazon Route 53から他のレジストラへのドメイン移管

Amazon Route 53から他の移管先レジストラにドメイン移管するための要件には、前述の「他のレジストラからAmazon Route 53へのドメイン移管」と同様の内容が挙げられます。その他、移管先のレジストラの仕様に合わせて要件を確認しておく必要があります。

移管の流れの概要は次のようになります。
1. DNSサービス(ホストゾーン設定など)を移行する場合は他のDNSサービスに予め設定を再現しておく(Amazon Route 53のDNSサービスを引き続き使用することも可能)。
※エイリアスレコードなどAmazon Route 53特有の機能は移行先DNSサービスで同等の機能を再現する方法を調査する必要があります。
2. Amazon Route 53または移行するDNSサービスのネームサーバー情報を取得する
3. Amazon Route 53コンソールから認証コードを取得する(一部の最上位ドメインは不要)
4. 移管先レジストラから移管をリクエストする(前述の認証コードの入力、使用するDNSサービスのネームサーバーの設定、プライバシー保護の設定など)
5. 移管リクエスト確認メールの承認リンクなどから移管承認手続きを実施する
6. ドメイン移管処理の待機(汎用最上位ドメイン：最大7日、地理的最上位ドメイン：最大10日)
7. 移管先レジストラでドメイン設定(自動更新設定、移管ロック、DNSSECなど)をする

DNSサービス

ホストゾーン

Amazon Route 53のホストゾーンではドメインと関連付けるためのネームサーバーを割り当て、後述のレコードタイプでレコードを作成してリソースへのルーティング設定をします。
Amazon Route 53では外部公開向けのパブリックホストゾーンとAmazon VPC向けのプライベートホストゾーンが使用できます。

パブリックホストゾーン

パブリックホストゾーンは後述するレコードタイプ、ルーティングポリシー、ヘルスチェックなどを設定してレコードをゾーン内に作成して使用します。
ここでは後述するレコード設定以外のパブリックホストゾーンの主な特徴を記載します。

  • ネームサーバーと委任セット
    パブリックホストゾーンを作成すると自動的にNSレコードとSOAレコードを自動作成します。
    NSレコードにはAmazon Route 53がホストゾーンごとに割り当てる4つのネームサーバーが設定されます。

この4つのネームサーバーは委任セットと呼ばれ、AWS CLI、AWS SDKなどからCreateReusableDelegationSet APIを使用することで再利用可能な委任セットを作成することもできます(委任セットは本記事執筆時点でAmazon Route 53コンソールからは作成できません)。

再利用可能な委任セットはAmazon Route 53のDNSサービスで使用するすべてのドメインで同じ4つのネームサーバーを使用できるため、複数のAWSアカウントでドメインおよびサブドメインを使用する場合などAmazon Route 53のDNSサービス設定作業を簡素化できます。

また、ホストゾーンと再利用可能な委任セットが同じAWSアカウントで作成された場合には、ホストゾーンにホワイトラベルネームサーバーが使用できます。
Amazon Route 53ネームサーバーはns-0000.awsdns-00.com.(0000, 00には任意の数字が入る)のようなドメイン形式ですが、ホワイトラベルネームサーバーを設定することでns1.example.com.のように所有しているドメインのサブドメイン名として使用できるようになります。

  • パブリックDNSクエリログ
    パブリックホストゾーンのクエリログはパブリックホストゾーンごとに設定でき、Amazon CloudWatch Logsに保管されます。
    クエリログの形式は次のようになります。
[ログ形式バージョン] [クエリのタイムスタンプ] [ホストゾーンID] [クエリ名] [クエリタイプ] [レスポンスコード] [レイヤー4プロトコル] [Route 53エッジロケーション] [リゾルバーIPアドレス] [EDNSクライアントサブネット]

次はクエリログの例です。

1.0 2022-05-01T00:00:00Z Z0123456789ABCDEFGHI hidekazu-konishi.com AAAA NOERROR UDP XXX00-XX1 203.0.113.0 -
プライベートホストゾーン
  • プライベートホストゾーンのルーティングポリシー、ヘルスチェックの制限
    Amazon Route 53のプライベートホストゾーンはAmazon VPC内からのプライベートなDNSクエリに対する名前解決を提供します。
    プライベートホストゾーンを使用するにはAmazon VPCの設定でenableDnsHostnamesとenableDnsSupportの両方をtrueにして、Amazon VPCをプライベートホストゾーンに関連付けます。
    プライベートホストゾーンにはパブリックホストゾーンよりも後述するルーティングポリシー、ヘルスチェックに関する制限があります。
    具体的にはプライベートホストゾーンでは地理的近接性ルーティングポリシーが使用できません。
    本記事執筆時点での状況を次に表で示します。
ルーティングポリシー プライベートホストゾーンでの使用 プライベートホストゾーンでの
ヘルスチェック関連付け
シンプルルーティング Yes −
フェイルオーバールーティング Yes Yes
位置情報ルーティング Yes Yes
地理的近接性ルーティングポリシー No No
レイテンシーに基づくルーティング Yes Yes
IPベースルーティングポリシー No No
複数値回答ルーティング Yes Yes
加重ルーティング Yes Yes

また、Amazon Route 53のエンドポイントを監視するヘルスチェックを使用する場合はプライベートIPアドレスをサポートしていないため、VPC内のインスタンスを監視対象にする場合はパブリックIPアドレスを割り当てる必要があります。
一方でAmazon CloudWatchアラームのメトリクスデータストリームを監視するヘルスチェックはプライベートなVPC内のインスタンスのメトリクスを使用できるため、パブリックIPアドレスを割り当てることなく使用できます。

詳細については後述するルーティングポリシー、ヘルスチェック、フェイルオーバーを参照してください。

  • スプリットビューDNS
    Amazon Route 53のプライベートホストゾーンではスプリットビューDNSをサポートしています。
    スプリットビューDNSはパブリック用とプライベート用で同じドメインを使用する設定です。
    (例：www.example.comはパブリック用、internal.example.comはプライベート用として使用する)
    (例：console.example.comをパブリック用とプライベート用で返却するIPアドレスを変える)

スプリットビューDNSの設定はパブリックホストゾーン、プライベートホストゾーンをそれぞれ作成してAmazon VPCをプライベートホストゾーンに関連付けることで実現できます。

  • 名前空間が重複する場合のルーティングの優先順位
    Amazon VPCのプライベートDNSリゾルバーはAmazon Route 53 Resolver(従来はAmazon Provided DNS)と呼ばれます。
    スプリットビューDNSを設定し、重複する名前空間を持つプライベートホストゾーンとパブリックホストゾーンがある場合、Amazon Route 53 Resolverはリクエストされたドメイン名との最も具体的な一致に基づいてトラフィックをルーティングします。
    次にプライベートホストゾーンとパブリックホストゾーンで名前空間が重複する場合のルーティング優先順位について具体例を挙げてみます。

(例)プライベートホストゾーンとパブリックホストゾーンで名前空間example.comが重複し、Amazon VPC内からportal.internal.example.comのDNSクエリをリクエストする場合

  1. Amazon Route 53 Resolverはプライベートホストゾーンにportal.internal.example.comと一致するものが存在するかを検索する。 一致するプライベートホストゾーンが存在すればリクエストのドメイン名と一致するレコードを検索し、レコードがあれば値を返す。一致するレコードが無ければNXDOMAIN（存在しないドメイン）を返す。
  2. 存在しなければ、プライベートホストゾーンにinternal.example.comと一致するものが存在するかを検索する。
    一致するプライベートホストゾーンが存在すればリクエストのドメイン名と一致するレコードを検索し、レコードがあれば値を返す。一致するレコードが無ければNXDOMAIN（存在しないドメイン）を返す。
  3. 存在しなければ、プライベートホストゾーンにexample.comと一致するものが存在するかを検索する。
    一致するプライベートホストゾーンが存在すればリクエストのドメイン名と一致するレコードを検索し、レコードがあれば値を返す。一致するレコードが無ければNXDOMAIN（存在しないドメイン）を返す。
  4. プライベートホストゾーンに一致する名前空間がなければ、パプリックDNSリゾルバーにリクエストを転送する。

つまり、名前空間が重複している場合にVPC内からDNSクエリをリクエストするとプライベートホストゾーンがパブリックホストゾーンよりも優先して検索されることになります。

  • Amazon Route 53 Resolverルールの優先順位
    後述するAmazon Route 53 Resolverルールがプライベートホストゾーンと同じドメインにトラフィックをルーティングする場合はAmazon Route 53 Resolverルールが優先されます。

  • プライベートDNSクエリログ
    プライベートホストゾーンのクエリログはAmazon Route 53 Resolverのクエリログで取得します。
    詳細については後述のリゾルバについての説明を参照してください。

レコード

レコードタイプ

Amazon Route 53でサポートされているレコードタイプは次のものになります。

A, AAAA, CAA, CNAME, DS, MX, NAPTR, NS, PTR, SOA, SPF, SRV, TXT

このうち、Aレコードでは次に説明するエイリアスレコードを選択できます。

エイリアスレコード

エイリアスレコードは特定のAWSリソースのドメイン名についてDNS名前空間の最上位ノードであるZone Apexを関連付けて作成できます。
Zone Apexとはサブドメインで使用するwwwなどのホスト名を含まないドメイン名そのもののことです(例：example.com)。Naked Domain、Root Domainと言われることもあります。
CNAMEレコードでもドメインを値に指定することはできますが、Zone Apexを指定することはできません。
そのため、以下のエイリアスレコードに対応しているAWSリソースで使用するドメイン名(IPアドレスが背後で可変)を独自ドメイン名に関連付ける場合に役立ちます。

  • Amazo API GatewayのカスタムリージョンAPIおよびエッジ最適化API
  • Amazon CloudFrontディストリビューション
  • AWS Elastic Beanstalk環境
  • ELBロードバランサー
  • AWS Global Accelerator
  • Amazon S3バケット
  • Amazon VPCインターフェイス型エンドポイント
  • Amazon Route 53ホストゾーン内のレコード
Evaluate target health(ターゲットヘルスの評価)について

Amazon Route 53のレコード設定に「Evaluate target health」という項目があります。
Evaluate target healthはエイリアスレコードでAmazon Route 53ヘルスチェックの代わりに参照先となっているAWSリソースの正常性を評価するかどうかを「Yes」「No」で設定するオプションです。
例えばApplication Load Balancer(ALB)をターゲットとしてEvaluate target healthを「Yes」に設定するとALBヘルスチェックの結果で後述のDNSフェイルオーバーの判定がおこなわれます。

ルーティング

Amazon Route 53では条件に応じてクエリ元に返却する値を変えるDNSルーティング機能があります。
その中でも位置情報ルーティングポリシー(Geolocation routing policy)、地理的近接性ルーティングポリシー(Geoproximity routing policy)、レイテンシールーティングポリシー(Latency routing policy)、IPベースルーティングポリシー(IP-based routing policy)ではDNS拡張プロトコルのEDNS0を採用しており、EDNS Client Subnet(edns-client-subnet)拡張をサポートしたDNSリゾルバーが送信する送信元ネットワーク情報を使用してDNSクエリ元の場所を判断しています。
edns-client-subnetをサポートしていないDNSリゾルバーからのDNSクエリに対してはDNSリゾルバの送信元IPアドレスを使用してDNSクエリ元の場所を概算します。

ルーティングポリシー

  • シンプルルーティングポリシー(Simple routing policy)
    シンプルルーティングポリシーはルーティングを判断する条件を指定せずに標準のDNSレコードを設定します。
    シンプルルーティングを使用するにはシンプルルーティングポリシーを設定してレコードを作成します。
    他のルーティングポリシーのように条件に合わせて複数の同じタイプと名称で作成できませんが、複数の値(IPアドレスなど)を指定することはできます。
    複数の値を指定した場合はリクエストに対して指定された値からランダムな値が返却されますが、ヘルスチェックは使用できないので返却値に対応するリソースの正常性は確認できません。
    複数の値に対してヘルスチェックによる正常性確認をしたルーティングをする場合は後述の複数値回答ルーティングポリシーを使用します。
    一方でシンプルルーティングポリシーではエイリアスレコードを1つのリソースのみ指定できます。

  • フェイルオーバールーティングポリシー(Failover routing policy)
    フェイルオーバールーティングポリシーはPrimaryレコードタイプが指定されたレコードからSecondaryレコードタイプが指定されたレコードへ関連付けられたヘルスチェックの状態を条件にフェイルオーバーします。
    フェイルオーバールーティングを使用するにはヘルスチェックを関連付けたPrimaryレコードタイプのレコードとSecondaryレコードタイプのレコードを作成します。
    ヘルスチェックの状態が正常である場合はPrimaryレコードタイプが指定されたレコードが返却され、ヘルスチェックの状態が異常である場合はSecondaryレコードタイプが指定されたレコードが返却されます。
    フェイルオーバールーティングポリシーではエイリアスレコードも使用できます。

  • 位置情報ルーティングポリシー(Geolocation routing policy)
    位置情報ルーティングポリシーはDNSクエリの発信元となる地理的な場所(大陸別、国別、米国の州別に指定)を条件にトラフィックをルーティングします。
    レイテンシールーティングを使用するにはルーティング対象の地理的な場所(大陸別、国別、米国の州別に指定)ごとに位置情報ルーティングポリシーを設定したレコードを作成します。
    ただし、位置情報ルーティングはIPアドレスにマッピングされている場所を利用しているため、場所にマッピングされていない一部のIPアドレスには地理的な場所を条件にできません。
    位置情報ルーティングポリシーでは、このような場所にマッピングされていない一部のIPアドレスやどの地理的な場所の条件にも一致しないIPアドレスをルーティングするためにデフォルトのレコードを作成することもできます。
    位置情報ルーティングポリシーとともにヘルスチェックを使用すると同じレコード名・タイプ・ルーティング設定をしているレコードの中から、国→大陸→デフォルト、というようにより広い範囲の順序で地理的な場所を指定したヘルスチェックの状態が正常なレコードを探して返却します。
    位置情報ルーティングポリシーではエイリアスレコードも使用できます。

  • 地理的近接性ルーティングポリシー(Geoproximity routing policy)
    地理的近接性ルーティングポリシーはDNSクエリの発信元とリソースの地理的な場所(ルーティングするリソースのあるAWSリージョンまたは緯度・経度を元にバイアスで地域範囲の広さを調整したもの)を条件にトラフィックをルーティングします。
    地理的近接性ルーティングを使用するには地理的近接性ルール(Geoproximity Rule)を設定したトラフィックポリシーを使用してトラフィックフローを作成します(本記事執筆時点でホスティングゾーンのレコード設定から作成することはできません)。
    地理的近接性ルールはルーティングするリソースのあるAWSリージョンまたはAWSリソース以外のリソースがある緯度・経度で地理的な場所を指定し、バイアスの値を変更してトラフィックを受け入れる地理的な場所の範囲を広げたり狭めたりして定義します。
    位置情報ルーティングポリシーが大陸別、国別、米国の州別を明確に指定してルーティングするのに対し、地理的近接性ルーティングポリシーは国またいで地理的な場所の範囲を柔軟に設定して受け入れるトラフィック量を調整します。
    位置情報ルーティングポリシーではエイリアスレコードも使用できます。
    ※本記事執筆時点ではプライベートホストゾーンでは「地理的近接性ルーティングポリシー(Geoproximity routing policy)」はサポートされていません。

  • レイテンシールーティングポリシー(Latency routing policy)
    レイテンシールーティングポリシーはエンドユーザーとAWSデータセンター間で発生するトラフィックに基づいてネットワークレイテンシーが最も低いAWSリージョンにルーティングします。
    レイテンシールーティングを使用するにはルーティング対象のAWSリージョンごとにレイテンシールーティングポリシーを設定したレコードを作成します。
    レイテンシールーティングポリシーとともにヘルスチェックを使用すると同じレコード名・タイプ・ルーティング設定をしているレコードの中からヘルスチェックの状態が正常なレコードを探して返却します。
    レイテンシールーティングポリシーではエイリアスレコードも使用できます。

  • IPベースルーティングポリシー(IP-based routing policy)
    IPベースルーティングポリシーは予め登録したルーティング対象のIP範囲のCIDRブロックを参照して条件に一致するクエリ元のトラフィックをルーティングします。
    IPベースルーティングポリシーを使用するには複数のCIDRブロックをCIDRの場所(CIDR location)としてCIDRコレクションに登録し、ルーティングの対象とするCIDRの場所をCIDRコレクションから選択してIPベースルーティングポリシーを設定したレコードを作成します。
    CIDRブロックとしてCIDRコレクションに登録したIP範囲以外からのトラフィックをルーティングする場合にはデフォルトの場所(Default location)を選択してレコードを作成します。
    ただし、IPベースルーティングポリシーに使用するCIDRコレクションへ指定できるCIDRブロックはIPv4が/0〜/24、IPv6が/0~/48のIP範囲で/32などは指定できません。
    ※本記事執筆時点ではプライベートホストゾーンでは「IPベースルーティングポリシー(IP-based routing policy)」はサポートされていません。

  • 複数値回答ルーティングポリシー(Multivalue answer routing policy)
    複数値回答ルーティングポリシーは最大8個まで設定できる複数の値(IPアドレスなど)からヘルスチェックを使用して正常性を確認した上でランダムに返却してルーティングします。
    複数値回答ルーティングを使用するにはルーティング対象の複数の値をそれぞれ複数値回答ルーティングポリシーを使用したレコードに登録してヘルスチェックを指定します。
    ※複数値回答ルーティングポリシーではエイリアスレコードはサポートされていません。

  • 加重ルーティングポリシー(Weighted routing policy)
    加重ルーティングポリシーはルーティング対象の全レコードの重み合計に対して割合となる重みをレコードにそれぞれ割り当てることで、トラフィック数を重み付けに応じて相対的に分散してルーティングします。
    加重ルーティングを使用するにはルーティング対象の重み付けごとに加重ルーティングポリシーを設定したレコードを作成します。
    加重ルーティングポリシーとともにヘルスチェックを使用すると同じレコード名・タイプ・ルーティング設定をしているレコードの中からヘルスチェックの状態が正常なレコードを探して返却します。
    加重ルーティングポリシーではエイリアスレコードも使用できます。

ヘルスチェック

Amazon Route 53ヘルスチェックはAWSサービスとの親和性が高いのはもちろんですが、AWSサービス以外のクラウドサービスやサーバーなどの外形監視にも使用できます。

ヘルスチェックの種類

  • エンドポイントを監視するヘルスチェック
    エンドポイントのヘルスチェックは世界各地のヘルスチェッカーによって応答時間と失敗回数に基づいて正常性が評価されます。
    18%を超えるヘルスチェッカーが正常と判断した場合はエンドポイントが正常と判断されます。一方、正常と判断するヘルスチェッカーが18%以下だとエンドポイントが異常と判断されます。
    エンドポイントを監視するヘルスチェックの方法には次のものがあります。

    • TCP
      ヘルスチェッカーがエンドポイントとのTCP接続を10秒以内に確立すると正常と判断されるヘルスチェックです。
    • HTTP/HTTPS
      ヘルスチェッカーがHTTP/HTTPSプロトコルでエンドポイント(IPアドレスまたはドメイン)とTCP接続を4秒以内に確立し、接続後2秒以内にHTTPステータスコード2xxまたは3xxで応答を受信すると正常と判断されるヘルスチェックです。
    • HTTP/HTTPSと文字列一致
      ヘルスチェッカーがHTTP/HTTPSプロトコルでエンドポイント(IPアドレスまたはドメイン)とTCP接続を4秒以内に確立し、接続後2秒以内にHTTPステータスコード2xxまたは3xxで応答を受信後、さらに2秒以内に指定された文字列が最初の5,120バイト内に含まれるレスポンス本文を受信した場合に正常と判断されるヘルスチェックです。

    ※プライベートホストゾーンのフェイルオーバーレコードなどエンドポイントを監視するヘルスチェックをVPC内のインスタンスに対して使用する場合はパブリックIPアドレスを割り当てる必要があります。

  • 他のヘルスチェックから算出した値を監視するヘルスチェック
    他のヘルスチェックから算出した値を監視するヘルスチェックはヘルスチェックに親子関係を構成して、最大256個設定できる子ヘルスチェックの正常性の合計数をもとに親ヘルスチェックに設定したしきい値で正常性を判断するものです。

    他のヘルスチェックから算出した値を監視するヘルスチェックの正常性判断には次のものが使用できます。

    • 監視対象のすべての子ヘルスチェックのうち少なくとも設定した任意の数以上が正常であること
    • 監視対象のすべての子ヘルスチェックが正常であること
    • 監視対象のすべての子ヘルスチェックのうち少なくとも1つが正常であること

  • Amazon CloudWatchアラームのメトリクスデータストリームを監視するヘルスチェック
    Amazon CloudWatchで作成したアラームを選択して、アラームに使用されているメトリクスデータストリームをもとに正常性を判断するヘルスチェックを作成できます。
    注意するべきなのは、このヘルスチェックの正常性判断にAmazon CloudWatchアラームの結果ではなく、Amazon CloudWatchアラームで監視しているメトリクスデータストリームが使用されているという点です。つまり、このヘルスチェックはAmazon CloudWatchアラームの結果がALARM状態になるのを待つことなく異常を検知します。
    Amazon CloudWatchのメトリクスデータストリームを使用するため、プライベートホストゾーンのフェイルオーバーレコードを設定する場合などでもVPC内のインスタンスにパブリックIPアドレスを割り当てることなく監視できます。

DNSフェイルオーバー

Amazon Route 53のDNSフェイルオーバーは前述のルーティングポリシーとヘルスチェック(エイリアスレコードはEvaluate target healthの設定を含む)を組み合わせて設定します。
ヘルスチェックまたはエイリアスレコードでEvaluate target healthが設定されている場合は次の流れでDNSフェイルオーバーがおこなわれます。

  1. ルーティングポリシーによって優先度の高いレコードを選択する
  2. 選択したレコードの正常性をヘルスチェックまたはエイリアスレコードでEvaluate target healthがYesの場合は参照先のAWSリソースの状態で判断する
  3. 選択したレコードの正常性が正常であれば該当のレコード値を返す
  4. 選択したレコードの正常性が異常であればルーティングポリシーによって次に優先度の高いレコードを選択して「2.」に戻る
  5. 選択したレコードの正常性が異常でルーティングポリシーによって次に選択するレコードがなければ、最後に選択したレコード値を返す

なお、ヘルスチェックも無く、エイリアスレコードでEvaluate target healthをNoにしている場合は正常性の判断をせずルーティングポリシーによって選択されたレコードが返されます。

リゾルバー

Amazon Route 53 Resolver

Amazon Route 53 ResolverはAmazon VPCに作成されるフォワーダーとフルサービスリゾルバーの機能を提供するDNSサーバーです。
Amazon Route 53 Resolverの発表以前はAmazon Provided DNSという名称でAmazon VPC内のプライベートな名前解決のみをサポートしていました。
Amazon VPCを作成した際に自動で作成されるデフォルトのAmazon Route 53 ResolverはVPCネットワークアドレスに2を足した予約済みIPアドレス(例：10.0.0.0/16の場合10.0.0.2)のDNSサーバーに関連づきます(この機能が従来のAmazon Provided DNSに相当します)。
また、Amazon Route 53 ResolverはAmazon VPCとオンプレミスや他のVPCなどのネットワーク(以降、対象ネットワークと呼ぶ)にあるリゾルバー同士がDNSクエリによる名前解決をするためのインバウンドエンドポイントとアウトバウンドエンドポイントを提供します。
これらのエンドポイントを作成する際には各エンドポイントごとにIPアドレスを割り当てたElastic Network Interface(ENI)を2つ以上、異なるアベイラビリティーゾーン(AZ)に作成する必要があります。

インバウンドエンドポイント(Inbound Endpoint)

インバウンドエンドポイントは対象ネットワークにあるDNSリゾルバーがAmazon Route 53 ResolverにDNSクエリをフォワード(転送)するためのエンドポイントです。
インバウンドエンドポイントを使用するためにはAmazon Route 53 ResolverのあるAmazon VPCとネットワーク間はAWS Direct ConnectまたはVPNで接続されている必要があります。
対象ネットワークにあるDNSリゾルバーでは該当するドメイン名を含むDNSクエリをインバウンドエンドポイントのIPアドレスに転送する設定をしておく必要があります。
対象ネットワークからインバウンドエンドポイントを使用した名前解決の流れは次のようになります。

  1. クライアントが対象ネットワークのDNSリゾルバーに転送対象ドメイン名のDNSクエリを送信する
  2. 対象ネットワークのDNSリゾルバーがDNSクエリをインバウンドエンドポイントのIPアドレスに転送する
  3. インバウンドエンドポイントからAmazon Route 53 ResolverにDNSクエリが転送される
  4. Amazon Route 53 ResolverがDNSクエリのドメイン名に対応する値を内部での名前解決または公開ネームサーバーへの再帰問い合わせで取得する
  5. Amazon Route 53 Resolverがインバウンドエンドポイントに値を返却する
  6. インバウンドエンドポイントが対象ネットワークのDNSリゾルバーに値を返却する
  7. 対象ネットワークのDNSリゾルバーがクライアントに値を返却する
アウトバウンドエンドポイント(Outbound Endpoint)

アウトバウンドエンドポイントはAmazon Route 53 Resolverが対象ネットワークにあるDNSリゾルバーにDNSクエリをフォワード(転送)するためのエンドポイントです。
アウトバウンドエンドポイントを使用するためにはAmazon Route 53 ResolverのあるAmazon VPCとネットワーク間はAWS Direct Connect、VPN、NAT Gatewayのいずれかで接続されている必要があります。
アウトバウンドエンドポイントは対象ネットワークにあるDNSリゾルバーに転送するクエリのドメイン名を制御する転送ルールを作成して使用します。
アウトバウンドエンドポイントの転送ルールの作成は次の項目を指定します。

  • ルール名称
  • ルールタイプ(ForwardまたはSystem)
    Forward：特定ドメイン名のDNSクエリを対象ネットワークのDNSリゾルバーに転送する場合に使用
    System：Forwardで設定した特定ドメイン名のうち、特定サブドメインのDNSクエリをAmazon Route 53 Resolverで名前解決する場合に使用
  • 対象のドメイン名(またはサブドメイン名)
  • アウトバウンドエンドポイント
  • ルールを関連付けるAmazon VPC(クエリの転送元)
  • 対象ネットワークにあるDNSリゾルバーのIPアドレス(クエリの転送先)
    ※ルールタイプがForwardの場合のみ指定
  • タグ

アウトバウンドエンドポイントの転送ルールの他にAmazon Route 53 ResolverがAWS固有ドメインなどの応答のために自動的に作成する自動定義ルールもあります。 自動定義ルールと同じドメインで転送ルールを作成した場合は転送ルールが優先され、対象ネットワークにあるDNSリゾルバーにクエリが転送されます。

また、ルールタイプにはForward、Systemの他にRecursiveがあり、「Internet Resolver」の名称で自動作成されます。
Recursiveルールタイプは転送ルールにも自動定義ルールにも存在しないドメインがクエリされた場合に再帰問い合わせをするために設定されます。

「Internet Resolver」ルールによる再帰問い合わせをせず、すべてのクエリを対象ネットワークに転送するには転送ルールで「.」(ドット)を指定したルールを作成します。

インバウンドエンドポイント(Inbound Endpoint)とアウトバウンドエンドポイント(Outbound Endpoint)の概要図

Amazon Route 53 Resolverのインバウンドエンドポイント(Inbound Endpoint)とアウトバウンドエンドポイント(Outbound Endpoint)の名前解決を概要図にまとめます。
■茶色の線はAmazon VPCからオンプレミス環境に向けた名前解決
■青色の線はオンプレミス環境からAmazon Route 53 Resolverを介するAmazon VPCに向けた名前解決
■オレンジ色の線はオンプレミス環境からAmazon Route 53 Resolverを介するインターネットに向けた名前解決

インバウンドエンドポイント(Inbound Endpoint)とアウトバウンドエンドポイント(Outbound Endpoint)の概要図
インバウンドエンドポイント(Inbound Endpoint)とアウトバウンドエンドポイント(Outbound Endpoint)の概要図

Amazon Route 53 Resolver DNS Firewall

Amazon Route 53 Resolver DNS FirewallはAmazon VPCからAmazon Route 53 Resolverを経由して送信されるアウトバウンドのDNSクエリに対してブロックリスト、許可リストによって送信先ドメイン名に対するフィルタリングをするDNSレベルのファイアウォールです。
Amazon Route 53 Resolver DNS FirewallはAWS Firewall Managerと統合されているため、AWS Organizationsの組織内のメンバーアカウントに対して管理アカウントから複数のメンバーアカウントのVPCにDNSファイアウォールルールを展開できます。
また、AWS Resource Access Manager(RAM)を使用するとAWSアカウント間でDNSファイアウォールルールグループを共有することも可能です。
Amazon Route 53 Resolver DNS Firewallは主に次の項目を設定して使用します。

  • ドメインリスト
    ドメインリストの種類にはユーザーがドメインを追加して管理する独自ドメインリスト(Owned domain lists)とAWSマネージドドメインリスト(AWS managed domain lists)があります。
    独自ドメインリストには1つ以上の複数のドメインを登録できます。

  • DNSファイアウォールルール
    DNSファイアウォールルールは独自ドメインリスト(Owned domain lists)またはAWSマネージドドメインリスト(AWS managed domain lists)を関連付けて、ALLOW、BLOCK、ALERTからいずれかのアクションを選択して作成します。

  • DNSファイアウォールルールグループ
    1つ以上の複数DNSファイアウォールルールを追加して構成するルールのグループです。
    複数のDNSファイアウォールルールを追加している場合には適用する優先順位を指定可能です。
    DNSファイアウォールルールグループは1つ以上の複数Amazon VPCに関連付けてルールを適用できます。

クエリログ

Amazon Route 53 ResolverのクエリログはAmazon VPCに関連付けて使用し、次の内容が記録されます。

  • Amazon VPC内で発生するDNSクエリとその応答(プライベートホストゾーンの名前解決を含む)
  • インバウンドエンドポイントおよびアウトバウンドエンドポイントを使用したDNSクエリ
  • Amazon Route 53 Resolver DNS Firewallルールで評価したDNSクエリ

Amazon Route 53 Resolverのクエリログは次のサービスに保存または配信できます。

  • CloudWatch Logsロググループ
  • Amazon S3バケット
  • Kinesis Data Firehose配信ストリーム

次はクエリログの項目と形式の例です。

{
  "version": "＜ログ形式バージョン(例：1.100000)＞",
  "account_id": "＜AWSアカウントID(例：123456789012)＞",
  "region": "＜リージョン(例：ap-northeast-1)＞", 
  "vpc_id": "＜VPC ID(例：vpc-12345678901234567)＞",
  "query_timestamp": "＜クエリのタイムスタンプ(例：2022-05-01T00:00:00Z)＞",
  "query_name": "＜クエリ名(例：private.hidekazu-konishi.com.)",
  "query_type": "＜クエリタイプ(例：A)＞",
  "query_class": "＜クエリクラス(例：IN)＞",
  "rcode": "＜応答コード(NOERROR)＞",
  "answers": [
    {
      "Rdata": "＜応答データ(例：10.0.0.10)＞",
      "Type": "＜応答DNSレコードタイプ(例：A)＞",
      "Class": "＜応答クラス(例：IN)＞"
    }
  ],
  "srcaddr": "＜クエリ送信元IPアドレス(例：172.31.0.10)＞",
  "srcport": "＜クエリ送信元ポート(例：52400)＞",
  "transport": "＜クエリ送信プロトコル(例：UDP)",
  "srcids": {
    "instance": "＜クエリ送信元リソースID(例：i-12345678901234567)＞"
    または
    "resolver_endpoint": "＜クエリ送信元リソースID(例：rslvr-in-123456789012345678)＞"
    "resolver_network_interface": "＜クエリ送信元リソースID(例：rni-12345678901234567)＞"
  },
  "firewall_rule_action": "＜DNS Firewallルールアクション(例：ALERT)＞",
  "firewall_rule_group_id": "＜DNS FirewallルールグループID(例：rslvr-frg-1234567890123456)＞",
  "firewall_domain_list_id": "＜DNS FirewallドメインリストID(例：rslvr-fdl-1234567890123456)＞",
}

Amazon Route 53 Application Recovery Controller(Amazon Route 53 ARC)

Amazon Route 53 Application Recovery Controller(Amazon Route 53 ARC)は主に準備状況チェック(Readiness check)とルーティング制御(Routing control)の2つの機能を持っています。

準備状況チェック(Readiness check)

準備状況チェックはアプリケーションを構成するAWSリソースの設定、キャパシティ、サービス制限などがフェイルオーバーを処理するようにスケーリングされ、障害を回避できるようになっているかを確認する機能です。

準備状況チェックを構成するコンポーネントには主に次のようなものがあります。

  • セル(Cell)
    セルはアプリケーションが独立して実行できるAWSリソースをグループ化したセットで、フェイルオーバーのプライマリまたはレプリカとなる単位を表します。
    セル同士の境界は一般的にアベイラビリティーゾーン(AZ)やリージョンで分離されます。

  • リカバリーグループ(Recovery group)
    リカバリーグループは2つ以上の機能面で同じ構成をしているセルをグループ化したフェイルオーバーを構成するプライマリおよびレプリカの単位を表します。

  • リソースセット(Resource set)
    リソースセットは複数のセルをまたいでグループ化した同じ機能の単位です。
    例えば複数のリージョンで構成されているプライマリ環境とレプリカ環境にそれぞれ作成されているApplication Load Balancer(ALB)をリソースセットにすることができます。

  • 準備ルール(Readiness rule)
    準備ルールはAmazon Route 53 ARCでサポートされているAWSリソースタイプごとに用意されたリソースを監査するためのルールです。
    準備ルールに基づいた評価によって各AWSリソースの準備ステータスが決定されます。

  • 準備スコープ(Readiness scope)
    準備スコープは準備チェック内のリカバリグループやセルの準備状況の情報を取得する範囲(リカバリグループ、セル)の設定です。
    リカバリーグループ全体のグローバルリソースに関連付けたり、リカバリーグループ内の特定のセルに関連付けたりできます。

  • 準備チェック(Readiness check)
    準備チェックはリソースセットでグループ化されたAWSリソースを監査するための設定です。
    準備チェックの対象となるAWSリソースは準備ルールに基づいて評価されます。
    準備チェックで準備スコープをリカバリーグループのリソースに関連付けることでリカバリグループやセルの準備状況の概要を取得できるようになります。

ルーティング制御(Routing control)

ルーティング制御は従来型よりもより詳細な条件を設定してAmazon Route 53ヘルスチェックとDNS名前解決を使用したフェイルオーバーおよびトラフィックルーティングを提供する機能です。

Amazon Route 53 ARCのルーティング制御には主に次の特徴があります。

  • 詳細なメトリクスやロジックなど柔軟な条件に基づいたフェイルオーバーが可能
  • 準備できていないレプリカへのフェイルオーバー、ルーティング先の無い設定、ルートフラッピングなど自動化されたルーティング処理の弊害を防ぐセーフティールールがある
  • メンテナンスや急な条件変更による復旧などに対応するためのセーフティールールの手動オーバーライドが可能

ルーティング制御を構成するコンポーネントには次のようなものがあります。

  • クラスター(Cluster)
    Amazon Route 53 ARCのルーティング制御で使用するクラスターはルーティング制御の状態を取得、更新するAPI実行をするためのエンドポイントを提供します。
    クラスターは5つのリージョンへ冗長的にエンドポイントが用意されます。また、1つのクラスターで後述する複数のコントロールパネルとルーティングコントロールを操作できます。
    クラスターには時間単位で課金が発生するので注意が必要です。

  • ルーティングコントロール(Routing controls)
    ルーティングコントロールはルーティングコントロールの状態を元にAmazon Route 53 ARC用のルーティングコントロールヘルスチェックを使用してセルに流れるトラフィックフローをON/OFFで制御します。
    ルーティングコントロールの状態はAmazon Route 53 Application Recovery Controller API(Route 53 ARC API)やAWS CLIを使用して取得と更新が可能です。
    これにより、トラフィックルーティングをプログラムコードのロジックによって柔軟な条件に基づいて自動制御したり、メンテナンス時などに手動制御したりできます。
    ※ルーティングコントロールの状態はAWSマネジメントコンソールからも取得と変更ができますが、Route 53 ARC APIを使用する方法が推奨されています。

  • ルーティングコントロールヘルスチェック(Routing control health check)
    ルーティングコントロールヘルスチェックはルーティングコントロールに関連付けられるAmazon Route 53 ARC用のヘルスチェックです。
    ルーティングコントロールヘルスチェックはセルのフロントにあるAWSリソース(ALBなど)のDNSレコードセット(フェイルオーバーレコードなど)に設定されます。
    ただし、ルーティングコントロールヘルスチェックは従来のヘルスチェックとは異なり、設定したエンドポイントの状態によってヘルスチェックのステータスが変更されるのではなく、ルーティングコントロールによってヘルスチェックの状態が変更されます。
    つまり、ルーティングコントロールヘルスチェックが関連づいているフェイルオーバーポリシーを設定したDNSレコードはルーティングコントロールの状態に基づいてフェイルオーバーします。

  • コントロールパネル(Control panel)
    コントロールパネルは複数のルーティングコントロールをグループ化して、後述するセーフティールールの適用を設定します。
    例えばルーティングコントロールを複数のAZにあるALBごとに設定し、コントロールパネルでグループ化してセーフティールールを適用できます。

  • デフォルトコントロールパネル(Default control panel)
    デフォルトコントロールパネルはクラスター作成時に自動的に作成され、クラスターで作成するすべてのルーティングコントロールを追加するコントロールパネルです。

  • セーフティールール(Safety rule)
    セーフティールールはルーティングコントロールのリカバリーアクションによって誤って可用性が低下することを防ぐためのルールです。
    例えば、準備できていないレプリカへのフェイルオーバー、ルーティング先の無い設定、ルートフラッピングなど自動化されたルーティング処理の弊害を防ぎます。

準備状況チェック(Readiness check)とルーティング制御(Routing control)の概要図

Amazon Route 53 ARCの準備状況チェック(Readiness check)とルーティング制御(Routing control)の用語の関係を、マルチリージョンでALB＋Auto Scaling(Amazon EC2)＋Amazon Dynamo DB(Global Table)を構成した例をもとに概要図にまとめます。

準備状況チェック(Readiness check)とルーティング制御(Routing control)の概要図
準備状況チェック(Readiness check)とルーティング制御(Routing control)の概要図

＜参考資料＞
AWS Documentation(Amazon Route 53)
AWS Documentation(Amazon Route 53 Application Recovery Controller)
Tech Blog with related articles referenced

まとめ

今回はAmazon Route 53の歴史年表を作成して、Amazon Route 53の機能一覧と概要を見てきました。

Amazon Route 53はドメイン登録やパブリックおよびプライベートのホスティングといった一般的なDNSサービスの機能をカバーした上で、AWSと親和性の高い多機能を提供しています。
特に複数種類のパターンで構成にあった設定ができるルーティングポリシーおよびフェイルオーバー機能、様々な条件で詳細な設定が可能なヘルスチェック機能などはAmazon Route 53を利用する上での大きな利点と言えます。
また、近年ではAmazon Route 53 Resolver DNS FirewallやAmazon Route 53 Application Recovery Controllerなど更にAWSにおけるDNS運用の利便性を向上する機能が登場してきています。
今後も継続的にAmazon Route 53がどのような機能を提供していくのかその動向をウォッチしていきたいと思います。

なお、今回の記事の英語版やAmazon Route 53以外のサービスも含めたAWSサービス全体の歴史年表もありますので、興味がありましたら御覧ください。

Written by Hidekazu Konishi
Hidekazu Konishi (小西秀和), a Japan AWS Top Engineer and a Japan AWS All Certifications Engineer

執筆者小西秀和

Japan AWS Top Engineer, Japan AWS All Certifications Engineer(AWS認定全冠)として、知識と実践的な経験を活かし、AWSの活用に取り組んでいます。
NRIネットコムBlog: 小西 秀和: 記事一覧
Amazon.co.jp: 小西 秀和: books, biography, latest update
Personal Tech Blog