Die AgentinNICOLENDERS.COM
DEEN
← Depeschen

NachschlagewerkDIE AGENTENFÜHRERINDIE ARCHIVARIN

Europa kostet neun Prozent

Veröffentlicht

Ein Sortiertisch aus Eiche mit drei unterschiedlich großen Messingfächern voller gleicher grauer Pakete, ein weiteres Paket liegt daneben auf der blanken Tischplatte.KI-generiert
Microsoft Foundry Model Deployment Pricing UpdateMicrosoft Community Hub

Neun Prozent. So viel Aufschlag kostet dich ab dem 1. September 2026 die Entscheidung, dass deine Inferenz in Europa verarbeitet wird, gemessen an derselben Anfrage über Global Standard. Ich habe die Zahl zuerst für die Nachricht gehalten. Ist sie nicht. Die Nachricht ist, dass Datenresidenz in Microsoft Foundry damit endgültig eine Position in deinem Kostenmodell geworden ist, und dass es sie für einen Teil deines Modellkatalogs überhaupt nicht zu kaufen gibt.

Drei Preisniveaus, ein Stichtag

Microsoft hat die Preise für Deployments angepasst, die den Verarbeitungsort einschränken. Global bleibt die Basis und bleibt unverändert. Alles, was enger gefasst ist, kostet mehr, und die neue APAC-Zone startet direkt oben.

Deployment-Typ

Wo verarbeitet wird

Preis gegenüber Global ab 01.09.2026

Global Standard

in jeder Azure-Region, in der das Modell deployed ist

Basis, unverändert

Data Zone Standard, EU

irgendwo innerhalb der EU-Zone

plus 9 Prozent

Data Zone Standard, APAC

irgendwo innerhalb der APAC-Zone, neu

plus 20 Prozent

Standard, also Regional außerhalb der USA

genau in der Region deines Deployments

plus 7 bis 16 Prozent

Zwei Dinge, die in der Ankündigung nicht betont werden und für die Planung mehr wiegen als die Prozentsätze.

Erstens betrifft der Aufschlag nur die Verarbeitung, nicht die Ablage. Ruhende Daten bleiben bei allen Deployment-Typen in der zugeordneten Azure-Geografie. Was du kaufst, ist die Zusage über den Weg der Anfrage, nicht über den Speicherort.

Zweitens hängt am Deployment-Typ auch deine Quota. Global-Standard-Deployments desselben Modells teilen sich innerhalb einer Subscription einen Pool über alle Regionen, Data-Zone-Deployments einen Pool pro Zone. Wenn du von Global auf EU wechselst, wechselst du also nicht nur den Tarif, sondern auch den Topf, aus dem du dich bedienst.

Datenzone ist nicht EU Data Boundary

Diese beiden Begriffe werden in Ausschreibungen synonym benutzt, und das geht regelmäßig schief.

Die Data Zone ist eine technische Eigenschaft eines einzelnen Deployments in Foundry. Du wählst sie beim Anlegen, sie gilt für genau dieses Deployment, und ab September hat sie einen Preis.

Die EU Data Boundary ist eine vertragliche Zusage über eine Reihe von Diensten hinweg. Sie hat einen anderen Geltungsbereich, eine eigene Ausnahmeliste und ein eigenes Kleingedrucktes. Beides zusammen ergibt keine gemeinsame Aussage über deine Architektur, sondern zwei getrennte Prüfungen.

Der Satz, den du in dein Prüfraster übernehmen solltest: Data Zone regelt, wo eine Anfrage verarbeitet wird. Die EU Data Boundary regelt, worauf Microsoft sich vertraglich festlegt. Ein Deployment kann in der EU-Zone laufen und trotzdem Modelle aufrufen, die aus dem Geltungsbereich der EU Data Boundary ausgenommen sind.

Die Ausschlussliste steht im Modellkatalog

Hier wird es konkret, und hier liegt der Teil, den du nicht durch Bezahlen lösen kannst.

Claude gibt es in Foundry in zwei Varianten, einmal auf Anthropic-Infrastruktur außerhalb von Azure und einmal Ende zu Ende auf Azure, letztere GA. Data Zone Standard existiert dafür ausschließlich als US-Zone und nur für die Azure-gehosteten claude-opus-5, claude-opus-4-8 und claude-sonnet-5. Eine EU-Zone gibt es für Claude nicht. Alles andere läuft Global Standard.

