はじめに
オンプレミスからAWSへの名前解決を行う際に名前解決の受け口となるインバウンドエンドポイントの集約について記載していきます。
そもそもなぜオンプレミスからAWSへの名前解決が必要なのか
オンプレミス、クラウド間でなぜ名前解決が必要になるのか疑問に思う人がいるかも知れません。その理由は単純で、AWSのリソースには固定IPでないリソースがあるからです。RDSやALBを始め、名前解決が必須であり、静的なIPアドレスでの接続をサポートしていないリソースが多々あります。そのため、名前解決が前提となるのです。AWS内であれば、AWSのResolverが名前解決を行ってくれますが、AWS外からの場合、名前解決をどのように実装するのか検討する必要があります。また、プライベートなドメインを利用している場合、オンプレミス側あるいはAWS側にDNSを置くことになり、その名前解決の転送を設計する必要があります。
シングルアカウントでの構成
まずはシングルアカウントでの構成です。
名前解決をオンプレミス側で実施する場合
この場合は非常にシンプルで、オンプレミスのDNSサーバのゾーンに対し、必要なレコードを登録します。
固定IPの場合はAレコードとなりますが、ALBなどの名前解決をベースとするリソースは、CNAMEレコードでAWSのリソースのFQDNを登録します。
また、AWSのリソースに関しては、xxx.amazonaws.comのような名前が振られますので、転送ルール（条件付きフォワーダなど）を設定し当該ゾーンの名前解決をAWSのインバウンドエンドポイント宛に転送するように指定します。
ユーザはオンプレミス側のDNSに問い合わせ（www2.exmaple.internal）、返却されたレコード(XXX.amazonaws.com)に基づき再度DNSに問い合わせを行い、転送ルールに基づきAWS側で転送されIPアドレスが返却されます。その結果対象のサービスへのアクセスが可能となります。
DNS自体をAWS側で管理する場合
個人的にはこちらの構成をおすすめしていますが、オンプレミス側では名前解決を単純に転送、すべてAWS側で名前解決をするという構成です。
この場合何がメリットかというと、Route53の機能を利用できること、オンプレミスのDNSには転送ルールの設定のみで、AWS側で自由にゾーンのレコードの書き換えができるということです。
Route53には様々なレコードの種類があり（レイテンシベースや重み付けなど）その利用が可能であるメリットは大きいです。また、BlueGreenデプロイや、障害発生時のレコード切り替えなどをRoute53側に寄せることで、AWSのAPIも利用でき、自由度があがります。
構成としては単純で、オンプレミス側は特定のゾーンの名前解決をインバウンドエンドポイントに転送するのみ、
あとはRoute53プライベートホストゾーンにて適時レコードを定義するのみです。
Route53のレコードが利用できますので、ALIASレコードも利用できます。
CNAMEレコードよりALIASレコードの方が、名前解決の効率は良いので、ALIASレコードが利用可能な場合は、ALIASレコードの利用をおすすめします。
マルチアカウントでの構成
次にマルチアカウントでの構成の場合です。
名前解決をオンプレミス側で実施する場合
シングルアカウントでの場合とほぼ変わりません。
この場合、amazonaws.comの名前解決は、VPC-Aで実施しても、Bで実施しても結果は変わらないですので、どちらか代表するVPCにエンドポイントを作成してあげるだけでよいです。
名前解決をクラウド側で実施する場合
インバウンドエンドポイントの集約なし
単純に考えると以下の構成となります。
VPC-A、Bそれぞれのインバウンドエンドポイントに対してゾーンごとに転送ルールを振り分ける構成となります。
この場合インバウンドエンドポイントのコストがVPCの数だけ加算されてしまいます。
インバウンドエンドポイントの集約あり
以下の構成では、インバウンドエンドポイントを１つに集約しています。
Route53プライベートホストゾーンを、VPC-Aにも紐付けることで、VPC-Bのインバウンドエンドポイントを削減しています。この構成はVPCが増えれば増えるだけ効果があります。インバウンドエンドポイントの費用は決して安くないため、ゾーンの共有が可能であれば、こちらの構成をおすすめします。
まとめ
オンプレミスとAWSのハイブリッドクラウド構成では名前解決が必ずポイントとなります。
管理面、リソース面での費用をできるかぎり削減して便利に使っていきたいですね。