【AWS基礎】Amazon Route 53のサービス概要

引き続きAWSを勉強していきます。

今回のテーマはAmazon Route 53です。

※本記事は2023年4月時点の情報を基にしています。

もくじ

１．Amazon Route 53とは

２．ドメイン登録機能

　・ホストゾーン

　・ルーティングポリシー

３．権威DNSサーバ機能

４．Route 53 ヘルスチェック

５．Route 53 Resolver

　・概要M

　・構成コンポーネントと動作イメージ

６．Route 53 resolver DNS Firewall

　・構成コンポーネント

　・フィルタリングの条件と流れ

１．Amazon Route 53とは

Amazon Route 53とは、一連のDNSサービスを提供する他、

ドメイン登録、さらにはフェイルオーバやスケーリング、ヘルスチェックといった、

ルーティング周りの様々な機能を併せ持った、便利なサービスである。

公式ドキュメントにも、

ドメイン登録、DNS ルーティング、ヘルスチェックの 3 つの主要な機能を任意の組み合わせで実行できます

とある。

様々な機能を利用できるがゆえに、Route 53を使う際は、

各種機能の概要を知ったうえで、必要な機能を取捨選択・組み合わせていく必要がある。

以降、Route 53の主な機能を順に紹介していく。

２．ドメイン登録機能

AWSに限らず一般的な話として、ドメインは世界で一意でないといけない。

（他の組織のドメインと自分のドメインがかぶっていたら、どちらに対する通信なのか分からなくなってしまう。ちなみにドメインって何？という方は別途ググってくださいm(__)m）

そのため、ドメインを取得したい場合、

世界にあるドメイン管理団体から「ドメイン登録業者」として認められた事業者に対し、

取得したいドメインを申請する必要がある。

で、Amazonもどうやらそのドメイン登録業者らしく、

Route 53を通して、ドメインを登録できるようになっている。

Route 53では、新規のドメイン登録と、既存ドメインの移管登録のいずれも可能である。

↓新規ドメイン登録時の登録画面（一部）

３．権威DNSサーバ機能

Route 53の代表的な機能の１つとして、DNSサーバとしての機能も挙げられる。

Route 53は、ドメイン情報を保持し、DNSクライアントからの名前解決要求に対応する、権威DNSサーバ（DNSコンテンツサーバ）として利用できる。

※DNSとは何かや、権威DNSサーバについては、以前の記事を参照。

◎ホストゾーン

Route 53で権威DNSサーバ機能を利用するには、「ホストゾーン」と呼ばれるものを作成する必要がある。

AWS公式ドキュメントによると、ホストゾーンは以下のようなものである。

ホストゾーンはレコードのコンテナであり、レコードには example.com やそのサブドメイン (acme.example.com や zenith.example.com) の特定のドメインのトラフィックをどのようにルーティングするかに関する情報を保持します。

AWS公式ドキュメントより

要するにホストゾーンとは、DNSレコード情報の保管先と言える。

作成できるホストゾーンは、公開有無によって2種類ある。

種別	説明
パブリック	ホストゾーン内のレコード情報を、インターネット上に公開する。 レコードは、インターネットでトラフィックをどのようにルーティングするかの情報を持つ。
プライベート	ホストゾーン内のレコード情報を、指定のVPC内に公開する。 レコードは、当該VPC内でトラフィックをどのようにルーティングするかの情報を持つ。

◎ルーティングポリシー

Route 53の各レコードは、トラフィックをどのようにルーティングするかの情報を持つ。

この情報とは、例えば「example.com」に向けた通信が来たら、

ドメインをIPアドレスに変換（名前解決）して「192.160.10.0/24」に転送するといった内容である。

Route 53の名前解決は、AレコードやCNAMEレコード、MXレコードなど、

一般的なDNSレコードに対応している。

ただし、Route 53には、このような単なる名前解決だけではなく、

追加の様々な情報を踏まえて、総合的にルーティング先を判断する機能も備わっている。

Route 53でどのようにルーティングするかは「ルーティングポリシー」で決めることができる。

ルーティングポリシーは、パブリックホストゾーンで８種類、

プライベートホストゾーンで６種類から選べる。

