Azure API Management を Internal（内部）VNet インジェクションで使うと、DNS の作り方、既定ドメインの扱い、オンプレ名解決、強制トンネリング時の管理プレーン通信が一気に複雑になります。設計の判断軸と具体的な構成例で整理します。
Internal VNet インジェクションで最初に押さえるべき全体像
Internal（内部）VNet インジェクションモードの APIM は、API の入口（ゲートウェイ）や開発者ポータルの到達性を VNet 内に閉じることで、インターネットから直接見えない API 基盤を作れるのが強みです。一方で、次の 2 つの「境界」をまたぐため、設計ミスが起きやすくなります。
- 名前解決の境界：既定 FQDN（myapim.azure-api.net など）を、どこから、どの DNS で引けるようにするか
- 経路の境界：API の実行トラフィック（データプレーン）と、サービス維持のための通信（管理プレーン/依存通信）をどう通すか
この記事では「Private DNS ゾーン」「カスタム DNS」「Azure Private DNS Resolver」「強制トンネリング」を 1 本の設計ストーリーとしてつなげ、検証～本番で詰まりがちなポイントを潰します。
APIM のエンドポイントを整理する（どの名前が、どこに向くのか）
Internal モードでは、同じ APIM サービスでも用途ごとに複数のホスト名が登場します。まずは「どのホスト名を、誰が使うのか」を整理すると、DNS とルートの設計が迷いません。
| 用途 | 代表的な FQDN 例 | 到達させたい範囲 | 設計の勘所 |
|---|---|---|---|
| API ゲートウェイ（実行） | myapim.azure-api.net | VNet / ピアリング / VPN・ER 経由の内部ネットワーク | Internal モードはプライベート IP へ解決させる。名前解決ができないと疎通以前に詰む。 |
| 開発者ポータル | myapim.developer.azure-api.net | 同上（運用方針次第で社内限定にも） | 検証段階では既定ドメインのままでもよい。将来カスタムドメイン化するなら証明書計画もセットで。 |
| 管理・運用（構成更新/スケール等） | （管理プレーンの宛先は内部で Azure 側と通信） | Azure 制御プレーンに必要な通信が成立すること | 強制トンネリングの影響が出やすい。ポート 3443 等を含む依存通信を「確実に外へ出す」設計が重要。 |
ポイントは、データプレーン（API の入出力）と管理プレーン（サービス維持のための通信）を同じ「閉域」の発想で扱うと事故る、という点です。Internal モードでも管理プレーン通信は完全には閉じません。ここを分けて考えるのが最短ルートです。
DNS 設計の最初の一手：「どこから使うか」を先に決める
Private DNS かカスタム DNS か以前に、Internal APIM では「名前を引けるべき利用者」を決めるのが重要です。名前解決の“配布範囲”が、そのまま到達性（＝公開範囲）になります。
| 利用者 | 典型例 | おすすめの名前解決パターン |
|---|---|---|
| 同一 VNet 内だけ | 同じ VNet の VM / AKS / App Service Environment | Private DNS ゾーンを APIM の VNet にリンクして完結 |
| ピアリング先の複数 VNet | Hub-Spoke で Spoke 側のアプリから利用 | Private DNS ゾーンを必要な VNet へ追加リンク（“必要最小限”がコツ） |
| オンプレ（VPN/ER）からも利用 | 社内端末やオンプレアプリが APIM を呼ぶ | オンプレ DNS と Azure の間で split-horizon（内部はプライベート IP、外部は別名）を設計。Resolver 併用が現実的 |
この前提が決まると、「どの DNS を採用すべきか」「Private DNS Resolver をどこに置くべきか」「どの VNet にリンクするべきか」が自然に決まります。
内部エンドポイントの名前解決：Private DNS ゾーンが“基本形”になる理由
Internal モードで最初にぶつかるのが、「既定ドメイン（azure-api.net）を、プライベート IP に解決させるにはどうするか」です。実務での基本形は Azure Private DNS ゾーンを使うパターンです。
Private DNS ゾーンでの構成イメージ
- Private DNS ゾーンとして
azure-api.netを作成 - APIM が所属する VNet（必要ならピアリング先 VNet も）をリンク
myapim、myapim.developerなどの A レコードを APIM のプライベート IP に向ける
これだけで、VNet 内のクライアントは既定 FQDN を引いた瞬間にプライベート IP に到達でき、APIM を「社内 API ゲートウェイ」として使える土台が整います。
レコード名はどう書く？（実際の登録例）
Private DNS ゾーンを azure-api.net とした場合、レコードの“名前”は相対名で登録します。例えば次のようになります。
| Private DNS ゾーン | レコード名（相対） | 解決される FQDN | 値 |
|---|---|---|---|
azure-api.net | myapim | myapim.azure-api.net | APIM のプライベート IP |
azure-api.net | myapim.developer | myapim.developer.azure-api.net | 同上（通常は同じプライベート IP） |
「developer は別ゾーン？」と混乱しがちですが、myapim.developer.azure-api.net は azure-api.net の下位であり、Private DNS ゾーン 1 つでまとめて管理できます。
手順をもう少し具体化（検証で迷わない最小セット）
検証フェーズなら「最小セット」で早く疎通を取り、後から拡張できる形にするのが得策です。
| 作業 | 目的 | 検証のコツ |
|---|---|---|
| Private DNS ゾーン作成（azure-api.net） | 既定ドメインを私設 DNS として扱う | このゾーンをリンクした VNet の中だけで効く（外部のインターネットには影響しない）。 |
| VNet リンク（APIM の VNet / 参照側 VNet） | どこから名前解決できるようにするかを明確化 | 「APIM のいる VNet だけリンク」だと、別 VNet のクライアントは解決できない。利用範囲に合わせて増やす。 |
| A レコード登録 | 既定 FQDN → プライベート IP | まずは myapim と myapim.developer の 2 つを入れて疎通。必要が出たら増やす。 |
| （推奨）自動登録はオフ | 想定外のレコード増殖を防ぐ | azure-api.net は“社内で管理する既定ドメイン”なので、基本は手動管理が安全。 |
Private DNS は “作って終わり” ではなく、「どの VNet にリンクするか」がそのまま “公開範囲” になります。後述するハブ＆スポークやオンプレ接続の設計とセットで考えると事故が減ります。
カスタム DNS（独自 DNS サーバー）を選ぶべきケースと設計ポイント
ブログなどで「VNet 内の独自 DNS（AD DNS など）を推奨」と書かれているのは、ハイブリッド環境で 名前解決の一元管理を重視するケースがあるためです。すでに社内 DNS に複雑な運用ルールがあり、Azure 側のゾーンを増やしたくない事情も現実にはあります。
カスタム DNS でやる場合の基本
- DNS サーバー（例：Windows Server DNS / BIND）で
azure-api.netゾーンを管理する myapim、myapim.developerなどを A レコードで APIM のプライベート IP に向ける- APIM を利用するサブネット（VM / AKS / ASE 等）が、その DNS を参照するように VNet の DNS 設定を変更する
Private DNS とカスタム DNS の比較（判断軸をテーブル化）
| 観点 | Azure Private DNS ゾーン | カスタム DNS（独自 DNS サーバー） |
|---|---|---|
| 運用負荷 | 低い（マネージド） | 中～高（サーバー運用/冗長化/監視が必要） |
| Azure 連携 | 強い（VNet リンクで簡単に適用範囲を制御） | 自前で設計（転送・委任・条件付きフォワード等） |
| ハイブリッド（オンプレ）との整合 | 工夫が必要（オンプレへ配布するには Resolver などを併用） | やりやすい（既存の社内 DNS の仕組みに寄せられる） |
| トラブルの典型 | VNet リンク漏れで解決できない | ゾーンの更新漏れ・冗長化不足で名前解決が不安定 |
結論としては、特段の理由がなければ Private DNS ゾーンが無難です。カスタム DNS は「既存運用に合わせる」ことでメリットが出ますが、その分だけ設計と運用の責任範囲が増えます。
カスタムドメインを使うときの考え方（検証→本番を滑らかにつなぐ）
検証は既定ドメイン（azure-api.net）で素早く動かし、本番で カスタムドメイン（例：api.example.com）に切り替える、という段階移行はよくあります。ここで重要なのは「DNS と証明書を同時に設計する」ことです。
| 対象 | 既定ドメイン例 | カスタムドメイン例 | 必要なもの |
|---|---|---|---|
| ゲートウェイ | myapim.azure-api.net | api.example.com | 社内 DNS（プライベート）で A/CNAME、証明書（CN/SAN） |
| 開発者ポータル | myapim.developer.azure-api.net | portal.example.com | 同上（ポータル用に別名・別証明書にすることも多い） |
Internal モードで社内限定にする場合、カスタムドメインも「プライベート DNS でのみ解決」させるのが自然です（いわゆる split-horizon / split-brain）。これにより、社内は api.example.com で内部 IP に到達し、インターネット公開が不要ならパブリック DNS 側にレコードを置かずに済みます。
証明書は、ゲートウェイ用とポータル用を分けると運用が楽です。例えば、ポータルは社内認証やリンクが絡むため、移行・切り替え時に影響が出やすいからです。逆に小規模なら 1 枚の SAN 証明書でまとめることも可能ですが、更新作業の影響範囲が広くなる点は意識します。
カスタムドメイン未使用でも azure-api.net の Private DNS ゾーンを作ってよいか
検証段階では「まず既定ドメインで動かしてから、必要になったらカスタムドメインにする」という進め方が現実的です。このとき、azure-api.net の Private DNS ゾーンを作ること自体は一般的で、基本的に問題ありません。
「インターネット側に影響しない」理由
- Private DNS ゾーンは リンクした VNet の中だけで参照される
- 外部の DNS（パブリック DNS）を書き換えるわけではない
ただし知っておきたい注意点（落とし穴はここ）
Private DNS ゾーンはそのドメインに対して “社内の正” になるため、リンクした VNet の中では *.azure-api.net の解決が Private DNS 側に寄ります。つまり、その VNet の中で参照したい名前は、必要な分だけレコードを用意するのが安全です。
| よくある状況 | 起きること | 対策 |
|---|---|---|
| APIM の FQDN だけ登録し、他の azure-api.net 名を使っていない | 基本は問題なし | 疎通確認（nslookup、curl 等）を早めに回す |
| 同一 VNet 内で別の azure-api.net 名を参照する可能性がある | 未登録名は解決できず、通信が失敗することがある | 必要な名前を洗い出して追加、またはリンク範囲を絞る |
| 将来カスタムドメイン（api.example.com）へ移行したい | 別ゾーン/証明書/バインド設定が必要になる | 検証は既定→本番はカスタム、の段階移行を前提に設計 |
検証では TTL を短めにしておくと、IP 変更や切り戻しが必要な場面でラクになります（本番では運用ポリシーに合わせて調整）。
Azure Private DNS Resolver でオンプレミスの FQDN を解決する
APIM を Internal にすると、API のバックエンドがオンプレミス（例：api.onprem.local）という構成も増えます。このとき「APIM（が属する VNet）からオンプレ DNS を引けるか？」は重要です。結論として、Azure Private DNS Resolver のアウトバウンドエンドポイント＋フォワーディングルールセットで実現できます。
Resolver を使うと何が嬉しいのか
- VNet 内のリソース（APIM/VM/コンテナ等）が、個別にオンプレ DNS を意識しなくてよい
- 「このサフィックスはオンプレへ転送」といったルールを Azure 側で集中管理できる
- VPN/ExpressRoute のハイブリッドと相性がよい（ルーティングと合わせて設計しやすい）
構成の考え方（最小構成 → 拡張）
設計上のコツは、Resolver を ハブ VNetに置き、スポーク（APIM の VNet など）から利用する形にすると拡張しやすいことです。
| コンポーネント | 配置例 | 役割 |
|---|---|---|
| Private DNS Resolver（アウトバウンド） | Hub VNet | 特定ドメインのクエリをオンプレ DNS に転送する出口 |
| フォワーディングルールセット | Hub VNet（複数 VNet にリンク） | 例：onprem.local は 10.0.0.10/10.0.0.11 に転送 |
| APIM（Internal） | Spoke VNet | バックエンドがオンプレの場合、名前解決と到達経路が必須 |
ここで注意したいのは、VNet の DNS 設定です。Azure 既定 DNS（Azure-provided）を使えるなら「ルールセットを VNet にリンクするだけ」でクエリが転送される運用がしやすいです。一方、VNet をカスタム DNS にしている場合は、クエリが Resolver の仕組みを経由しないことがあります。次のように整理すると設計判断がしやすくなります。
| VNet の DNS 設定 | オンプレへの転送（アウトバウンド） | Azure Private DNS の参照 | 現実的な解 |
|---|---|---|---|
| Azure-provided DNS | ルールセットのリンクで実現しやすい | そのまま解決できる | まずはこの形が一番シンプル |
| カスタム DNS（AD DNS 等） | カスタム DNS が転送/再帰を握る | そのままだと参照できないことがある | 条件付きフォワードで Resolver（インバウンド）へ投げる、またはゾーンを自前で管理 |
オンプレ→Azure 方向も必要なら（補足）
社内端末から myapim.azure-api.net を引きたい（VPN/ER 経由で APIM に到達させたい）場合は、オンプレ DNS から Azure Private DNS ゾーンへ問い合わせる経路も必要になります。この場合は Resolver の インバウンドエンドポイントを用意し、オンプレ DNS の条件付きフォワード先に指定すると、Private DNS ゾーンの名前解決をオンプレへ“配布”できます。Internal APIM を社内共通基盤として育てるなら、この拡張を見越しておくと後で楽です。
強制トンネリング環境での管理プレーン通信：設計の結論と選択肢
強制トンネリング（forced tunneling）を有効にしていると、既定では 0.0.0.0/0 のアウトバウンドがオンプレ側 NVA/ファイアウォールへ向きます。Internal モードの APIM では、これが原因でプロビジョニングや更新、スケール操作が不安定になることがあります。よくあるのが「API の疎通は OK なのに、APIM の更新だけ失敗する」パターンです。
管理プレーンだけ別扱いが必要になる理由
- 管理プレーン通信は、API の実行トラフィックとは宛先・ポート・頻度が異なる
- オンプレ経由にすると、経路が長くなり、タイムアウトや非対称ルーティングの原因になりやすい
- 必要な宛先は機能（証明書/Key Vault/監視等）で増えるため、例外管理が雪だるま式に増える
そのため実務上は、管理プレーン（および APIM の依存通信）だけは Azure 側で安定して外へ出す設計が推奨されがちです。質問にあった 2 択（UDR で直出し vs オンプレ FW 例外）も、ここに帰着します。
選択肢を比較（どちらが“ベストプラクティス寄り”か）
| 案 | メリット | デメリット | 向いている環境 |
|---|---|---|---|
| UDR で管理プレーン宛てだけ Azure 側の出口へ | 経路が単純で安定しやすい。非対称ルーティングを避けやすい。 | 「全トラフィックをオンプレで検査」のポリシーと衝突することがある。 | クラウド側で egress を完結できる（Azure Firewall/NAT Gateway 等を許容） |
| オンプレ FW で例外（ポート 3443 等）を許可 | 強制トンネリング方針を崩さずに済む。 | 宛先の管理・追随が大変。トラブルシュートが難しくなりやすい。 | コンプライアンス上、オンプレ経由が必須。運用体制が厚い |
“無難で壊れにくい” という観点では、UDR で管理プレーン系を Azure 側の安定した出口へ逃がす設計が取り回し良いです。オンプレ例外で成立させることも可能ですが、運用の難易度は上がります。
UDR を切るときの実践ポイント
- 「何を例外にするか」を 依存通信の単位で決める（管理プレーンだけ、証明書連携だけ、など）
- APIM サブネットのルートテーブルは 最小例外 → 監視 → 拡張で作る（最初から盛りすぎない）
- 直出し先は “素の Internet” だけでなく、Azure Firewall や NAT Gatewayで出口を固定すると監査・ログが取りやすい
また、オンプレ FW で例外を作る場合は「ポートを開ける」だけで終わらず、宛先（IP/FQDN）の追随と、SNAT を含む経路の対称性（行きと帰りが一致すること）まで含めて設計します。ここが曖昧だと、たまに成功・たまに失敗という最も辛い状態になります。
“最低限ここだけ”押さえる通信の考え方
詳細な宛先一覧は機能やリージョンで変わりますが、設計としては次のように分解すると整理しやすいです。
| 分類 | 例 | 閉域で完結させたいか | 強制トンネリング時の扱い |
|---|---|---|---|
| データプレーン | クライアント→APIM、APIM→バックエンド | 可能（Internal モードの主目的） | オンプレ/Hub 経由でも設計しやすい |
| 管理プレーン | 構成更新、スケール、プラットフォーム維持 | 難しい（Azure 側との通信が前提） | Azure 側の出口へ逃がすか、オンプレ FW で例外運用 |
| 付帯機能の依存通信 | 証明書（Key Vault）、監視（ログ送信）、バックアップ等 | 方針次第 | 必要機能に合わせて例外を追加。最小から始める |
おすすめ構成例：Hub-Spoke で“DNS と経路”を分離する
Internal APIM とハイブリッド（VPN/ER）を組み合わせる場合、DNS と経路をハブに集約しておくと運用が安定します。典型的な構成例を文章で整理します。
- Hub VNet：Azure Firewall（または NVA）、Private DNS Resolver、共有サービス（監視/踏み台等）
- Spoke VNet：APIM（Internal）、バックエンド連携用サブネット
- DNS：Private DNS ゾーン（azure-api.net）＋必要に応じてカスタムドメイン用のプライベートゾーン
- 経路：オンプレ宛てプレフィックスは VPN/ER へ、その他は Azure 側の出口へ（必要なら APIM の管理プレーンだけ例外）
| 悩み | ハブ集約での解決イメージ |
|---|---|
| オンプレ名解決が必要 | Hub の Resolver で転送し、Spoke はルールセットをリンクして使う |
| Private DNS ゾーンを複数 VNet に配りたい | 必要な VNet だけをリンク。ピアリングの数が増えても設計が崩れにくい |
| 強制トンネリングで管理プレーンが不安定 | Hub の出口（Firewall/NAT）へ戻す、または APIM サブネットで例外ルートを作る |
検証・運用で使えるチェックリスト（DNS/ルートの事故を早期発見する）
Internal APIM のトラブルは「名前解決」と「経路」が原因のことが多いので、検証で次のチェックをルーチン化すると、切り分けが劇的に早くなります。
名前解決チェック
- VNet 内の VM から
nslookup myapim.azure-api.netを実行し、想定のプライベート IP が返る nslookup myapim.developer.azure-api.netも同様に確認- カスタム DNS 利用時は、DNS サーバー自身の再帰/転送設定（条件付きフォワード）を確認
疎通チェック
- クライアント→APIM（443 等）の接続が通る（TLS 失敗なら SNI/証明書を疑う）
- APIM→バックエンド（オンプレ/同一 VNet）の接続が通る（DNS 解決とルート両面）
管理プレーン/依存通信チェック
- APIM の構成変更やスケール操作を実施し、失敗しないかを確認（疎通試験だけだと見逃しやすい）
- 強制トンネリング環境では、APIM サブネットのルート（0/0 と例外）と、FW 側の許可ログを突き合わせる
よくあるトラブルと“現場での切り分け”
| 症状 | 原因の候補 | まずやること |
|---|---|---|
| APIM の FQDN が引けない（NXDOMAIN） | Private DNS ゾーン未リンク、カスタム DNS で転送していない | VNet リンク確認、DNS サーバーの条件付きフォワード確認 |
| ゲートウェイは見えるが Developer Portal が見えない | myapim.developer のレコード未登録 | 必要なホスト名の洗い出しと A レコード追加 |
| API 実行はできるのに、構成更新/スケールが失敗する | 強制トンネリングで管理プレーン通信が遮断/非対称 | APIM サブネットのルートと FW の許可（ポート 3443 等）を確認 |
| オンプレ FQDN が解決できずバックエンドに到達しない | Resolver 未設定、ルールセット未リンク、VPN/ER の DNS 経路不足 | フォワーディングルールセットとリンク状態、オンプレ DNS の到達性を確認 |
まとめ：Internal APIM を安定させる設計の着地点
- 既定ドメインで運用するなら、まずは azure-api.net の Private DNS ゾーンでプライベート IP へ解決させる
- カスタム DNS は「既存運用に寄せたい」場合に有効。ただし運用責任が増える点を織り込む
- オンプレ名解決は Azure Private DNS Resolver（アウトバウンド＋ルールセット）で集中管理すると設計が崩れにくい
- 強制トンネリング下では、管理プレーン/依存通信は Azure 側の安定した出口へ逃がすのが壊れにくい（UDR 例外が実務的）
- 検証フェーズは「既定ドメイン＋Private DNS」で素早く疎通し、本番要件（カスタムドメイン/監査）に合わせて段階的に拡張する
コメント