Как превратить Azure AI Foundry в управляемый AI‑шлюз с помощью Azure API Management

Что нового

Microsoft предлагает использовать Azure API Management (APIM) как «AI‑шлюз» перед Azure AI Foundry. Это не отдельный продукт, а архитектурный паттерн, который добавляет управляемый контрольный пункт поверх уже работающих AI‑сервисов.

Ключевые новшества:

1. Пер‑модельная телеметрия по токенам без изменений клиентского кода
   APIM ставится перед Azure AI Foundry и:

   • прозрачно проксирует OpenAI‑совместимые запросы;
   • автоматически аутентифицируется в Foundry через system-assigned managed identity;
   • пишет в Azure Monitor / Application Insights метрики по токенам с размерами по моделям и деплойментам.

2. Отчётность и chargeback по моделям
   В метрики попадают:

   • Total Tokens, Prompt Tokens, Completion Tokens;
   • Model Name и Model Deployment Name;
   • API Id, подписка APIM, IP клиента, Product ID.
     Это позволяет собрать «книгу учёта» по токенам за месяц по каждой модели и каждой команде.

3. Политика, которая «видит» каждую модель и каждый токен
   В APIM добавляется кастомная inbound‑политика, которая:

   • выбирает backend Azure AI Foundry;
   • получает токен Entra ID для https://cognitiveservices.azure.com через managed identity;
   • вытаскивает имя модели из URL или JSON‑тела (оба варианта);
   • вызывает azure-openai-emit-token-metric (в примере namespace genai-tokens).

4. Готовый паттерн для смешанных деплойментов
   Один и тот же шлюз может стоять перед разными моделями в Azure AI Foundry. В примере:

   | Deployment | Model | Capacity (TPM) | |-----------|--------|----------------| | gpt-4.1 | gpt-4.1| 500K | | gpt-5 | gpt-5 | 50K |

   Большой разрыв по TPM (500K против 50K) делает раздельный учёт по моделям не пожеланием, а требованием к управлению.

5. Guardrail по затратам: алерт на дневной лимит токенов
   На базе метрик можно собрать лог‑запрос в Azure Monitor, который раз в час проверяет:

   • сколько токенов съела каждая модель за последние 24 часа;
   • какие деплойменты вышли за дневной бюджет (например, 50 000 токенов).
     При превышении срабатывает alert и шлёт уведомление в почту или Microsoft Teams.

6. Интеграция с Azure Front Door и WAF для AI Landing Zone
   Поверх APIM добавляется:

   • Azure Front Door как глобальная точка входа и TLS‑терминация;
   • Web Application Firewall (WAF) с Microsoft_DefaultRuleSet_2.1 и Microsoft_BotManagerRuleSet_1.0;
   • IP‑фильтрация и rate limiting ещё до попадания трафика в APIM и Foundry.

7. Без ключей — только managed identity и private endpoint
   В референсной архитектуре:

   • Azure AI Foundry, Key Vault, Storage, AI Search доступны только по private endpoint;
   • APIM ходит в Foundry через system-assigned managed identity;
   • TLS‑сертификат для Front Door лежит в Key Vault;
   • трафик из спиц проходит через Azure Firewall;
   • Azure Policy навешивает guardrails на подписку.

Как это работает

Базовый сценарий «до»: простой прокси

Если просто импортировать API Azure AI Foundry в APIM и ничего не настраивать, получится прозрачный прокси:

<policies>
  <inbound>
    <base />
    <set-backend-service id="apim-generated-policy" backend-id="testfoundry277-ai-endpoint" />
  </inbound>
  <backend><base /></backend>
  <outbound><base /></outbound>
  <on-error><base /></on-error>
</policies>

APIM честно перекидывает запросы на Foundry, но не даёт сигнала по использованию токенов на уровне моделей. Всё смешивается в одну ресурсную телеметрию.

Расширенный сценарий «после»: управляемый шлюз

Нужен слой, который:

• понимает, какая модель вызывается;
• знает, сколько токенов она потребляет;
• пишет это в единый источник телеметрии.

Для этого в inbound‑политику APIM добавляется кастомный блок:

