015-AWS SAP AWS 「理論・実践・一問道場」アカウント関のプライベートホストゾーンを名前解決

type

status

date

slug

summary

理論

Amazon Route 53のプライベートホストゾーンとVPC関連付けに関する知識

1. プライベートホストゾーン（Private Hosted Zone）

プライベートホストゾーンは、AWSのRoute 53におけるDNS管理機能の一つで、特定のVPC内でのみ解決されるDNSレコードを管理します。インターネット上ではアクセスできず、プライベートネットワーク内のリソース同士の名前解決を行うために使用されます。

VPCとの関連付け: プライベートホストゾーンは、特定のVPCと関連付けて使用します。この設定により、そのVPC内のインスタンスやリソースがDNS名を解決できるようになります。また、他のVPCと接続する場合や複数のVPCで利用する場合は、関連付けの手続きを行う必要があります。

2. VPC間でのDNS解決

異なるVPC間でDNS解決を行いたい場合、VPC PeeringやTransit Gatewayを使ってVPC同士を接続し、その後、DNS解決機能を有効化する必要があります。VPC Peeringを利用する場合、DNS解決を有効にする設定が必要で、これによりVPC間で名前解決を行うことができます。

3. AWS CLIによる設定

AWSマネジメントコンソールだけでは、VPCとプライベートホストゾーンを異なるアカウント間で関連付けることはできません。CLIやSDKを使用して、VPCの関連付けの承認や実際の設定を行う必要があります。

関連付けの承認: アカウントAのVPCからアカウントBのVPCに対してプライベートホストゾーンの関連付けを許可する承認プロセスを行います。この承認を通じて、アカウントBのVPCがアカウントAのプライベートホストゾーンのレコードを解決できるようになります。

4. アカウント間での設定

AWSでは、通常、プライベートホストゾーンを同一アカウント内のVPCに関連付けることができますが、異なるアカウント間で関連付けを行う場合、明示的な承認が必要です。これにより、異なるアカウント間でDNS解決を行うためのアクセス権限を付与できます。

まとめ

この問題に関連する本質的な知識は、Route 53のプライベートホストゾーンをVPC間で適切に管理する方法に関するものです。特に、異なるアカウント間でプライベートホストゾーンを関連付けるためには、AWS CLIやSDKを利用した設定が必要であり、VPC PeeringやTransit Gatewayを使ったDNS解決の設定も考慮する必要があります。このような設定を行うことで、異なるVPC間での名前解決を実現することができます。

実践

参照元：

【Route 53】別アカウントのプライベートホストゾーンを名前解決

AWS経験5年以上の僕が詳しくご説明します。本記事の内容 Route 53のプライベートホストゾーンを作成する作成したプライベートホストゾーンを別アカウントのVPCと関連付ける別ア

https://kacfg.com/aws-associate-private-hosted-zone-different-account/

別アカウントのプライベートホストゾーンを名前解決：はじめに

今回はアカウントBで作成したプライベートホストゾーンのDNSレコードを、アカウントAから名前解決できるように設定します。

💡

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

設定したVPC内でのみ使用できるプライベート用のドメイン

インターネットに公開するパブリックドメインとは使用目的が異なる

[VPCの関連付け] を行うことで、別のAWSアカウントからも名前解決できる

別アカウントのプライベートホストゾーンを名前解決するための準備

事前準備として、アカウントAとアカウントBでVPCとEC2を作成します。

2つのアカウントのVPC DNS設定を有効化

アカウントAとアカウントBのVPC画面で、以下のDNS設定が [有効] になっていることを確認します。

2つのアカウントのVPC DNS設定を有効化

アカウントAとアカウントBのVPC画面で、以下のDNS設定が [有効] になっていることを確認します。

💡

DNSホスト名

DNS解決

もし無効になっている場合は、対象のVPCを選択 -> 右上の [アクション] -> [DNSホスト名を編集] または [DNS解決を編集] からそれぞれ有効化します。

2つのアカウントでEC2を用意

プライベートホストゾーンへのVPC関連付けは、マネジメントコンソールからは設定できません。 AWS CLIやAWS SDKなどを使用する必要がありますが、今回はAWS CLIを使用します。

アカウントAとアカウントBでEC2 (Amazon Linux 2023) をt2.microで作成、パブリックサブネットに配置しパブリックIPアドレスを付与します。

下記の設定項目に基づいてEC2を作成してください。

設定項目	アカウントA	アカウントB
所属VPC	プライベートホストゾーンを関連付けるVPC　VPC-A	EC2が配置され、プライベートホストゾーンを利用するVPC　VPC-B
EC2インスタンス	Amazon Linux 2023（t2.micro、パブリックサブネット、パブリックIPアドレス付与）EC2-A	Amazon Linux 2023（t2.micro、パブリックサブネット、パブリックIPアドレス付与）EC2-B
サブネット	パブリックサブネット	パブリックサブネット

2つのアカウントのEC2にIAMロールを設定

