Azure AI Gateway: Foundry und MCP mit APIM einrichten

Unterstützt vonAnzeige

Eine Anwendung ruft direkt ein Foundry-Modell auf. Eine andere hat ihren eigenen API-Key. Ein dritter Agent verbindet sich mit einem MCP-Server. Alles funktioniert – aber damit entstehen auch weitere Stellen für Zugriffskontrollen, Limits und Monitoring.

Ein Azure AI Gateway kann diesen Aufrufen einen gemeinsamen Einstieg geben. In dieser Anleitung schaue ich mir mit Azure API Management die Foundry-Anbindung, MCP-Tools und die neuere Gateway-Oberfläche an. Dabei trenne ich die Konfiguration im Portal von den Dingen, die ein echter Client-Test noch nachweisen muss.

Der passende Video-Walkthrough

Wo das Azure AI Gateway sitzt#

Die AI-Gateway-Funktionen gehören zu Azure API Management. Sie ersetzen weder das Modell-Deployment noch das Tool-Backend. Microsoft beschreibt in seiner AI-Gateway-Übersicht unter anderem Routing, Token-Kontrollen, Caching und Monitoring. Die Verfügbarkeit hängt von Funktion und Service-Tier ab.

Das Gateway liegt zwischen den Aufrufern und ihren Diensten. Dort kannst du gemeinsame Policies anwenden und Requests beobachten. Das Backend braucht trotzdem eigene Zugriffskontrollen. Der Weg über ein Gateway sollte einem Agenten nicht pauschal Zugriff auf alle dahinterliegenden Tools und Daten geben.

Wenn du die Governance-Grenze genauer betrachten möchtest, findest du sie in meinem bisherigen Guide zu API Management und MCP als Kontrollschicht. Dieser Artikel folgt der Modell- und MCP-Konfiguration aus meiner neueren Aufnahme.

Den Service-Tier vor den Portal-Schritten auswählen#

Starte mit einer Entwicklungsressource, fiktiven Daten und einem Modell-Deployment, das du sicher testen kannst. Du brauchst Rechte für die Konfiguration von API Management und der Foundry-Ressource sowie passenden Zugriff für die Backend-Identität des Gateways.

Wähle den Tier nicht nur nach dem günstigsten Einstiegspreis. Die hier gezeigte MCP-Anbindung steht im Consumption-Tier nicht zur Verfügung. Prüfe die unterstützten Tiers und Einschränkungen in Microsofts Anleitung für bestehende MCP-Server.

Developer ist für Entwicklung und Tests gedacht und hat kein Produktions-SLA. Vergleiche für eine produktive Architektur die Funktionen, Kapazitäten und Netzwerkanforderungen in den APIM-Preis- und Tier-Informationen.

Ich nenne hier bewusst keinen festen Monatsbetrag. Ein Preis aus einer Demo hängt von Region, Währung, Tier und damaligem Preisstand ab. Rechne neben dem Gateway auch Modellnutzung und zusätzliche Dienste wie Cache oder Monitoring ein. Ein Budgetalarm hilft, ist aber kein harter Ausgabenstopp.

Foundry-Modelle importieren und die Backend-Identität prüfen#

In der Aufnahme schaue ich zuerst in die klassische API-Management-Oberfläche und danach in die neuere, als Preview gekennzeichnete AI-Gateway-Oberfläche. Der Import-Assistent findet Foundry-Deployments und bietet eine Auswahl für die Authentifizierung.

Echter Ausschnitt aus der Aufnahme: der Foundry-Import-Assistent, keine nachgebaute Oberfläche.

Die Auswahl Managed Identity im Assistenten ist noch keine abgeschlossene Zugriffsprüfung. Prüfe, ob die vorgesehene Identität die benötigten Rechte auf dem richtigen Backend besitzt. Sende danach einen Request durch das Gateway. Prüfe auch, ob Aufrufer das Gateway weiterhin mit direkten Requests an den Modell-Endpunkt umgehen können.

