AWSにおけるパブリックDNSの利用パターン

はじめに

AWSにおけるパブリックDNSの利用パターンをいくつか解説をしていきたいと思います。

パターン

①外部のDNSサーバでのドメイン管理、名前解決
外部のDNSサーバでドメインを管理し、そのDNSサーバにCNAMEレコードやAレコード等で、AWS上のリソースを登録するパターンです。既存ドメインが既に存在するパターンなどで利用することが多いでしょう。
②Route53でのドメイン管理、名前解決
Route53でドメインを購入するか、Route53をレジストラでDNS指定して、名前解決をRoute53で行うパターンです。
③外部のDNSサーバでのドメイン管理、サブドメインをRoute53に委任し、Route53での名前解決
外部のDNSサーバでドメインを管理していますが、サブドメインを払い出し、そのサブドメインの名前解決権限をRoute53に飲するパターンです。

パターン１　外部のDNSサーバでのドメイン管理、名前解決

このパターンでは、既存のDNSサーバやドメインが存在する場合、もしくはAWS外でドメインを管理したい場合に、外部のDNSサーバやサービスで名前解決を行います。この場合、当該ドメインを管理するDNSサーバにて、CNAMEレコードやAレコード等で、AWS側のリソースのFQDN、IPアドレスを指定します。
メリットとしてはドメイン管理を中央集権的に行っている組織での管理が容易になることが挙げられますが、デメリットとしては、Route53特有のレコードALIASレコードや、フェイルオーバールーティングの機能などが利用できないこと、AWS側のリソースと同一の環境で管理しないがための、登録にかかるリードタイム、ZoneApexに対してのCNAMEレコード登録不可等があげられます。

＃　パターン２ Route53でのドメイン管理、名前解決

このパターンではAWS上で外部から購入したドメインやRoute53上で購入したドメインを管理し、Route53で名前解決を行う方式です。AWS上で完結するため、AWS特有の機能が利用できるメリットがあります。ALIASレコードによる、効率の良い名前解決や、フェイルオーバールーティングなどRoute53の便利な機能を利用することが可能です。

パターン3 外部のDNSサーバでのドメイン管理、サブドメインをRoute53に委任し、Route53での名前解決

ちょうど中間的なアプローチです。既存ドメインを管理するDNS上でサブドメインを払い出します。まず、Route53でサブドメインでパブリックホストゾーンを作成、当該パブリックホストゾーンのNSレコードを既存ドメインのDNSサーバでサブドメインのNSレコードとして登録することが可能です。権限を委任することで、Route53で名前解決が可能ですし、独自機能も利用できます。また、ゾーン自体がAWS側で管理となるため、レコードの追加変更が容易です。バックアップ・リストアなどでAWS上のFQDNが変わってしまった場合でも迅速に対応できるでしょう。

まとめ

#	方式	メリット	デメリット
1	外部のDNSサーバでのドメイン管理、名前解決	中央集権的な管理、既存ドメインへの影響なし	Route53の独自機能利用不可、ZoneApexに対するCNAMEレコード登録不可、運用時のリードタイム
2	Route53でのドメイン管理、名前解決	Route53独自の機能利用可、ZoneApexに対するALIASレコードの定義、運用時のリードタイム	中央集権的にドメインを管理している場合DNSが分散する
3	外部のDNSサーバでのドメイン管理、サブドメインをRoute53に委任し、Route53での名前解決	oute53独自の機能利用可、ZoneApexに対するALIASレコードの定義、運用時のリードタイム	ドメインが長くなったり、.が一つ増える、初期の既存ドメインとの調整コスト

各方式をまとめてみました。個人的にはAWSのリソースはRoute53で管理することがおすすめです。
要件や運用方法などに合わせて最適な選択をしていきたいものですね。