Cloud DNSとは？Google Cloudのマネージド権威DNSの仕組み・料金・ルーティングを実装者向けに解説【2026年時点】

Cloud DNSは、Google Cloud（GCP）が提供するフルマネージドの権威DNSサービスです。世界各地のAnycastネームサーバー上でドメインの名前解決を担い、一般公開ゾーンによるインターネット向け公開と、限定公開ゾーンによるVPC内部の名前解決の両方を1つのサービスで扱えます。この記事では、Cloud DNSの定義とアーキテクチャ、ゾーン設計とハイブリッド名前解決、ルーティングポリシー、料金体系、gcloud・Terraformでの管理、そしてRoute 53やAzure DNSとの使い分けまでを、実装者・技術選定者の視点で整理します。数値・仕様の根拠はGoogle Cloud公式ドキュメント（2026年7月時点）です。

まとめ：Cloud DNSの機能・料金・ルーティングと採用判断

Cloud DNSはGoogleのグローバルインフラ上で動く権威DNSで、権威サーバーからのクエリ応答について月間100%稼働のSLAを掲げています。公開ゾーン・限定公開ゾーン・DNS転送・DNSピアリング・DNSSEC・レスポンスポリシーゾーンを備え、加重ラウンドロビン・地域別・フェイルオーバーの3方式でトラフィックを制御できます。

料金はマネージドゾーン単位（2026年時点で0〜25ゾーンは約$0.20/ゾーン/月）とクエリ従量（0〜10億で$0.40/100万クエリ）の二本立てで、小規模なら月額数ドル規模に収まります。判断の軸はシンプルです。GCPを中核に据え、VPC内部の名前解決や100%稼働SLAを求めるなら第一候補になります。一方、すでにRoute 53でマルチクラウドの名前解決を集約済みで、レイテンシベースの高度なルーティングを多用している組織は、移行の実益が薄い場合があります。

Cloud DNSの定義とAnycast権威ネームサーバーの全体像

まず、Cloud DNSがDNSのどの役割を担うサービスなのかを押さえます。DNSには「名前を問い合わせる側（リゾルバ）」と「答えを持つ側（権威サーバー）」がありますが、Cloud DNSは後者、つまりゾーンの正本を保持して応答する権威DNSに位置づけられます。

Cloud DNSとは何か・GCPのフルマネージド権威DNS

Cloud DNSは、ゾーンの管理・レコード配信・スケーリングをGoogle側が受け持つマネージドサービスです。利用者はサーバーの構築や冗長化を意識せず、ゾーンとレコードを定義するだけで名前解決を提供できます。応答はGoogleのAnycastネットワークが担い、問い合わせ元に地理的に近いロケーションへ自動的に振り向けられるため、世界規模でも安定した応答を返せる点が特長です。運用者から見ると、bindの設定ファイルを保守する代わりに、gcloudコマンドやAPIでレコードを宣言的に管理する形になります。

100%稼働SLAが保証する範囲と権威DNSでの運用上の注意点

Cloud DNSのSLAは、少なくとも1台のGoogleマネージド権威ネームサーバーからクエリに応答できる時間について、月間稼働率100%を掲げています。Google Cloudは主要DNSプロバイダの中で100%のSLAをいち早く打ち出しました。ただしこの100%は「権威応答の可用性」であって、ドメイン全体の到達性を無条件に保証するものではありません。委任元レジストラのNS設定ミス、TTLの設計、DNSSECの鍵運用といった利用者側の設定は保証対象外です。100%という数字を、自社の設定品質まで担保してくれる魔法として読まないことが実務上の出発点になります。

Cloud DNSが対応するレコードタイプとゾーンの基本構造

Cloud DNSは主要なリソースレコードを標準でサポートします。ゾーンは「どのドメイン空間を管理するか」を表す単位で、そのなかに各レコードセットを登録していきます。

Aレコードやエイリアスの詳細な書き方・digでの確認手順は、レコード種類ごとにAレコードとは何かとAAAA・CNAMEとの違いで掘り下げています。ゾーンとレコードの関係を先に理解しておくと、後述のルーティングポリシーの設計が読みやすくなります。

Cloud DNSのゾーン設計と公開・限定公開の名前解決の仕組み

Cloud DNSの設計上のポイントは、公開範囲の異なるゾーンを組み合わせて、外向きと内向きの名前解決を同じサービスで完結させられる点にあります。

一般公開ゾーンと限定公開ゾーンの使い分け（split-horizon）

一般公開ゾーンは公共インターネットに応答を返すゾーンで、自社サイトやAPIのドメインを外部に公開する用途に使います。限定公開ゾーンは、指定した1つ以上のVPCネットワークの中だけで有効なゾーンです。同じドメイン名でも、外部からのアクセスと内部からのアクセスで異なるIPを返す「split-horizon（水平分割）」構成を、公開ゾーンと限定公開ゾーンの併用で実現できます。社内システムを内部IPで解決させつつ、外部には公開用のエンドポイントだけを見せる、といった分離が典型例です。VPC内部の名前解決という観点は、AWSのプライベートホストゾーンと発想が近く、プライベートDNSと内部名前解決の設計と比較すると各クラウドの考え方の差が見えてきます。

