トップ > Amazon Route 53 > 【やってみた】Route 53 Resolverを使ったマルチアカウントにおけるプライベートドメインの名前解決基盤実装

【やってみた】Route 53 Resolverを使ったマルチアカウントにおけるプライベートドメインの名前解決基盤実装

Amazon Route 53
記事タイトルとURLをコピーする

こんにちは。ES課で研修中の田原です。

マルチAWSアカウントで繋がったAWS基盤において、どの様にプライベートドメインの名前解決を実装するのが適切かを調べていた際に、以下のAWSブログ「Route 53 Resolverでマルチアカウント環境の DNS 管理を簡素化する」を発見しました。

aws.amazon.com

非常に興味深い設計内容でしたので、「Route 53 Resolverを使ったマルチアカウントにおけるプライベートドメインの名前解決基盤実装」を実際に本ブログで実施してみたいと思います。

※2024/10時点の構築手順となります。アップデート等で変更になっている箇所は適宜読み替えを実施してください。

全体構成と構築ステップ

全体構成

・AWSブログ内で以下の全体構成概要が示されています。

  • Central DNS Accountを基盤の中心として、Route53 Resolverの「エンドポイント」、「転送ルール」を収容
  • ワークロード用のAccount3つに対して、「転送ルールを共有」、「各ワークロードのプライベートホストゾーンを関連付け」を実施
  • オンプレのDNS環境へ「条件付きフォワーダー」にてAWS環境の名前解決を実現

※詳細は以下のAWSブログをご参照ください。

Route 53 Resolverでマルチアカウント環境の DNS 管理を簡素化する | Amazon Web Services ブログ


・上記の内容に従いながら、決まっていない値を追加して以下の構成内容を最終構成として実装を進めていきます。

  • 各アカウントはすべて「東京リージョン」での構築を想定しています。
  • Central DNS AccountをNWアカウントとして、Route53 Resolverに加えTransitGatewayのNWコンポーネントを収容しています。
  • 2つのワークロードアカウントは、異なるシステム（または本番や開発）を想定とした独立したAWSアカウントが、オンプレミスやVPC間の相互に名前解決が必要なケースを想定しています。
  • オンプレミス環境を模擬したAWSアカウントは、DNSサーバ（BIND）が設置されており、DNSサーバを経由したAWS環境と相互に名前解決が必要なケースを想定しています。

最終構成

各アカウントの設計情報

AWSアカウント NWアカウント ワークロードアカウント＃1 ワークロードアカウント＃2 オンプレミス模擬アカウント
VPC　CIDR 172.27.0.0/16 10.1.0.0/16 10.2.0.0/16 192.168.0.0/16
収容プライベート ドメイン ー acc1.awscloud.private acc2.awscloud.private onprem.private
AWS環境リソースの識別子 NW WL1 WL2 ONP

構築ステップ

・構築については以下のステップで進めていきます。

ステップ 概要 対応内容
1 各アカウントのVPC周辺前提環境の構築 ・CloudFormationによる各アカウントの前提環境構築（VPC、SecurityGroup、EC2、TransitGateway）をおこないます。
・環境構築後に、名前解決を行わない各環境間のIPアドレスでの疎通を実施します。
2 NWアカウントにおけるDNS設定 ・NWアカウントにおいて「リゾルバエンドポイント」、「転送ルールの作成」、「転送ルールのResource Access Managerの共有」を実施します。
3 ワークロードアカウントへの共有DNS転送ルールの関連付け ・各ワークロードアカウントへ転送ルールの共有と関連付けをおこないます。
4 ワークロードアカウントのプライベートホストゾーン作成と関連付け ・各ワークロードでプライベートホストゾーンを作成します。
・作成したプライベートホストゾーンをNWアカウントのVPCへ関連付けをおこないます。
5 オンプレミスDNSのフォワーダー追加設定 ・オンプレミス環境のDNSへ条件付きフォワーダーの設定をおこないます。

ステップ①：各アカウントのVPC周辺前提環境の構築

1-1.CloudFormationによる環境展開

