Route 53 Resolver エンドポイントとVPCエンドポイントを集約してみた

こんにちは！クラウド事業本部の吉田です。

タイトルにするには長すぎたので省略しましたが、ハイブリッドクラウドおよびマルチアカウント環境上でRoute 53 Resolver エンドポイントとVPCエンドポイントを集約する検証を行いました。

NTT東日本様のご厚意により、Managed SD-WANとクラウドゲートウェイ クロスコネクトを利用したAWSへの閉域接続環境で検証させていただきました。

Managed SD-WAN｜ネットワークマネージド・閉域ネットワークサービス｜法人のお客さま｜NTT東日本
クラウドゲートウェイシリーズ｜法人向けクラウドサービス｜法人のお客さま｜NTT東日本

貴重な機会をいただき、誠にありがとうございました！

構成図

全体構成図

大まかな構成内容は、下記の通りです。

• AWSアカウントは下記の2つで構成
  • 共通NW AWSアカウント
    • 以下のリソースを集約する共通NW AWSアカウント
      • Route 53 Resolver インバウンド/アウトバウンドエンドポイント
      • VPCエンドポイント
  • メンバー AWSアカウント
    • 共通NW AWSアカウントのネットワークリソースを参照するメンバー AWSアカウント
• オンプレミスと各AWSアカウントとの接続は、Direct Connect GatewayとVGWによって接続

VPCエンドポイントのプライベートDNSを有効にすると、AWSマネージドのプライベートホストゾーンが作成されます。

リソース VPC エンドポイントのプライベート DNS を有効にし、VPC で DNS ホスト名と DNS 解決の両方が有効になっている場合、カスタム DNS 名を持つリソース設定用に非表示 AWSのマネージドプライベートホストゾーンが作成されます。ホストゾーンには、VPC 内のリソースエンドポイントのネットワークインターフェイスのプライベート IP アドレスに解決するリソースのデフォルト DNS 名のレコードセットが含まれています。

引用元：AWS PrivateLink経由で VPC リソースにアクセスする

今回の検証のゴールは、オンプレミスからもメンバー AWSアカウントからも、共通NW AWSアカウントのAWSマネージドのプライベートホストゾーンを利用して共通NW AWSアカウントのVPCエンドポイントを名前解決し、共通NW AWSアカウントのVPCエンドポイント経由でメンバー AWSアカウントにあるS3にアクセスすることです。

各環境からの名前解決の経路について説明します。

オンプレミスからの名前解決

オンプレミスからは、Route 53 Resolver インバウンドエンドポイントを利用して名前解決をします。

Route 53 Resolver インバウンドエンドポイントは、Route 53 ResolverがあるVPC外の環境からRoute 53 Resolverを参照する際に利用されるエンドポイントです。

Route 53 Resolver インバウンドエンドポイントの利用イメージは、下記の記事がとてもわかりやすいので、ぜひお読みください。

【ざっくり解説】Route 53 ResolverとResource Access Managerについて3段階で図解説する## 第2段階 Route 53 Resolver エンドポイント

VPCエンドポイントへの名前解決とS3へのアクセスの流れは、下記の通りです。

• オンプレミス端末がS3バケットへのアクセスを試みる
• オンプレミスDNSサーバーがap-northeast-1.amazonaws.com宛のクエリをRoute 53 Resolver インバウンドエンドポイントへ転送
  • 今回の検証環境にはDNSサーバーがないので、端末上のDNS設定にRoute 53 Resolver インバウンドエンドポイントのIPを設定しました
• Direct Connect GatewayとVGWを経由したDNSクエリをRoute 53 Resolver インバウンドエンドポイントが受信し、共通NW AWSアカウント内のRoute 53 Resolverへ転送
• Route 53 ResolverがAWSマネージドのプライベートホストゾーンを参照
• S3のVPCエンドポイント用のプライベートホストゾーンから、エンドポイントのプライベートIPアドレスを取得
• 解決されたIPアドレス情報が元の経路を逆にたどり、オンプレミス端末に返送される
• オンプレミス端末は取得したプライベートIPアドレスを使用し、共通NW AWSアカウントのVPCエンドポイントを経由してS3バケットにアクセス

メンバー AWSアカウントからの名前解決

