Das Chargeback-Design entscheidet ein Azure-Monitor-Limit, keine Buchhaltungspräferenz: Eine Custom Metric erlaubt 10 Dimension-Keys, API Management verbraucht bereits 5 davon für Defaults, und die aktiven time series, die eine Policy produziert, sind das Produkt der eindeutigen Werte jeder Dimension, die man hinzufügt. Drei Dimensionen mit je zehn Werten sind tausend time series, gegen eine Obergrenze von 50.000 aktiven time series pro Region und Subscription in einem Zwölf-Stunden-Fenster. Wer eine User-ID oder eine Request-ID auf diese Metrik legt, macht die Telemetrie der Plattform selbst zum Ausfall. Teil 4 hat die drei Request-Pfade abgeschlossen. Dieser Teil beantwortet die Frage, für die die ganze Serie existiert: Welches Team hat was ausgegeben, und wie hindert das Gateway eines davon daran, die Quota aller anderen zu verbrauchen.

Zwei Credentials, zwei verschiedene Aufgaben

API Management bietet zwei Mechanismen, die routinemäßig als Alternativen behandelt werden, obwohl sie Komplemente sind.

Ein subscription key identifiziert einen Consumer für Products, Quotas und Analytics. Er kommt im Ocp-Apim-Subscription-Key-Header an, oder in einem subscription-key-Query-Parameter, der nur geprüft wird, wenn der Header fehlt, und beide Namen sind pro API konfigurierbar. Keys werden paarweise ausgegeben, damit eine Anwendung von Key A auf Key B wechseln und A mit minimaler Unterbrechung neu generieren kann.

Zwei Eigenschaften von Keys muss man einplanen, statt sie wegzudefinieren. Erstens: API Management hat keinen eingebauten Lifecycle für subscription keys: keine Ablaufdaten, keine automatische Rotation. Rotation ist ein Workflow, den man selbst baut, mit Azure PowerShell oder den SDKs, und wer ihn nicht baut, dessen Keys leben für immer. Zweitens wird der Key per Default an das Backend weitergereicht, wo er in Backend-Monitoring-Logs landen kann und überall dort, wohin diese Logs verschickt werden. Ein set-header am Ende der Inbound-Section, der ihn entfernt, ist ein Zwei-Zeilen-Fix für einen Credential-in-Logs-Befund, den andernfalls ein Auditor entdeckt.

Ein JWT von Microsoft Entra ID beantwortet eine andere Frage: Ist dieser Aufrufer gerade autorisiert. Es läuft nativ ab, lässt sich zentral widerrufen und trägt claims. Anwendungen beziehen eines über den OAuth2 Client Credentials Flow, und das Gateway validiert es, bevor irgendetwas anderes läuft:

<validate-jwt header-name="Authorization" require-scheme="Bearer"
              require-expiration-time="true" require-signed-tokens="true"
              clock-skew="60"
              output-token-variable-name="jwt"
              failed-validation-httpcode="401"
              failed-validation-error-message="Invalid or missing token.">
  <openid-config url="https://login.microsoftonline.com/{{tenant-id}}/v2.0/.well-known/openid-configuration" />
  <audiences>
    <audience>api://genai-gateway</audience>
  </audiences>
  <required-claims>
    <claim name="roles" match="any">
      <value>model.invoke</value>
    </claim>
  </required-claims>
</validate-jwt>

output-token-variable-name ist der Teil, der seinen Platz verdient: Das validierte Token landet in einer Policy-Variablen, sodass spätere Policies einen claim daraus lesen können, statt einem Header zu vertrauen, den der Aufrufer kontrolliert. Das ist sofort relevant, denn die nächste Entscheidung ist, welcher Wert die Quota schlüsselt.

Die Falle des anonymen Zugriffs

Das gehört klar ausgesprochen, weil die Konfiguration, die es produziert, harmlos aussieht. Ob eine API ohne subscription key aufrufbar ist, hängt von zwei unabhängigen Einstellungen ab: ob die API selbst eine Subscription verlangt, und ob jedes Product, dem sie zugeordnet ist, eine verlangt. Verlangt die API keine Subscription, sind Aufrufe ohne Key im API-Kontext erlaubt, selbst wenn ein product-scoped Key ebenfalls funktionieren würde. Das Gateway tut exakt, was man ihm gesagt hat; niemand hat ihm die Absicht gesagt.