・各アカウントの前提環境構築（VPC、SecurityGroup、EC2、TransitGateway）をおこなっていきます。本項目が完了すると以下の構成となります。

ステップ①：各アカウントのVPC周辺前提環境の構築

・手動ですべての構築は煩雑となるため、以下のgithubのリンクの先に今回利用をするCloudFormationを準備しています。

github.com

事前準備CloudFormationファイルの詳細

フォルダ 内容
01_NW-Account 「NWアカウント」内で利用する以下のコンポ―ネットを作成します。

・01_VPC.yml　：　ネットワークに関するリソース作成（VPC、サブネット、ルートテーブル）
・02_SecurityGroup.yml　：　DNSエンドポイントのセキュリティグループ作成
・03_None-Action　：　NWアカウントはEC2コンポーネントは無い為実施不要です
・04_TGW.yml　：　TransitGateway+Attachmentの作成、ルートテーブルの追加、Resource Access Managerでの共有
02_WorkLoad-Account1 「ワークロードアカウント1」内で利用する以下のコンポ―ネットを作成します。

・01_VPC.yml　：　ネットワークに関するリソース作成（VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、EIP）
・02_SecurityGroup.yml　：　EC2のセキュリティグループ作成
・03_EC2.yml　：疎通確認用EC2の作成
・04_TGW.yml　：　TransitGateway アタッチメントの作成、ルートテーブルの追加
03_WorkLoad-Account2 「ワークロードアカウント2」内で利用する以下のコンポ―ネットを作成します。

・01_VPC.yml　：　ネットワークに関するリソース作成（VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、EIP）
・02_SecurityGroup.yml　：　EC2のセキュリティグループ作成
・03_EC2.yml　：疎通確認用EC2の作成
・04_TGW.yml　：　TransitGateway アタッチメントの作成、ルートテーブルの追加
04_On-pre-Account 「オンプレミスアカウント」内で利用する以下のコンポ―ネットを作成します。

・01_VPC.yml　：　ネットワークに関するリソース作成（VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、EIP）
・02_SecurityGroup.yml　：　EC2のセキュリティグループ作成
・03_EC2.yml　：疎通確認用EC2の作成、DNSサーバ(bind)用EC2の作成
・04_TGW.yml　：　TransitGateway アタッチメントの作成、ルートテーブルの追加

・下記の手順にてCloudFormationのデプロイを実行します。

■前提
・構築アカウントは「01_NW-Account」→「02_WorkLoad-Account1」→「03_WorkLoad-Account2」→「04_On-pre-Account」の順番で各アカウント内のCloudFormationの実施をおこないます。

・各アカウント内のCloudFormation実施は「01_VPC.yml」→「02_SecurityGroup.yml」→「03_EC2.yml」→「04_TGW.yml」の順番で実施をおこないます。


■手順
〇「01_NW-Account」の手順
・「CloudFormation」から「スタック」→「スタックの作成」→「新しいリソースを使用」→「既存のテンプレートを選択」→「テンプレートファイルのアップロード」より、ファイルのアップロードをおこないます。

・前提に記載の順番にデプロイをおこないます。
　※「04_TGW.yml」については、ワークロードアカウント1、ワークロードアカウント2、オンプレミスアカウントの3つのAWSアカウントを、「スタックの詳細を指定」時のパラメーター画面で入力する必要があります。

・すべてのスタックのステータスが「CREATE_COMPLETE」で、問題無くデプロイされたことを確認します。


〇「02_WorkLoad-Account1」、「03_WorkLoad-Account2」、「04_On-pre-Account」の共通手順
・「Resource Access Manager」から「自分と共有/リソースの共有」で、TransitGatewayが共有されていることを確認し、「リソース共有の承諾」を実施します。また、「共有リソース」項目からTransitGatewayのリソースIDを確認します（例：tgw-****）

・「CloudFormation」から「スタック」→「スタックの作成」→「新しいリソースを使用」→「既存のテンプレートを選択」→「テンプレートファイルのアップロード」より、ファイルのアップロードをおこないます。

・前提に記載の順番にデプロイをおこないます。
　※「04_TGW.yml」については、上記で確認をしたTransitGatewayのリソースIDを、「スタックの詳細を指定」時のパラメーター画面で入力する必要があります。