次は、メンバー AWSアカウントからの名前解決です。
こちらの構成は下記の公式ドキュメントで提示されているアーキテクチャを参照しております。

複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス

この構成の一番重要なポイントは、共通NW AWSアカウントのリゾルバー転送ルールをRAMを利用しメンバー AWSアカウントと共有している点です。

VPC内から別環境のDNSサーバーを利用する場合は、Route 53 Resolver アウトバウンドエンドポイントを利用する必要があります。
通常、アクセス元のVPC上にRoute 53 Resolver アウトバウンドエンドポイントを作成する必要があります。
そこで、RAMを利用しリゾルバー転送ルールを共有することで、別のAWSアカウントのVPC上にあるRoute 53 Resolver アウトバウンドエンドポイントを利用できます。
そして、リゾルバー転送ルールのターゲットIPにRoute 53 Resolver インバウンドエンドポイントのIPを指定することで、別のAWSアカウントのプライベートホストゾーンを参照できるようになります。
このように対応することで、Route 53 Resolver インバウンド/アウトバウンドエンドポイントを1つのAWSアカウントに集約することができます。

VPCエンドポイントへの名前解決とS3へのアクセスの流れは、下記の通りです。

• メンバー AWSアカウントのEC2がS3バケットへのアクセスを試みる
• EC2からのDNSクエリがメンバー AWSアカウント内のRoute 53 Resolverに送信される
• メンバー AWSアカウントのRoute 53 ResolverがRAMで共有された共通NW AWSアカウントのリゾルバー転送ルールを参照
• 共有されたリゾルバー転送ルールに基づき、DNSクエリが共通NW AWSアカウントのRoute 53 Resolver アウトバウンドエンドポイントに転送される
  • リゾルバー転送ルールのドメインはap-northeast-1.amazonaws.comを指定します
• Route 53 Resolver アウトバウンドエンドポイントからRoute 53 Resolver インバウンドエンドポイントへDNSクエリが転送される
• Route 53 Resolver インバウンドエンドポイントから共通NW AWSアカウント内のRoute 53 Resolverにクエリが転送される
• Route 53 ResolverがAWSマネージドのプライベートホストゾーンを参照
• S3のVPCエンドポイント用のプライベートホストゾーンから、エンドポイントのプライベートIPアドレスを取得
• 解決されたIPアドレス情報が元の経路を逆にたどり、EC2に返送される
• EC2は取得したプライベートIPアドレスを使用し、VPC Peeringを経由し、さらに共通NW AWSアカウントのVPCエンドポイントを経由し、S3バケットにアクセス

環境準備

下記の内容で環境を用意しました。
下記以外の設定に関しては、画面キャプチャ付きで設定していきます。

• 共通NW AWSアカウント
  • ネットワーク
    • VPC
    • サブネット
      • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット
      • VPCエンドポイント用サブネット
    • VPCエンドポイント
      • 全てのエンドポイントでプライベートDNSを有効
      • SSM インターフェイスVPCエンドポイント
        • SSMセッションマネージャーを利用してEC2に接続するため
      • S3インターフェイスVPCエンドポイント
      • STSインターフェイスVPCエンドポイント
        • オンプレミス環境でのスイッチロールのために利用
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント
    • VPCペアリング
      • メンバーアカウントのVPCと接続
    • ルートテーブル
      • プライベートサブネット用ルートテーブル
        • オンプレミスへのルート
          • 動的ルーティングの場合は、ルート伝播を有効化する
        • メンバーアカウントのVPCへのルート
          • ターゲットはVPCペアリング
      • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット用ルートテーブル
        • 上記と同様
  • セキュリティグループ
    • VPCエンドポイント用のセキュリティグループ
      • メンバーアカウントのVPC CIDRと、オンプレミス側のCIDRを許可
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用セキュリティグループ
      • 下記の公式ドキュメントの内容で作成
      • リゾルバーエンドポイントのスケーリング - Amazon Route 53
      • このセキュリティグループについて検証した記事がありますので、ぜひお読みください（今回は公式ドキュメント通りに設定しました）
      • Route 53 Resolver Endpointに必要なセキュリティグループのルールを確認してみた | DevelopersIO
