- Дата публикации
Как не сломать корпоративный ИИ в Azure: частный DNS и схема hub‑and‑spoke
Что появилось / что изменилось
Microsoft на реальном продакшн-кейсе разобрала типовой сценарий: крупная ИИ‑платформа в Azure, полностью в приватных сетях. Без выхода в интернет, с жёстким egress-контролем и только через Private Endpoint.
Главное, что меняется по сравнению с «простым» деплоем в Azure:
- Вся архитектура строится вокруг частной сети: hub‑and‑spoke, централизованный фаервол/NVA, собственные DNS‑серверы в хабе.
- Все PaaS‑сервисы (Cognitive Services, Azure OpenAI, Key Vault, Storage, Search и др.) доступны только через Private Endpoint.
- Azure Container Apps работают во внутреннем режиме (internal load balancer), без публичного входа.
- DNS перестаёт быть «фоном» и становится критичным компонентом: без правильной настройки ломаются автоскейл, аутентификация, доступ к секретам и Terraform‑деплой.
Microsoft по шагам описывает, как настроить:
- интеграцию кастомного DNS с внутренним резолвером Azure 168.63.129.16;
- централизованные private DNS‑зоны и их линковку со всеми VNet;
- отдельную DNS‑зону и wildcard‑записи для Container Apps во внутреннем режиме;
- согласованную политику маршрутизации, NSG и фаервола для DNS‑трафика и сервисных тегов.
Как это работает
В частной архитектуре Azure есть несколько ключевых узлов.
-
Внутренний резолвер Azure 168.63.129.16. Он знает всё про:
- системные домены Azure;
- FQDN Private Endpoint‑ов;
- private DNS‑зоны вида
privatelink.*.
Если вы используете свои DNS‑серверы в хабе, они по умолчанию этого не знают. Нужны conditional forwarders на 168.63.129.16.
-
Private DNS‑зоны для PaaS‑сервисов. Для приватных endpoint‑ов Azure создаёт зоны, например:
privatelink.cognitiveservices.azure.com;privatelink.openai.azure.com;privatelink.vaultcore.azure.net;privatelink.search.windows.net;privatelink.blob.core.windows.net.
Если ваши DNS‑серверы не форвардят запросы в эти зоны на 168.63.129.16, резолв либо падает, либо уходит на публичные адреса, которые блокирует фаервол.
-
Container Apps с internal load balancer. При включённом
internal_load_balancer_enabled = trueAzure создаёт внутренний домен среды (например,something.internal), но не создаёт за вас private DNS‑зону и записи.Чтобы сервис‑ту‑сервис трафик внутри Container Apps работал, нужно вручную:
- создать private DNS‑зону под домен среды;
- добавить wildcard‑записи
*,*.internalи@(apex); - направить их на статический IP Container Apps Environment;
- если у вас свой DNS — добавить conditional forwarder на эту зону.
-
Линковка зон и сетей. Private DNS‑зоны можно раскидать по разным подпискам, но они должны быть привязаны (linked) ко всем нужным VNet:
- hub;
- все spoke‑сети с нагрузкой;
- VNet с DNS‑серверами;
- VNet с операционными системами админов или виртуальными рабочими столами.
Плюс к этому фаервол, NSG и маршруты должны пропускать:
- DNS (TCP/UDP 53) между рабочими подсетями и DNS‑серверами;
- трафик по сервисным тегам Azure:
AzureCloud,CognitiveServices,AzureActiveDirectory,Storage,AzureMonitorи др.
Что это значит для вас
Если вы строите корпоративную ИИ‑платформу в Azure без публичного доступа, DNS‑архитектура — не «деталь», а часть дизайна системы.
Что делать до продакшна:
- Заложить кастомные DNS‑серверы в хабе с conditional forwarders на 168.63.129.16 для всех
privatelink.*‑зон и домена Container Apps. - Хранить private DNS‑зоны централизованно (отдельная подписка или общая инфраструктурная) и линковать их ко всем VNet, где есть нагрузка и админские машины.
- Для Azure Container Apps с внутренним входом сразу создавать DNS‑зону среды и wildcard‑записи на IP окружения.
- Проверять, что фаервол и NSG не режут DNS и трафик к Azure‑сервисам по сервисным тегам.
Где это особенно полезно:
- платформы генеративного ИИ и ML, которые работают только через Private Endpoint (Azure OpenAI, Cognitive Services, приватный доступ к хранилищам и поиску);
- среды с жёстким регуляторным контролем, где интернет закрыт, а egress идёт только через NVA;
- мульти‑среды (dev/test/prod) с общим хабом и разными spoke‑сетями.
Где может быть избыточно:
- небольшие пилоты, где ИИ‑сервисы доступны по публичным endpoint‑ам и достаточно стандартного DNS Azure;
- сценарии, где нет строгих требований к приватности сети и можно обойтись без hub‑and‑spoke и NVA.
Если вы работаете из России, доступ к Azure и связанным ИИ‑сервисам часто требует VPN и юридически корректную юрисдикцию аккаунта. Это нужно учитывать на этапе планирования, особенно если заказчик — международная группа компаний.
Место на рынке
Речь идёт не о новом сервисе, а о практическом паттерне для Azure: сочетание hub‑and‑spoke, Private Endpoint‑ов, кастомного DNS и Container Apps во внутреннем режиме.
Прямое сравнение «в процентах» с AWS или Google Cloud здесь некорректно: Microsoft описывает именно то, как устроен DNS и private networking в Azure и как это влияет на ИИ‑нагрузки.
Если смотреть по классам решений:
- В AWS похожие задачи решают через Route 53 Resolver, PrivateLink и Transit Gateway. Но детали работы системного резолвера и схемы линковки зон отличаются.
- В Google Cloud это комбинация Cloud DNS, Private Service Connect и Shared VPC.
Плюс Azure даёт чёткий опорный IP‑адрес внутреннего резолвера 168.63.129.16 и стандартный набор private DNS‑зон privatelink.* для ИИ‑сервисов и хранилищ. На этом Microsoft строит «чертёж» для надёжного запуска ИИ‑нагрузок в приватной сети.
Практический вывод: если ваш основной облачный стек — Azure, то предложенная схема private DNS и сетевой архитектуры может стать базовым шаблоном для всех будущих ИИ‑проектов, чтобы не ловить странные падения Container Apps, проблемы с аутентификацией и «рандомные» фейлы Terraform.