＊パブリックホストゾーンの場合

パブリックホストゾーンでは、ルーティングポリシーを以下から選べる。

いずれのポリシーを選んでも、名前解決というDNS本来の機能も実行される。

ポリシー	説明
シンプルルーティング	普通のDNSサーバとして、単純に名前解決を行う方法。 全クライアントがRoute 53から同じレスポンスを受信する。
加重	同じ名前を持つ複数のリソースに、 あらかじめ指定した分散比率で通信を分散させる方法。 負荷分散や、新しいバージョンのソフトウェアのテストなどの目的で使用すると良い。
位置情報	ユーザの地理的場所に基づいて通信先リソースを決める方法。 地理的場所は、大陸別／国別／米国州別に指定できる。 法的な理由で通信先を限定したい時などに使用すると良い。
レイテンシ	レイテンシ（通信にかかる時間）が最小となるリージョンにルーティングする方法。 複数のAWSリージョンにリソースがあり、 レイテンシを下げたいときに使用すると良い。
フェイルオーバ	プライマリリソースの異常時にはルーティング先を変える方法。 本ルーティングポリシーのもとでは、通常、 Route 53はプライマリにルーティングするが、 異常時はセカンダリにルーティングする。
複数値回答	DNSクエリへの応答時、条件に合う複数のレコード値全て(最大8つまで)を返す方法。 応答時には正常ステータスの値のみが返される。 (例外として、全てが異常な時は異常値が返される) 例えば複数のWebサーバ稼働時、 Route 53が各サーバのIPアドレスをDNSクエリへの応答として返すと、 クライアント側では応答を一定期間キャッシュする。 キャッシュが残っている間に、Webサーバの1つに障害が発生しても、 本ポリシーを採用していれば、キャッシュの応答内にある 別のIPアドレスに通信を試行できるようになる。
地理的近接性	ユーザの位置とリソース配置場所の地理的距離が短くなるようにルーティングする方法。 世界規模の巨大なシステムで、リソースやユーザが世界各地に存在するような場合に便利。
IP ベース	ユーザ情報を踏まえてルーティングする方法。 例えば、特定のISP経由でアクセスするユーザを特定のリソースにルーティングすることで、 ネットワーク伝送コストやパフォーマンスの最適化を実現したい場合に効果を発揮する。

＊プライベートホストゾーンの場合

プライベートホストゾーンでは、ルーティングポリシーを以下から選べる（各ポリシーの詳細はパブリックホストゾーンに同じ）。

　・シンプルルーティング
　・加重
　・位置情報

　・レイテンシ
　・フェイルオーバ
　・複数値回答

４．Route 53 ヘルスチェック

Route 53 ヘルスチェックは、

AWSが設けている世界各地のヘルスチェッカーから、チェック対象のリソースへ接続試行し、状態を確認するサービスである。

以下を対象としたヘルスチェックが可能となっている。

監視対象	説明
エンドポイントの状態	ドメイン名またはIPアドレスとポート番号で監視したい リソース（エンドポイント）を指定し、 世界中のヘルスチェッカーからHTTP／HTTPS／TCPで 定期的にリクエストを送信する。 応答結果により、ヘルス状態が判定される。
CloudWatch アラームの状態	CloudWatchメトリクスのステータスを指定し、監視する。 監視するメトリクスの例としては、 Amazon DynamoDBのスロットル読み込みイベント数や、 ELBの正常機能中のホスト数などが挙げられる。 前提としてCloudWatchでアラームを作成しておく必要がある。（CloudWatch アラームの詳細は別記事にて紹介）
他のヘルスチェックの状態	設定済のヘルスチェック(通常複数)の状態を監視し、ヘルスチェックの結果を総合的に算出する。 以下のような複雑なヘルスチェックの判定をしたい時に利用する。 ・指定したヘルスチェック5個のうち少なくとも3個が正常なら、全体として正常とみなす（＝5個中3個以上が異常なら、異常と判断） ・指定したヘルスチェック5個すべてが正常なら、全体として正常とみなす（＝5個中1個でも異常があれば、異常と判断） ・指定したヘルスチェック5個のうち1つ以上が正常なら、全体として正常とみなす（＝5個全てが異常な時だけ、異常と判断）