・すべてのスタックのステータスが「CREATE_COMPLETE」で、問題無くデプロイされたことを確認します。

1-2.IPアドレスベースでの疎通確認

・AWSブログに紹介されている以下3つのユースケースで通信の確認をおこないます。前提として、「IPアドレスベースでの疎通は可能な事」、「現状、名前解決はできない事」の確認をおこないます。

・「EC2」→「インスタンス」から、対象の名前のインスタンスを選択して、「接続」→「セッションマネージャ」でインスタンスへ接続します。
・実行コマンドを入力し、IPベースでのping疎通ができていることを確認します。

1-2.IPアドレスベースでの疎通確認

・【ケース①】ワークロード1（host1.acc1.awscloud.private：10.1.1.10） →　オンプレミス（host1.onprem.private：192.168.2.10）
　　・ログイン対象インスタンス：WL1-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping 192.168.2.10
　　・実行コマンド3　：　ping host1.onprem.private

・【ケース②】オンプレミス（host1.onprem.private：192.168.2.10）　→　ワークロード1（host1.acc1.awscloud.private：10.1.1.10）
　　・ログイン対象インスタンス：ONP-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping 10.1.1.10
　　・実行コマンド3　：　ping host1.acc1.awscloud.private

・【ケース③】ワークロード1（host1.acc1.awscloud.private：10.1.1.10　→　ワークロード2（host2.acc2.awscloud.private：10.2.1.10）
　　・ログイン対象インスタンス：WL1-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping 10.2.1.10
　　・実行コマンド3　：　ping host2.acc2.awscloud.private

ステップ②：NWアカウントにおけるDNS設定

・ステップ②の構築範囲は以下の赤枠となります。

ステップ②：NWアカウントにおけるDNS設定

2-1.リゾルバーエンドポイント作成

・ここからは、AWSブログに記載の以下の手順コメントを元に構築を進めます。

リゾルバーエンドポイントを作成します。DNS クエリをオンプレミス DNS に転送するアウトバウンドエンドポイントと、オンプレミスのワークロードや他の AWS アカウントから転送された DNS クエリを受信するインバウンドエンドポイントを作成する必要があります。

・まず、固定IPアドレスのアウトバウンドエンドポイントを以下の手順で作成します。

※リゾルバーエンドポイントはAZが異なる最低2つのエンドポイントを作成する必要があります。

・【NWアカウント】において、「Route53」→「リゾルバー/アウトバウンドエンドポイント」へ移動します。

・「アウトバウンドエンドポイントの作成」をクリックし、以下を入力します。
　・エンドポイント名　：　※任意のエンドポイント名で問題ございません※
　・当該リージョンの VPC ：　※Cfnにて作成された「NW-vpc01」を選択※
　・このエンドポイントのセキュリティグループ　：　※Cfnにて作成された「NW-SG-dns」を選択※
　・エンドポイントのタイプ　： IPv4
　・IP アドレス #1
　　・アベイラビリティーゾーン　：　ap-northeast-1a
　　・サブネット　：　※Cfnにて作成されてた「NW-subnet-private-01-a」を選択※
　　・IPv4 アドレス　：　172.27.1.12
　・IP アドレス #2
　　・アベイラビリティーゾーン　：　ap-northeast-1c
　　・サブネット　：　※Cfnにて作成されてた「NW-subnet-private-02-c」を選択※
　　・IPv4 アドレス　：　172.27.2.12

・次に、固定IPアドレスのインバウンドエンドポイントを以下の手順で作成します。

※リゾルバーエンドポイントはAZが異なる最低2つのエンドポイントを作成する必要があります。

※インバウンドエンドポイントは後述の転送ルールにおいて、宛先の指定IPアドレスとなるためIPアドレスを固定化しています。

・【NWアカウント】において、「Route53」→「リゾルバー/インバウンドエンドポイント」へ移動します。

