新しい Route53 コンソールで別 AWS アカウントのリソースをターゲットとするエイリアスレコードを登録してみた

Route53 でクロスアカウントなエイリアスレコードの登録をしたい場合の操作イメージです。昔は良かったなんて言ってられないですよね。前を向いて生きていきましょう。

UI 変わってるやん……

コンバンハ、千葉(幸)です。

Route53 ホストゾーンでは、クロスアカウントでのエイリアスレコードの登録もできます。

そんな話を以前に書いたりしました。(エイリアスレコードとはなんぞや?と言った細かいところの話は以下に任せて、改めて取り上げることはしません。)

当時の記憶を頼りに久しぶりに作業しようとしたところ、コンソールのデザインがガラッと変わっていたためにどのように作業すればいいのかを 15 分ほど迷ってしまいました

今後同じような事態に陥った方の 15 分を節約できるように、操作のイメージを記載しておきます。

クイック作成でのエイリアスレコードの登録手順

ホストゾーンが作成済みの前提で、レコードの作成画面から話を進めていきます。今回は別の AWS アカウントにある ALB をターゲットにしたいとします。

エイリアスレコードを登録したい場合は、画面右上の「エイリアス」のトグルボタンを切り替えます。

Route53Alias

「トラフィックのルーティング先」という項目に切り替わるため、プルダウンから対象のリソース種別を選択します。(今回であれば ALB を選択。)

Route53Alias-9970247

リージョナルなリソースの場合はリージョンの選択を行う項目が表示されるため、選択します。そうすると自アカウント内のリソースの検索窓が表示されるため、ここで直接 DNS 名を入力します。(予めコピーしておいてペーストするのがおすすめです。)

Route53Alias-9970381

↑リージョンの選択まで済ませてようやく DNS 名を入力できる、ということに気づくのに時間がかかりました。

ALB の DNS 名はALB名-000000000.ap-northeast-1.elb.amazonaws.comのような形式のものです。 ALB の画面から確認しておきましょう。

上記の操作でレコードを登録すると、きちんとエイリアスレコードとして登録できています。

Route53Alias-9970559

一点気になる点として、今回の操作では「トラフィックのルーティング先」として登録された DNS 名の先頭にdualstack.が付与されていませんでした。青枠で囲っているものは同じアカウントに存在する ALB をプルダウンから選択して登録したレコードで、こちらにはdualstack.が付与されています。

これは ELB をポイントするレコードにおいて IPv4 アドレスと IPv6 アドレスの両方をサポートすることを表すものですが、今回の構成では不要であったために特に対応はせずそのままにしました。

どちらの場合も、コンソールで DNS 名に [dualstack.] が付加されます。ウェブブラウザなどのクライアントが、ドメイン名 (example.com) またはサブドメイン名 (www.example.com) の IP アドレスをリクエストする場合、クライアントは IPv4 アドレス (A レコード)、IPv6 アドレス (AAAA レコード)、または IPv4 アドレスと IPv6 アドレスの両方を (別のリクエストで) リクエストできます。[dualstack.] の指定により、Route 53 は、クライアントがリクエストした IP アドレス形式に基づいて、ロードバランサーに対する適切な IP アドレスで応答することができます。

必要な場合には先頭にdualstack.を付与した DNS 名を登録すればいいとは思いますが……未検証です。また別の機会に譲りたいと思います。

ウィザードからエイリアスレコードを登録する場合

ここまで見てきた画面はクイック作成と呼ばれるものですが、他にウィザードからの登録もできます。

レコード登録の画面だけ抽出して載せると、以下のイメージです。

Route53Alias-9970678

↑「エイリアス」に切り替えるトグルボタンがない他は、クイック作成の場合とほぼ同じです。

「値/トラフィックのルーティング先」の項目で選択するプルダウンでエイリアスか否かを指定できます。

Alias

初見でとっつきにくさを感じましたが、理解すればなんてことはなかったですね。

マネジメントコンソールの UI は変わりゆくもの

Route 53 のコンソールは 2020年7月ごろに現在の新しい UI に変更されました。これからも変更は入っていくでしょうので、今回確認した手順も 1 年後には使えないかも知れません。

そういった影響を避けるために AWS CLI なり IaC なりで設定を行うべき、というのは分かっていますが、言ってもね、コンソールからやりたい時もありますよね。

人間だもの

マネジメントコンソールの儚さに思いを馳せながらも、自分と同じところでつまずいた方の参考になれば幸いです。

以上、 チバユキ (@batchicchi) がお送りしました。