はじめに
オンプレミスとの間での名前解決の転送に欠かせいないResolverの転送ルールと、エンドポイントの共有について書いていきたいと思います。
シングルアカウントでの構成
まずは通常パターンです。
特定の名前解決に関して、オンプレミス等のDNSに転送したい場合は、Route53リゾルバルールの定義と、通信の出口となるアウトバウンドエンドポイントを作成します。
名前解決は、リゾルバを経由し、ルールにマッチした場合、転送先に指定したDNSサーバにアウトバウンドエンドポイント経由で行われます。
マルチアカウントでの構成
次にマルチアカウントでの構成を考えてみます。
普通に考えると、シングルアカウント構成の場合と同じく、対象のVPCそれぞれにリゾルバルールならびに、アウトバウンドエンドポイントを作成し、名前解決を行います。
※TransitGW等の記載は省略しています。
マルチアカウントでの構成(転送ルールの共有)
次に転送ルールの共有を行った場合の構成です。
この場合、まずリゾルバルールの共有を、アカウント間で共有します。
そうすると、共有したリゾルバルールで定義した名前解決をVPC-Aのアウトバウンドエンドポイント経由で名前解決することが可能です。この際、2つのVPC間を接続する必要はありません。また、アウトバウンドエンドポイントは1つに集約ができます。
2つの構成の比較
正直どちらもよいのでは?と思うかもしれませんが、2つの構成において、メリデメがそれぞれあります。
転送ルールを共有する場合のメリットはコストです。
0.125USD / 1 時間*AZ数の料金がかかるため、安くはありません。アカウントが増えれば増えるだけ、このコストがかさみます。ルールを集約するとこのコストを削減することが可能です。ただし、ルールのメンテナンスが1アカウントに集約されるため、組織内で手続きや運用ルール等を事前に定めておく必要があります。
構成 | メリット | デメリット |
---|---|---|
転送ルール共有なし | ・アカウントごとに転送ルールを定義できるため、アカウントごとに組織が別れている場合などに調整が不要 |
・アウトバウンドエンドポイントのコストがアカウント数分かかる |
転送ルール共有あり | ・アウトバウンドエンドポイントのコストが1アカウント分のみとなる | ・転送ルールを1アカウントに集約するため、対象アカウントを管理している側で、ルールのメンテナンスが必要。組織が別れている場合などでは、運用が複雑になる可能性がある |
まとめ
ハイブリッドクラウドでは名前解決が非常に重要な要素となります。
今回は外部への名前解決をどのように実装するのか、そのコストをどのように削減可能かを記載しました。
2つのメリット、デメリットを把握し最適な構成を選択していきましょう。
参考