・「インバウンドエンドポイントの作成」をクリックし、以下を入力します。
　・エンドポイント名　：　※任意のエンドポイント名で問題ございません※
　・当該リージョンの VPC ：　※Cfnにて作成された「NW-vpc01」を選択※
　・このエンドポイントのセキュリティグループ　：　※Cfnにて作成された「NW-SG-dns」を選択※
　・エンドポイントのタイプ　： IPv4
　・IP アドレス #1
　　・アベイラビリティーゾーン　：　ap-northeast-1a
　　・サブネット　：　※Cfnにて作成されてた「NW-subnet-private-01-a」を選択※
　　・IPv4 アドレス　：　172.27.1.11
　・IP アドレス #2
　　・アベイラビリティーゾーン　：　ap-northeast-1c
　　・サブネット　：　※Cfnにて作成されてた「NW-subnet-private-02-c」を選択※
　　・IPv4 アドレス　：　172.27.2.11

2-2.転送ルール作成・NWアカウント用VPCへの関連付け

2 つの転送ルールを作成します。最初のルールは、ゾーン onprem.private の DNS クエリをオンプレミスの DNS サーバーの IP アドレスに転送することです。2 番目のルールは、ゾーン awscloud.private の DNS クエリをリゾルバーのインバウンドエンドポイントの IP アドレスに転送することです

・転送ルールをドメイン毎に作成をします。

・本環境は、オンプレミス環境は「onprem.private」で設定をおこないます。転送先の宛先のIPアドレスは「オンプレ環境のDNSサーバ（192.168.1.10）」を指定します。

・【NWアカウント】において、「Route53」→「リゾルバー/ルール」へ移動します。

・「ルールの作成」をクリックし、以下を入力します。
　・名前　：　※任意の名前で問題ありません。※
　・ルールタイプ　：　「転送」になっていることを確認　
　・ドメイン名　：　onprem.private
　・アウトバウンドエンドポイント　：　※先ほど作成したアウトバウンドエンドポイントを選択※
　・ターゲット IP アドレス
　　・IPv4 アドレス　：　192.168.1.10　※オンプレDNSサーバのIPアドレス※

・本環境は、AWS環境ドメイン（acc1.awscloud.private、acc2.awscloud.private）は親の一つのドメインとして「awscloud.private」にまとめることが出来るため、こちらで設定をおこないます。

・ポイントとして転送先のIPアドレスは「リゾルバーインバウンドエンドポイント（172.27.1.11、172.27.2.11）」を指定します。

・【NWアカウント】において、「Route53」→「リゾルバー/ルール」へ移動します。

・「ルールの作成」をクリックし、以下を入力します。
　・名前　：　※任意の名前で問題ありません。※
　・ルールタイプ　：　「転送」になっていることを確認　
　・ドメイン名　：　awscloud.private
　・アウトバウンドエンドポイント　：　※先ほど作成したアウトバウンドエンドポイントを選択※
　・ターゲット IP アドレス
　　・IPv4 アドレス　：　172.27.1.11　※作成したインバウンドエンドポイントのIPアドレス※
　　・IPv4 アドレス　：　172.27.2.11　※作成したインバウンドエンドポイントのIPアドレス※

2-3.転送ルールのNWアカウント用VPCへの関連付け

ルールを作成したら、ゾーン onprem.private のルールをステップ #1 で作成した DNS-VPC に関連付けます(他の転送ルールを DNS-VPC に関連付ける必要はありません)。これにより、Route 53 リゾルバーはドメインクエリの転送をそれに応じて開始できます。

・オンプレミス環境ドメイン(onprem.private)の転送ルールをNWアカウントのVPCに関連付けます。

※AWS環境ドメイン(awscloud.private)の転送ルールは、NWアカウントVPCへの関連付けは不要です。（宛先がNWアカウントVPC内のインバウンドエンドポイントの為、関連付け時にエラーとなります。）

・【NWアカウント】において、「Route53」→「リゾルバー/ルール」へ移動します。作成をした「onprem.private」のルールをクリックします。

・「VPCを関連付ける」をクリックし、以下を入力します。
　・このルールを使用する VPC　：　※Cfnにて作成された「NW-vpc01」を選択※

2-4.転送ルールのRAM共有