<policies>
  <inbound>
    <base />
    <set-backend-service backend-id="foundry-apim-si-ai-endpoint" />
    <authentication-managed-identity resource="https://cognitiveservices.azure.com" />

    <!-- Resolve the model/deployment name. The Foundry Model Inference API
         (/models/chat/completions, /models/embeddings, /anthropic/v1/messages)
         passes it in the JSON body as "model". The Azure OpenAI-style surface
         (/openai/deployments/{name}/...) passes it in the URL path. Handle both. -->

    <set-variable name="deployment-id" value="@{
        var path = context.Request.Url.Path ?? "";
        var m = System.Text.RegularExpressions.Regex.Match(path, "/deployments/([^/?]+)");
        if (m.Success) { return m.Groups[1].Value; }
        try {
            var body = context.Request.Body?.As<JObject>(preserveContent: true);
            var model = body?["model"];
            if (model != null && !string.IsNullOrEmpty(model.ToString())) {
                return model.ToString();
            }
        } catch (Exception) { }
        return "unknown";
    }" />

    <!-- Emit token-usage metrics dimensioned by model, so consumption can be
         sliced per model in Azure Monitor / Application Insights. -->

    <azure-openai-emit-token-metric namespace="genai-tokens">
        <dimension name="ModelDeploymentName" value="@((string)context.Variables["deployment-id"])" />
        <dimension name="ModelName" value="@((string)context.Variables["deployment-id"])" />
        <dimension name="APIId" value="@(context.Api.Id)" />
        <dimension name="Subscription" value="@(context.Subscription?.Id ?? "none")" />
        <dimension name="Client IP" value="@(context.Request.IpAddress)" />
        <dimension name="Product ID" value="@(context.Product?.Id ?? "none")" />
    </azure-openai-emit-token-metric>
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

Что происходит по шагам:

1. set-backend-service
   APIM выбирает backend — ваш Azure AI Foundry endpoint.

2. authentication-managed-identity
   Gateway получает токен Entra ID для cognitiveservices.azure.com от имени своей system-assigned managed identity.
   API‑ключи нигде не хранятся и не передаются.

3. set-variable deployment-id
   Политика пытается определить имя модели/деплоймента:

   • сначала ищет в URL путь /openai/deployments/{name}/... и вытаскивает {name};
   • если не нашла, парсит JSON‑тело и берёт поле model (для /models/chat/completions, /models/embeddings, /anthropic/v1/messages);
   • если не удалось — пишет unknown.

   Это критично, потому что разные API‑поверхности Azure AI Foundry кодируют модель по‑разному.

4. azure-openai-emit-token-metric
   Политика отправляет в Azure Monitor и Application Insights метрики по токенам с нужными размерами (dimensions).
   Дальше вы можете строить графики, алерты и chargeback‑отчёты.

Поток запроса end‑to‑end

Схема работы на один запрос:

1. Клиент вызывает OpenAI‑совместимый endpoint APIM.
2. APIM применяет inbound‑политику:
   • выбирает backend Azure AI Foundry;
   • получает токен через managed identity;
   • вычисляет имя модели;
   • настраивает эмиссию метрик.
3. APIM проксирует запрос в Foundry и получает ответ.
4. APIM возвращает ответ клиенту без изменений.
5. Параллельно метрики по токенам улетают в Azure Monitor / Application Insights.

Клиентский код при этом не меняется: URL — это endpoint APIM, формат запросов — тот же, что и для Azure OpenAI‑совместимого API.

Почему важно уметь читать модель и из URL, и из тела

В Azure AI Foundry есть два основных типа поверхностей:

• OpenAI‑стиль: /openai/deployments/{name}/chat/completions — модель зашита в URL.
• Foundry / Anthropic‑стиль: /models/chat/completions, /models/embeddings, /anthropic/v1/messages — модель указывается в теле JSON как "model".

Если шлюз понимает только один вариант, часть трафика окажется «безымянной» и выпадет из аналитики по моделям. Dual‑shape‑разбор в политике решает это и даёт единый слой управления поверх всех клиентов.

Где живут метрики

Метрики, которые шлёт azure-openai-emit-token-metric, попадают в:

• Azure Monitor (namespace genai-tokens);
• Application Insights (таблица customMetrics).

