Ein ausgehandelter Modellpreis ist nicht automatisch der Preis, den ein Workload nutzen kann. AWS beschreibt am 13. Oktober diese Lücke für geeignete Drittanbieter-Modelle in Amazon Bedrock: Eine akzeptierte private Marketplace-Offerte erzeugt eine Lizenz, doch verteilte Grants können angenommen und trotzdem deaktiviert sein.
AWS zeigt zwei Wege. Ein Python-Skript lässt Administratoren erhaltene Lizenzen einmalig prüfen und aktivieren. Ein ereignisgesteuertes CDK-Beispiel verarbeitet wiederkehrende Vereinbarungen mit Verkäuferprüfung, Grant-Erstellung, Aktivierung, Wiederholungen und Protokollen. Beide handeln keinen Rabatt aus und beweisen durch ihre Installation keine Einsparung.
Der Zweck ist, zentrale Vertragsbedingungen in Entwicklungs-, Produktions-, Geschäftsbereichs- oder Regionalkonten nutzbar zu machen. Damit wachsen die Folgen eines falschen Verkäufers oder Zielbereichs. Beschaffungsfreigabe, technische Aktivierung und Rechnungsprüfung bleiben unterschiedliche Ereignisse.
Lizenz, Grant und Rechnung sind verschiedene Zustände
AWS Marketplace Private Pricing Offers, kurz MPPO, legen ausgehandelte Geschäftsbedingungen fest. Bei geeigneten License-Manager-gestützten Bedrock-Modellen erzeugt die Annahme eine Lizenz. Managed Entitlements verteilen dieses Recht durch Grants an eine Organisation, ausgewählte Organisationseinheiten oder benannte Konten.
Sind alle AWS-Organizations-Funktionen aktiviert, werden Organisations-Grants automatisch angenommen, bleiben aber bis zur Aktivierung deaktiviert. AWS nennt ACTIVE und WORKFLOW_COMPLETED als Zustände, nach denen der Preis gilt. Beschaffung kann deshalb eine angenommene Offerte und konfigurierte Ziele sehen, während betroffene Nutzung noch nicht dem vereinbarten Preispfad folgt.
Bei konsolidierter Abrechnung ohne sämtliche Organizations-Funktionen müssen Empfängerkonten Grants manuell annehmen. Zentrale Abrechnung ist keine vollständige Organisationsintegration. Lizenzressourcen werden in us-east-1 verwaltet, auch wenn Modellaufrufe in anderen unterstützten Bedrock-Regionen erfolgen.
Das ursprüngliche Abonnementkonto erhält die Rechnung für verteilte Nutzung; Empfänger schließen nicht jeweils ein unabhängiges Abonnement. Das zentralisiert Transparenz, beseitigt aber keine interne Zuordnung. Tags, Kostenkategorien und Verantwortliche bleiben für Showback oder Chargeback nötig. Lizenzstatus, Modellaufruf und tatsächliche Gebühren benötigen getrennte Beobachtung.
Das Skript bleibt eine begrenzte Bedieneraktion
Das eigenständige Python-Werkzeug listet empfangene Lizenzen des Managementkontos. Standardmäßig erstellt es nur einen Dry-Run-Plan, keine Grants oder Aktivierungen. Der Bediener prüft Aussteller, Lizenz und Umfang und führt erst mit --apply sowie ausdrücklicher Managementkonto-ID aus.
Es erstellt und aktiviert organisationsweite Grants für ausgewählte Lizenzen. Das passt zu bekanntem Rückstand oder seltenen Vereinbarungen ohne dauerhafte CDK-Infrastruktur. Eine fortlaufende Policy-Engine ist es nicht.
Entscheidend ist die fehlende Verkäufer-Allowlist. Der Mensch muss jeden Aussteller mit Beschaffungsunterlagen und akzeptierter Marketplace-Vereinbarung vergleichen. Wiederholtes unbeaufsichtigtes Verarbeiten beliebiger Eingänge würde diese Vertrauensgrenze entfernen.
Auch die organisationsweite Verteilung braucht bewusste Zustimmung. Regulierte Unternehmen trennen etwa klinische Produktion von Forschung oder begrenzen Modelle auf genehmigte Entwicklungs- und Produktionseinheiten. Technisch erfolgreiche Aktivierung kann den geschäftlich erlaubten Umfang trotzdem überschreiten.
Anschließend wird der License-Manager-Status geprüft und nach Eingang der Daten repräsentative Nutzung in Cost Explorer kontrolliert. AWS warnt vor Stunden bis Tagen Verzögerung. Ein aktiver Grant belegt Aktivierung, nicht sofort korrekte Einzelgebühren. Die Rabattprüfung des Beispiels benötigt zur realen Vereinbarung passende Aussteller- und Kontoeingaben.
CDK reagiert auf Verträge, nicht fertige Lizenzen
Die wiederkehrende Architektur verbindet EventBridge, Lambda, DynamoDB, License Manager und CloudWatch. Auf dem Standard-Eventbus in us-east-1 filtert eine Regel Quelle aws.agreement-marketplace und Detailtyp Purchase Agreement Created - Acceptor.
Lambda prüft die Verkäufer-Allowlist in DynamoDB. Für einen zugelassenen Verkäufer sucht die Funktion die zugehörige Lizenz, erstellt einen Grant für konfigurierte Ziele und fordert über CreateGrantVersion den aktiven Zustand an.
Das Vertragsereignis garantiert keine Bereitschaft nachgelagerter Ressourcen. Ein neuer Grant kann noch nicht aktivierbar sein; das Beispiel wiederholt daher, während License Manager seinen Ablauf beendet. CloudWatch zeichnet Aktivierung, Verschiebung und Überspringen auf. Das erklärt Verarbeitung, ersetzt aber keine Genehmigungsunterlagen für Verkäufer und Ziele.
Bereitstellung muss aus dem Organizations-Managementkonto in us-east-1 erfolgen, mit allen Organisationsfunktionen und einem geeigneten License-Manager-gestützten Bedrock-Angebot. SaaS liegt außerhalb des Beispiels. Es ist kein universeller Prozessor aller privaten Marketplace-Angebote.
License Manager und Marketplace benötigen beide vertrauenswürdigen Zugriff und serviceverknüpfte Rollen. Ein Bootstrap-Werkzeug prüft Voraussetzungen; sein Apply-Modus aktiviert Integrationen und erstellt Rollen nach ausdrücklicher Kontobestätigung. Konfiguration enthält Organisations-ID, bestätigte Verkäufer, Benachrichtigungen und optionale Ziele. Ohne eigene Ziele gilt die ganze Organisation; Einheiten oder Einzelkonten grenzen ein.
Verkäuferidentität und Zielumfang sind die Kontrollgrenze
AWS bezeichnet die Allowlist als Sicherheitsgrenze. Verkäuferkonto-IDs sollten aus angenommenem Vertrag oder erhaltener Lizenz bestätigt werden, nicht anhand eines Anzeigenamens. Ungeprüfte oder zu breite Einträge können unerwünschte Grants über sämtliche Ziele ermöglichen.
Das gibt einem Modell nicht automatisch unbeschränkten Zugriff auf Unternehmensdaten. IAM, Service-Kontrollen, Modellberechtigungen und Anwendungsarchitektur regeln reale Nutzung. Entitlements verändern die kommerzielle Berechtigung und möglicherweise den zentralen Rechnungsträger, sind aber nicht mit sämtlichen Datenrechten gleichzusetzen.
Organisationseinheiten nutzen eine bestehende Hierarchie. Benannte Konten sind enger, verlangen jedoch Pflege bei neuen Workloads. Ein organisationsweites Ziel kann einer zentralen Plattform dienen, während regulierte Umgebungen Freigaben je Umgebung und Datenklasse benötigen.
Verkäufer-, Organisations- und Zieländerungen brauchen Review und kontrollierte Bereitstellung. Warnungen müssen Fehler und wiederholt verschobene Aktivierungen erfassen. Ereigniszustellung und Lizenzbereitschaft sind getrennt; verzögerte, doppelte oder fehlende Verarbeitung muss vorgesehen werden, statt Stille im Log als Vollständigkeit zu deuten.
Abgleich vergleicht angenommene Verträge, erhaltene Lizenzen, erlaubte Ziele und aktive Grants. Er erkennt fehlende Aktivierung, unerwartete Ziele oder Grants ohne aktuellen genehmigten Vertrag. Das Skript kann bei Wiederherstellung helfen, braucht aber gemeinsame Zuständigkeit mit dem Stack gegen Duplikate und Zielkonflikte. Ausstellerzuordnung, Freigaben und Wiederherstellungsschritte müssen im Vorfall zugänglich bleiben.
Zentraler Einkauf ersetzt keine Vertragsauslegung
Beschaffung verantwortet den Vertrag, Plattformtechnik Verteilung und Aktivierung, Sicherheit Vertrauen und Umfang, FinOps Gebühren und Zuordnung. Unklare Zuständigkeit kann viele kleine Kontoverzögerungen durch einen zentralen Engpass ersetzen.
AWS-Kunde Heidi Health berichtet von Millionen klinischer Konsultationen pro Woche mit Drittanbieter-Grundmodellen. Plattformleiter Marcus Lau beschreibt private Preise als Hilfe zur Zuordnung von Nutzung und Bedingungen über Konten und Einheiten und betont automatische Grants für neue Modelle. Das ist eine Kundenperspektive, kein unabhängiger Einsparungsnachweis.
Verlängerungen, neue Verträge und Umstrukturierungen benötigen weitere Prüfung. Automatisierung interpretiert weder Abdeckung noch Änderungen oder Wirksamkeitsdaten. Ein angenommener Vertrag mit künftigem Beginn macht neue Bedingungen nicht sofort verfügbar. Zusätzliche Modelle, Regionen oder Produktvarianten sind nicht automatisch vom bestehenden Vertrag umfasst.
Erfolg verlangt drei übereinstimmende Belege
Erstens wird die Zeit vom qualifizierten Vertragsereignis zum akzeptierten aktiven Zustand gemessen, einschließlich Verkäuferablehnungen, Suchverzögerungen, Verschiebungen und manueller Eingriffe. Zweitens werden nach Vertrags- und Kontoänderungen Vereinbarungen, Lizenzen, Ziele und Grants abgeglichen. Drittens werden nach Verfügbarkeit der Abrechnung repräsentative Nutzung, erwartete Bedingungen, Aussteller und Rechnungseigentümer geprüft.
Ein kontrollierter Rollout beginnt mit Dry Run und einer bestätigten Lizenz. Ereignisverarbeitung startet anschließend für wenige Verkäufer und eng begrenzte Ziele. Erst wenn Protokolle, Status und Rechnung übereinstimmen, wird erweitert. Wiederherstellung muss unbekannte Verkäufer, fehlende Ereignisse, verspätete Aktivierung und überraschende Gebühren behandeln.
Das Skript passt zu begrenzter, vertrauenswürdiger Arbeit mit menschlicher Prüfung. CDK passt zu wiederkehrenden Verträgen mit sicher kodierbarer Policy. Entscheidend ist nicht die installierte Automatisierungsmenge, sondern ob jeder Vertrag einen exakten Verkäufer, genehmigte Ziele, erwarteten Zustand und verantwortlichen Rechnungseigentümer hat.