Ich würde drei Werte nebeneinander dokumentieren: den Endpunkt für die Anwendung, die Gateway-Identität und das Backend-Deployment. Das macht die Fehlersuche bei einem späteren Request deutlich einfacher.

Modell-Aliasse nutzen, ohne automatisches Failover anzunehmen#

Die neuere Oberfläche zeigt auch Modell-Aliasse. Ein stabiler Name auf der Client-Seite kann einen Backend-Wechsel erleichtern, ohne jede Anwendung anzupassen.

Ein Alias beweist aber weder automatisches Failover noch Lastverteilung oder identisches Modellverhalten. In der Aufnahme erstelle und prüfe ich einen Alias. Einen Backend-Ausfall mit erfolgreichem Fallback zeige ich nicht.

Vergleiche vor einem echten Wechsel Antworten, Tool-Aufrufe, Latenz und Token-Nutzung anhand repräsentativer Aufgaben. Ändere die Zuordnung danach kontrolliert und behalte eine bekannte funktionierende Zuordnung für einen Rollback. Ein technisch gültiger Response reicht nicht, wenn das neue Modell den Ablauf kaputtmacht.

Zwei unterschiedliche Wege für MCP mit API Management#

Einen bestehenden MCP-Server anbinden#

Hier bleibt der MCP-Server das Backend und API Management wird zum Einstiegspunkt. Du musst die Authentifizierung in beide Richtungen betrachten: vom Client zum Gateway und vom Gateway zum MCP-Server. Microsoft erklärt diese Trennung in den Sicherheitshinweisen für MCP.

Der Verbindungsversuch in meiner Aufnahme wird nicht erfolgreich abgeschlossen. Deshalb stelle ich ihn nicht als funktionierende Ende-zu-Ende-Integration dar. Ein Portaleintrag oder eine Auswahl im Katalog beweist noch keine Erreichbarkeit des Backends.

Ausgewählte REST-Operationen als MCP-Tools bereitstellen#

Der andere Weg nutzt eine bestehende REST-API. In der Demo wähle ich Operationen der Echo API aus und stelle sie als Tools bereit. Die entstandene Liste zeigt, welche Schnittstelle angeboten wird.

Starte mit einer kleinen Read-only-Schnittstelle. Prüfe Namen, Beschreibungen, Eingabeschemas und Backend-Berechtigungen, bevor du Schreibaktionen ergänzt. Die REST-zu-MCP-Dokumentation beschreibt das unterstützte Setup.

Die Aufnahme zeigt die Tool-Auswahl, keinen abgeschlossenen MCP-Client-Aufruf. Teste als Nächstes ein erlaubtes Tool und eine Operation ausserhalb des vorgesehenen Umfangs. Eine kleinere Tool-Liste allein schliesst nicht automatisch alle anderen Zugriffswege zur REST-API.

Request-Limits, Token-Limits und Kosten-Policies unterscheiden#

Die Gateway-Oberfläche bringt verschiedene Kontrollen zusammen. Sie messen trotzdem unterschiedliche Dinge:

Kontrolle	Welche Frage beantwortet sie?	Was ich prüfen würde
Request Rate Limit	Wie viele Aufrufe darf dieser Client in einem Zeitraum senden?	Zählerschlüssel und Reaktion beim Überschreiten
Token-Limit	Wie viel Modellnutzung ist erlaubt?	Token-Zählung, unterstütztes Backend und Streaming-Verhalten
Kostenbezogene Policy	Welche Nutzung berechnet diese Policy?	Preisannahmen, Geltungsbereich und Zurücksetzen des Zählers

Keine davon ist automatisch ein harter Ausgabendeckel für das gesamte Azure-Abonnement. Ein gemeinsamer Zähler kann ausserdem dazu führen, dass eine Anwendung das Kontingent einer anderen verbraucht. Lege die Grenze bewusst fest und teste mit zwei unterschiedlichen Aufrufern.

Caching und Content Safety separat testen#

Im Portal schaue ich mir Semantic Caching und Content Safety an. Vor dem Erstellen der Konfiguration werden beide Optionen in der Aufnahme deaktiviert. Diese Folge zeigt daher weder einen Cache-Hit noch eine blockierte unsichere Antwort.