DNS転送・ピアリング・サーバーポリシーでのハイブリッド解決

オンプレミスとクラウドをまたいだ名前解決には、転送とピアリングの機能を組み合わせます。送信サーバーポリシーや転送ゾーンを使えば、Cloud DNSが解決できないクエリをオンプレミスのDNSサーバーへ送出できます。逆に受信サーバーポリシーを設定すると、オンプレミス側からCloud DNSの限定公開ゾーンへ問い合わせを届けられるのが受信側の役割です。DNSピアリングは、あるVPCの名前解決を別のVPCのゾーンに委ねる仕組みで、共有サービス用のVPCに名前解決を集約する設計に向きます。ハイブリッド環境では、どの方向のクエリをどの経路で解決するかを図に起こしてから設定するのが安全です。

DNSSECとレスポンスポリシーゾーンによるDNSの保護と対策

セキュリティ面では2つの機能が軸になります。1つはマネージドDNSSECで、ゾーンに電子署名を付けてキャッシュ汚染やなりすましを防ぎ、Google Public DNSのような検証リゾルバと組み合わせると応答の真正性を確認できます。鍵の生成・ローテーションはGoogle側が管理するため、運用負荷を抑えて導入できる点が利点です。もう1つはレスポンスポリシーゾーン（RPZ）で、既知の悪性ドメインの解決をブロックしたり、特定パターンにNXDOMAINを返したりする、DNS層のファイアウォールとして機能します。DNSSECの仕組みそのものはDNSSECの役割と導入手順で詳しく整理しています。

Cloud DNSのルーティングポリシーとトラフィック制御の設計

単純な名前解決だけでなく、応答するIPをクエリの条件で切り替えられるのがルーティングポリシーです。可用性と遅延低減の両面で使えます。

加重ラウンドロビン/地域別/フェイルオーバーの3方式と選び方

ルーティングポリシーは大きく3方式に分かれます。加重ラウンドロビン（WRR）は、複数の応答先に0〜1の重みで割合を割り振り、段階的なトラフィック移行やカナリアリリースに使えます。地域別（ジオロケーション）は、クエリ元のリージョンに応じて最も近いエンドポイントを返し、レイテンシと法域の分離に役立つ方式です。フェイルオーバーは、主系がヘルスチェックで異常と判定されたときに待機系のVIPへ切り替える方式です。3方式は排他ではなく、地域別で振り分けたうえで各地域内をフェイルオーバーで冗長化する、といった組み合わせが実務では多くなります。

ヘルスチェックと連動するフェイルオーバー構成と設計上の注意点

フェイルオーバーの肝はヘルスチェックとの連動です。バックアップVIPへ送るトラフィックの割合を0〜1で指定でき、100%を送れば手動での完全切り替えもできます。設計上の落とし穴はTTLです。DNSレベルの切り替えはキャッシュのTTLが切れるまで旧系に届き続けるため、フェイルオーバーを速くしたいゾーンではTTLを短めに設定しておく必要があります。TTLを短くすればクエリ数が増え、後述の従量課金に響く点とのバランスを取ります。DNSフェイルオーバーはロードバランサの切り替えより粒度が粗いため、秒単位の切り替えが要る要件ではロードバランサ側の機能と併用するのが現実的です。

Cloud DNSの料金体系とgcloud・APIでの管理方法

コストは「ゾーンをいくつ持つか」と「クエリがどれだけ来るか」で決まります。構造を理解すれば見積もりは難しくありません。

マネージドゾーンの単価とクエリ課金体系の内訳(2026年時点)

料金はマネージドゾーンの保有数とクエリ数の従量で構成されます。2026年7月時点のGoogle Cloud公式価格は次のとおりで、小規模なゾーンとクエリ量なら月額は数ドル規模に収まります。

注意点は、ルーティングポリシーを使うクエリは通常クエリより単価が高い（0〜10億で$0.70/100万クエリ）ことです。高トラフィックのゾーンで地域別やフェイルオーバーを多用する場合は、通常クエリとの差額が積み上がるため、TTL設計とあわせて試算しておきます。

gcloud・Cloud DNS API・Terraformでの管理と権限設計

Cloud DNSはコンソールのほか、gcloud dnsコマンド、Cloud DNS API、Terraformで宣言的に管理できます。インフラをコードで管理する現場では、ゾーンとレコードセットをTerraformのリソースとして定義し、レビューを経て反映する運用が定着しています。権限はIAMで制御し、変更を許す担当にはDNS管理者ロール、監査・参照だけの担当には読み取りロールを割り当てて、最小権限で分離するのが定石です。手作業のコンソール変更を残すと構成ドリフトの原因になるため、本番ゾーンはコード管理に寄せるのが無難です。

