Route53で管理しているドメインからサブドメインを作成して、別アカウントのAPI Gatewayのカスタムドメインと紐付ける

やること整理
1. アカウントBでサブドメインを作成する。
2. アカウントAの親ドメインとサブドメインのトラフィックをを紐付ける
3 アカウントBのAPI Gatewayでサブドメインをカスタムドメインとして設定する。
確認
- 参考

やること整理

タイトルが長くて分かりにくいが、状況は以下のような感じ。

f:id:lukefone-story:20191026132043p:plain — 概要図

つまりやることを整理すると、以下の順番になる

アカウントBでサブドメインを作成する。
アカウントAの親ドメインとサブドメインのトラフィックをを紐付ける
アカウントBのAPI Gatewayでサブドメインをカスタムドメインとして設定する。

以降自分のドメイン名、nooozui.com を使用して、サブドメインsample.nooozui.comを作成する。 f:id:lukefone-story:20191026134037p:plain

1. アカウントBでサブドメインを作成する。

まずアカウントBのRoute53でホストゾーンを作成するが、その前に一応アカウントAの親ドメインの登録状況をRoute53で確認してみる。

f:id:lukefone-story:20191026134037p:plain — accountB-route53-hostzone(nooozui.com)

アカウント内で使用しているAレコードを除き、作成時に自動的に設定されたレコードが設定されていることがわかる。レコードについてはここでは詳しく述べないが、このうちSOA(ドメインについての基本情報)とNS(ネームサーバ情報)は定義が自動的に作成される。レコードについては以下に平易にまとめてあるので確認したほうが良いだろう。

qiita.com

docs.aws.amazon.com

なおネームサーバとは、ドメインについてIPアドレスやレコード情報を保持しているサーバとざっくり理解しておくと良い。実際にドメインでwebサイトにアクセスする際には、これらのネームサーバに対して問い合わせを行い、対象サイトにIPアドレスを入手する。

現状確認は終了したので、早速アカウントBで新規にサブドメインでホストゾーンを作成する。

f:id:lukefone-story:20191026135803p:plain — Route53-ホストゾーン作成

作成すると次のようにNSとSOAレコードが生成されるのがわかる。

f:id:lukefone-story:20191026135904p:plain — Route53-サブドメインでホストゾーン作成

2. アカウントAの親ドメインとサブドメインのトラフィックをを紐付ける

アカウントAの親ドメインにサブドメインのNSレコードを作成する。ここでNSレコードには4つほどネームサーバの情報が

    ns1.amazon.com
    ns2.amazon.org
    ns3.amazon.net
    ns4.amazon.co.uk

のように登録されていると思う。これらはアカウントAの親ドメインのホストゾーンに作成するNSレコードのネームサーバとなるため、記録しておく。以下のようにNSレコード作成時に、記録したネームサーバの値を貼り付けて登録する。

f:id:lukefone-story:20191026141647p:plain — Route53-アカウントA-サブドメインのNSレコード作成

f:id:lukefone-story:20191026141744p:plain — Route53-アカウントA-サブドメインのNSレコード作成後

ここまでで、2アカウント間のドメイン使用に関する設定は一旦完了となる。以降、API Gatewayのカスタムドメインとして使用するための設定を行う。

3 アカウントBのAPI Gatewayでサブドメインをカスタムドメインとして設定する。

3.1 ACMでサブドメインのTLS証明書を取得する

API Gatewayには制約があり、httpsによるアクセスしかできない。そのため、TLS証明書を取得する必要があるが、そのための便利なサービスとしてACM(AWS Certificate Manager)というものがある。なお、TLS証明書はAPI Gatewayが存在するアカウントBで取得する。

注意：API Gatewayで作成するAPIをリージョナル or エッジ最適化のどちらかにするかで証明書を発行するリージョンが異なる。リージョナル　-> APIを公開するリージョンエッジ最適化　-> us-east-1 リージョン (バージニア北部)のみ

上記のようにTLS証明書取得時のリージョンには注意が必要だが、今回はリージョナル(ap-northeast-1(東京))なAPIを作成することとして進める。 ACMの画面に入り、「パブリックな証明書のリクエスト」を選択すると次のような画面にくるので、以下のようにサブドメイン名を入力して先に進む。

f:id:lukefone-story:20191026143637p:plain — アカウントB-ACM-パブリックな証明書のリクエスト

すると以下画像のように検証方法の選択を迫られるが、ここは「DNS検証」の方がよい。理由はAWSのドキュメントで以下のように説明してあるが…

f:id:lukefone-story:20191026143928p:plain — ACM-パブリックな証明書のリクエスト-検証方法の選択

ACM は CNAME (正規名) レコードを使用し、ユーザーがドメインの所有者または管理者であることを検証します。DNS 検証を選択すると、DNS データベースに挿入するための 1 つ以上の CNAME レコードが ACM から提供されます。たとえば、追加の名前として www.example.com を使用して example.com ドメインの証明書をリクエストする場合、ACM によって 2 つの CNAME レコードが作成されます。各レコードは、ユーザーのドメインおよびアカウントに固有のものとして作成され、名前と値が含まれます。この値は、ACM が所有するドメインを指すエイリアスであり、ACM が証明書を自動更新するときに使用されます。CNAME レコードを 1 度のみ DNS データベースに追加します。ACM は、証明書が使用中であり、CNAME レコードが残っている限り、自動的にこの証明書を更新します。また、ドメインが Amazon Route 53 を使用して作成されている場合、ACM によって CNAME レコードを書き込むことができます。

要は証明書は更新時に毎回検証をしないといけないが、DNS検証を使用すればRoute53を使用している限り自動的に証明書を更新してくれるので、使用しているwebサービスでいつの間にか証明書の期限切れだった…なんてことがなくなるようだ。

DNSの検証を選択後、次のような画面に移る。下の部分に「Route53でのレコード作成」ボタンがあるが、これはDNS検証専用のサブドメインをアカウントB内のホストゾーンにつくることを示しており、これを選択する。