最後に、2 つの転送ルールをすべての参加アカウントと共有する必要があります。そのためには、AWS Resource Access Manager を使用し、ルールを AWS 組織全体または特定のアカウントと共有できます。

・「オンプレミス環境ドメイン(onprem.private)の転送ルール」と「AWS環境ドメイン(awscloud.private)の転送ルール」の2つをResource Access Managerを利用して、ワークロードアカウントに共有をします。

・【NWアカウント】において、「Resource Access Manager」→「自分が共有/リソースの共有」へ移動します。

・「リソースの共有を作成」をクリックし以下を入力します。
　リソース共有の詳細を指定
　　・Name　：　※任意の名前で問題ありません。※
　　・リソースタイプ　：　リゾルバルール
　　　・表示された「オンプレミス環境ドメイン(onprem.private)の転送ルール」と「AWS環境ドメイン(awscloud.private)の転送ルール」の2つを選択します。
　プリンシパルにアクセス権限を付与する
　　・プリンシパルタイプの選択　：　AWSアカウント　※AWSアカウントIDをワークロードアカウント#1/#2について入力します※

ステップ③：ワークロードアカウントへの共有DNS転送ルールの関連付け

・ステップ③の構築範囲は以下の赤枠となります。

ステップ③：ワークロードアカウントへの共有DNS転送ルールの関連付け

AWS Resource Access Manager からの共有ルールに同意します。ルールが AWS 組織と共有されている場合、このステップは不要です。次に、転送ルールを各アカウントのワークロードをホストするVPC に関連付けます。関連付けが完了すると、リゾルバーはルールに従ってDNSクエリの転送を開始します。

・各ワークロードアカウントにおいてResouceAccessManagerから共有された2つの転送ルールを同意して有効化します。

・【ワークロードアカウント#1】と【ワークロードアカウント#2】において、「ResouceAccessManager」→「自分と共有/リソースの共有」をクリックします。

・NWアカウントより共有された「転送ルール」を選択し、「リソース共有を承認」をクリックします。

・2つの転送ルールを各ワークロードのVPCへ関連付けをします。

※この時点で「各ワークロードのVPC」→「オンプレミス」への名前解決は実施可能となります。

・【ワークロードアカウント#1】と【ワークロードアカウント#2】において、「Route53」→「リゾルバー/ルール」をクリックします。

・NWアカウントより共有された「オンプレミス環境ドメイン(onprem.private)の転送ルール」をクリックします。
　・「VPCを関連付ける」をクリックし、以下を入力します。
　　・このルールを使用する VPC　：　※Cfnにて作成された「WL1-vpc01」または「WL2-vpc01」を選択※

・NWアカウントより共有された「AWS環境ドメイン(awscloud.private)の転送ルール」をクリックします。
　・「VPCを関連付ける」をクリックし、以下を入力します。
　　・このルールを使用する VPC　：　※Cfnにて作成された「WL1-vpc01」または「WL2-vpc01」を選択※

ステップ④：ワークロードアカウントのプライベートホストゾーン作成と関連付け

・ステップ④の構築範囲は以下の赤枠となります。

ステップ④：ワークロードアカウントのプライベートホストゾーン作成と関連付け

4-1.プライベートホストゾーンの作成・ワークロードへの関連付け

awscloud.private のサブドメインを持つ各参加アカウントにプライベートホストゾーンを作成し、そのアカウントで実行されている VPC に関連付けます。

・ワークロード1アカウントとワークロード2アカウントの各Route53においてプライベートホストゾーンを作成します。各ワークロードのVPCに関連付けをします。

・【ワークロードアカウント#1】と【ワークロードアカウント#2】において、「Route53」→「ホストゾーン」をクリックします。

・「ホストゾーンの作成」をクリックし、以下を入力します。
　ホストゾーン設定
　　・ドメイン名　：　：　※ワークロードアカウント#1の場合は「acc1.awscloud.private」、ワークロードアカウント#2の場合は「acc2.awscloud.private」となります※
　　・タイプ　：　プライベートホストゾーン
　ホストゾーンに関連付ける VPC 
　　・リージョン　：　アジアパシフィック（東京）
　　・VPC ID　：　※ワークロードアカウント#1の場合は「WL1-vpc01」、ワークロードアカウント#2の場合は「WL2-vpc01」となります※