Lege vor dem Aktivieren eines Caches fest, was gespeichert werden darf, welche Identitäten Einträge teilen dürfen und wann Änderungen alte Ergebnisse ungültig machen. Ähnliche Prompts unterschiedlicher Nutzer können andere Berechtigungskontexte haben. Ein Cache, der diese Grenze ignoriert, kann ein ansonsten sorgfältiges Design aushebeln.

Teste bei Content Safety die konfigurierten Kategorien und Schwellwerte mit kontrollierten Eingaben. Die Ergebnisse belegen eine einzelne Kontrolle. Sie beweisen nicht, dass ein Agent keine Daten preisgeben oder unberechtigte Aktionen ausführen kann.

Meine Abnahmetests für einen Gateway-Piloten#

Diese Tests würde ich als Nächstes ausführen. Es sind Empfehlungen, keine Ergebnisse aus der Aufnahme:

1. Einen erlaubten Modell-Request durch das Gateway senden und den zugehörigen Monitoring-Eintrag finden.
2. Einen Request ohne oder mit ungültigen Zugangsdaten senden und die Abweisung im gewählten Authentifizierungskonzept prüfen.
3. Eine gültige Identität ohne Zugriff auf die vorgesehene Ressource verwenden und prüfen, dass der Request das Backend nicht erreicht.
4. Ein konfiguriertes Request- oder Token-Limit überschreiten und Abweisung, Zeitraum und Zurücksetzen des Zählers nachvollziehen.
5. Mit einem zweiten Aufrufer prüfen, ob dessen Kontingent getrennt oder bewusst geteilt ist.
6. Ein ausgewähltes MCP-Tool aufrufen und danach eine nicht freigegebene Operation sowie einen direkten Backend-Aufruf versuchen.
7. Das Backend in einer sicheren Testumgebung unerreichbar machen und das tatsächliche Verhalten prüfen. Failover erst behaupten, wenn ein konfigurierter Fallback funktioniert.
8. Traces und Logs auf Prompts, Zugangsdaten und sensible Ausgaben prüfen, bevor Aufbewahrung oder Zugriffsrechte erweitert werden.

Notiere für jeden Test Policy-Version, Zeitpunkt, Aufrufer und Korrelationskennung. Das hilft mehr als ein Screenshot eines erfolgreich abgeschlossenen Assistenten.

Häufige Fragen#

Ist Azure AI Gateway ein separates Produkt neben API Management?#

Hier bezeichnet es die AI-Gateway-Funktionen und die Oberfläche innerhalb von Azure API Management. Prüfe weiterhin, welche Funktionen dein gewählter Tier unterstützt.

Brauche ich für jede Agenten-Demo ein Gateway?#

Nein. Für ein kleines isoliertes Experiment kann eine direkte Modellverbindung sinnvoll sein. Ein Gateway hilft eher, wenn mehrere Anwendungen gemeinsame Zugriffsregeln, Nutzungskontrollen und klare Betriebsverantwortung brauchen.

Wird ein Modell-Deployment durch den Import privat?#

Nein. Der Import beweist nicht, dass öffentlicher Zugriff oder direkte Aufrufe blockiert sind. Prüfe Netzwerk und Berechtigungen für Gateway und Backend separat.

Für die Plattform rund um das Gateway hilft mein Foundry-Sicherheitsguide: Netzwerk, Identität und Guardrails bleiben getrennte Kontrollen. Bei einem extern laufenden Agenten erklärt der Agent-365-Registrierungsrundgang den Registereintrag. Er ersetzt kein Enforcement im Azure AI Gateway.

Was ich daraus mitnehme#

Ich würde mit einem Modell, einer kleinen MCP-Tool-Schnittstelle und wenigen messbaren Tests starten. Wenn der Aufrufpfad verstanden ist, kannst du erweitern. Der Nutzen eines gemeinsamen Gateways liegt nicht in der Anzahl der Dienste im Portal, sondern in einer Grenze für Requests, die du erklären, testen und betreiben kannst.