IAMポリシーはRoute 53のCreateVPCAssociationAuthorizationなどが必要です。

今回はテスト目的のため、上記権限が含まれるIAMポリシーPowerUserAccessをIAMロールに付与し、それぞれのEC2に設定します。

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

アカウントBでプライベートホストゾーンとAレコードを作成します。

1. アカウントBのEC2 プライベートIPアドレスをメモ

アカウントBのEC2画面から、EC2に設定されているプライベートIPアドレスをテキストエディタなどにコピペしておきます。

2. アカウントBでプライベートホストゾーンを作成

アカウントBのRoute 53画面でプライベートホストゾーンを作成します。

[ホストゾーン] -> [ホストゾーンの作成] をクリック。

[ホストゾーン設定] は以下のとおり設定。今回はテスト目的なのでドメイン名は [example.com] としました。

ドメイン名：example.com

説明：（オプション）今回は設定しない

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

[ホストゾーンに関連付けるVPC] は以下のとおり設定し、[ホストゾーンの作成] をクリック。

リージョン：アジアパシフィック (東京)

VPC ID：アカウントB側のVPC

タグ：（オプション）今回は設定しない

3. プライベートホストゾーンにAレコードを作成

アカウントBのEC2 プライベートIPアドレスに紐づくAレコードを作成します。

[レコードを作成] をクリック。

以下のとおり設定し [レコードを作成] をクリックします。[TTL] と [ルーティングポリシー] はデフォルトのままで大丈夫です。

レコード名：ec2-account-b

レコードタイプ：A - IPv4アドレスと一部のAWSリソースに・・略

値：前の手順でメモしたアカウントBのEC2プライベートIPアドレス

Aレコードを作成できました。

4. アカウントB側のホストゾーンIDを確認

[ホストゾーンの詳細] をクリックし、[ホストゾーン ID] をテキストエディタなどにコピペしておきます。このあとのAWS CLI実行時に使用します。

ちなみに、[関連付けられた VPC] にはアカウントBのVPC IDだけが表示されていますが、本手順を進めるとアカウントAのVPC IDも追加されます。

5. アカウントBで名前解決できることを確認

アカウントBのEC2 (Amazon Linux 2)にSSH接続します。

アカウントBのEC2で以下を実行し、作成したプライベートホストゾーンのレコードが名前解決できることを確認します。

名前解決に失敗する場合は、数分待ったあと再度確認します。DNSレコードが浸透（伝播）されるまで少し時間がかかるためです。

💡

名前空間 (example.com など) が重複する場合、パブリックDNSよりプライベートDNSが優先的に名前解決されます。

プライベートホストゾーンへのVPC関連付け (VPC associate)

1. アカウントA側のVPC IDを確認

302263050396

アカウントAのVPC画面から、VPC IDをテキストエディタなどにコピペしておきます。このあとのAWS CLI実行時に使用します。

2. アカウントB側でアカウントAのVPCからの関連付けを許可

Amazon Route 53 と AWS CLI を使用して、VPC（仮想プライベートクラウド）とプライベートホストゾーンの関連付けを認可する手順を実行しています。この操作により、特定の VPC を Route 53 のプライベートホストゾーンに関連付けることができるようになります。

アカウントBのプライベートホストゾーンに対して、アカウントAのVPCからの関連付けを許可します。

アカウントBのEC2で以下のcreate-vpc-association-authorization を実行します。

少し混乱しやすいのですが、プライベートホストゾーンIDはアカウントB側で、VPC IDはアカウントA側である点に注意しましょう。

3. アカウントA側からアカウントBのプライベートホストゾーンへのVPC関連付け

アカウントAから、アカウントBのプライベートホストゾーンに対してVPC関連付けを行います。

アカウントAのEC2 (Amazon Linux 2)にSSH接続し、アカウントAのEC2で以下の associate-vpc-with-hosted-zone を実行します。

出力例：コマンド実行直後は [Status] が [PENDING] となっている

数秒経過後に再度 associate-vpc-with-hosted-zone を実行してみます。

通常であれば以下が表示されますが、「既にVPC関連付けが済んでいる」という内容なので、これは正しい結果です。（以下は見やすいように改行しています）

アカウントBのRoute53 画面を更新すると、[関連付けられたVPC] にアカウントAの VPC ID が追加されています。

4. VPC関連付けの許可を削除

手順3のVPC関連付けが完了したあとは、手順2で実施した「VPC関連付けの許可」を削除しておきます。同じVPC IDからのVPC関連付けの再実行を防ぐためです。

例えば、今後アカウントBのプライベートホストゾーンで他アカウントからのVPC関連付け削除したとします。その場合は上記の「VPC関連付けの許可」を削除しておかないと、アカウントBの同じVPC IDから再度 VPC関連付けができてしまいます。

別の言い方をすると、プライベートホストゾーンを持つAWSアカウントが許可した時だけ、他のアカウントからのVPC関連付けできるようにするということですね。

VPC関連付けの許可を削除しても、設定済みのVPC関連付けには影響しません。

