この記事はアイレット25卒社員によるAWSブログリレーのAmazon Route 53編です。
この記事はJapan AWS Top Engineerのクラウドインテグレーション事業部 クラウドコンサルティングセクション 鈴木 健斗さん監修の下、執筆をしております。

AWSブログリレーでは初学者や営業職の方などのこれからAWSについて学習する方向けに1記事1AWSサービスの概要やユースケースを解説するブログリレーとなっております。
AWSブログリレーについてはこちらの記事で詳しく記載しておりますので、ぜひ見てください!

Amazon Route 53の概要

Webサイトにアクセスした際にブラウザの上部に「https://~~~~~」といったドメイン名を見たことがあるかと思います。
Route 53ではこのURLを指定の文字列にすることができるAWSサービスです。
Route 53の最も基本的な役割は「名前解決」といった役割があります。どういうことかというとhttps://~~~~といったドメイン名を192.0.2.1のような
コンピュータが通信に使うIPアドレスに変換するプロセスのことです。
このブログでは、以下の流れでRoute 53の解説を行なっていきます。
どんな機能があるか
活用することで得られるメリット
活用例
料金

どんな機能があるか

ホストゾーン

ホストゾーンとは特定のドメインに関するDNSレコードをまとめて保持・管理するためのコンテナです。
例えば、example.comというホストゾーンを作成したとします。それに対してwww.example.comといったDNSレコードを格納することでwww.example.comというドメインには192.0.0.1(仮のIPアドレス)を返すといったドメインの名前解決を実現することができます。
ホストゾーンは以下の2種類が存在します。
パブリックホストゾーン
プライベートホストゾーン
それぞれについて深掘りしていきます。

パブリックホストゾーン

パブリックホストゾーンはインターネット全体に公開するためのホストゾーンです。
目的はブラウザ上から世界中のどこからでもアクセスできるWebサイトやメールサーバーなどのパブリックなリソースの名前解決に活用することが目的です

ホストゾーンの中身
ホストゾーンの中身には、WebサーバーのIPアドレスを指し示すAレコードやAWSのロードバランサーやCloudFrontといった他のサービスを指し示すRoute 53独自のエイリアスレコード
を登録しています。それにより、世界中からのアクセスを適切な接続先に振り分けることができます。
ホストゾーンの中に格納するレコードについては後ほど詳細に解説します。

プライベートホストゾーン

プライベートホストゾーンはパブリックホストゾーンとは対照的で、インターネットには公開されないプライベートなネットワーク専用のホストゾーンです。
目的はVPCなどの特定のAWSネットワーク内部でのみ使用する名前解決が目的です。

具体的な活用例:インターネットには公開したくない社内管理システムやVPC内のデータベースサーバーに固定のIPアドレスではなく、わかりやすいドメインでアクセスするために活用されます。

レコード

レコードとは、ホストゾーン内で「ドメイン名(例: www.example.com)とIPアドレス(例: 192.0.2.1)をどのように対応付けるか」を定義する、個々の設定情報のことです。

レコードには以下のレコードタイプが存在し、用途に合わせて使い分けをします。

Aレコード

役割:ドメイン名をIPv4アドレスに対応付けることが役割です

用途:WebサーバーのIPアドレスを指定する際によく活用されます。

AAAAレコード

役割:ドメイン名をIP v6アドレスに対応付けます。AレコードのIPv6バージョンです。

用途:用途はAレコードとほとんど同じでWebサーバーのIPアドレスを指定する際に活用されますが、IPv6に適応した環境でしか活用できないです。

CNAMEレコード

役割:あるドメイン名を別のドメイン名に対応付けることが役割です。

用途:AWS外部のサービスにドメインを紐付けることが活用の場として推奨されています。
注意点として、AWSリソースにドメインを紐付ける際にCNAMEレコードを活用することは非推奨とされています。

MXレコード

役割:指定したドメイン宛のメールを処理するメールサーバーを指定する役割があります。

用途:user@example.com(仮のメールアドレス)宛のメールをどのサーバーに配送すればいいかを定義するために活用されます。

Route 53独自のレコード「エイリアスレコード」

エイリアスレコードは標準のDNSレコードと似ていますが、AWSサービスと連携するために最適化されたRoute 53独自のレコードです。

エイリアスレコードのメリット

AWSリソースに直接紐付けられる
AレコードはIPアドレスしか指定できないです。それに対し、ELBやCloudFrontといったAWSの主要サービスは障害対応や規模の増減によって使われるIPアドレスが動的に変化します。
なのでAレコードではドメインとして機能しなくなる可能性があるのです。

そこでエイリアスレコードを活用することで、ELBのエンドポイントやCloudFrontのディストリビューション名といったAWSリソース自体をAレコードまたはAAAAレコードとして指定することができます。