・各プライベートホストゾーンに疎通対象のサーバーのAレコードの登録をおこないます。

・【ワークロードアカウント#1】と【ワークロードアカウント#2】において、「Route53」→「ホストゾーン」→「作成したホストゾーン」をクリックします。

・「レコードの追加」をクリックし、以下を入力します。
　・ワークロードアカウント#1（acc1.awscloud.private）の場合
　　・レコード名：host1
　　・レコードタイプ：Aレコード
　　・値：10.1.1.10

　・ワークロードアカウント#1（acc2.awscloud.private）の場合
　　・サブドメイン：host2
　　・タイプ：Aレコード
　　・値：10.2.1.10

4-2.プライベートホストゾーンのNWアカウントへの関連付け

プライベートホストゾーンを DNS-VPC に関連付けます。これにより、集中管理された DNS-VPC はプライベートホストゾーンのドメインを解決し、AWS アカウント間の DNS リゾルバーとして機能できます

・作成をした各プライベートホストゾーンをNWアカウントのVPCへ関連付けを行います。

※こちらの手順はAWSポータル上からは実施が出来ない為、「AWS　CLI」にて実施をおこないます。

※この時点で「各ワークロードのVPC」間の名前解決は実施可能となります。

■ワークロードアカウント#1
・「CloudShell」を開きます。

・以下のコマンドの「ワークロード1のプライベートホストゾーンID」、「NWアカウントVPCのID」を修正して実行します
aws route53 create-vpc-association-authorization --hosted-zone-id <ワークロード1のプライベートホストゾーンID> --vpc VPCRegion=ap-northeast-1,VPCId=<NWアカウントVPCのID>


■ワークロードアカウント#2
・「CloudShell」を開きます。

・以下のコマンドの「ワークロード2のプライベートホストゾーンID」、「NWアカウントVPCのID」を修正して実行します
aws route53 create-vpc-association-authorization --hosted-zone-id <ワークロード2のプライベートホストゾーンID> --vpc VPCRegion=ap-northeast-1,VPCId=<NWアカウントVPCのID>


■NWアカウント
・「CloudShell」を開きます。

・以下の2つのコマンドの「ワークロード1のプライベートホストゾーンID」、「ワークロード2のプライベートホストゾーンID」、「NWアカウントVPCのID」を修正して実行します
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <ワークロード1のプライベートホストゾーンID> --vpc VPCRegion=ap-northeast-1,VPCId=<NWアカウントVPCのID>
aws route53 associate-vpc-with-hosted-zone --hosted-zone-id <ワークロード2のプライベートホストゾーンID> --vpc VPCRegion=ap-northeast-1,VPCId=<NWアカウントVPCのID>

・実施をおこなうとプライベートホストゾーンの画面で関連付けられたVPCにNWアカウントのVPCが追加されます。

ステップ⑤：オンプレミスDNSのフォワーダー追加設定

・ステップ⑤の構築範囲は以下の赤枠となります。

ステップ⑤：オンプレミスDNSのフォワーダー追加設定

オンプレミスで実行されているワークロードから awscloud.private ドメイン内のサブドメインを解決できるようにするには、Central DNS アカウントに作成されたリゾルバーインバウンドエンドポイントの 2 つの IP アドレスにドメインクエリを転送する条件付き転送ルールを設定する必要があります。

・オンプレミスのDNSサーバにAWS環境ドメイン（awscloud.private）に対する、条件付きフォワーダーの設定を追加します。

※この時点で「オンプレミス」→「各ワークロードのVPC」への名前解決は実施可能となります。

■前提
・本検証環境では、オンプレミスDNSサーバはBINDにて構築をしているため、BINDに条件付きフォワーダーの設定を追加します。

