Route53 Global Resolverを使ってみた

はじめに

11/30にAmazon Route53 Global Resolverがプレビュー公開されました。
実際に触って調べてみた所感を書きたいと思います。

Route 53 Global Resolverとは

FAQ より抜粋します。

• インターネット経由でどこからでもグローバルに到達できる DNS リゾルバー
• パブリックドメインとプライベートドメインの両方のトラフィックを簡単に解決して転送
• インターネット経由のクエリのセキュリティと信頼性を確保
• グローバル エニーキャスト IP 経由でアクセス可能な統合ソリューションを提供
• 企業がオンプレミス、ブランチオフィス、リモートクライアントからクラウドまたはオンプレミスでホストされているパブリックドメインやプライベートアプリケーションに行われたクエリの解決と転送を簡素化できるよう支援
• 暗号化された DNS 接続 (DNS-over-HTTPs/DNS-over-TLS を使用) のオプションを提供
• 悪意のある可能性のあるドメインやレピュテーションの低いドメインへのクエリを制御およびブロックする機能を提供

マネコンのグローバルリゾルバーのトップ画面には、「利点と特徴」として以下のように説明されています。

運用オーバーヘッドの削減
インターネット上のパブリックドメインと Route 53 プライベートホストゾーンでホストされているプライベートドメインのクエリを、どこからでもグローバルに解決することで、DNS 解決を簡素化し、運用コストを最小限に抑えます。

セキュリティ運用の簡素化
DNS ポリシーとルールを一貫して適用することで、すべてのトラフィックのセキュリティ管理を改善します。DoH/DoT プロトコルを使用して DNS トラフィックを暗号化し、エニーキャスト IP を通じて高可用性を維持します。包括的な監査とコンプライアンスのために、すべての DNS クエリを一元的にログ記録します。

同じくマネコン上に構成イメージがあり、わかりやすそうだったので載せておきます。

料金

料金は下記のとおりです。

• プレビュー期間中は無料
• リージョン別時間料金とクエリ料金の2つで課金
  • リージョン別時間料金
    • 最初の2リージョン
      • $5/時間（ DNSフィルタリング無しの場合は$4.5/時間 ）
    • 追加リージョン
      • $1.5/時間（ DNSフィルタリング無しの場合は$0.75/時間 ）
  • クエリ料金
    • すべてのリージョンで生成されたクエリの総数でカウント
    • 10億クエリまで無料
    • 10億クエリを超えると$1.5/100万クエリ

リージョン別時間料金が$5/時間なので、1か月を730時間とした場合、$3,650/月です。
かなり高額に感じられます・・・（計算が間違っているのでしょうか？）

利用可能なリージョン

東京リージョンが対応しています！

• US East (N. Virginia) Region
• US East (Ohio) Region
• US West (N. California) Region
• US West (Oregon) Region
• Europe (Frankfurt) Region
• Europe (Ireland) Region
• Europe (London) Region
• Asia Pacific (Mumbai) Region
• Asia Pacific (Singapore) Region
• Asia Pacific (Tokyo) Region
• Asia Pacific (Sydney) Region

使ってみた

グローバルリゾルバーの作成

とりあえずマネコンから作成してみます。リージョンは東京を選択しました。

エラーになりました。リージョンは最小で2つ選択する必要がありました。

ドキュメントにちゃんと書いてありました。

(翻訳)
Route 53 Global Resolver は、パブリックドメインとプライベートドメイン間のトラフィック分割による DNS 解決を可能にし、選択した 2 つ以上の AWS リージョンを通じて高可用性を提供します。

• 自動地理的ルーティング- DNS クエリは、最適なパフォーマンスを実現するために最も近い AWS リージョンに自動的にルーティングされます。
• 組み込みの冗長性- リージョンが利用できなくなった場合、トラフィックは自動的に次の最も近いリージョンにフェイルオーバーします。

(翻訳)
リージョンでは、グローバルリゾルバーをインスタンス化するAWSリージョンを2つ以上選択します。最適なパフォーマンスを得るには、クライアントに最も近いリージョンを選択してください。

バージニアも追加して計2つ選択しました。

今度は無事作成できました。ステータスが作成中から実行中に変わるまで11分ほどかかりました。

グローバルリゾルバーのエンドポイント

ここでふと、マネコンのRoute53グローバルリゾルバー画面のURLに含まれるリージョンがus-east-2（オハイオ）であることに気づきました。

そこで、CloudShellからCLIで設定を確認してみました。こちら の記事と同様ですが、CloudShellのCLIバージョンは最新ではなくRoute53グローバルリゾルバーに未対応であったため、最新化しました。

バージョン2.32.7で対応しています。

CLIでグローバルリゾルバーをリストアップしてみます。

aws route53globalresolver list-global-resolvers

CloudShellを開くとus-east-1（バージニア）リージョンで起動しました。そのまま実行すると、エンドポイントに接続できませんでした。

us-east-2（オハイオ）リージョンを指定すると、作成したグローバルリゾルバーの設定を確認することができました。

こちら で知った「Explore AWS Capabilities by Region」でリージョンごとのAPI対応状況を調べてみたところ、以下のような状況になっていることが確認できました。
※数が多くて折りたたまれていますが、すべてオハイオのみ利用可能でした。

動作確認

一般パブリックドメインの名前解決

早速、名前解決を試してみましたが、タイムアウトになってしまいました。

この時点ではグローバルリゾルバーを作成したのみでしたが、グローバルリゾルバー作成後に追加する設定項目として下記があります。

• DNSビュー
• ドメインリスト
• ログ配信

DNSビューについて AWSブログ から引用します。

DNS ビューは、クライアントやソースを異なる論理的グループに分け、それぞれのグループに対する DNS 解決方法を決定するのに役立ちます。これにより、組織内の異なるクライアントに対して、異なる DNS フィルタリングルールやプライベートホストゾーンの解決ポリシーを維持できます。

