Microsoft Foundry: Reicht Deploy as Web App, oder brauchst du einen Backend-Proxy?

Teams feiern immer noch, wenn der Container auf dem richtigen Port lauscht. Bei Agent-Webapps mit Foundry dahinter ist das die leichte Hälfte. Die schwere Hälfte ist: als wer die App läuft, wie OBO fließt und wie der Egress Foundry, Search und Storage erreicht, ohne dass die VNet-Geschichte zur Folklore wird.

Deploye das Muster zuerst als Identität und Netzwerk. Hostname und Node-Version sind Grundausstattung.

Abbildung 1. Zuerst Identität und Egress. Eine Foundry-Webapp ist ein Design für Identität und Egress, das zufällig einen Container ausführt. Den Hostnamen zu feiern ist kein Nachweis für Staging.

Kontext und Rahmenbedingung

Ein häufiges Muster bei Container-Frontends in App Service vor Foundry: Demos laufen auf dem Laptop, und Staging scheitert an DNS und Identität. Die Prompts waren in Ordnung. Die Managed Identity und das Private DNS nicht.

Nutze ACR, App Insights und die Entra App Registrations wieder, statt eine zweite Identitätsebene zu erfinden. Regionale VNet-Integration ist für den Egress da. Öffentlicher Ingress ist eine eigene Produktentscheidung. On-behalf-of funktioniert nur, wenn die App als die richtige User-assigned Identity mit den richtigen API-Berechtigungen läuft. Private DNS und eine Subnetzplanung schlagen die Zuversicht von "auf meinem Laptop läuft es".

Abbildung 2 zeigt die Learn-Seite zur regionalen VNet-Integration. Die Integration verändert Namensauflösung und ausgehende Pfade stärker als Hostnamen.

Abbildung 2. Regionale VNet-Integration gibt der App einen Weg nach draußen zu Private Endpoints. Sie entscheidet für sich allein nicht, ob Nutzer die App aus dem öffentlichen Internet erreichen. Quelle: Microsoft Learn: App Service VNet integration.

Design

1. Nutze die Identitätsebene wieder

Eine klare Geschichte für die Entra App Registration der API, eine User-assigned Managed Identity für Azure-Ressourcen, durchgängig dieselben App Insights. Leg keine parallelen App Registrations pro Umgebung ohne Übersicht an. Nutze ACR wieder, damit die Herkunft der Images langweilig bleibt. Neue Identitätsobjekte brauchen Verantwortliche und einen Plan für die Rotation.

2. Trenne Produktentscheidungen zum Ingress von der Mechanik des Egress

VNet-Integration gibt der App einen Weg nach draußen zu Private Endpoints. Sie entscheidet für sich allein nicht, ob Nutzer die App aus dem öffentlichen Internet, über Front Door oder über privaten Zugriff erreichen. Schreib das im Design als zwei Abschnitte. Wer beides vermischt, produziert Diagramme, die niemand umsetzen kann. Abbildung 3 zeigt die Trennung.

Abbildung 3. Haltung zum Ingress gegenüber der Mechanik des Egress. Öffentlicher Ingress plus privater Egress ist eine gültige Entscheidung für eine Stage. Eine einzige Wolke mit der Aufschrift "privat" ist kein Design.

3. OBO braucht die richtige Laufzeitidentität und die richtigen Berechtigungen

OBO-Flows ohne Secrets scheitern auf verwirrende Weise, wenn der App-Identität die API-Berechtigungen fehlen oder die Token-Audience falsch ist. Prüfe Identität und Consent, bevor du Prompts feinjustierst. "Das Modell ist langsam" ist ein häufiges falsches Etikett für Authentifizierungsfehler.

4. Plane Subnetze und Private DNS bewusst

Private Endpoints für Foundry, Cognitive Search und Storage brauchen ein DNS, das das Integrationssubnetz des App Service auch tatsächlich nutzt. Fehlende Private-DNS-Zonen zeigen sich als sporadische Plattformfehler, die wie SDK-Bugs aussehen. Prüf die Namensauflösung per Checkliste von der App nach außen.

5. Deployment-Checkliste: Identität und DNS vor Prompt-Qualität

Mach Releases abhängig von: zugewiesener Identität, vorhandenen Rollenzuweisungen, funktionierender Auflösung im Private DNS, geprüftem Egress zu den Abhängigkeiten und App Insights, die Daten empfangen. Prompt-Evals kommen, wenn die Ebene ehrlich ist. Sonst feilst du an Formulierungen, während das Netzwerk Aufrufe verliert. Abbildung 4 zeigt die Reihenfolge der Nachweise.