• メンバー AWSアカウント
  • ネットワーク
    • VPC
    • サブネット
      • プライベートサブネット
    • VPCペアリング
      • 共通NW AWSアカウントのVPCと接続
    • ルートテーブル
      • プライベートサブネット用ルートテーブル
        • オンプレミスへのルート
          • 動的ルーティングの場合は、ルート伝播を有効化する
        • 共通NW AWSアカウントのVPCへのルート
          • ターゲットはVPCペアリング
  • セキュリティグループ
    • EC2用のセキュリティグループ
      • オンプレミスからの疎通確認用にオンプレミス側のIPを許可
  • EC2
    • プライベートサブネットに配置
  • S3バケット
    • 「共通NW AWSアカウントのS3インターフェイスVPCエンドポイント経由アクセス、もしくは、特定のIAMユーザー・IAMロールからのアクセス」以外はアクセス拒否をするS3のバケットポリシーを設定
    • 設定内容は、過去のAWS Site-to-Site VPNの記事を参照してください
    • AWS Site-to-Site VPN経由でS3にアクセスしてみた
  • IAM
    • オンプレミスで利用するスイッチロール用IAMユーザーとS3アクセス用IAMロールを作成
    • 設定内容は、過去のAWS Site-to-Site VPNの記事を参照してください
    • AWS Site-to-Site VPN経由でS3にアクセスしてみた

作業一覧

• 各AWSアカウント上でVGWとDirectConnect Gatewayの関連付けを申請
• Route53 インバウンドエンドポイント/アウトバウンドエンドポイント作成
• リゾルバー転送ルール作成
• RAMによるリゾルバー転送ルールの共有

各AWSアカウント上でVGWとDirect Connect Gatewayの関連付けを申請

まずオンプレミス環境と各AWSアカウントを接続するために、VGWとDirect Connect Gatewayの関連付けを申請します。
今回は、NTT東日本様のAWSアカウント上にあるDirect Connect Gatewayに関連付けを申請する形となります。

VGWとDirectConnect Gatewayの関連付けの申請は、Direct Connect Gatewayのページで行います。

ナビゲーションペインから「仮想プライベートゲートウェイ」をクリックしますと、VGWの一覧が表示されますので、対象のVGWをクリックしてください。

「Direct Connectゲートウェイの関連付け」タブをクリックした後、「Direct Connectゲートウェイを関連付ける」をクリックしてください。

設定画面に移りますので、以下の内容で設定します。

• 関連付けアカウントタイプ
  • 別のアカウント
• Direct Connect ゲートウェイ ID
  • 接続先のDirect Connect GatewayのID
• Direct Connect ゲートウェイの所有者
  • 接続先のDirect Connect GatewayがあるAWSアカウントID

これで関連付けの申請は完了です。
Direct Connect GatewayがあるAWSアカウント上で、この関連付けを承認すればVGWとDirect Connect Gatewayは関連付けられます。

Route 53 Resolver インバウンド/アウトバウンドエンドポイント作成

Route 53 Resolver インバウンド/アウトバウンドエンドポイントを共通NW AWSアカウント上で作成します。

Route 53 Resolver インバウンドエンドポイント作成

Route 53 Resolver インバウンドエンドポイントのページは、Route 53のページのナビゲーションペインから「インバウンドエンドポイント」をクリックすることで表示できます。

以下の設定で、作成します。

• エンドポイント名
  • common-nw-inbound-endpoint
• VPC
  • 共通NW AWSアカウントのVPC
• セキュリティグループ
  • Route 53 Resolver インバウンドエンドポイント用セキュリティグループ
• エンドポイントのタイプ
  • IPv4
• プロトコル
  • Do53
• IPアドレス#1
  • AZ
    • ap-northeast-1a
  • サブネット
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット
  • IPv4
    • 自動的に選択されたIPv4アドレスを使用します
• IPアドレス#2
  • AZ
    • ap-northeast-1c
  • サブネット
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット
  • IPv4
    • 自動的に選択されたIPv4アドレスを使用します

Route 53 Resolver アウトバウンドエンドポイント作成

Route 53 Resolver アウトバウンドエンドポイントのページは、Route 53のページのナビゲーションペインから「アウトバウンドエンドポイント」をクリックすることで表示できます。

以下の設定で、作成します。

• エンドポイント名
  • common-nw-outbound-endpoint
• VPC
  • 共通NW AWSアカウントのVPC
