はじめに
AWSをはじめ、クラウドサービスとオンプレミス等のハイブリットクラウド環境での名前解決は非常に重要です。
例えば、ELB、RDS、S3等のIPアドレスでの接続をサポートしていないサービスが多々有り、名前解決を利用しないと利用できないケースがほとんどです。
AWS側からオンプレミス側、オンプレミス側からAWS側と相互に名前解決を行う必要のある構成が多く、複雑になるケースが多いため、しっかりと抑えておく必要があります。
今回は、AWSにおける名前解決のおさらいと、オンプレミス環境とAWS環境で同一ドメインを重複して利用したいというケースの解決手法をご紹介します。
AWSにおける名前解決のおさらい
おさらい程度に軽くまとめます。詳細までは記載しないので、もっと深く知りたいよって方は、別途ご紹介するBlackBeltをご参照ください。
各種サービスの名前解決
クラウドサービスにおいて、不要になったら、障害が発生したら捨てる、必要なときにリソースをスケールアウトで拡張するという特徴を実現するためには、都度変わってしまうIPアドレスを管理するより、名前解決の仕組みを利用するほうが望ましいです。図に示すとおり、AWSのサービスでも、名前解決が基本となっており、AWSが自動生成するFQDNへの接続で利用が可能になります。
AWSにおける名前解決に関するサービス
言わずもがな、Amazon Route53ですが、以下のように細かくサービスが別れます。
今回の構成では、２、３、４を利用しますが、一通り振り返り的に概要を記載します。
- Amazon Route53 Public Hosted Zone
- Amazon Route53 Private Hosted Zone
- Amazon Route53 Resolver
- Amazon Route53 Resolver for Hybrid Clouds
Amazon Route53 Public Hosted Zone
インターネット上に公開し、対象ゾーンの名前解決を行うフルマネージドのDNSサービスです。
AWSのサービスでも、AWS外のサービスでも自由にレコードを定義できます。
SLAは１００％、ドメインの取得や、他のドメインレジストラからの移譲、サブドメインの移管も可能です。
参考：トラフィックルーティング
Route53では以下のうようなトラフィックルーティングが可能です。
- シンプル：静的な回答orラウンドロビンでの回答
- 加重：指定した比率での回答
- フェイルオーバー：ヘルスチェックの結果に基づき、正常なレコードを回答
- 複数回答：ランダムに正常なリソースを回答
- レイテンシー：レイテンシーが最も低いレコードを回答
- 位置情報：クライアントの位置情報に基づき回答
- 物理的近接性：クライアントの地理的情報に基づき、最も近いレコードを回答
一例として、フェイルオーバールティングの構成を記載します。
Region1で障害が発生してもヘルスチェックに基づき、Route53が回答するレコードをRegion2に切り替えることで、
ユーザ影響を最小限に留めることが可能です。
Amazon Route53 Private Hosted Zone
VPCに閉じたプライベートネットワーク内のDNSドメインレコードを管理するサービスです。
AWSのリソース、AWS外のリソース問わずに自由にレコードの定義が可能です。
AWSから払い出されるデフォルトのFQDNをCNAMEレコードやAレコードで定義し、カスタマイズしたFQDNでアクセスしたい等のケースで利用します。
Amazon Route53 Resolver
VPCに標準で備わるDNSサーバ（フォワーダとフルサービスリゾルバ）です。
（旧名称：Amazon Provided DNS）
私個人としては、旧名称の方が馴染み深いなと思ってしまいます。
VPC内では通常、DHCPにより、IPアドレス、DNSサーバが配布されますが、デフォルトのDNSサーバはRoute53 Resolverとなっています。※DHCPオプションセットを変更することで任意のDNSに変更することも可能です。
Amazon Route53 Resolver for Hybrid Clouds
オンプレミスなどの環境とAWS間での名前解決を中継してくれるサービスです。
オンプレミスへのDNSリクエストの転送や、オンプレミスからの名前解決を受付をしてくれます。
実施したい構成
ようやく本題です。おまたせしました。
ハイブリット環境で名前解決をしており、通常はオンプレミスのDNSサーバで名前解決を行っています。
この環境で、AWS側からオンプレミスドメインを利用し、ELBにアクセスしたいのですが、
オンプレミス側にはプロキシやFWといったNW機器が含まれ、DNSレコードには当該NW機器のIPアドレスが定義されているため、名前解決を行っても、ELBへの接続ができません。そのため、一部のAWS側リソースに関してのみ、
独自の名前解決ができないかという課題になります。
VPC単体構成での解決手法
まずはVPC内部での解決手法を記載します。
方式は以下に示す２つが考えられます。
VPC単体構成での解決手法①
リゾルバールールにシステムタイプのルールを定義し、独自に解決したいFQDNを定義します。
これにより、オンプレミス側DNSサーバへの転送が行われず、プライベートホストゾーンでの独自の名前解決が可能です。
VPC単体構成での解決手法②
リゾルバールールは特に変更せず、プライベートホストゾーンでFQDN単位でのゾーンを定義します。
この場合、ZoneApexへのレコード定義となるため、CNAMEレコード等の一部のレコードが利用できません。
複数VPC構成での解決手法
複数VPC環境での解決手法を記載します。
方式は以下に示す２つが考えられます。
複数VPC構成での解決手法①
VPC単体構成の場合とほぼ同じですが、プライベートホストゾーンを紐付けているVPCではシステムタイプのルールを定義し、独自に解決したいFQDNを定義します。その他のVPC側では、独自に解決したいFQDNに関して、転送を担うVPCにあるインバウンドエンドポイントへの転送ルールを記載します。
複数VPC構成での解決手法②
VPC単体構成の場合とほぼ同じですが、リゾルバールールには手を加えず、プライベートホストゾーンでFQDN単位でのゾーンを定義し、すべてのVPCと紐付けます。
結局どの案がいいの？
以下、私見に基づくメリデメです。
個人的には、解決策Aがシンプルでおすすめですが、通信ルール等の管理が手間であれば、解決策Bを利用することもありかと思います。
解決策①のメリデメ
| パターン | メリット | デメリット |
|---|---|---|
| 共通 | ・ホストゾーンが１つで済む ・マネジメントコンソール上だけで作業ができる（解決策②はCLIが必須） |
・レコード追加のたびに、リゾルバールールのメンテナンスが必要 |
| 単一VPC | - | - |
| 複数VPC | ・接続の流れがわかりやすい | ・VPCの増減に対応し、すべてのVPCでエンドポイントの通信ルールの定義、管理が必要 |
解決策②のメリデメ
| パターン | メリット | デメリット |
|---|---|---|
| 共通 | ・リゾルバールールのメンテナンスが不要 | ・ホストゾーンをレコード数分用意する必要がある ・ZoneApexへのレコード定義となるため、CNAMEレコード等一部のレコードが利用不可 |
| 単一VPC | - | - |
| 複数VPC | ・エンドポイント間の接続がないため、通信ルール等の管理が不要 | ・ホストゾーンの数だけ、VPCとの共有設定が必要(AWSCLIが必須) |
まとめ
ハイブリットクラウドにおける名前解決は非常に重要かつ複雑になることが多いですが、
AWSでは上記のようなさまざまなサービスが用意されています。
ちょっと複雑ですが、しっかり覚えて使いこなしたいものです。
参考文献