いずれのヘルスチェックであっても、CloudWatchの機能と連携し、

異常時にAmazon SNSでアラームを通知することができる。

ただしここで設定したアラームは、 us-east-1 リージョンに配置される。

ヘルスチェックの活用事例として、

ヘルスチェック実行+ルーティングポリシーをフェイルオーバにする運用が可能である。

ヘルスチェックの結果、プライマリ（現用系）に障害があると判断されれば、

Route 53の応答をセカンダリ（待機系）に自動的に切り替えることができる。

５．Route 53 resolver

◎概要

Route 53 Resolverとは、VPC内部で働くDNSの機能であり、

VPCに標準で備わっている。

Route 53 Resolverは、VPC内のリソースの他、

専用のエンドポイントを通じて、別のVPC内やオンプレミスのリソースからも、

名前解決の要求を受け付ける。

ただし、Route 53 Resolver自身がレコード情報を保持しているわけではない。

Route 53 Resolverは、名前解決の要求が来たら、

そのDNSレコード情報を持っている（持っていそう）なDNSサーバ（※）に、要求を転送する。

（※）：インターネット上に公開されているDNSサーバや、オンプレミス環境にある社内DNSサーバ、Route 53のホストゾーンなど。

要するにRoute 53 Resolverは、

VPC内やオンプレミスといった、自前のリソースからの名前解決要求を

一括で仲介するような役割を担っていると考えれば良い。

◎構成コンポーネントと動作イメージ

Route 53 Resolverを構成するコンポーネントは以下の通りである。

コンポーネント	説明
インバウンドエンドポイント	オンプレミスまたは別のVPCから、 VPCにDNSクエリを受け取る時のエンドポイント。
アウトバンドエンドポイント	オンプレミスまたは別のVPCに、 VPCからDNSクエリを送る時のエンドポイント。
ルール	ドメイン名と転送先の対応づけ。 VPC⇔オンプレミスでの名前解決要求時、 DNSクエリをどこに転送するかを決める。 作成したルールはVPCに直接適用される他、 複数のAWSアカウントで共有も可能。

例えば、オンプレミス環境にある内部DNSサーバに、

VPC内のEC2から名前解決をしたい場合、以下のような構成・流れになる。

６．Route 53 Resolver DNS Firewall

Route 53 Resolver DNS Firewallとは、

Route 53 ResolverへのDNSクエリを精査し、接続の可否をフィルタリングするための機能である。

名前の通り、Route 53 Resolver専用のFWだと考えれば良いと思う。

◎構成コンポーネント

Route 53 Resolver DNS Firewallの構成コンポーネントは以下の通りである。

コンポーネント	説明
ルール	ドメイン名と接続可否を対応付けたフィルタリングルール。
ルールグループ	ルールの集合体。 ルールグループの単位でVPCに紐づけ、 フィルタリングルールを適用することになる。
ドメインリスト	フィルタリング対象とするドメインの集合体。 ユーザが独自で作成できる他、 AWSが管理・提供するリスト（※）も選べる。 （※）既知マルウェアの通信先ドメインのリストなど

◎フィルタリングの条件と流れ

フィルタリングが機能するには、以下①、②の両条件を満たしている必要がある。

①ルールグループがVPCのRoute 53 Resolverに関連付けられていること

②以下のいずれかのDNSクエリであること

　・VPC内で発信されるDNSクエリ

　・オンプレミスのリソース→Route 53 Resolverのエンドポイント→VPC　の経路で渡されるDNSクエリ

①と②の条件を満たしている場合に、Route 53 Resolver DNS Firewallは

設定されたルールグループやルールに基づいて、DNSクエリをフィルタリングし、

Route 53 Resolverにその結果を返却する。

おわりに…

Route 53、単なるDNSサーバかと思ったら、

設定次第で色々活用できるようで、奥が深くてびっくりでした(･ω･)

この記事に書ききれていない機能や活用方法も多々あります。（フェイルオーバ機能とか、グラフィカルにDNSルーティングポリシーを決められるサービスとかとか…。複雑すぎる！！）

1回ではとうてい学びきれないので、あとは現場で実践しながら、適宜学んでいこうと思います。