DNSビューを作成してみます。DNSビュー名以外はすべてデフォルト値です。

DNSビューが作成できました。

DNSビュー作成後に追加することができる設定項目は下記のとおりです。

• DNSファイアウォールルール
• プライベートホストゾーン
• アクセスソース
• アクセストークン

アクセス制御の方式は2種類あり、それぞれ下記の要素に基づいてDNSクエリの許可または拒否を判定します。

• アクセスソース：クライアントIP
• アクセストークン：期限付きの認証トークン

今回はアクセスソースを利用してみます。
CloudShell上で自身のグローバルIPを確認します。

アクセスソースにCloudShellのグローバルIPを追加します。

今回はプロトコルをDo53としましたが、選択肢は3つあります。

• Do53：UDP/TCP 経由の標準 DNS (ポート 53)
• DoT：DNS over TLS (ポート 853)
• DoH：DNS over HTTPS (ポート 443)

今度はCloudShell上から名前解決することができました！

プライベートホストゾーンの名前解決

下記のようなプライベートホストゾーンを作成しました。

DNSビューにプライベートホストゾーンを紐づけていない状態だとタイムアウトになりました。

DNSビューにプライベートホストゾーンを紐づけます。

名前解決できるようになりました！

パブリックとプライべートに同一ドメインのゾーンがある場合の名前解決

グローバルリゾルバー経由でAmazonドメインの名前解決をしてみます。Amazonがホストし一般公開されているゾーンの情報が返ってきました。

Amazonドメインをプライベートホストゾーンで作成し、グローバルリゾルバーに紐づけてみます。

名前解決の結果はプライベートホストゾーンの情報になりました。つまり、パブリックとプライべートに同一ドメインのゾーンがある場合、プライベートホストゾーンの情報が優先されます。

スプリットビュー DNS（スプリットホライズン DNS）

グローバルリゾルバーのメリットの一つに、複雑なDNS構成を簡素化できる点があります。

ハイブリッド環境で展開している組織は、分散環境全体で DNS 解決を管理する際に運用の複雑さに直面します。パブリックなインターネットドメインとプライベートなアプリケーションドメインを解決するには、スプリット DNS インフラストラクチャを維持する必要があることが多く、特に複数の拠点に複製する場合には、コストや管理負担が増大します。

ここに出てくる「スプリット DNS」は、「スプリットビュー DNS」や「スプリットホライズン DNS」と同義で、下記のように説明されています。

スプリットビュー DNS では、社内用（accounting.example.com）と社外用（公開ウェブサイト（www.example.com）など）で同じドメイン名（example.com）を使用します。また、社内と社外で同じサブドメイン名を使用しながら、異なるコンテンツを提供したり、社内ユーザーと社外ユーザーに異なる認証を要求したりすることも可能です。

具体的な構成で考えてみた

下記のようなオンプレとAWSを接続したハイブリッド環境は、企業で一般的に利用されている構成だと思います。

グローバルリゾルバーを使うと下記のような構成になると考えられます。

メリットは下記のとおりです。

• Route53リゾルバーインバウンドエンドポイントが無くなる
• オンプレDNSからドメインごとにDNSクエリの転送先を分岐させる必要がなくなる

上記のシンプルな構成で金額を比較すると下記のようになります。（※通信やクエリにかかる料金はいったん無視）

• グローバルリゾルバー（2リージョン展開の場合）：$3,650/月
• インバウンドエンドポイント（エンドポイント2つの場合）：$182.5/月 ( $0.125/h × 730h × 2ENI)

構成はシンプルになりますが、代償が大きすぎるように感じます・・・

もう少し構成が複雑な場合を見るために、VPCの数を増やしてみます。

先ほどよりも構成を簡素化する効果が多少増えたように感じられる気がします。
これだけではまだまだ金額差が大きいですが、オンプレ拠点が複数あったり、VPCやAWSアカウントも複数あるような複雑なハイブリット環境であればあるほど、効果は大きくなり、金額的にも近くまたは安くなる可能性もあるかもしれません。

セキュリティ機能

ここまで「構成や管理の簡素化」の観点でのみ見てきましたが、グローバルリゾルバーには以下のようなセキュリティ機能が備わっており、グローバルリゾルバーの一か所でまとめてセキュリティ対策を施せる点は大きなメリットの一つです。

• DNSクライアント認証
  • アクセスソース
  • アクセストークン
• DNSSEC検証
  • DNSレスポンスが真正であり、改ざんされていないことを確認
• DNSファイアウォール
  • ドメインによるフィルタリング
    • カスタムのリスト
    • AWS管理のマネージドドメインリスト
      • 脅威のカテゴリー（マルウェア、フィッシング など）
      • コンテンツカテゴリー（暗号通貨、犯罪行為および違法行為 など）
  • 高度な脅威保護
    • DNSトンネリング
      • 攻撃者がクライアントへのネットワーク接続を確立せずに DNS トンネルを使用してクライアントからデータを盗み出す
    • ドメイン生成アルゴリズム（DGA）
      • マルウェア攻撃を開始するために大量のドメインを生成するために攻撃者によって使用される

さいごに

ここまで見てきて機能としては有用なものだと感じました。ただ個人的には金額面が気にかかりました。構成の簡素化でより大きな効果を得られるだけの複雑さや規模を持つ環境や、DNSのレイヤーでセキュリティ対策が重視されるような環境には最適な機能なのかもしれません。

弊社では一緒に働く仲間を募集中です！

現在、様々な職種を募集しております。
カジュアル面談も可能ですので、ご連絡お待ちしております！

募集内容等詳細は、是非採用サイトをご確認ください。