【要約】複数VPCへのDNS設計について考える [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
設計者は、オンプレミスからAWSへの名前解決を行う際、管理対象となるフォワーダーを最小化したいと考えている。具体的には以下の課題に直面する。
- ・VPCが増えるたびにInbound Endpointを設置すると、コストが肥大化する。
- ・AWSサービス名と独自ドメイン名では、解決に必要な仕組みが異なる。
- ・VPC間の通信経路（PeeringやTGW）の確保が、設計の複雑さを増大させる。
// Approach
筆者は、解決したい名前の種類に応じて、2つの異なる設計アプローチを検証した。
- ・AWSサービス名（S3等）への解決: Route53 Resolver Ruleを使用する。各VPCにInbound/Outbound Endpointを配置し、クエリを転送する。
- ・独自ドメイン名への解決: HUB用VPCにInbound Endpointを集約する。各VPCのPrivate Hosted Zone（PHZ）をHUB VPCに関連付ける手法を採用する。
// Result
検証の結果、名前の種類によって最適な設計手法が異なることが明らかになった。
- ・Resolver Rule案: VPC間の直接通信が必要となる。組織をまたぐ環境では、セキュリティ要件により導入が困難な場合がある。
- ・PHZ集約案: Inbound Endpointを1つに集約できる。VPC間の通信経路も不要であり、コストと運用の両面でメリットが大きい。
Senior Engineer Insight
> DNS設計はネットワークトポロジーと密接に関係する。Resolver Rule案は、VPC間の通信経路確保がボトルネックとなる。特にセキュリティポリシーが厳しい環境では、実装のハードルが高い。一方、PHZの集約はコスト効率に優れる。ただし、PHZの関連付け管理という運用負荷が伴う。大規模環境では、これらを組み合わせた設計が現実的だ。