はじめに

オンプレミスからAWSのプライベートDNSを使用して名前解決したい、あるいは、オンプレミスからAWS PrivateLinkにアクセスしたいといった要件を実現するためにRoute 53 Resolverを利用するケースがあります。
AWS→オンプレミスも同様です。

Route 53 Resolverとは

これをガバメントクラウド上のシステムに導入した際、発生する課題と対応方針が以下の記事でまとめられていましたので簡単に紹介させていただきます。
https://aws.amazon.com/jp/blogs/news/govcloud-domain-name-resolution/

インバウンドエンドポイントは運用管理アカウントに置き、他事業者からプライベートゾーンの共有を受ける方針です。
インバウンドエンドポイントが一つだけで良いため、ランニングコストの観点でメリットがあると紹介されています。

AWS CLI、AWS SDK、Amazon Route 53 APIを利用して、プライベートゾーンを他のアカウントのVPVに紐づけることができます。
※名前空間が重複しないように注意

create-vpc-association-authorization
--hosted-zone-id <value>
--vpc <value>

上記に加え、プライベートホストゾーンも一つにまとめて管理しようという方針です。
コスト観点ではメリットがありますが、レコードのCRUDの度にヒューマンコストがかかる構成となっています。

他アカウントにもインバウンドエンドポイントを用意し、運用管理アカウントからの通信をチェーンしていく方針。
もちろんコストは高くなりますが、アカウントごとに関連性が無かったりセキュリティ上の観点から外部に共有したくないといった場合はスタンダードなやり方になりそうです。

オンプレミスとからの入り口もアカウントごとに用意する方針です。
オンプレミス側のフォワーダー設定がアカウントの数だけ増えるので、前方針の方がメリットはありそうです。

アウトバウンドエンドポイントは運用管理アカウントに置き、他アカウントにリゾルバルールを共有する方針です。
アウトバウンドエンドポイントが一つだけで良いため、ランニングコストの観点でメリットがあると紹介されています。
\

Route 53 Resolver コンソールを AWS Resource Access Manager と統合することで、Resolver ルールを他AWSアカウントと共有可能です。
リゾルバルールで定義された名前解決は、アウトバウンドエンドポイントが無いアカウントからも可能となります。

DHCPオプションセットを作成し、VPCに関連付けることで、名前解決の参照先を運用管理アカウントへ集約する方針です。
アカウント内のVPCエンドポイントが使用できなくなるとのことで、よほどのことがない限りこの方針は取らないかなと見受けました。

オンプレミスからAWS環境へのアクセス時の構成と逆になります。
オンプレへの出口調整は、運用管理アカウントに任せることができるメリットがあります。

この方針もオンプレミスからAWS環境へのアクセス時の構成と逆になります。

今回の構成例はガバメントクラウドに限った話ではなく、マルチアカウント構成をとるシステムすべてに流用できる話であるため大変勉強になりました。
アカウント特性とコストをトレードオフにとり最適な構成を目指していきたいです。