Abbildung 4. Reihenfolge der Nachweise. DNS, Rollen und OBO vor den Prompt-Suites. Dreh die Reihenfolge um, und du bekommst schöne Evals auf einer Ebene, die die Abhängigkeiten in Produktion immer noch nicht erreicht.

6. Container sind portabel, die Ebene nicht

Dasselbe Image kann in einem Labor ohne Private Endpoints laufen. Das beweist keine MVP-Reife. Gleichwertige Umgebungen bei Identität und Netzwerk zählen mehr als gleiche Node-Patchstände.

Wiederverwenden, ohne das Falsche einzufrieren

ACR und App Insights wiederzuverwenden heißt nicht, dass jede Stage dieselben Secrets oder dieselben Private Endpoints teilt. Nutze das Muster und die Ressourcentypen wieder. Isoliere die Instanzen. Schreib die Matrix auf: welche Registrierungen, welche Identitäten, welche DNS-Zonen pro Stage. Die Matrix ist langweilig. Der Ausfall durch eine fehlende Zeile ist es nicht.

Reihenfolge der Nachweise im Staging

Weise die DNS-Auflösung zu Private Endpoints von der App aus nach. Weise die Rollenzuweisungen der Managed Identity auf Foundry, Search und Storage nach. Weise OBO mit einem echten Nutzerpfad nach. Erst dann lass die Prompt-Suites laufen. Wer diese Reihenfolge umdreht, bekommt schöne Eval-Tabellen auf einer Ebene, die den Abhängigkeitsgraphen in Produktion immer noch nicht erreicht. Identität und Egress sind der release train; die Prompts fahren im Personenwagen mit.

Wenn Staging "vorübergehend" noch öffentliche Foundry-Endpunkte nutzt, halte diese Schuld im ADR mit einer verantwortlichen Person fest. Vorübergehende Netzwerkausnahmen überleben gern bis zum ersten Security-Review.

Leg pro Stage ein einziges Netzwerkdiagramm neben die Checkliste ins Repo, damit das Onboarding nicht von einem Whiteboard-Foto abhängt.

Häufige Fehler

Fixierung auf den Hostnamen. TLS und DNS für den Hostnamen erledigt, Egress zu Foundry ignoriert.

Zweite Identitätsebene. Doppelte App Registrations und widersprüchliche Redirect-URIs.

OBO mit der falschen MI. Tokens werden ausgestellt, Aufrufe an Ressourcen liefern 401/403.

"Läuft auf dem Laptop" als Nachweis für Staging. Öffentliche Foundry-Endpunkte verdecken Lücken im Private DNS.

Prompt-Tuning während Ausfällen. Verschwendete Zyklen auf der falschen Ebene.

Öffentlicher Ingress als Dauerannahme. Das Produkt will später privat; ein Redesign ist teuer.

So übernehmen oder anpassen

So übernehmen

• Container in App Service mit regionaler VNet-Integration für privaten Egress.
• User-assigned Managed Identity plus benannte Entra App Registrations; keine doppelten Ebenen ohne Übersicht.
• OBO ohne Secrets mit geprüften API-Berechtigungen.
• Private Endpoints und Private DNS für Foundry, Search und Storage, wie es die Stage verlangt.
• Haltung zum Ingress (öffentlich, vorgeschaltet oder privat) pro Stage ausdrücklich entschieden.
• Die Release-Checkliste prüft Identität und DNS vor der Arbeit an Prompts und Evals.

Vor dem Einsatz anpassen

User-assigned Identities und Private Endpoints kosten Einrichtungszeit und Plattformwissen. Dafür verschwinden wild verteilte Secrets und öffentlich erreichbare Abhängigkeiten. Strenge Checklisten verlangsamen das erste Deployment und beschleunigen jeden Vorfall danach. Entra-Apps über Stages hinweg wiederzuverwenden verlangt saubere Pflege von Redirects und Audiences; Duplizieren wirkt einfacher, bis sich die Consent-Bildschirme vermehren. VNet-Integration schränkt die Skalierungsoptionen ein; dokumentiere sie, statt sie in einer Feuerwehrübung zu entdecken.

Wichtigste Quellen: App Service VNet integration, managed identities und die Netzwerk-Leitfäden zu Microsoft Foundry auf Microsoft Learn.

Überlegst du, statt dieses Backends Foundry Hosted Agents zu nutzen? Lies zuerst Foundry Hosted Agents brauchen trotzdem eine Front Door: Hosted Agents verlagern die Laufzeit, nicht die Anmeldung, die Rollen oder die Zuordnung von Sessions pro Nutzer.

Deploye Identität und Egress als das Produkt. Dann justiere den Node-Host. Bei der Demo ist die Reihenfolge umgekehrt, in Produktion nicht.