Записываются:

• Total Tokens;
• Prompt Tokens;
• Completion Tokens;
• ModelName, ModelDeploymentName;
• APIId, Subscription, Client IP, Product ID.

Дальше это доступно через Kusto‑запросы.

Примеры запросов для аналитики и chargeback

Пер‑модельное потребление токенов с начала месяца:

customMetrics
| where name == "Total Tokens"
| where timestamp >= startofmonth(now())
| extend ModelName = tostring(customDimensions["ModelName"])
| summarize TotalTokens = sum(valueSum), Calls = sum(valueCount)
    by ModelName

Разбивка токенов по модели и подписке (для chargeback):

customMetrics
| where name == "Total Tokens"
| where timestamp >= startofmonth(now())
| extend Model = tostring(customDimensions["ModelName"]),
         Sub   = tostring(customDimensions["Subscription"])
| summarize Tokens = sum(value) by Model, Sub, name
| order by Tokens desc

Guardrail по дневному бюджету токенов

На этих же данных можно строить алерты. Пример запроса, который ищет модели, превысившие дневной лимит токенов за последние 24 часа:

// Rolling 24-hour token-budget guardrail — returns any model over its daily cap 

let dailyTokenBudget = 50000; // max Total Tokens per model in a rolling 24h window 
customMetrics | where name == "Total Tokens" 
| where timestamp > ago(24h) 
 extend Model = tostring(customDimensions["ModelName"])
 | summarize TokensLast24h = sum(value) by Model 
| where TokensLast24h > dailyTokenBudget 
| extend OverBudgetBy = TokensLast24h - dailyTokenBudget 
| project Model, TokensLast24h, DailyBudget = dailyTokenBudget, OverBudgetBy

Как использовать:

• оформить как scheduled log search alert в Azure Monitor;
• периодичность, например, раз в час за последние 24 часа;
• условие — если запрос вернул хотя бы одну строку;
• action group — email, Teams, webhook.

В результате команда получает сигнал об перерасходе в течение дня, а не после счёта от Azure.

Безопасный периметр: Front Door + WAF

APIM решает задачу управления токенами и доступом к моделям. Чтобы закрыть внешний периметр, Microsoft предлагает добавить Azure Front Door с WAF.

Что даёт этот слой:

• OWASP‑защита
  Включённый набор правил Microsoft_DefaultRuleSet_2.1 и Microsoft_BotManagerRuleSet_1.0:

  • блокирует типовые веб‑атаки из OWASP Top 10;
  • закрывает известные CVE;
  • режет вредоносных ботов.
    Режим — prevention, то есть подозрительные запросы получают 403 и не доходят до APIM.

• IP‑фильтрация и rate limiting
  Кастомные WAF‑правила позволяют:

  • пускать только доверенные диапазоны IP;
  • ограничивать частоту запросов на уровне edge.

• Глобальный edge и DDoS‑защита
  Front Door завершает TLS на периметре, даёт одну публичную точку входа и встроенную защиту от DDoS.

Вместе с landing zone для Foundry получается цепочка: Front Door + WAF → APIM (AI‑шлюз) → private endpoint Azure AI Foundry, Key Vault, Storage, AI Search.

Что это значит для вас

Для кого это вообще актуально

Этот паттерн нужен тем, у кого:

• уже есть несколько команд, которые используют Azure OpenAI‑совместимые API;
• в Azure AI Foundry крутится несколько моделей с разной ценой и лимитами (как в примере с gpt-4.1 на 500K TPM и gpt-5 на 50K TPM);
• затраты на AI растут, и нужен прозрачный контроль: кто, какую модель и как интенсивно использует.

Если у вас один pet‑проект на GPT‑4.1, APIM как AI‑шлюз будет избыточным. Как только в игру входят несколько продуктов, внешние партнёры или жёсткие бюджеты — эта архитектура начинает экономить деньги и нервы.

Практические сценарии

1. Внутренний chargeback между командами
   Вы можете:

   • завести отдельные APIM‑подписки (products/subscriptions) для разных команд или приложений;
   • собирать отчёты «модель → подписка → токены за месяц»;
   • переводить токены в деньги и распределять бюджет по подразделениям.