・オンプレミスの疎通用のEC2は、オンプレミスDNSサーバへ名前解決を実施する設定(/etc/systemd/resolved.conf）がCloudFormation実施時に対応済みとなります。


■手順
・「EC2」→「インスタンス」から、「ONP-dns-server」の名前のインスタンスを選択して、「接続」→「セッションマネージャ」でインスタンスへ接続します。

・以下のコマンドを実行して設定ファイルの末尾に追記をおこない、保存します。
sudo vim /etc/named.conf

-----追記内容　ここから-----
zone "awscloud.private" {
        type forward;
        forward only;
        forwarders {
          172.27.1.11;
          172.27.2.11;
        };
};
-----追記内容　ここまで-----

・以下のコマンドでDNSサーバを再起動し設定を反映させます。
sudo systemctl restart named-chroot

プライベートドメイン名ベースでの疎通確認

・「1-2.IPアドレスベースでの疎通確認」でおこなった3つの通信を、プライベートドメイン名ベースで接続が可能になったかの確認をおこなっていきます。

・「EC2」→「インスタンス」から、対象の名前のインスタンスを選択して、「接続」→「セッションマネージャ」でインスタンスへ接続します。
・実行コマンドを入力し、プライベートドメイン名でのping疎通ができていることを確認します。

プライベートドメイン名ベースでの疎通確認

・【ケース①】ワークロード1（host1.acc1.awscloud.private：10.1.1.10） →　オンプレミス（host1.onprem.private：192.168.2.10）
　　・ログイン対象インスタンス：WL1-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping host1.onprem.private

・【ケース②】オンプレミス（host1.onprem.private：192.168.2.10）　→　ワークロード1（host1.acc1.awscloud.private：10.1.1.10）
　　・ログイン対象インスタンス：ONP-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping host1.acc1.awscloud.private

・【ケース③】ワークロード1（host1.acc1.awscloud.private：10.1.1.10　→　ワークロード2（host2.acc2.awscloud.private：10.2.1.10）
　　・ログイン対象インスタンス：WL1-ec2
　　・実行コマンド1　：　hostname
　　・実行コマンド2　：　ping host2.acc2.awscloud.private

・こちらで完成となります。お疲れさまでした。各ケースにおけるプライベートドメイン名での名前解決と接続確認が取れることができました。

お片付け（作成リソースの削除）

・本手順で構築したリソースは課金が発生致します。検証が終わって不要なリソースは以下の流れで削除をおこないます。

・各リソースは依存関係があるため、以下の順番で削除をお願いします。

1. プライベートホストゾーンの削除
　1-1. プライベートホストゾーンの追加レコード削除（host1, host2の2つ）【ワークロードアカウント#1,#2】
　1-2 .プライベートホストゾーン自体の削除（acc1.awscloud.private、acc2.awscloud.privateの2つ）【ワークロードアカウント#1,#2】

2. リゾルバールールの削除
　2-1. リゾルバルールのVPCの関連付けの解除【NWアカウント, ワークロードアカウント#1,#2】
　2-2. リゾルバルール自体の削除（awscloud.private、onprem.privateの2つを実行）【NWアカウント】

3. リゾルバーエンドポイントの削除（インバウンド、アウトバウンドの2つ）【NWアカウント】

4. Resource Access Managerのリゾルバールールの削除（1つ）【NWアカウント】

5.CloudFormationの削除
　・構築アカウントは「04_On-pre-Account」→「03_WorkLoad-Account2」→「02_WorkLoad-Account1」→「01_NW-Account」の順番で各アカウント内のCloudFormationの削除をおこないます。
　・各アカウント内のCloudFormationの削除実施は「04_TGW.yml」→「03_EC2.yml」→「02_SecurityGroup.yml」→「01_VPC.yml」の順番で実施をおこないます。

まとめ

いかがでしたでしょうか？

とても長い記事になってしまいましたが、「Route 53 Resolverを使ったマルチアカウントにおけるプライベートドメインの名前解決」の実装方法をご紹介いたしました。

Route 53 Resolverを一つの環境にまとめることで、集約化のコストメリットや運用の効率化につながる構成と感じました。

本ブログが誰かの学びになれば幸いです。

田原宏樹(執筆記事の一覧)

子供とのお出かけとPodcastを聞くことが趣味です。

  翻译：