今後、プライベートホストゾーンとアカウントAのこのVPCを再度関連付けたい場合は、手順 2 および 3 を繰り返します。

アカウントBのEC2で以下の list-vpc-association-authorizations を実行します。

出力例：[VPCs] にVPC関連付けを許可しているVPCが表示される

アカウントBのEC2で以下の delete-vpc-association-authorization を実行します。

コマンドが成功した場合は、結果は何も出力されません。

アカウントBのEC2で以下の list-vpc-association-authorizations を実行します。

出力例：[VPCs] が空になった

5. アカウントAで名前解決できることを確認

アカウントAのEC2で以下を実行し、作成したプライベートホストゾーンのレコードが名前解決できることを確認します。

名前解決に失敗する場合は、数分待ったあと再度確認します。

他アカウントのプライベートホストゾーンを名前解決：まとめ

別アカウントで作成したプライベートホストゾーンのレコードを、DNSで名前解決する手順をご紹介しました。

VPC関連付けのコマンドで、VPC IDの指定が少し混乱しやすいので、手順をよく確認しながらAWS CLIを実行していただければと思います。

最後に、テスト目的で作成したプライベートホストゾーンは忘れずに削除しましょう。

一問道場

ある企業が複数のAWSアカウントを使用しています。

DNSレコードは、Account A の Amazon Route 53 プライベートホストゾーンに保存されています。

アプリケーションとデータベースは、Account B に配置されています。

ソリューションアーキテクトは、新しい VPC に 2層アプリケーションをデプロイする予定です。

設定を簡素化するため、Account A の Route 53 プライベートホストゾーンに db.example.com の CNAME レコードセットを作成し、Amazon RDS エンドポイントを登録しました。

しかし、デプロイ時にアプリケーションが起動に失敗しました。

トラブルシューティングの結果、db.example.com が Amazon EC2 インスタンス上で解決できないことが判明しました。

ソリューションアーキテクトは、Route 53 のレコードセットが正しく作成されていることを確認済みです。

この問題を解決するために、ソリューションアーキテクトが取るべき手順はどれですか？

（2つ選択）

選択肢

データベースを新しい VPC の別の EC2 インスタンスにデプロイし、そのインスタンスのプライベート IP アドレス用のレコードセットをプライベートホストゾーンに作成する。

アプリケーション層の EC2 インスタンスに SSH で接続し、RDS エンドポイントの IP アドレスを /etc/resolv.conf ファイルに追加する。

Account A のプライベートホストゾーンを、Account B の新しい VPC と関連付けるための承認を作成する。

Account B で example.com ドメインのプライベートホストゾーンを作成し、AWS アカウント間で Route 53 のレプリケーションを構成する。

Account B の新しい VPC を Account A のホストゾーンに関連付ける。そして、Account A で関連付けの承認を削除する。

どの選択肢を選びますか？

選択肢の解説

A. データベースを新しい VPC の別の EC2 インスタンスにデプロイし、そのインスタンスのプライベート IP アドレス用のレコードセットをプライベートホストゾーンに作成する。

→ 誤り

この手順では、問題の根本原因である VPC 間の DNS 解決を解決できません。Route 53 プライベートホストゾーンの設定に手を加えないため、DNSが解決しない問題が残ります。

B. アプリケーション層の EC2 インスタンスに SSH で接続し、RDS エンドポイントの IP アドレスを /etc/resolv.conf ファイルに追加する。

→ 誤り

/etc/resolv.conf を変更しても、これは手動設定でありスケーラビリティや自動化に欠けます。また、RDS エンドポイントの IP アドレスは動的に変わる可能性があり、これでは管理が非効率的です。根本的な解決策ではありません。

C. Account A のプライベートホストゾーンを、Account B の新しい VPC と関連付けるための承認を作成する。

→ 正解

Route 53 プライベートホストゾーンはデフォルトで同一アカウント内の VPC にのみ関連付けられます。他のアカウント（Account B）の VPC からアクセスするには、関連付け承認を作成する必要があります。これにより、Account A のホストゾーンを Account B の VPC から参照できるようになります。

D. Account B で example.com ドメインのプライベートホストゾーンを作成し、AWS アカウント間で Route 53 のレプリケーションを構成する。

→ 誤り

Route 53 プライベートホストゾーンにおいて、AWSアカウント間でのレプリケーションはサポートされていません。この手順は実現不可能です。

E. Account B の新しい VPC を Account A のホストゾーンに関連付ける。そして、Account A で関連付けの承認を削除する。

→ 正解

Account B の VPC を Account A のプライベートホストゾーンに関連付けることは正しい手順です。これにより、Account B の VPC 内で db.example.com が解決可能になります。関連付けの承認を削除するという手順も、関連付けが有効になった後は不要になるため問題ありません。

正解

C と E

解決のポイントは、VPC 間での Route 53 プライベートホストゾーンの利用を正しく設定することです。この問題では、異なる AWS アカウントにまたがる VPC 間で DNS 解決を有効にするための手順が求められています。