2. Контроль дорогих моделей (например, gpt-5)
   При разнице 500K TPM vs 50K TPM по gpt-4.1 и gpt-5 вы можете:

   • вешать более жёсткий дневной лимит по токенам на gpt-5;
   • отслеживать всплески использования gpt-5 в реальном времени;
   • в крайних случаях — отключать конкретные продукты или подписки.

3. Безопасный публичный AI‑endpoint
   Если вы даёте внешний API на базе Foundry:

   • Front Door + WAF режут мусор и атаки на периметре;
   • APIM авторизует клиентов, ведёт аналитику и лимиты;
   • Foundry и остальные сервисы живут в приватной сети.

4. Миграция с прямого доступа к Azure OpenAI на управляемый слой
   Клиенты продолжают ходить по OpenAI‑совместимому API, но уже к APIM. В ответе ничего не меняется.
   Вы получаете:

   • централизованную авторизацию и ключи доступа;
   • детальную телеметрию;
   • возможность постепенно вводить квоты, кэш, контент‑фильтры.

5. Планирование ёмкости и бюджетов
   На основе фактических токенов по моделям и продуктам вы можете:

   • оценивать, насколько хватает текущих TPM‑лимитов;
   • планировать апгрейды деплойментов в Foundry;
   • заранее пересматривать бюджеты, а не реагировать постфактум.

Где это не поможет

• Если вы не используете Azure AI Foundry и Azure OpenAI‑совместимый API, паттерн в таком виде неприменим.
• Если у вас один небольшой сервис с фиксированной моделью и понятным бюджетом, APIM + Front Door + WAF могут добавить лишнюю сложность.
• Если ваша компания не может использовать Azure из‑за юридических ограничений или санкций, доступ к этим сервисам будет проблемой. В ряде случаев для работы может потребоваться VPN и юридическая проверка.

Ограничения, о которых стоит помнить

• Всё завязано на инфраструктуру Azure: Azure Monitor, Application Insights, Front Door, WAF, private endpoints, managed identity.
• Управляемость зависит от качества Kusto‑запросов и настройки alert‑правил — их придётся сделать и поддерживать.
• Политики APIM нужно сопровождать как код: тестировать, версионировать, документировать.

Место на рынке

С чем это можно сравнить

По сути, Microsoft предлагает архитектурный слой управления AI‑API на базе уже существующего продукта APIM. Аналоги в других экосистемах:

• API‑шлюзы в AWS (API Gateway + WAF, с отдельными метриками и quota‑политиками);
• коммерческие AI‑шлюзы и observability‑платформы, которые считают токены и строят chargeback поверх LLM.

Отличительные особенности этого подхода внутри Azure‑экосистемы:

• Глубокая интеграция с Azure AI Foundry
  Политика azure-openai-emit-token-metric знает о токенах LLM и умеет их снимать без доработки клиентских приложений.

• Связка с Azure Monitor и Application Insights
  Не нужно подключать внешний observability‑стек — все метрики и алерты живут в стандартных инструментах Azure.

• Единый security‑контур
  Front Door + WAF + private endpoints + managed identity + Azure Policy образуют законченную историю для enterprise‑компаний, которые и так живут в Azure Landing Zone.

Прямых численных сравнений с альтернативами (скорость, latency, стоимость против других AI‑шлюзов) в материале нет. Для оценки придётся ориентироваться на ваши внутренние требования по безопасности, управлению и уже выбранный стек облака.

Как запустить

Ниже — сводный чек‑лист по запуску паттерна на базе примеров из материала.

1. Подготовить Azure AI Foundry

1. Создайте ресурс Azure AI Foundry.
2. Разверните нужные модели, например:
   • gpt-4.1 с лимитом 500K TPM;
   • gpt-5 с лимитом 50K TPM.
3. Убедитесь, что endpoint Foundry доступен из вашей сети APIM (через private endpoint, если вы используете закрытую схему).

2. Настроить Azure API Management как AI‑шлюз

1. Создайте или выберите существующий инстанс APIM.
2. Импортируйте API Azure AI Foundry в APIM (OpenAI‑совместимый или Foundry‑стиль).
3. На уровне API или операции замените базовую inbound‑политику на расширенную:

