先日 パブリックアクセスを無効にした RDS のエンドポイントの名前解決について記事を書いた のですが、今度は AWS サービスのインターフェース型 VPC エンドポイント（インターフェースエンドポイント）を作成して他の VPC から参照させる時の名前解決の仕組みも整理してみます。
具体的には、インターフェースエンドポイントを 1 つの VPC に設置し（「集約 VPC」とします）、集約 VPC とルーティングが可能な別の VPC（「利用側 VPC」とします）からインターフェースエンドポイントへ接続できるよう、利用側 VPC からインターフェースエンドポイント名を名前解決するためには、どのような構成があるかについて検証します。
集約 VPC のインターフェースエンドポイントを利用側 VPC から名前解決するパターンは 2 通りある
集約 VPC にあるインターフェースエンドポイントを名前解決するには、利用側 VPC の設定により、2 パターンの方法があります。
- 集約 VPC にある Route 53 インバウンドエンドポイントを DNS 参照先に設定する
- 集約 VPC のあるアカウントにて AWS サービスのエンドポイント名で Route 53 プライベートホストゾーンを作成して名前解決させる
これらの名前解決パターンのイメージ図は次のとおりです。
なお、オンプレミスからインターフェースエンドポイントを名前解決する方法は、Route 53 インバウンドエンドポイントを参照する方法の一択となります。
オンプレミス、利用側 VPC ともに、全て Route 53 インバウンドエンドポイントを参照する構成であれば、難しく考えることなく普通にインターフェースエンドポイントを作成するだけでよいです。
しかし、利用側 VPC の中に Route 53 インバウンドエンドポイントを参照しない構成のものがある場合、名前解決について注意が必要であり、今回はこの注意点を中心に検証をしていきます。
集約 VPC の Route 53 インバウンドエンドポイントを DNS 参照先に設定する構成
一方の利用側 VPC には DHCP オプションセットを使うなどで DNS リゾルバーの参照先を集約 VPC にある Route 53 インバウンドエンドポイントへ向け転送するよう構成しています。
よって、集約 VPC 内でインターフェースエンドポイントの名前解決ができる構成になっていれば、利用側 VPC でも同様に解決可能です。
先述のとおり、全ての利用側 VPC がこの構成である場合は、特に注意することはありません。
AWS サービス名の Route 53 プライベートホストゾーンを作成して VPC に関連付ける構成
もう一方の利用側 VPC には、集約 VPC のあるアカウントで作成された、AWS サービスのエンドポイント名の Route 53 プライベートホストゾーンが関連付けられています。
この集約 VPC アカウントの Route 53 プライベートホストゾーンは、AWS サービスのエンドポイント名（ssm.ap-northeast-1.amazonaws.com など）を、インターフェースエンドポイント名（vpce-hoge.ssm.ap-northeast-1.vpce.amazonaws.com など）のエイリアスに設定しています。
よって、この Route 53 プライベートホストゾーンが関連付けられた利用側 VPC は、当該 AWS サービスのエンドポイント名を名前解決すると集約 VPC のインターフェースエンドポイントの IP アドレスが返ってくる構成です。
つまり Route 53 プライベートホストゾーンがインターフェースエンドポイントの名前解決について重要な役割を持っているのですが、インターフェースエンドポイントを作成する時の設定に気をつけないと、Route 53 プライベートホストゾーンを作成できません。
これが今回の注意点ですので、次項から詳しく解説していきます。
インターフェースエンドポイントを集約する時はプライベート DNS 名を無効にする
インターフェースエンドポイントを作成する際、プライベート DNS 名を有効にするかどうかの設定があります。
これは他の VPC にインターフェースエンドポイントを利用させる際の重要なポイントとなるため、先に結論から書いておきます。
インターフェースエンドポイントを一つの VPC へ集約したい場合は、いずれの名前解決パターンであっても、以下の設定にすべきです。
- インターフェースエンドポイントの プライベート DNS 名を無効 にする
- AWS サービス名で Route 53 プライベートホストゾーンを作成し、集約 VPC に関連付ける
インターフェースエンドポイントのプライベート DNS 名の有効無効、AWS サービスのエンドポイント名の Route 53 プライベートホストゾーンの有無で、名前解決の結果がどうなるか見てみます。
| 名前解決パターン | プライベート DNS 名 | Route 53 プライベートホストゾーンの集約 VPC への関連付け | 結果 |
|---|---|---|---|
| 集約 VPC の Route 53 インバウンドエンドポイントを参照 | 有効 | なし | OK |
| 集約 VPC の Route 53 インバウンドエンドポイントを参照 | 無効 | なし | NG（パブリック IP アドレスが返る） |
| 集約 VPC の Route 53 インバウンドエンドポイントを参照 | 無効 | あり | OK |
| 利用側 VPC に Route 53 プライベートホストゾーンを関連付け | 有効 | - | NG（Route 53 プライベートホストゾーン自体を作れない） |
| 利用側 VPC に Route 53 プライベートホストゾーンを関連付け | 無効 | あり | OK |
いずれの名前解決パターンでも結果が OK となるのは、プライベート DNS 名が無効で、Route 53 プライベートホストゾーンを集約 VPC へ関連付けしているケースのみとなっています。
理由は後述しますが、まずはこの方針で名前解決パターンを構築してみます。
名前解決パターンの設定手順
インターフェースエンドポイントの作成
今回は検証として Systems Manager の Session Manager で必要となる ssm, ssmmessages の 2 つの AWS サービスのインターフェースエンドポイントを集約 VPC に作成します（全て東京リージョンとします）。
作成の際、「DNS 名を有効化」のオプションは必ず外します。
プライベート DNS 名を無効にしたインターフェースエンドポイントが作成できました。
プライベート DNS 名を無効にしている場合、AWS サービスのエンドポイント名を名前解決してもパブリック IP アドレスが返ってくるため、このままではエンドポイントに疎通ができません。
この状態でプライベート IP アドレスへ名前解決できるようにするためには、Route 53 プライベートホストゾーンを作成する必要があります。
Route 53 プライベートホストゾーンの作成
集約 VPC のあるアカウントで、ssm のエンドポイント名である ssm.ap-northeast-1.amazonaws.com というドメインで、集約 VPC に関連付けた Route 53 プライベートホストゾーンを作成します。
Route 53 プライベートホストゾーンが作成できたら、ssm のインターフェースエンドポイント名へのエイリアスに設定したレコードを追加します。
レコードが追加できたら、同じ手順で ssmmessages の Route 53 プライベートホストゾーンを作成します。
これにより、集約 VPC 内で ssm, ssmmessages のエンドポイント名を名前解決すると、プライベート IP アドレスが返ってくるようになり、エンドポイントへ疎通できるようになります。
Route 53 インバウンドエンドポイントで名前解決を確認
集約 VPC 内で ssm, ssmmessages のエンドポイントを名前解決できるようになったため、集約 VPC にある Route 53 インバウンドエンドポイントを DNS リゾルバーとして参照する利用側 VPC からも名前解決ができるようになっています。
名前解決ができない場合、利用側 VPC の DHCP オプションセットなどを確認し、DNS リゾルバーが集約 VPC の Route 53 インバウンドエンドポイントを向いているか確認しましょう。
次に、Route 53 インバウンドエンドポイントを参照していない方の利用側 VPC にて ssm, ssmmessages の名前解決ができるよう、先ほど作成した Route 53 プライベートホストゾーンをこの別アカウントの利用側 VPC にも関連付けてみます。
別アカウント VPC への Route 53 プライベートホストゾーン関連付け
同じアカウント内の VPC へのRoute 53 プライベートホストゾーンの関連付けであれば、マネジメントコンソールからでも設定可能です。
しかし別アカウントの VPC への関連付けになると、AWS CLI などから操作する必要があります。
Route 53 プライベートホストゾーンを作成した、集約 VPC のある方のアカウントのクレデンシャルで、以下のコマンドを AWS CLI から実行します。
$ aws route53 create-vpc-association-authorization --hosted-zone-id "プライベートホストゾーンの ID" --vpc VPCRegion=ap-northeast-1,VPCId="VPC の ID" --region ap-northeast-1 --profile "プロファイル名"
成功すると以下のような JSON が出力されます。
次に利用側 VPC のあるアカウントのクレデンシャルで、以下のコマンドを AWS CLI から実行します。
$ aws route53 associate-vpc-with-hosted-zone --hosted-zone-id "プライベートホストゾーンの ID" --vpc VPCRegion=ap-northeast-1,VPCId="VPC の ID" --region ap-northeast-1 --profile "プロファイル名"
同様に JSON が出力されます。
マネジメントコンソールから Route 53 プライベートホストゾーンの VPC への関連付けについて確認してみます。「関連付けられた VPC」に上記コマンドで設定した VPC ID があれば成功です。
関連付けが確認できたら、最後に集約 VPC のある方のアカウントのクレデンシャルで、VPC への関連付け要求を削除するため、以下のコマンドを AWS CLI から実行すれば、Route 53 プライベートホストゾーンに関する作業は完了です。
$ aws route53 delete-vpc-association-authorization --hosted-zone-id "プライベートホストゾーンの ID" --vpc VPCRegion=ap-northeast-1,VPCId="VPC の ID" --region ap-northeast-1 --profile "プロファイル名"
Route 53 プライベートホストゾーンを関連付けた利用側 VPC から名前解決を確認
名前解決が成功していれば、Route 53 プライベートホストゾーンを関連付けた VPC からも ssm, ssmmessages の名前解決ができるようになり、EC2 インスタンスが Session Manager へ接続できるようになります。
以上で、集約 VPC にインターフェースエンドポイントをまとめ、利用側 VPC から利用できる名前解決パターンが全て完成しました。
インターフェースエンドポイントのプライベート DNS 名を無効にしなければならない理由
インターフェースエンドポイントのプライベート DNS 名を無効にしなければ、AWS サービスのエンドポイント名で Route 53 プライベートホストゾーンが作成できません。
試しにインターフェースエンドポイントのプライベート DNS 名を有効にした状態で、当該 AWS サービスのエンドポイント名で Route 53 プライベートホストゾーンを作成しようとすると、以下の画像のようにエラーとなります。
これは、プライベート DNS 名を有効にしてインターフェースエンドポイントを作成すると、裏で AWS が管理する Route 53 プライベートホストゾーンが自動的に VPC に関連付けられるような動作となるため、同じドメイン名で Route 53 プライベートホストゾーンを作成できないためです。
この自動で作られた Route 53 プライベートホストゾーンはユーザーから操作できず、別の VPC に関連付けることができないため、この制約を避けるためにはプライベート DNS 名を無効にしてインターフェースエンドポイントを作る必要があります。
ここで、インターフェースエンドポイントのプライベート DNS 名を無効にすると、集約 VPC 内で当該 AWS サービスのエンドポイント名を名前解決するとパブリック IP アドレスが返ってくるようになってしまいます。
そのため、集約 VPC にある Route 53 インバウンドエンドポイントからもプライベート IP アドレスに名前解決するためには、同様に Route 53 プライベートホストゾーンを作成して集約 VPC に関連付けなければなりません。
運用していく上で、全ての VPC が Route 53 インバウンドエンドポイントを参照するよう統制できればよいのですが、現実は別のオーナーが管理するアカウントの VPC を繋がなければならないなど、2 つの名前解決パターンの両方に対応できることが求められることもあると考えられるため、初めから Route 53 プライベートホストゾーンを作成できるように、インターフェースエンドポイントのプライベート DNS 名は無効にする方針で構成するのがよいのかなと思います。