• セキュリティグループ
  • Route 53 Resolver アウトバウンドエンドポイント用セキュリティグループ
• エンドポイントのタイプ
  • IPv4
• プロトコル
  • Do53
• IPアドレス#1
  • AZ
    • ap-northeast-1a
  • サブネット
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット
  • IPv4
    • 自動的に選択されたIPv4アドレスを使用します
• IPアドレス#2
  • AZ
    • ap-northeast-1c
  • サブネット
    • Route 53 Resolver インバウンド/アウトバウンドエンドポイント用サブネット
  • IPv4
    • 自動的に選択されたIPv4アドレスを使用します

リゾルバー転送ルール作成

リゾルバー転送ルールを共通NW AWSアカウント上で作成します。

リゾルバー転送ルールを作成する前に、Route 53 Resolver インバウンドエンドポイントのIPを確認します。

Route 53 Resolver インバウンドエンドポイントのページから、作成したエンドポイントをクリックし、詳細画面からIPアドレスを確認します。
確認したIPをメモしてください。

リゾルバールールのページは、Route 53のページのナビゲーションペインから「ルール」をクリックすることで表示できます。

以下の設定で作成します。

• 名前
  • common-nw-forwarding-rule
• ルールタイプ
  • 転送
• ドメイン名
  • ap-northeast-1.amazonaws.com
• アウトバウンドエンドポイント
  • common-nw-outbound-endpoint
• ターゲットIPアドレス
  • 確認したRoute 53 Resolver インバウンドエンドポイントの2つのIPを指定

RAMによるリゾルバー転送ルールの共有

リゾルバー転送ルール共有元 AWSアカウント(共通NW AWSアカウント)上での作業

RAMを利用して、共通NW AWSアカウント上で作成したリゾルバー転送ルールをメンバー AWSアカウントに共有します。

RAMのページのナビゲーションペインから「自分が共有」の「リソースの共有」をクリックします。
このページから、今いるAWSアカウントのリソースを他のAWSアカウントに共有するRAMが作成できます。

以下の設定で作成します。

• 名前
  • common-nw-forwarding-rule-ram
• リソース
  • タイプ
    • 「リゾルバルール」を選択
  • 表示されたリゾルバー転送ルール(common-nw-forwarding-rule)を選択
• マネージド型アクセス許可
  • デフォルト
• プリンシパル
  • すべてのユーザーとの共有を許可
• プリンシパルタイプ
  • AWSアカウント
  • メンバー AWSアカウントのIDを入力し、「追加」をクリック

これでリゾルバー転送ルール共有元の共通NW AWSアカウントの作業は完了です。

リゾルバー転送ルール共有先 AWSアカウント(メンバー AWSアカウント)上での作業

共通NW AWSアカウントから共有されたリゾルバー転送ルール用のRAMをメンバー AWSアカウント上で承認します。

RAMのページのナビゲーションペインから「自分と共有」の「リソースの共有」をクリックし、表示されている共通NW AWSアカウントのRAMをクリックします。

詳細画面にある「リソース共有を承認」をクリックし、表示されたポップの「承認」をクリックすると、RAMが承認されます。

これで、メンバー AWSアカウントでも共通NW AWSアカウントのリゾルバー転送ルールを利用できるようになりました。

次に、ナビゲーションペインから「共有リソース」をクリックし、表示されている共通NW AWSアカウントのリゾルバー転送ルールをクリックします。

この詳細画面から、共有されたリゾルバー転送ルールをメンバー AWSアカウントのVPCと関連づけることができます。
「VPCを関連付ける」をクリックし、表示されたポップからメンバー AWSアカウントのVPCを選択した後、「追加」をクリックします。

これで、メンバー AWSアカウント上のap-northeast-1.amazonaws.comドメインへのDNSクエリは、共通NW AWSアカウントのAWSマネージドのプライベートホストゾーンに投げられるようになりました。

疎通確認

オンプレミスから各AWSアカウント上のEC2への疎通確認

S3への疎通確認の前に、オンプレミスからAWSアカウントへの疎通確認するために、各AWSアカウント上のEC2へpingを打ちます。
（環境準備のところでは説明を省略していますが、共通NW AWSアカウントのプライベートサブネットに疎通確認用のEC2を立てていました）

共通NW AWSアカウント

ping 10.2.0.165