<policies>
  <inbound>
    <base />
    <set-backend-service backend-id="foundry-apim-si-ai-endpoint" />
    <authentication-managed-identity resource="https://cognitiveservices.azure.com" />

    <set-variable name="deployment-id" value="@{
        var path = context.Request.Url.Path ?? "";
        var m = System.Text.RegularExpressions.Regex.Match(path, "/deployments/([^/?]+)");
        if (m.Success) { return m.Groups[1].Value; }
        try {
            var body = context.Request.Body?.As<JObject>(preserveContent: true);
            var model = body?["model"];
            if (model != null && !string.IsNullOrEmpty(model.ToString())) {
                return model.ToString();
            }
        } catch (Exception) { }
        return "unknown";
    }" />

    <azure-openai-emit-token-metric namespace="genai-tokens">
        <dimension name="ModelDeploymentName" value="@((string)context.Variables["deployment-id"])" />
        <dimension name="ModelName" value="@((string)context.Variables["deployment-id"])" />
        <dimension name="APIId" value="@(context.Api.Id)" />
        <dimension name="Subscription" value="@(context.Subscription?.Id ?? "none")" />
        <dimension name="Client IP" value="@(context.Request.IpAddress)" />
        <dimension name="Product ID" value="@(context.Product?.Id ?? "none")" />
    </azure-openai-emit-token-metric>
  </inbound>
  <backend>
    <base />
  </backend>
  <outbound>
    <base />
  </outbound>
  <on-error>
    <base />
  </on-error>
</policies>

4. Включите system-assigned managed identity для APIM и выдайте ей доступ к Azure AI Foundry.

3. Подключить телеметрию и алерты

1. Включите Diagnostic Settings для APIM и Foundry, чтобы слать логи и метрики в Log Analytics / Application Insights.
2. Убедитесь, что в customMetrics появляются записи с именем Total Tokens и нужными dimensions.
3. Создайте Saved Queries:
   • пер‑модельное потребление за месяц;
   • разбивка по подпискам для chargeback.
4. Создайте log search alert для дневного токен‑лимита на базе запроса:

let dailyTokenBudget = 50000; // max Total Tokens per model in a rolling 24h window 
customMetrics | where name == "Total Tokens" 
| where timestamp > ago(24h) 
 extend Model = tostring(customDimensions["ModelName"])
 | summarize TokensLast24h = sum(value) by Model 
| where TokensLast24h > dailyTokenBudget 
| extend OverBudgetBy = TokensLast24h - dailyTokenBudget 
| project Model, TokensLast24h, DailyBudget = dailyTokenBudget, OverBudgetBy

5. Привяжите alert к action group с нужными каналами уведомлений.

4. Закрыть периметр Front Door + WAF

1. Создайте Azure Front Door и укажите backend — ваш APIM endpoint.
2. Настройте WAF‑политику:
   • включите Microsoft_DefaultRuleSet_2.1 и Microsoft_BotManagerRuleSet_1.0 в режиме prevention;
   • добавьте правила IP‑фильтрации и rate limiting при необходимости.
3. Подключите TLS‑сертификат из Azure Key Vault.
4. Привяжите Front Door к публичному домену, который будут использовать клиенты.

После этого ваш путь запроса выглядит так: клиент → Front Door + WAF → APIM (AI‑шлюз с учётом токенов) → Azure AI Foundry по private endpoint.

---

Итог: Microsoft предлагает не переписывать все AI‑приложения, а добавить один управляемый слой перед Azure AI Foundry. APIM превращается в точку, где вы видите, кто и сколько токенов тратит на каждую модель, а Front Door с WAF закрывает внешний периметр. Дальше поверх этого можно наращивать квоты, кэш, контент‑безопасность и устойчивость — без ломки клиентского кода.

---

Читайте также

• Apple SpeechAnalyzer обошёл Whisper на Mac и iPhone: тесты, цифры и кому это реально нужно
• Amazon SageMaker AI научился сам подбирать инфраструктуру для генеративных моделей — теперь через UI
• Google обучила медицинский ИИ на триллионе минут данных с Fitbit и Pixel Watch