Dazu kommen zwei Punkte, die selten zusammen genannt werden: Claude wird in Foundry über eine Azure-Marketplace-Subscription in Claude Consumption Units abgerechnet und läuft unter den Produktbedingungen als Non-Microsoft Product. Und Foundry liefert für Claude-Deployments kein eingebautes Content Filtering. Wenn du eine Filterschicht brauchst, konfigurierst du sie selbst.

Für die Praxis heißt das: Bei Modellen, die als Partner-Modelle im Katalog liegen, fällt die Residenzentscheidung schon bei der Modellauswahl und nicht erst beim Deployment. Lies die Zeile im Katalog, bevor du die Architektur zeichnest, nicht danach.

Auf der Seat-Seite gibt es keinen Deployment-Typ

In der Depesche zum AI-Gateway war die These, dass ein Gateway nur den Verkehr sieht, der über API-Keys läuft, und dass Seats außen vor bleiben. Beim Verarbeitungsort ist es dieselbe Trennung, nur mit anderen Folgen.

In Copilot, Copilot Studio und den Agent-Modi in Word, Excel und PowerPoint wählst du keinen Deployment-Typ. Du bekommst stattdessen Schalter im Admin Center, und zwei davon gehören auf deine Liste.

Der eine heißt sinngemäß "AI providers operating as Microsoft subprocessors" und steuert die Nutzung von Anthropic-Modellen in den Microsoft-365-Apps. Die Verarbeitung findet dabei außerhalb der EU Data Boundary statt, Anthropic tritt als Microsoft-Subprozessor unter Produktbedingungen und DPA auf. Für Tenants in EU, EFTA und UK, die nach dem 25. März 2026 angelegt wurden, ist der Schalter standardmäßig an. Bei älteren Tenants steht die Voreinstellung im Message Center.

Der andere ist das Flex Routing, mit dem Inferenz bei Lastspitzen die EU Data Boundary verlassen kann. In der Power Platform taucht dafür eine eigene Checkbox auf, sobald die Umgebung in der EU Data Boundary liegt.

Beide Schalter kosten dich nichts und ändern trotzdem die Antwort auf die Frage, die dein Datenschutzbeauftragter stellt. Das ist der Unterschied zur Foundry-Seite: Dort kaufst du Residenz, hier verwaltest du sie.

Was ich nicht beurteilen kann

Die vier Prozentsätze stammen aus der Ankündigung von Microsoft. Die Preisseite selbst rendert die Tarife pro Modell und Region erst im Portal, ich konnte die Werte deshalb nicht einzeln gegenprüfen. Wenn du budgetierst, zieh die Zahlen aus dem Pricing Calculator für deine konkreten Modelle und nicht aus diesem Text.

Ob der Aufschlag auch für Provisioned Throughput gilt, ist mir nicht klar. Reservations werden getrennt nach Global, Data Zone und Regional gekauft und sind untereinander nicht austauschbar, das spricht für getrennte Tarife. Ob laufende Reservations Bestandsschutz haben, habe ich nicht belegt gefunden.

Offen ist außerdem, ob die Anpassung Modelle erreicht, die wie Claude über den Marketplace in eigenen Verrechnungseinheiten abgerechnet werden. Da es dort ohnehin keine EU-Zone gibt, ist die Frage für europäische Workloads eher akademisch.

Meine Empfehlung

Entscheide den Deployment-Typ pro Workload, nicht pro Tenant. Eine Tenant-weite Regel "alles EU" klingt sauber und zahlt neun Prozent auf Anfragen, die diese Zusage nie gebraucht hätten.

Bevor der Stichtag durchläuft, brauchst du zwei Listen. Die erste: alle Deployments, die heute auf Data Zone oder auf Regional außerhalb der USA laufen. Das ist genau die Menge, deren Rechnung im September steigt. Die zweite: pro Workload eine Zeile mit Modell, Deployment-Typ und Begründung. Wo die Begründung leer bleibt, ist Global richtig.

Und dann die zwei Schalter im Admin Center, mit Datum und Verantwortlichem. Das ist keine technische Maßnahme, sondern die wichtigste.

Ich halte die Änderung für ehrlich. Ein regionaler Pool mit hoher Verfügbarkeit kostet mehr als ein globaler, und ein Preisschild zwingt zu der Entscheidung, die vorher gern unter "machen wir sicherheitshalber" verschwunden ist. Mein Vorbehalt bleibt trotzdem: Ein Aufschlag, den du bezahlen kannst, ist harmlos gegenüber einer Zone, die es für dein Modell nicht gibt. Prüf die Verfügbarkeit zuerst, den Preis danach.

Quellen

Microsoft Foundry · Governance & Compliance