ガバメントクラウドにおけるオンプレミスからAWSへの名前解決の指針について

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

:::note info
## Route 53 Resolverとは
- VPC内にてデフォルトで存在する、フォワーダー機能を持つDNSサーバー
- Route 53 プライベートホストゾーンへ通信を転送

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/b1056a38-5823-ca24-ee36-1fe35d210f59.png)
### インバウンドエンドポイントの利用
- インバウンドエンドポイントを立てることで、エンドポイント経由でオンプレミスからRoute 53 Resolverにクエリ処理を送ることが可能
- つまり、オンプレミスからAWS上の名前解決が可能に！
### アウトバウンドエンドポイントの利用
- アウトバウンドエンドポイントを立てることで、エンドポイント経由でRoute 53 ResolverからオンプレDNSサーバにクエリ処理を送ることが可能
- Route 53 Resolver Ruleにて、Route 53 ResolverがどのDNSサーバーを参照するかのルールを定義しておく
- VPCが複数ある場合は、上記ルールをResource Access Manager経由で共有することで、管理コストを削減可能
- つまり、AWSからオンプレミス上の名前解決が可能に！
:::

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

# オンプレミスからAWSの名前解決
## Route 53 Private Hosted Zone を他の VPC へ共有する方法
インバウンドエンドポイントは運用管理アカウントに置き、他事業者からプライベートゾーンの共有を受ける方針です。
インバウンドエンドポイントが一つだけで良いため、ランニングコストの観点でメリットがあると紹介されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/337aa808-3047-b177-0e8c-cf89fe14aae9.png)

:::note info
## プライベートゾーンの共有
AWS CLI、AWS SDK、Amazon Route 53 APIを利用して、プライベートゾーンを他のアカウントのVPVに紐づけることができます。
※名前空間が重複しないように注意
```
create-vpc-association-authorization
--hosted-zone-id <value>
--vpc <value>
```
:::


## 運用管理アカウントで集中管理する方法
上記に加え、プライベートホストゾーンも一つにまとめて管理しようという方針です。
コスト観点ではメリットがありますが、レコードのCRUDの度にヒューマンコストがかかる構成となっています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/6de92c9f-d346-4a66-8931-ee63307cbaeb.png)
## Route 53 Resolver エンドポイントを連携する方法
他アカウントにもインバウンドエンドポイントを用意し、運用管理アカウントからの通信をチェーンしていく方針。
もちろんコストは高くなりますが、アカウントごとに関連性が無かったりセキュリティ上の観点から外部に共有したくないといった場合はスタンダードなやり方になりそうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/8944b26b-6e00-1382-49a5-ac2f40375230.png)
## 個別の Resolver エンドポイントを運用する方法
オンプレミスとからの入り口もアカウントごとに用意する方針です。
オンプレミス側のフォワーダー設定がアカウントの数だけ増えるので、前方針の方がメリットはありそうです。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/c52f5a88-5ebf-af6a-4948-3c27006de863.png)

# AWSからオンプレミスの名前解決
## Route 53 Resolver Rule を他の AWS アカウントへ共有する方法
アウトバウンドエンドポイントは運用管理アカウントに置き、他アカウントにリゾルバルールを共有する方針です。
アウトバウンドエンドポイントが一つだけで良いため、ランニングコストの観点でメリットがあると紹介されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/050a37a3-fc3c-d90b-d7d7-150899af92a0.png)\

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


## DHCP を変更する方法
DHCPオプションセットを作成し、VPCに関連付けることで、名前解決の参照先を運用管理アカウントへ集約する方針です。
アカウント内のVPCエンドポイントが使用できなくなるとのことで、よほどのことがない限りこの方針は取らないかなと見受けました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/396f119f-f11a-3bed-f7da-f713d877b29b.png)

## Route 53 Resolver エンドポイントを連携する方法
オンプレミスからAWS環境へのアクセス時の構成と逆になります。
オンプレへの出口調整は、運用管理アカウントに任せることができるメリットがあります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/632812f1-5df1-f3ce-5161-d3f4854dfde4.png)

## 各アカウントで個別のResolver エンドポイントを運用する方法
この方針もオンプレミスからAWS環境へのアクセス時の構成と逆になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/992414/e8b8002d-e183-37bf-39fb-ce8f2cc8ed47.png)

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