Für ein Gateway vor bezahlter Modellkapazität lautet die Regel: Jede API verlangt eine Subscription und jedes Product verlangt eine Subscription, und die validate-jwt-Policy läuft unabhängig davon, sodass ein nicht authentifizierter Aufruf zweimal scheitert. Auch Key-Scopes zählen: Ein service-scoped oder all-APIs-scoped Key öffnet jede API der Instanz, was für das eigene Tooling des Plattform-Teams richtig ist und für einen Consumer falsch. Consumer bekommen product-scoped Keys.

Quota, und wogegen man sie zählt

Die Token-Limit-Policy aus Teil 1 nimmt einen counter-key, und diese Wahl ist das gesamte Tenancy-Modell. Auf der Subscription-ID zu schlüsseln ergibt einen Bucket pro Consumer, und genau das brauchte der Incident aus Teil 1: Der Marketing-Batch-Job kann die Quota des Kundenassistenten nicht leeren, weil beide verschiedene Subscriptions mit verschiedenen Countern sind.

<llm-token-limit counter-key="@(context.Subscription.Id)"
                 tokens-per-minute="{{tpm_tier}}"
                 estimate-prompt-tokens="true"
                 remaining-tokens-variable-name="remainingTokens"
                 remaining-tokens-header-name="x-remaining-tokens" />

Das verbleibende Kontingent in einem Response-Header zurückzugeben ist die zwei zusätzlichen Attribute wert. Ein Client, der seinen eigenen Spielraum sieht, kann drosseln, bevor er eine 429 bekommt, und ein Support-Gespräch über Throttling beginnt mit einer Zahl, die beide Seiten sehen können.

Products werden zu den Tiers: ein interaktives Product mit hohem Per-Minute-Limit und moderater Tagesquota, ein Batch-Product mit dem Gegenteil, und ein Sandbox-Product mit Limits, die niedrig genug sind, dass eine außer Kontrolle geratene Schleife in einem Notebook ein Ärgernis bleibt statt ein Incident. Ein Tenant ist eine Entra-ID-Anwendung plus eine oder mehrere Product-Subscriptions, provisioniert durch das Terraform im 30-tenants-Layer aus Teil 2, nie durch ein Ticket.

Das Dimension-Budget

Jetzt die Einschränkung aus dem Lead, formuliert als die Designregel, die sie erzeugt. Azure Monitor begrenzt Custom Metrics auf 10 Dimension-Keys, und API Management nutzt 5 davon für Defaults, darunter Region, Service ID, Service Name und Service Type. Bleiben maximal 5 eigene Dimensionen pro Policy. Das größere Limit ist kombinatorisch: Aktive time series entsprechen dem Produkt der eindeutigen Werte über die Dimensionen im Zeitraum, drei Dimensionen mit je zehn Werten steuern also tausend bei, und die regionale Obergrenze liegt bei 50.000 aktiven time series pro Subscription in zwölf Stunden. Mehrere API-Management-Instanzen in derselben Region zahlen auf dasselbe regionale Total ein.

Die Konsequenz ist eine saubere Trennung, die es verdient, in die Dokumentation der Plattform selbst geschrieben zu werden:

  • Metriken tragen ausschließlich Dimensionen mit niedriger Kardinalität. Tenant, Modell-Alias, Environment. Drei Dimensionen, begrenzte Wertemengen, Dashboards, die schnell laden, und Alerts, die auf das Richtige feuern.
  • Logs tragen alles andere. Request-ID, User-ID, falls sie überhaupt erfasst wird, Prompt- und Completion-Größen, Latenz, welches Backend bedient hat. Application Insights und Log Analytics sind der Ort, an dem Per-Request-Attribution lebt, und der monatliche Chargeback-Job fragt sie ab.
<llm-emit-token-metric namespace="llm-metrics">
  <dimension name="Tenant"      value="@(context.Subscription.Name)" />
  <dimension name="ModelAlias"  value="@(context.Request.MatchedParameters.GetValueOrDefault("model","unknown"))" />
  <dimension name="Environment" value="{{env}}" />
</llm-emit-token-metric>

Drei Dimensionen, mit Absicht. Die vierte, nach der jemand fragen wird, ist die User-ID, und die Antwort ist nein: Sie gehört in den Log-Eintrag, wo Kardinalität Storage kostet statt das Metrik-Budget einer ganzen Region.

Chargeback, das eine Diskussion mit Finance übersteht

