目次
Route 53 の特徴
Amazon Route 53 は、AWS の DNS サービスです。ひとことで言うと、ドメイン名を管理して、アクセス先を正しく案内する仕組みです。Route 53 の主な機能は ドメイン登録、DNS ルーティング、ヘルスチェック の3つです。
Amazon Route 53 がサポートしている DNS レコードタイプ
- A レコードタイプ … 名前を IPv4 アドレスに向ける
- AAAA レコードタイプ … IPv6 アドレスに向ける
- CAA レコードタイプ … どの認証局(CA)がそのドメインの証明書を発行してよいかを制限する
- CNAME レコードタイプ … 別名を付ける
- MX レコードタイプ … メール配送先
- NAPTR レコードタイプ … 番号や名前から、どのサービスへ変換・案内するかを定義する
- NS レコードタイプ … そのドメインを管理するDNSサーバーを示す
- PTR レコードタイプ … IPアドレスから名前を逆引きする
- SOA レコードタイプ … そのゾーンの基本情報(管理者・更新番号など)を持つ
- SPF レコードタイプ … そのドメインからメール送信を許可された送信元を示す
- SRV レコードタイプ … 特定サービスの接続先ホスト名とポート番号を示す
- TXT レコードタイプ … 文字列情報を持たせる汎用レコード(確認用、認証用など)
エイリアスレコード
上記 DNS レコードタイプだけでなく、「エイリアスレコード」と呼ばれる Route 53 独自の DNS 機能の拡張も利用できます。エイリアスレコードは、Route 53 独自の Alias という設定付きのレコードのことです。エイリアスレコードは Route 53 で作成できるレコードの一種で、CloudFront や S3、ELB などの AWS リソースに向けられます。
CNAME レコードと同様に、エイリアスレコードを使用すると、選択した AWS リソース (CloudFront ディストリビューションや Amazon S3 バケットなど) にトラフィックをルーティングできます。特にエイリアスレコードは CNAME と異なりルートドメイン(Zone Apex)にも設定できます。
- Amazon API Gateway リージョン固有のカスタム API またはエッジ最適化 API の IP アドレスを返す
- Amazon VPC インターフェイスエンドポイントの IP アドレスを返す
- CloudFront ディストリビューション(CloudFront エッジサーバーの IP アドレスを返す)
- Elastic Beanstalk 環境(IP アドレスを返す)
- ELB ロードバランサーの IP アドレスを返す
- AWS Global Accelerator アクセラレータの IP アドレスを返す
- 静的ウェブサイトとして設定されている Amazon S3 バケットの IP アドレスを返す)
- 同じホストゾーン内の別の Route 53 レコード
ルートドメイン(Zone Apex、ゾーンアペックス)とは
Zone Apex は、そのホストゾーンの一番上の名前のことです。ホストゾーンと同じ名前のレコードです。
たとえば、以下のような構成です。
- ホストゾーンが
example.comなら Zone Apex =example.comになります。 www.example.comやapi.example.comは Zone Apex ではありません。これらはサブドメインです。example.comを登録した場合、zone apex はexample.comです。
エイリアスレコードとCNAMEレコードの違い
- エイリアスレコード ← 無料、Route 53 が AWS リソース向けに便利化した仕組み
- CNAME レコード ← 有料、別の「名前」に向ける
パブリックホストゾーン
インターネット公開用のホストゾーンです。
- プライベートホストゾーンと異なり、インターネット側で名前解決をしたい場合に利用します。
- インターネット上に公開された DNS ドメインレコードを管理するコンテナです。
- example.com などのドメインのトラフィックをインターネットまたは特定のドメインでルーティングする情報を保持しています。
プライベートホストゾーン
VPC 内専用のホストゾーンです。
- パブリックホストゾーンはインターネット上で名前を解決(IPアドレスを返す)してくれますが、プライベートホストゾーンを使用すると VPC 内限定でプライベート IP アドレスを返してくれます。
- ホストゾーンを作成したら、別の AWS アカウントを使用して作成したものを含め、さらにVPCを追加することができます。(複数の VPC を関連付けることができます。)
- VPC 同士が相互アクセス可能であればリージョンの異なる VPC でも、同じホストゾーンを利用できます。
ルーティングポリシーについて
ルーティングポリシーでクエリに応答する方法を決定します。
■各ルーティングポリシー
- シンプルルーティングポリシー – ドメインで特定の機能を実行する単一のリソースがある場合に使用します。たとえば、example.com ウェブサイトにコンテンツを提供する 1 つのウェブサーバーなどです。トラフィックを複数インスタンスなどにランダムに分散してルーティングします。
- フェイルオーバールーティングポリシー – アクティブ/パッシブフェイルオーバーを構成する場合に使用します。
- 位置情報ルーティングポリシー – ユーザーの位置に基づいてトラフィックをルーティングする場合に使用します。位置情報ルーティングポリシーはコンテンツをローカライズして、ユーザーの言語でウェブサイトの一部またはすべてを表示できます。位置情報ルーティングは DNS と IP アドレスの位置情報に基づいてルーティングするため、リソースの近さに基づいてルーティングする設定ではありません。例えば、ドイツの位置情報にいるユーザーに対してはドイツ語を表示するようにドメインを構成するといったり、位置情報に応じた表示変更やサーバー設定などが可能となります。
- 地理的近接性ルーティングポリシー – リソースの場所に基づいてトラフィックをルーティングし、必要に応じてトラフィックをある場所のリソースから別の場所のリソースに移動する場合に使用します。CloudFrontリソースをユーザー近くのリソースにルーティングするには、地理的近接性ルーティングポリシーを利用します。
- レイテンシールーティングポリシー – 複数の AWS リージョンにリソースがあり、レイテンシーの最も小さいリージョンにトラフィックをルーティングする場合に使用します。
- 複数値回答ルーティングポリシー – ランダムに選ばれた最大 8 つの正常なレコードを使用して Route 53 が DNS クエリに応答する場合に使用します。
- 加重ルーティングポリシー – 指定した比率で複数のリソースにトラフィックをルーティングする場合に使用します。
加重ルーティングポリシーですが、「複数のリソース」という所がポイントとなります。
複数のリソースを使用して負荷分散やテストなどで利用できるというメリットがあります。
- 加重ラウンドロビン ← WRR(Weighted Round Robin)
加重ルーティングポリシー
Route 53 の加重ルーティングを使用することで、各リソースに送信するトラフィック量に相当する相対的な重みを設定できます。
たとえば 3つの EC2 インスタンスでリクエストを受けているが、各 EC2 インスタンスに性能の偏りがある場合、性能の偏りにあわせて負荷を分散することが可能です。
また、加重ルーティングは、ブルーグリーンデプロイを行う場合に有効です。
具体的には、既存環境と新しいバージョンの環境にトラフィックを徐々に誘導する、新しいバージョンで問題が発生した場合に既存環境にフォールバックする等が行えます。
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/implement-change.html
==== 抜粋ここから ====
イミュータブルインフラストラクチャにアプリケーションをデプロイする場合は、Canary デプロイまたはブルー/グリーンデプロイを使用します。
Canary デプロイは、通常は単一のサービスインスタンス (Canary) で実行される新しいバージョンに、少数の顧客を誘導する方法です。
次に、生じた動作の変更やエラーを詳細に調べます。
重大な問題が発生した場合、Canary からトラフィックを削除して、ユーザーを以前のバージョンに戻すことができます。
デプロイが成功したら、変更やエラーをモニタリングしながら、希望の速度で完全にデプロイされるまでデプロイを続行できます。
AWS CodeDeploy では、デプロイ設定で Canary デプロイを有効にすることでことができます。
ブルーグリーンデプロイは Canary デプロイに似ていますが、アプリケーション全体が並行してデプロイされる点が異なります。
2 つのスタック (青と緑) 間でデプロイを交互に行います。
この場合も、トラフィックを新しいバージョンに送信したときにデプロイに問題が発生した場合は、古いバージョンにフォールバックできます。
通常、すべてのトラフィックが一度に切り替えられますが、各バージョンへのトラフィックの一部を使用し、Amazon Route 53 の加重 DNS ルーティング機能を使用して新しいバージョンの採用をダイヤルアップすることもできます。
AWS CodeDeploy と AWS Elastic Beanstalk は、ブルーグリーンデプロイを有効にするデプロイ構成で設定できます。
==== 抜粋ここまで ====
Canary デプロイ(Canary リリース)とは
Canary デプロイとは、新バージョンのアプリをリリースする際に、一気に切り替えるのではなく全体の10%とか20%ずつリリースしてテストをしていくリリース方法です。
Amazon Route 53 トラフィックフローとは
- 複雑なルーティングポリシーを作成できます。
- ルーティングの順番を設定できます。
- 世界中で複数のエンドポイントが実行され、レイテンシー、地理的場所、エンドポイントの状態に基づいてユーザーが最適なエンドポイントに接続されるため、エンドユーザーのためにアプリケーションのパフォーマンスと可用性を向上させることができます。
- 開発者は、レイテンシー、エンドポイントの状態、負荷、地理的近接性、地理的場所を含め、最も注意すべき制約に基づいてトラフィックをルーティングするポリシーを簡単に作成できます。
- AWS マネジメントコンソールでシンプルなビジュアルポリシービルダーを使用して、テンプレートをカスタマイズしたり、ポリシーをゼロから構築したりできます。
Route 53 VPC Resolver とは
Route 53 VPC Resolver は、VPC 内のリソースが使う DNS の再帰リゾルバです。以前の「Route 53 Resolver」です。各 VPC でデフォルトで使え、パブリック DNS 名、VPC 固有の DNS 名、Route 53 Private Hosted Zone の名前解決を行います。VPC からは一般に VPC の CIDR の “+2” の IP(例:10.0.0.0/24 の場合は 10.0.0.2)を通じてこの Resolver に到達します。
何もしなくても、EC2 の内部 DNS 名や Private Hosted Zone のレコード、一般的なインターネット向けの名前解決は Resolver が処理します。追加設定が必要になるのは、AWS とオンプレミス/他ネットワークの間で DNS を中継したいときや、DNS レベルの制御・監査をしたいときです。
DNS の再帰リゾルバとは
DNS の再帰リゾルバは、利用者の代わりに名前解決を最後までたどってくれる DNS サーバーです。
たとえば、あなたのPCがwww.example.com の IP アドレスを知りたいとなった場合、このとき PC はまず 再帰リゾルバ に問い合わせます。再帰リゾルバが、必要なら外部のDNSサーバーたちに順番に問い合わせて、最終的な答えを集めて返してくれます。
ちなみに PC にもリゾルバがありますが、こちらも DNS 問い合わせをするための仕組み です。たとえばブラウザやOSがwww.example.comの IP を知りたいと思ったときに、DNS 問い合わせを実行する部分です。こちらは再起リゾルバとは異なり、名前解決だけするアプリや機能と言った感じです。スタブリゾルバ と呼ばれます。

コメント