内部DNSをIaCで管理する4ステップ、Route 53とCloudflareどちらを選ぶか

社内向けAPIやマーケットプレイス連携のホスト名を、Terraformなどのインフラコード（IaC、Infrastructure as Codeの略で、サーバー設定をコードとして管理する手法）で管理し始めると、必ず突き当たる問題があります。

それは「デプロイでDNSレコードを書き込んだつもりが、実際に世の中に公開されている値と一致しているか確認できない」という問題です。CI/CDパイプラインを運用しているエンジニアや、社内DNSのホスト名切り替えをレビュー可能な形にしたいインフラ担当者に向けて、DNS管理をIaC化する際の判断軸を整理します。

なぜ「書き込み成功」だけでは不十分なのか

DNSプロバイダのAPIが200番台のレスポンスを返したとしても、それは「リクエストを受理した」ことの証明にすぎません。

実際に権威DNSサーバー（そのドメインの正式な回答を返すサーバー）が公開している値が、リポジトリの意図と一致しているかは別の話です。この2つを混同すると、以下のような不具合が数か月単位で放置されます。

• リポジトリ外で誰かが手動編集したレコード
• 新しいターゲットの隣に残された古いレコード
• マージされたのに反映されていないロールバックコミット

HTTPの書き込み成功だけを監視するダッシュボードでは、この3つのケースをどれも検知できません。対策として提案されているのが、デプロイ後に「望ましいレコード集合」と「実際の権威応答」を突き合わせる差分チェックです。プルリクエストが望ましいレコード集合になり、デプロイが冪等（べきとう、同じ操作を何度実行しても結果が変わらない性質）なupsert（存在すれば更新、なければ追加する操作）を送り、権威ルックアップの結果と比較して一致すれば成功、不一致ならデプロイを失敗させる、という流れです。

比較には配列比較ではなく集合比較を使う点も実務上のポイントです。DNSの応答順序には意味がないため、順序違いを誤検知しないようにする必要があります。またDNSの伝播（変更が世界中のリゾルバに反映されるまでの遅延）を考慮し、書き込み直後に読み取ると古い値が返ることがある点にも注意が必要です。ポーリング（一定間隔で確認を繰り返す方式）に期限を設けて待つ設計が現実的です。

判断軸1: 既存のクラウド境界がどこにあるか

DNSゾーンの管理主体がすでにどこにあるかが、最初に見るべき軸です。

AWSでVPCやIAMをすでに運用しているなら、Route 53（AWSのマネージドDNSサービス）を使うのが最短距離になります。デプロイ用のIAMロールも既存の権限体系に乗せられるため、新たな認証の仕組みを増やさずに済みます。

同様に、CloudflareでゾーンとWAFなどの運用制御をすでに行っているならCloudflare DNSが自然な選択です。Google Cloudのプロジェクト単位でIAMを管理しているならGoogle Cloud DNSが適合します。

判断軸2: プロバイダ間の移植性が実際の要件か

2つ目の軸は「将来的に別のDNSプロバイダへ乗り換える可能性が、現実的な要件としてあるか」です。

特定プロバイダのAPIに直接アダプタを書くと、そのプロバイダ固有の概念（Route 53のホストゾーンID、Cloudflareのゾーン識別子など)がデプロイコードに染み込みます。これ自体は悪いことではありませんが、後で別プロバイダへ移行する際にアダプタを丸ごと書き換えるコストが発生します。

移植性を優先するなら、DNS操作用に薄い抽象化レイヤー（1つのAPI契約を保ったまま裏側のベンダーだけ差し替えられる層）を挟む設計もあります。ここで注意したいのは「移植性がロードマップ上のスローガンで終わっていないか」という点です。抽象化レイヤーはそれ自体が新たな運用対象になるため、実際に複数プロバイダを使い分ける計画がなければ、むしろ複雑さを増やすだけになります。

判断軸3: 対象レコードが「安定」か「頻繁に変わる」か

3つ目の軸は見落とされがちですが重要です。マーケットプレイス向けのホスト名のように、切り替えの頻度が低く人がレビューする価値があるレコードと、コンテナやVMのインスタンスが起動・停止するたびに変わるエンドポイントは、性質がまったく異なります。

後者のような頻繁に変化するサービスの所在地情報を、IaCのプルリクエストとデプロイの差分チェックのループに乗せるのは適切ではありません。マイクロサービス構成でコンテナのIPが動的に変わる環境では、Consulやkubernetes内部のServiceリソースのようなサービスレジストリ（動的なインスタンスの所在を登録・検索する仕組み）を使うべきです。IaCの差分チェックは、レビュー可能な安定したホスト名にこそ向いています。

選択肢の比較

ケース別の推奨

判断軸を踏まえると、次のように整理できます。

• AWS上にVPC・IAM・既存の本番システムがすでにあるなら、Route 53を選び、Terraformのaws_route53_recordリソースでレコードをリポジトリ管理するのが最短距離です
• CloudflareでWAFやCDN設定を既存運用しているなら、CloudflareのTerraformプロバイダで同じレビューフローに乗せるのが自然です
• 複数クラウドを併用する計画が具体的にあり、DNSプロバイダの切り替えが実際に検討事項に上がっているなら、抽象化レイヤーの導入を検討する価値があります
• コンテナオーケストレーション環境でインスタンスが頻繁に入れ替わるなら、そのレコードはIaCの差分チェックの対象から外し、サービスレジストリに任せます

あえて見送るべき条件

一方で、この仕組みを導入しないほうがよい条件もあります。

まず、DNSレコードの変更頻度が極端に低く、手動更新でも事故が起きていないチームでは、差分検証パイプラインを構築するコストが見合わない可能性があります。数か月に1回しか変わらないレコードに、ポーリング付きの検証ロジックを常設するのは過剰投資です。

また「将来マルチクラウドになるかもしれない」という漠然とした期待だけで抽象化レイヤーを先に導入するのも避けたほうがよい選択です。移植性は具体的な移行計画があって初めて価値を持ちます。仮説段階では、まず単一プロバイダのネイティブツールで運用し、実際に乗り換えの必要が生じたタイミングでアダプタ層を挟む方が、無駄な運用負荷を避けられます。

まとめ

内部DNSのホスト名管理をIaC化する際は、まず自分たちのDNSゾーンが実際にどのクラウドの制御下にあるかを確認してください。

そのうえで、Terraformなどの構成ファイルに書いた「望ましいレコード集合」と、権威DNSから読み取った実際の値を突き合わせる差分チェックを、デプロイパイプラインに組み込めるかを検討する価値があります。集合比較とポーリング期限の設計は、実装前に必ず押さえておきたいポイントです。

最後に、対象のレコードが「安定していてレビューに値するもの」か「頻繁に変わる動的なもの」かを仕分けしてから着手すると、無理のない範囲でこの仕組みを取り入れられます。