Der monatliche Job ist gewöhnliches Data Engineering, und seine Glaubwürdigkeit beruht darauf, in der Genauigkeit explizit zu sein, nicht darauf, präzise zu sein. Teil 3 und 4 haben drei Klassen etabliert, und das Chargeback-Dokument benennt sie:

  • Synchron ohne Streaming: gemessen aus der usage des Modells selbst. Exakt.
  • Synchron mit Streaming: Prompt- und Completion-Tokens am Gateway geschätzt, weil Streaming die Schätzung erzwingt, unabhängig von der Policy-Konfiguration. Approximativ, mit der Drift als eigener Metrik getrackt.
  • Batch: exakt, aus den request counts des Jobs selbst und der usage pro Antwort in der Output-Datei, weil die Control Plane ihn eingereicht hat.

Der Job produziert eine Zahl pro Tenant und eine Abstimmungszeile: die Summe der zugeordneten Ausgaben gegen die tatsächlichen Ressourcenkosten der Periode. Ein Residual von wenigen Prozent, stabil von Monat zu Monat, ist der ehrliche Preis der Schätzung. Ein wachsendes Residual ist ein Bug, meistens ein Aufrufer, der einen Weg am Gateway vorbei gefunden hat. Das Residual zu veröffentlichen statt zu verstecken macht den Rest der Zahl glaubwürdig, und es ist zugleich der Detektor für den Bypass-Pfad, vor dem Teil 1 gewarnt hat.

Wenn ein Team sein eigenes Gateway braucht

Gelegentlich passen die Anforderungen eines Consumers nicht in geteilte Infrastruktur: ein regulierter Workload, der eigene Netzwerkisolation braucht, oder ein Team, das seine eigenen APIs verwalten muss, ohne die von irgendjemand anderem zu berühren. Dafür existieren API-Management-Workspaces, und die Wahl liegt zwischen dem Default-Managed-Gateway des Service, verfügbar in den v2-Tiers ohne zusätzliche Gateway-Kosten und mit Zugriff auf die eingebauten Fähigkeiten, und einem separaten workspace gateway, verfügbar auf Basic v2, Standard v2, Premium und Premium v2, das starke Laufzeitisolation und unabhängige Skalierung, Hostname und Netzwerkkonfiguration einkauft, zum Preis von Mehrkosten, längerem Deployment und Unterstützung in weniger Regionen.

Ein Detail entscheidet, ob das reversibel ist: Die Virtual-Network-Konfiguration eines workspace gateway lässt sich nur bei der Erstellung des Gateways setzen und danach nicht mehr ändern. Seine Netzwerkkonfiguration ist außerdem unabhängig von der der API-Management-Instanz. Ein workspace gateway, ohne Isolation erstellt von einem Team, das sie später braucht, ist ein Rebuild.

Fehlerbilder, die man im Blick behalten sollte

  • Eine Dimension mit hoher Kardinalität in einer Policy. Sie wirft keinen Fehler. Sie verbraucht still das Budget aktiver time series der Region, und das erste Symptom ist, dass die Custom Metrics anderer Teams nicht mehr erscheinen.
  • Keys, die nie ablaufen. Es gibt keinen eingebauten Ablauf und keine Rotation. Ohne Rotations-Workflow funktioniert das Credential einer stillgelegten Anwendung weiter, und nichts meldet das.
  • Der subscription key in Backend-Logs. Das Default-Verhalten reicht ihn weiter. In der Inbound-Section entfernen, und die Logs des Backends einmal prüfen, statt es anzunehmen.
  • Eine API, die keine Subscription verlangt. Anonymer Zugriff im API-Kontext, erreicht durch eine Konfiguration, die sich wie großzügig liest statt wie offen.
  • Chargeback, veröffentlicht ohne sein Residual. Findet ein Product Owner zum ersten Mal eine Abweichung, die nicht offengelegt wurde, ist jede künftige Zahl verhandelbar.

Was Teil 6 erbt

Tenants mit echten Identitäten, Quotas, die halten, und eine monatliche Zahl pro Team mit ausgewiesener Genauigkeit. Das setzt die nächste Frage präzise auf: Das günstigste Token ist das nie gesendete, und semantisches Caching ist der erste Mechanismus dieser Serie, der die Rechnung senkt, statt sie nur zuzuordnen. Er verändert außerdem still, was die Zahlen oben bedeuten, denn ein Cache-Hit ist ein Request, der nichts gekostet hat und trotzdem in irgendjemandes Report auftauchen muss.

Weiterlesen

Für die Infrastruktur- und Plattform-Seite, so etwas in diesem Maßstab zu betreiben, gibt es die Field Notes auf ercan.cloud, und der Hub liegt auf ercanermis.com.

Referenzen