・ゾーンエイペックスに設定できる
DNSの標準ルールではexample.comのようなサブドメインがないドメイン名(これをゾーンエイペックスという)にはCNAMEレコードを設定できません。
しかし、エイリアスレコードはこの制約を受けません。そのためwwwなしのexample.comへのアクセスを直接ELBやCloudFrontに向けることができます。
これにより、wwwあり、なし両方のアクセスをAWSリソースで受け止めることができます。

ルーティングポリシー

レコードがどこに接続するかを決めるのに対して、「どのように、どのルールに基づいて接続先を振り分けるか」を定義するのがルーティングポリシーです。
このルーティングポリシーを適切に活用することでシステムを安定的に運用することに繋がります。
ここからはどんなルーティングポリシーがあるかについて触れていきます。

シンプルルーティング

最も基本的なポリシーで、一つのドメインに対して、一つまたは複数のIPアドレスを登録します。
複数のIPアドレスが登録されている場合は、ドメインに対してアクセスが来るたびに、ランダムに一つのIPアドレスを返します。複数アドレス登録していることで、簡易的な負荷分散として機能します。

フェイルオーバールーティング

「アクティブ」と「パッシブ」の二つの接続先を設定し、システムの可用性を高めるためのポリシーです。
通常時はプライマリサーバーを活用し、Route 53がプライマリサーバーを常に監視しています。
もしプライマリがヘルチェックに応じなくなり、異常を検知した際に自動的にセカンダリサーバーに接続を切り替えます。
こういったルーティングを実現するのがフェイルオーバールーティングです

レイテンシーベースルーティング

世界中にサーバーを配置しているシステムに適しているポリシーで、ユーザーにとって最も応答が速いサーバーへ自動的に振り分けるポリシーです。
例えば、東京リージョンとオハイオ(米国)リージョンに同じWebサーバーを設置しているとします。
日本からのアクセスは東京リージョンの方が近いので東京リージョンのWebサーバーへ接続。アメリカからのアクセスはオハイオリージョンの方が近いのでオハイオリージョンのWebサーバーへ接続。
こういったルーティングを実施するのが、レイテンシーベースルーティングです。

位置情報ルーティング

レイテンシーに基づくのではなく、ユーザーの地理的な場所(国や地域)に基づいて、指定した接続先に振り分けるポリシーです。
国ごとに表示する言語を変えたいWebサイトやライセンスや法律によって特定の国からのアクセスを制限したい場合などにこのポリシーを活用します。

加重ルーティングポリシー

複数の接続先に対して、重みを設定しトラフィックを指定した比率で分散させるポリシーです。
サーバーAには重み90、サーバーBには重み10と設定すると、トラフィック全体の90%がサーバーAに10%がサーバーBに振り分けられるといったイメージです。
新しい機能を一部のユーザーにだけ公開してテストするといったA/Bテストを実施する際に活用されます。

活用することで得られるメリット

・AWSサービスとのシームレスな連携

AWSでWebサービスを構築する際に活用するELBやCloudFrontなどのシステムの状況に応じてIPアドレスが動的に変わるため、Route 53のエイリアスレコードを活用することで運用がしやすくなります。

・ルーティングポリシーによる可用性とパフォーマンスの向上

Route 53を活用することで、ただ名前解決をするだけでなく、トラフィックの振り分けをどのように行うかを構築をする段階で制御できます。
その上、用途に合わせてルーティングポリシーを選択できることも強みの一つだと思います

Route 53の利用料金

Route 53の料金体系は使った分だけ料金が発生する従量課金制、初期費用や最低料金等もありません。
料金が発生するところは大きく分けてホストゾーン・DNSクエリ・ドメイン登録の3つに分かれます。

ホストゾーンの料金

ホストゾーンはホストゾーンの数に応じて毎月固定の料金が発生します。
パブリックホストゾーン、プライベートホストゾーンで料金が変わることはなく、以下の料金設定になってます。
・最初の25個のホストゾーン:$0.5/月(1ホストゾーンあたり)
・26個目以降のホストゾーン:$0.1/月(1ホストゾーンあたり)
特徴として、ホストゾーンは作成してから12時間以内に削除すれば料金が発生しません。
初学者の方や機能を試してみたい方が活用する分には料金が発生しないので、試しに活用してみる際のハードルが低いと思います。

DNSクエリの料金

DNSクエリはホストゾーンに対して行われたDNSクエリの数と種類に応じて料金が発生します。
料金は100万クエリあたりで計算されます。

・標準クエリ
シンプルルーティングやフェイルオーバールーティングのクエリがこの標準クエリに該当します。
最初の10億クエリ/月まで$0.4/100万クエリ

