2026年6月9日

Azure DNS で費用最適化する手順｜Private DNS ゾーンの集約と DNS Private Resolver の構成見直し

DNS・名前解決

Azure DNS の費用は、ゾーンの数、問い合わせの量、そして DNS Private Resolver を使っている場合はエンドポイントなどの構成要素の数で決まります。パブリックゾーンが数個しかない環境でも、プライベートエンドポイントを使い始めると Private DNS ゾーンやリゾルバーが仮想ネットワークごとに増え、気づかないうちに費用と管理の手間が膨らみます。この記事では、ハブアンドスポーク構成を例に、プライベート側の DNS を集約して重複を減らす手順を説明します。

費用の切り分け方や TTL の見直しといった全般的な手順は、同じシリーズの別記事で扱っています。この記事はプライベート側の構成見直しに絞っています。料金体系や上限値は改定されることがあるため（2026年10月現在）、金額や制限値は Azure の料金ページとドキュメントで確認してください。コマンドは例として示すので、実行前に引数を自分の環境に合わせてください。

なぜプライベート側で費用が膨らむのか

プライベートエンドポイントを作るとき、ポータルの既定の流れでは、そのサービス用の Private DNS ゾーン（例: privatelink.blob.core.windows.net）も一緒に作られることがあります。チームごと、サブスクリプションごとにこれを繰り返すと、同じ名前のゾーンが何十個もできます。

同名のゾーンが複数あると、費用が増えるだけでなく、次のような問題も起きます。

ある仮想ネットワークでは名前が解決できるのに、別の仮想ネットワークでは解決できない
どのゾーンが正しいのか分からず、レコードの追加先を間違える
オンプレミスから引くときに、どのリゾルバーへ転送すればよいか分からない

つまり、集約は費用の削減と同時に、名前解決の一貫性を取り戻す作業でもあります。

手順1：Private DNS ゾーンを一覧にして重複を見つける

まず、テナント全体の Private DNS ゾーンを書き出します。Azure Resource Graph を使うと、複数のサブスクリプションを一度に検索できます（Azure CLI に resource-graph 拡張が必要です）。

az extension add --name resource-graph

az graph query -q "
resources
| where type =~ 'microsoft.network/privatednszones'
| project name, resourceGroup, subscriptionId,
          records = toint(properties.numberOfRecordSets),
          links = toint(properties.numberOfVirtualNetworkLinks)
| order by name asc
" --first 1000 -o table

結果を名前順に並べると、同じ名前のゾーンが複数のリソースグループやサブスクリプションにあるかがすぐに分かります。あわせて次の点を確認します。

レコード数が1件だけのゾーン: SOA レコードしかなく、実際には使われていない可能性があります。
仮想ネットワークへのリンクが0件のゾーン: どこからも参照されていない可能性があります。
同名のゾーンが複数ある: 集約の候補です。

使われていないように見えても、プライベートエンドポイントの DNS ゾーングループから参照されている場合があります。削除の判断は手順3で行います。

手順2：集約先のハブを決める

集約先は、ハブとなる仮想ネットワークがあるサブスクリプション（接続や共有サービス用のサブスクリプション）に置くのが一般的です。各 privatelink.* ゾーンをそこに1つずつ作り、各スポークの仮想ネットワークへリンクします。

# ハブ側のゾーンを各スポークの仮想ネットワークへリンクする例
az network private-dns link vnet create \
  --resource-group rg-dns-hub \
  --zone-name privatelink.blob.core.windows.net \
  --name link-spoke-app1 \
  --virtual-network /subscriptions/<sub-id>/resourceGroups/rg-app1/providers/Microsoft.Network/virtualNetworks/vnet-app1 \
  --registration-enabled false

privatelink 系のゾーンでは自動登録は使わないので、--registration-enabled false にします。1つのゾーンにリンクできる仮想ネットワークの数には上限があるため、スポークが多い環境ではドキュメントの制限値を確認しておきます。

手順3：レコードを移し、古いゾーンを外す

