Azure DNS の費用は、主に「ゾーンの数」と「問い合わせ（クエリ）の量」で決まります。そのため、使っていないゾーンを整理し、変わらないレコードの TTL を適切に伸ばし、クエリ量を監視して異常に気づける状態にすることが、費用を抑える基本の3手です。この記事では、Azure CLI と Azure Monitor を使って現状を把握し、安全に削減するまでの手順を、つまずきやすい点と確認方法つきで説明します。
費用がどこで発生しているかを理解する
最初に、Azure DNS 周りで課金の対象になる要素を整理しておきます。具体的な単価はリージョンや契約形態、改定によって変わるため、ここでは仕組みだけを説明します（2026年10月現在）。最新の料金体系は Azure の公式料金ページで確認してください。
- パブリック DNS ゾーン: ホストしているゾーンの数に応じた月額と、そのゾーンが受けたクエリ数に応じた料金がかかります。
- プライベート DNS ゾーン: 仮想ネットワーク内で使うゾーンも、ゾーン数とクエリ数で課金されます。パブリックとは別枠で計上されます。
- Azure DNS Private Resolver: オンプレミスとの名前解決に使うリゾルバーは、エンドポイントなどの構成要素ごとに継続的な費用が発生する仕組みです。使っていないエンドポイントが残っていると、クエリがなくても費用が積み上がります。
- 周辺サービス: Traffic Manager や Front Door を DNS と組み合わせている場合、それらのサービスには別の課金があります。「DNS が高い」と感じたとき、実は周辺サービスの費用だったということもあります。
つまり、削減の対象は「数を減らせるもの（ゾーン・エンドポイント）」と「量を減らせるもの（クエリ）」の2種類です。
手順1：Cost Management で DNS の費用を切り分ける
いきなり設定を変える前に、どの要素がどれだけ費用を占めているかを確かめます。Azure ポータルの Cost Management でコスト分析を開き、サービス名でフィルターをかけて Azure DNS の費用だけを表示します。グループ化の軸をリソースにすると、どのゾーンの費用が大きいかが分かります。
ここで見るポイントは次の3つです。
- ゾーン数による費用とクエリによる費用のどちらが大きいか: ゾーン数が多いだけなら整理で減らせます。クエリが大きいなら TTL や問い合わせ元の見直しが必要です。
- 特定のゾーンだけ突出していないか: 一つのゾーンだけクエリが多い場合、TTL が極端に短い、または想定外の問い合わせ元がある可能性があります。
- 月ごとの推移: 急に増えた月があれば、その時期に行った変更（TTL の短縮、新サービスの導入など）と照らし合わせます。
部署やサイトごとに費用を分けたい場合は、DNS ゾーンにタグを付けておくと、コスト分析でタグ単位に集計できます。
手順2：不要なゾーンを洗い出して整理する
ゾーン数に応じた費用は、使っていないゾーンでも毎月発生します。検証用に作ったまま放置したゾーンや、すでに手放したドメインのゾーンがないかを確認します。
# サブスクリプション内のパブリック DNS ゾーンを一覧する
az network dns zone list \
--query "[].{name:name, rg:resourceGroup, records:numberOfRecordSets}" \
--output table
# プライベート DNS ゾーンも同様に確認する
az network private-dns zone list \
--query "[].{name:name, rg:resourceGroup}" \
--output table一覧の中から、次のようなゾーンを候補にします。
- レコードが NS と SOA だけで、実質的に何も入っていないゾーン
- レジストラ側のネームサーバーが Azure DNS を向いていないゾーン（
dig NS example.comで確認します。Azure 以外のネームサーバーが返ってくるなら、そのゾーンは誰にも参照されていません） - 同じドメイン名で重複して作られたゾーン（別のリソースグループやサブスクリプションにある場合があります）
削除の前にはゾーンを書き出してバックアップを取ります。 削除したゾーンを作り直すと、割り当てられるネームサーバーが変わることがあり、元に戻すにはレジストラ側の設定変更も必要になります。
# ゾーンファイルとして書き出しておく
az network dns zone export \
--resource-group rg-dns \
--name old-example.com \
--file-name old-example.com.zone
# 内容を確認してから削除する
az network dns zone delete \
--resource-group rg-dns \
--name old-example.com逆に、本番で使っているゾーンを誤って消す事故を防ぐため、重要なゾーンには削除ロックをかけておくことをおすすめします。az lock create --lock-type CanNotDelete でリソースに削除禁止のロックを設定できます。
手順3：TTL を見直してクエリ量を減らす
Azure DNS が受けるクエリの多くは、世界中のキャッシュ DNS サーバー（利用者のプロバイダや公開 DNS）から来ます。キャッシュ DNS は TTL の間だけ答えを保持するので、TTL が短いほど頻繁に問い合わせが来て、クエリ課金が増えます。
確認すると、移行作業のときに 60 秒や 300 秒へ下げた TTL が、そのまま戻されていないケースがよくあります。変更する予定のないレコードであれば、TTL を 1 時間（3600 秒）程度に戻すだけでクエリ量が下がることがあります。
# ゾーン内のレコードセットと TTL を一覧する
az network dns record-set list \
--resource-group rg-dns \
--zone-name example.com \
--query "[].{name:name, type:type, ttl:ttl}" \
--output table
# www の A レコードの TTL を 3600 秒に変更する
az network dns record-set a update \
--resource-group rg-dns \
--zone-name example.com \
--name www \
--set ttl=3600ただし、TTL を伸ばすことには代償もあります。
- 切り替えが遅くなる: サーバー移転や障害時の向け先変更が、TTL の分だけ反映に時間がかかります。移転の予定があるレコードは、作業の前日までに短くしておく運用にします。
- フェイルオーバー用のレコードには向かない: Traffic Manager などで向け先を切り替える構成では、短い TTL が前提になっています。費用だけを見て伸ばすと、障害時の切り替えが遅れます。
費用と切り替えの速さのどちらを優先するかを、レコードごとに決めるのが現実的です。
手順4：Azure Monitor でクエリ量を監視する
Azure DNS のゾーンには、クエリ量（QueryVolume）やレコードセット数のメトリクスが用意されています。ポータルでゾーンを開き、メトリクスの画面でクエリ量を時系列で表示すると、どの時間帯に問い合わせが多いかが分かります。表示名は画面の更新で変わることがありますが、クエリ量に相当する指標を選べば同じ情報が得られます。
# ゾーンのリソース ID を取得してクエリ量を確認する
ZONE_ID=$(az network dns zone show \
--resource-group rg-dns --name example.com --query id -o tsv)
az monitor metrics list \
--resource "$ZONE_ID" \
--metric QueryVolume \
--interval PT1H \
--aggregation Total \
--output table監視で見つかりやすい問題には、次のようなものがあります。
- 特定の時間だけ急増している: 外形監視サービスが短い間隔で名前解決をしている、TTL を極端に短くしたレコードがある、といった原因が考えられます。急増の始まった時刻と、その前後に行った設定変更を突き合わせます。
- 特定のゾーンだけ常に多い: TTL が短いレコードが集中しているか、メール配信や API など問い合わせの多い用途に使われている可能性があります。手順3の一覧で TTL を確認します。
- 存在しない名前への問い合わせ: 存在しない名前（NXDOMAIN を返す問い合わせ）も、通常はクエリとして数えられます。不審な増加が続く場合は、問い合わせ元のパターンを調べます。
想定外の増加にすぐ気づけるよう、Azure Monitor のアラートでクエリ量にしきい値を設定するか、Cost Management の予算機能で月額の上限に近づいたら通知されるようにしておくと安心です。
手順5：プライベート側の構成を見直す
社内ネットワークとの名前解決に Azure DNS Private Resolver を使っている場合、エンドポイントが構成要素ごとに課金されるため、使われていないものを整理する効果が大きくなります。
- 検証用に作った受信・送信エンドポイントが残っていないか
- 同じ役割のリゾルバーを仮想ネットワークごとに作っていないか（ハブとなる仮想ネットワークに集約し、ピアリングや転送ルールで共有できないか）
- プライベート DNS ゾーンが用途ごとに細かく分かれすぎていないか
構成を集約すると、障害の影響範囲が広がる面もあります。本番で変更する前に、検証用のサブスクリプションや仮想ネットワークで名前解決が引き続きできることを確かめてから進めます。
まとめ
- Azure DNS の費用は、ゾーン数とクエリ量、Private Resolver のエンドポイントなどの構成要素で決まります。単価は変わるため、仕組みを理解したうえで公式の料金ページで確認します。
- Cost Management でサービス別・リソース別に費用を切り分け、どこを削るかを先に決めます。
- 不要なゾーンはエクスポートしてから削除し、本番ゾーンには削除ロックをかけます。
- 移行時に短くした TTL を戻すとクエリ量が下がることがありますが、切り替えの速さとのバランスをレコードごとに判断します。
- QueryVolume の監視とアラート、予算通知で、想定外の増加に早く気づける状態にしておきます。