Cloud DNSを採用すべき企業と見送るべき場面の判断基準

ここからは独自の観点で、どんな組織がCloud DNSを選ぶと合理的で、どんな場合は見送るべきかを条件付きで言い切ります。DNSは一度移すと切り戻しに時間がかかるため、選定は慎重に行う価値があります。

採用が合理的になる条件・GCP中心と100%SLA重視の構成

Cloud DNSが第一候補になるのは、インフラの中核をGoogle Cloudに置いている組織です。GKEやCloud Load Balancing、Cloud RunといったGCPリソースと同じIAM・同じプロジェクト境界で名前解決を管理でき、限定公開ゾーンでVPC内部の名前解決も一元化できます。権威応答の月間100%稼働SLAを重視する要件、DNSSECを運用負荷を抑えて導入したい要件にも合致します。マルチリージョン構成で地域別ルーティングやフェイルオーバーをDNS層で組みたいケースも、標準機能で完結できる点が強みです。

見送り・過剰投資となる場面と代替(Route 53等)の検討

逆に、すでにAWSのRoute 53でマルチクラウド全体の名前解決を集約し、レイテンシベースルーティングなど成熟した機能を運用に組み込んでいる組織は、Cloud DNSへ移す実益が薄くなりがちです。SLA100%はRoute 53やAzure DNSも掲げており、可用性の数字だけでは差がつきません。判断は「どのクラウドに寄せると運用が一元化されるか」で行うのが実務的です。

ドメインの新規購入まで1サービスで完結させたい場合、Cloud DNSは権威DNSに特化しており、レジストラ機能は別サービスに分かれる点も、Route 53との運用感の違いとして押さえておきます。

受託開発やクラウド移行でCloud DNSを扱う際の実務判断

受託開発やクラウド移行の現場では、DNSの移管は移行計画の最後で失敗が表に出やすい工程です。移行時はTTLを事前に短縮し、新旧ゾーンを並行させて段階的にNSを切り替える手順が定石です。GCPへのシステム移行やVPC設計、内部名前解決の整理までを含めて外部の実装体制に相談したい場合は、AWS・Google Cloud・Azureを横断するクラウドインフラ構築の受託開発で、要件定義から移行設計まで支援しています。自社のクラウド構成に合わせてCloud DNSを組み込む判断を、実装前提で相談できます。

よくある質問

Cloud DNSの選定・運用でよく寄せられる質問に、実装者の視点で簡潔に答えます。

Cloud DNSとRoute 53の違いは何ですか？

最大の違いは統合先クラウドです。Cloud DNSはGoogle Cloud、Route 53はAWSと同じIAM・エコシステムで管理できます。可用性はどちらも100%SLAを掲げており差はつきません。ルーティングの選択肢はRoute 53がレイテンシベースなど幅広く、Route 53はドメイン購入（レジストラ機能）も同一サービスで完結する点が異なります。中核に置くクラウドに合わせて選ぶのが基本です。

Cloud DNSの料金はどれくらいかかりますか？

2026年7月時点で、マネージドゾーンは0〜25ゾーンが約$0.20/ゾーン/月、クエリは0〜10億で$0.40/100万クエリです。小規模なサイトなら月額は数ドル規模に収まります。ルーティングポリシーを使うクエリは$0.70/100万クエリ〜と割高になるため、高トラフィックで多用する場合は差額を試算してください。

Cloud DNSでドメインを購入できますか？

Cloud DNS自体は権威DNS（ゾーンとレコードの管理）に特化しており、ドメインの新規登録はCloud Domainsなど別のサービスが担います。他社レジストラで取得したドメインのNSをCloud DNSのネームサーバーに向ければ、購入元を問わず名前解決だけをCloud DNSに任せられます。

限定公開ゾーンでは何ができますか？

限定公開ゾーンは、指定したVPCネットワークの内部だけで有効なゾーンです。社内システムやマイクロサービスを内部IPで名前解決させたり、公開ゾーンと同名で内外に別のIPを返すsplit-horizon構成を組んだりできます。オンプレミスとの相互解決には、転送ゾーンや受信サーバーポリシーを併用します。

Cloud DNSのSLA100%は無停止を保証しますか？

SLAが保証するのは、Googleマネージド権威ネームサーバーがクエリに応答できる月間稼働率です。委任元レジストラのNS設定ミスやTTL設計、DNSSECの鍵運用など、利用者側の設定に起因する障害は対象外です。100%という数字を、自社設定の品質まで担保するものと誤読しない運用が前提になります。

関連記事

• Aレコードとは？IPv4への対応付けとAAAA・CNAMEとの違い：Cloud DNSで登録するレコードの種類と書き方を実装者向けに詳解
• プライベートDNSとは？内部名前解決とRoute 53プライベートゾーン：限定公開ゾーンと対比できるVPC内部名前解決の設計
• DNSSECとは？DNSの安全性を守る仕組みと導入手順：Cloud DNSのマネージドDNSSECの土台となる仕組みの詳細