AWS Bedrock-Keys werden nun durch ein internes LLM-Gateway geschützt, das es jedem Team in einem Fintech-Unternehmen ermöglicht, die Modelle aufzurufen, wobei jede Anfrage an ein Token-Budget pro Team gebunden ist. Diese Änderung verhindert die Praxis, IAM-Anmeldedaten über Repositories und Notebooks zu verstreuen – eine Gewohnheit, die bereits drohte, das KI-Budget des Unternehmens an einem einzigen Nachmittag aufzubrauchen.

Warum die Vergabe von AWS-Keys schnell im Chaos endet

Nicht-technische Gruppen in der Organisation baten um direkten Zugriff auf die Sprachmodelle des Unternehmens. Auf dem Papier war die einfachste Antwort, die Modelle in AWS zu aktivieren und jeder Gruppe eine IAM-Berechtigung zu erteilen. Zehn Minuten Arbeit, ein paar Anpassungen der Richtlinien, und die Aufgabe war erledigt – zumindest theoretisch.

In der Praxis verursacht die Vergabe von IAM-Anmeldedaten drei versteckte Kosten:

  • Credential Sprawl – Keys landen in .env-Dateien, CI-Pipelines, Jupyter-Notebooks und Ad-hoc-Skripten. Jede Kopie wird zu einer Fehlerquelle, sobald eine Rotation erforderlich ist.
  • Null Transparenz – Ein einziger gemeinsamer Key gibt keinen Aufschluss darüber, welches Team oder welcher Codeabschnitt den Verbrauch verursacht. Wenn eine Endlosschleife startet, kann das gesamte Budget aufgebraucht sein, bevor es jemand bemerkt.
  • Operativer Aufwand – Das Verfolgen, wer welche Berechtigung hat, das Entziehen von Zugriffen und das Auditieren der Nutzung entwickelt sich schnell zu einem manuellen, fehleranfälligen Prozess.

Das Fintech-Team erkannte, dass die „schnelle Lösung“ bald zu einem Sicherheits- und Kosten-Albtraum werden würde.

Stattdessen: Aufbau eines Reverse-Proxy-Gateways

Die Lösung bestand darin, einen schlanken Reverse Proxy zwischen jeder internen Anwendung und AWS Bedrock zu schalten. Der Proxy hält die echten AWS-Anmeldedaten an einem einzigen, durch einen Vault gesicherten Ort und stellt den Aufrufern kurzlebige, menschenlesbare Token (zum Beispiel lllkey_9f3c) aus.

Wichtige Designpunkte:

  • Keine AWS-Anmeldedaten verlassen das Gateway – Entwickler und Dienste sehen niemals die tatsächlichen IAM-Keys.
  • Richtliniendurchsetzung pro Token – Jeder Token kann auf eine bestimmte Modellfamilie oder eine maximale Token-Anzahl beschränkt werden.
  • Vollständiger Audit-Trail – Jede Anfrage wird mit einem Namen protokolliert.

Wie das Gateway eine Anfrage verarbeitet

  1. Token empfangen – Der Client fügt seinen llmkey_…-Token in den HTTP-Header ein.
  2. Token validieren – Das Gateway prüft den Status des Tokens (aktiv, nicht abgelaufen) und ob die Anfrage innerhalb des zugewiesenen Budgets bleibt.
  3. Modell-Whitelist – Es wird bestätigt, dass das angeforderte Modell für diesen Token zulässig ist.
  4. Weiterleitung an Bedrock – Die Anfrage wird unter Verwendung der gespeicherten IAM-Anmeldedaten an AWS gesendet.
  5. Protokollierung und Abrechnung – Token-Verbrauch, Modellname und Kostenschätzung werden zur Berichterstattung in eine zentrale Datenbank geschrieben.

Da das Fintech-Unternehmen alle Daten innerhalb seines eigenen Netzwerks halten muss, kam ein SaaS-Angebot eines Drittanbieters nicht infrage.

Was das Unternehmen gewonnen hat

  • Modellkontrolle – Teams, die nur ein kostengünstiges Modell benötigen, können darauf beschränkt werden, was die versehentliche Nutzung teurerer Varianten mit höherer Kapazität verhindert.
  • Budgetschutz – Token haben ein hartes Token-Limit. Wenn das Limit erreicht ist, gibt das Gateway einen Fehler zurück, anstatt stillschweigend weitere Credits zu verbrauchen.
  • Zuordnung für die Finanzabteilung – Ein auf den Nutzungsprotokollen basierendes Dashboard zeigt genau an, welches Team oder welcher Dienst wie viel für KI ausgegeben hat, und verwandelt eine vage Tabellenkalkulation in einen transparenten Bericht.

Auch der operative Workflow änderte sich. Keine neuen IAM-Richtlinien, keine Rotation von Secrets und kein Risiko, dass Keys in die Versionsverwaltung gelangen.

Gegenargument: Warum keinen Managed Service verwenden?

Ein häufiges Gegenargument ist, dass der Aufbau eines eigenen Gateways zusätzlichen Entwicklungs- und Wartungsaufwand bedeutet. Im Fall des Fintech-Unternehmens überwog die Notwendigkeit, den gesamten KI-Datenverkehr und die Nutzungsdaten hinter der Unternehmens-Firewall zu halten, den Komfort einer Drittanbieter-Lösung. Der interne Proxy erforderte ein Wochenende Entwicklungsarbeit, ersparte jedoch Monate an Bereinigung von Anmeldedaten und Budgetüberschreitungen, die auf den naiven Ansatz der Key-Verteilung gefolgt wären.

Fazit

Die Vergabe von AWS Bedrock-Keys ist eine Abkürzung, die schnell zu einem Sicherheits- und Budget-Albtraum wird. Ein bescheidenes Reverse-Proxy-Gateway – in einem Wochenende entwickelt – zentralisiert Anmeldedaten, erzwingt Limits pro Team und bietet den Audit-Trail, den die Finanzabteilung benötigt. Für jede Organisation, die es mehreren Gruppen ermöglichen möchte, mit LLMs zu experimentieren, ohne die Kontrolle aufzugeben, amortisiert sich der Gateway-Ansatz durch vermiedene Zwischenfälle und eine klarere Sichtbarkeit der Ausgaben.