$ ping 10.2.0.165
PING 10.2.0.165 (10.2.0.165): 56 data bytes
64 bytes from 10.2.0.165: icmp_seq=0 ttl=121 time=10.177 ms
64 bytes from 10.2.0.165: icmp_seq=1 ttl=121 time=11.548 ms
64 bytes from 10.2.0.165: icmp_seq=2 ttl=121 time=9.625 ms
64 bytes from 10.2.0.165: icmp_seq=3 ttl=121 time=9.543 ms

メンバー AWSアカウント

ping 10.3.0.32

$ ping 10.3.0.32
PING 10.3.0.32 (10.3.0.32): 56 data bytes
64 bytes from 10.3.0.32: icmp_seq=0 ttl=121 time=10.193 ms
64 bytes from 10.3.0.32: icmp_seq=1 ttl=121 time=9.240 ms
64 bytes from 10.3.0.32: icmp_seq=2 ttl=121 time=10.049 ms
64 bytes from 10.3.0.32: icmp_seq=3 ttl=121 time=9.943 ms

Direct Connect GatewayとVGWを経由して、オンプレミスから各AWSアカウントに疎通できることを確認できました。
余談ですが、初めてDirect Connect Gatewayを利用したので、結構感動しました。

オンプレミスからのS3アクセス

今回の検証環境にはDNSサーバーがないので、端末上でDNS設定をします。

イーサネットのDNS設定で、Route 53 Resolver インバウンドエンドポイントのIPを指定します。

スイッチロール用IAMユーザーのアクセスキー・シークレットキーを設定します。

aws configure

スイッチロール用のプロファイルを設定します。

vi ~/.aws/config

下記の内容を追記してください。

[profile s3-access]
region = ap-northeast-1
role_arn = {スイッチロール先のS3アクセス用IAMロールのARN}
source_profile = default

では、オンプレミスからの疎通確認用ファイルをS3にアップロードしてみましょう。

過去のAWS Site-to-Site VPNの検証の時とは違い、VPCエンドポイントのプライベートDNSで名前解決できるため、AWS_ENDPOINT_URL_<SERVICE>変数を設定する必要はありません。

cd ~/
touch onpremises-test.txt
aws s3 cp ./onpremises-test.txt s3://{S3バケット名}/ --profile s3-access

$ cd ~/
$ touch onpremises-test.txt
$ aws s3 cp ./onpremises-test.txt s3://member-XXXXXXXX/ --profile s3-access
upload: ./onpremises-test.txt to s3://member-XXXXXXXXX/onpremises-test.txt

マネージドコンソール上で、S3にファイルが配置されていることを確認してみます。

無事、オンプレミスからの疎通確認用ファイルがアップロードされていました。

メンバー AWSアカウントからのS3アクセス

メンバー AWSアカウントのEC2から、S3にアクセスします。

SSM Session Managerで、メンバー AWSアカウントのEC2にログインします。
SSM Session Managerを利用できる時点で、共通NW AWSアカウントのSSMエンドポイントに名前解決できてそうですね。

では、メンバー AWSアカウントからの疎通確認用ファイルをS3にアップロードしてみましょう。

cd ~/
touch member-test.txt
aws s3 cp ./member-test.txt s3://{S3バケット名}/

sh-5.2$ cd ~/
sh-5.2$ touch member-test.txt
sh-5.2$ aws s3 cp ./member-test.txt s3://member-XXXXXXXXX/
upload: ./member-test.txt to s3://member-XXXXXXXXX/member-test.txt
sh-5.2$

マネージドコンソール上で、S3にファイルが配置されていることを確認してみます。

無事、メンバー AWSアカウントからの疎通確認用ファイルがアップロードされていました。

さいごに

前回の記事の環境にRoute 53 Resolver インバウンドエンドポイントを導入して検証するつもりでしたが、リッチな構成の検証ができて満足です。

以上、クラウド事業本部の吉田でした！

参考記事

• ハイブリッドクラウドかつマルチアカウント構成で、Route 53 Resolver イン / アウトバウンドエンドポイントの集約 | DevelopersIO
• [アップデート] S3 インターフェースエンドポイントでプライベート DNS 名を使用できるようになりました | DevelopersIO
• 複数の VPC から中央のAWS のサービスエンドポイントにプライベートにアクセスする - AWS 規範ガイダンス