重複したゾーンにあるレコードを、ハブ側のゾーンへ移します。ここは名前解決が一時的に止まりやすい作業なので、1つのゾーン、1つのスポークずつ進めます。

古いゾーンのレコードを書き出して控えにする
ハブ側のゾーンに同じ A レコードを作る（またはプライベートエンドポイントの DNS ゾーングループの参照先をハブ側のゾーンに変える）
対象スポークで、古いゾーンの仮想ネットワークリンクを削除し、ハブ側のゾーンをリンクする
スポーク内の VM から名前解決を確認する
問題がなければ古いゾーンを削除する

# 古いゾーンの控え
az network private-dns record-set list \
  --resource-group rg-app1 \
  --zone-name privatelink.blob.core.windows.net -o json > backup-app1-blob.json

同じ名前のゾーンを、1つの仮想ネットワークへ2つ同時にリンクすることはできません。そのため、手順3の「外してからつなぐ」の間は、その仮想ネットワークで該当サービスの名前が引けない時間が生じます。業務時間外に行うか、影響の小さいスポークで手順を確かめてから進めてください。

スポークの VM からは次のように確かめます。プライベート IP アドレスが返れば成功です。

nslookup mystorageaccount.blob.core.windows.net

手順4：DNS Private Resolver を1か所にまとめる

オンプレミスとの名前解決に DNS Private Resolver を使っている場合、受信エンドポイント、送信エンドポイント、転送ルールセットが構成要素になります。スポークごとにリゾルバーを作っていると、その分だけ費用がかかります。

まとめ方の基本は次のとおりです。

リゾルバーはハブの仮想ネットワークに1つ置く
オンプレミスの DNS サーバーからは、ハブの受信エンドポイントへ条件付き転送する
Azure からオンプレミスのドメインを引くための転送ルールセットは、同じリージョンの複数の仮想ネットワークにリンクして共有する

# リゾルバーとルールセットの一覧（dns-resolver 拡張が必要）
az extension add --name dns-resolver
az dns-resolver list -o table
az dns-resolver forwarding-ruleset list -o table

一覧で、検証用に作ったまま残っているリゾルバーや、同じ役割のものが複数ないかを確認します。また、オンプレミスの DNS サーバー側の転送先を先にハブの受信エンドポイントへ変えてから、古いリゾルバーを削除する順番にしないと、社内から Azure の名前が引けなくなります。

一方で、すべてを1か所に集めると、その構成の障害がすべてのスポークに影響します。リージョンをまたぐ構成や、可用性の要件が高い環境では、費用だけで判断せず、どこまで集約するかを決めてください。

手順5：再び増えないようにルールを作る

集約しても、各チームが従来どおりの手順でプライベートエンドポイントを作れば、また同名のゾーンが増えます。次のような仕組みで防ぎます。

作成手順の統一: プライベートエンドポイントを作るときは、ハブ側の既存ゾーンを選ぶ手順を文書化する
Azure Policy: スポークのサブスクリプションで privatelink.* ゾーンの作成を拒否するポリシーや、プライベートエンドポイントの DNS 設定をハブ側のゾーンへ自動で向けるポリシーを使う（組み込みポリシーの名前や内容はドキュメントで確認してください）
定期的な一覧の確認: 手順1のクエリを月に1回程度実行し、新しく増えたゾーンがないかを確認する

まとめ

プライベートエンドポイントの利用が広がると、同名の Private DNS ゾーンやリゾルバーがスポークごとに増え、費用と名前解決の不整合が生じます。
Resource Graph でテナント全体のゾーンを一覧にし、重複、レコード1件だけのゾーン、リンクのないゾーンを見つけます。
ハブにゾーンを集約し、1つのゾーン、1つのスポークずつ、控えを取ってからリンクを付け替えます。
DNS Private Resolver はハブに集め、ルールセットを共有しますが、障害の影響範囲とのバランスを考えます。
作成手順の統一と Azure Policy で、重複が再び増えないようにします。