10万クエリや1万クエリの場合は料金どうなるかと疑問に思う方がいるかと思います。(というか私が気になりました)
シンプルルーティングでの10万クエリの場合は$0.04、1万クエリだと$0.004$となります。
また、100万クエリってどれくらいシステムを活用すると100万クエリになるかイメージがつきにくいですよね。
DNSクエリは基本的に「ブラウザやアプリが、ドメイン名からIPアドレスを知る必要がある時」に発生します。
DNSキャッシュによって名前解決した結果を一定時間保持するので、WebサイトやアプリにアクセスするたびにDNSクエリが発生するわけでもありません。
これらを踏まえて月間のPV数が300万ほどになる人気サイトの規模になってようやく100万クエリを超えてくるといったイメージになると思います。

・高度なルーティングクエリ
レイテンシールーティングや位置情報ルーティングのクエリがこの高度なルーティングクエリに該当します。
レイテンシールーティングでは$0.6/100万クエリ
位置情報ルーティングでは$0.7/100万クエリ

ここで重要になるのが、エイリアスレコードを使用してELBやCloudFrontなど特定のAWSリソースを指すクエリは、追加料金なし(無料)で処理されます。

そのため、コストを最適化するといった意味でもエイリアスレコードを活用することがおすすめです(要件に応じて活用できるかどうかは変わります)

ドメイン登録料金

これはDNS機能とは別で、Route 53で「.com」や「.jp」といったドメイン各自体を取得・管理する場合の料金です。
料金はドメインの種類によって年額の料金が異なります。
・.com:$13/年
・.net:$11/年
・.jp:$89/年

注意:この料金は10月31日時点での料金となっています。そのためこの記事を読んでいただいている日時によっては料金が変更されている可能性があります。
ご認識の程よろしくお願い致します。

活用例

ここからは私が実際にRoute 53を活用してRoute 53で作成したカスタムドメイン(レコード)からindex.htmlへのアクセスを実現した例を紹介します。
この活用例は、Route 53のイメージを掴みやすくするため、構成内容は比較的簡単なものにしています。そのため、実際の案件ではもっと複雑な構成内容になっていることがほとんどだと思います。
ただ、この活用例を見ることで一からRoute 53を実際に活用するところがイメージできるかと思います。

構成図

ユーザーがブラウザにカスタムドメイン(k-nakatani-blog-relay.sre1.clp-staging.jp)からEC2上(Webサーバー)のindex.htmlへアクセスするといった構成内容になっています。
VPC環境のパブリックサブネットに配置されているEC2(Webサーバー)にユーザーがRoute 53に登録したカスタムドメイン経由でアクセスするといった構成内容になっています。

ステップ1:VPCの構築


VPCの構築の段階でパブリックサブネット・ルートテーブル・インターネットゲートウェイの構築を同時に構築しました。これでVPC環境の作成ができました。
ルートテーブルを確認するとパブリックサブネットの関連付けがされていること、ルートにインターネットゲートウェイが設定されていることが確認できます。

ステップ2:セキュリティグループの構築


Webサーバーの役割を持つEC2のセキュリティグループを構築します。
インバウンドルールで社内VPNのIPアドレスからのSSH接続とHTTP接続を許可します。

ステップ3:EC2の構築


Webサーバーの役割を果たすためのApacheがインストールされたEC2のAMIを予め取得しておきました。
このAMIからEC2を構築します。構築後、パブリックIPアドレスのElasticIPをEC2に関連付けします。このElasticIPがこの後のRoute 53でのレコード作成に関係してきます。

ステップ4:Route 53でレコードの登録


ここからが今回の本題で、Route 53でカスタムドメインとなるレコードの登録を行います。
上のスクリーンショットでは「sre1.clp-staging.jp」という検証アカウントの検証用のホストゾーンを選択して、レコードの作成を行っています。
今回はレコード名を「k-nakatani-blog-relay.sre1.clp-staging.jp」で登録をしています。このレコード名がカスタムドメインとなり、ブラウザのアドレスバーで入力することでEC2のパブリックアドレスと名前解決を行い、index.htmlにアクセスができるようになります。
レコードタイプはAレコードに設定しています。
今回の要件では、以下のスクリーンショットのようにエイリアスレコードを活用することができません。なので今回はAレコードとしてレコードを登録しています。


値の項目ですが、ここは先程構築したEC2のパブリックIPアドレスを設定する必要があります。この設定を行うことで、レコードがパブリックIPアドレスで名前解決を実施することができるようになります。
ルーティングポリシーについては、今回の構成では特に設定要件がないのでシンプルルーティングを設定しています。
これでレコードの登録が完了です。

ステップ5:カスタムドメインからWebページへアクセスできるかを確認

無事カスタムドメインからWebページへアクセスすることができました。
注意:実際のシステム開発ではセキュリティの危険性からhttp接続でWebページにアクセスすることはありません。SSL証明書を発行して、証明書をドメインに関連付ける必要があります。

まとめ

ここまで読んでいただきありがとうございました!Route 53がどんなサービスなのかや、具体的な活用方法を理解して頂けると嬉しいです!

参考ドキュメント:https://aws.amazon.com/jp/route53/