Über den Kunden
Der Kunde ist ein Unternehmen im Bereich digitale Gesundheit, das persönliche Gesundheitsdaten – darunter Krankenakten, Fitnessdaten von Wearables, Laborergebnisse und Medikamenteninformationen – mit einer Sammlung geprüfter medizinischer Inhalte zusammenführt. Die Plattform wandelt diese Informationen in personalisierte Gesundheitsübersichten um, anstatt die Nutzer mit fragmentierten Daten allein zu lassen.
Die Plattform richtet sich sowohl an Einzelnutzer als auch an Partner aus dem Gesundheitswesen, die eigene Markenversionen betreiben.
Die Infrastruktur des Produkts basiert auf AWS, wobei containerisierte Workloads auf Amazon ECS mit AWS Fargate ausgeführt werden, CloudFront für Web-Frontends und Keycloak für die Identitätsverwaltung und Single Sign-On (SSO) zum Einsatz kommen. Amazon Bedrock bildet die Grundlage für verschiedene KI-Funktionen innerhalb des Produkts, neben weiteren Diensten wie OpenSearch, Amazon RDS, Amazon SQS, Amazon SES, Amazon SNS und AgentCore.
Das Unternehmen wollte den Einsatz von KI auf die Arbeitsabläufe der Entwickler ausweiten, indem es Claude Code über Amazon Bedrock einführte, dabei jedoch die Kontrolle über Zugriff, Sicherheit und Kosten behalten wollte.
Herausforderungen und Anforderungen
Das Entwicklungsteam wollte einen KI-Programmierassistenten auf Basis von „Claude Code“ mit Amazon Bedrock bereitstellen. Durch diesen Ansatz blieb der Zugriff auf das Modell innerhalb der bestehenden AWS-Sicherheitsgrenzen des Unternehmens, anstatt auf eine separate API-Integration eines Drittanbieters zurückzugreifen.
Um die anfängliche Einführung zu beschleunigen, wurde der Zugriff über einen gemeinsam genutzten IAM-Benutzer mit zwei langfristig gültigen Zugriffsschlüsseln konfiguriert. Dies ermöglichte den Entwicklern zwar einen sofortigen Zugriff auf den Assistenten, brachte jedoch erhebliche Risiken in Bezug auf Sicherheit und Kostenmanagement mit sich.
Aufgrund der gemeinsam genutzten Zugangsdaten war es unmöglich, Modellaufrufe einzelnen Entwicklern zuzuordnen oder klare Nutzungsgrenzen pro Person festzulegen. Im Rahmen einer Kostenanalyse stellte ITGix einen Spitzenwert von etwa 581 Modellaufrufen pro Stunde von einem einzigen Schlüssel aus fest, der auf das Claude-Befehlszeilentool zurückgeführt werden konnte.
Zudem gab es keine wirksame Ausgabenobergrenze. Eine außer Kontrolle geratene Sitzung oder ein durchgesickertes Zugangsdaten könnten daher zu unerwarteten Kosten führen.
Die Anforderungen waren klar: Umstellung auf individuelle, zeitlich begrenzte und überprüfbare Entwicklerzugriffe; Beschränkung des Zugriffs auf genehmigte Modelle; Festlegung eines definierten Budgets mit Frühwarnungen bei ungewöhnlichen Ausgaben; sowie automatische Sperrung weiterer Bedrock-Modellaufrufe bei Überschreitung der Budgetgrenze.
Die erste Runde der Kostenkontrolle brachte jedoch ein weiteres Problem ans Licht. Die Kosten für Claude Sonnet 5 hatten das vereinbarte monatliche Limit überschritten, doch im AWS-Budget wurden keine Ausgaben ausgewiesen, sodass keine Warnmeldung ausgelöst wurde.
Die Untersuchung ergab zwei Faktoren, die dazu beigetragen haben:
- Falsche Filterung der Dienste: Das Budget wurde nach dem Amazon Bedrock-Dienst gefiltert, während die Modellkosten unter separaten Dienstleistungspositionen aufgeführt wurden.
- Ein weiterer Tag-Filter: Die kombinierten Filter ergaben keine passenden Buchungen.
Die Abrechnungskennzahlen von CloudWatch wiesen dieselbe Einschränkung auf, da sie die erforderlichen modellbezogenen Gebühren nicht offenlegten.
Das Problem wurde dadurch verschärft, dass auch andere Teile der Plattform diese Modelle nutzten. Zwar wurden die Ausgaben der Entwickler über ein Tag zur Kostenverrechnung erfasst, doch wurden die Modellaufrufe nicht über eine mit einem Tag versehene Ressource geleitet. Infolgedessen wurden die entsprechenden Modellkosten nicht dem Tag zugeordnet.
Schließlich führte die Einschränkung der Entwicklerberechtigungen auf ein neu erstelltes benutzerdefiniertes Inferenzprofil dazu, dass Claude-Code-Anfragen fehlschlugen. Obwohl das benutzerdefinierte Profil ausdrücklich zugelassen war, überprüfte Amazon Bedrock bei der Verarbeitung von Anfragen über das benutzerdefinierte Profil auch den Zugriff auf das ursprüngliche Inferenzprofil und das zugrunde liegende Modell.
Die Lösung musste die Bereiche Identitätsmanagement, Autorisierung, Kostenzuordnung, Budgetüberwachung und Modellzugriff gemeinsam abdecken.
Lösung
ITGix hat Claude Code über Amazon Bedrock im eigenen AWS-Konto des Kunden bereitgestellt und die Konfiguration anschließend optimiert, nachdem im praktischen Einsatz Lücken in der ursprünglichen Einrichtung zutage getreten waren.
Die Arbeit umfasste die Authentifizierung einzelner Entwickler, modellspezifische Zugriffsberechtigungen, die Kostenverrechnung, die automatisierte Budgetüberwachung sowie die Erkennung von Anomalien.
Individueller Entwicklerzugang mit dem AWS IAM Identity Center
ITGix hat den gemeinsamen IAM-Benutzer deaktiviert und den Entwicklerzugriff auf das AWS IAM Identity Center umgestellt.
Entwickler authentifizieren sich nun über SSO und erhalten temporäre Zugangsdaten über einen speziellen Berechtigungssatz, der auf Amazon Bedrock und genehmigte Anthropic-Modelle, darunter Sonnet, beschränkt ist.
Sitzungen laufen nach acht Stunden ab, sodass sich Entwickler erneut authentifizieren müssen. Dadurch entfällt die Abhängigkeit von gemeinsam genutzten, langfristig gültigen Zugriffsschlüsseln und es werden dauerhafte Sitzungen vermieden.
Durch diese Änderung wurden individuelle Identitäten für die Modellnutzung festgelegt, sodass Aufrufe dem Entwickler zugeordnet werden können, der sie getätigt hat. Der Zugriff kann zudem für eine einzelne Person widerrufen werden, ohne dass andere Teammitglieder davon betroffen sind.
AWS-Budgetdurchsetzung und Erkennung von Kostenabweichungen
Um über die reine Kostenüberwachung hinauszugehen, hat ITGix ein monatliches AWS-Budget eingerichtet, um die Nutzung von Claude Code zu verfolgen.
Wird der Budgetgrenzwert überschritten, löst eine automatisierte Budgetmaßnahme eine Ausführungsrolle aus, die eine IAM-Verweigerungsrichtlinie anwendet, welche den Aufruf des Bedrock-Modells blockiert. Dadurch wird die Steuerung von einem reinen Benachrichtigungsmechanismus auf eine durchgesetzte Ausgabenobergrenze umgestellt.
Zudem wurde die AWS Cost Anomaly Detection eingeführt, um ungewöhnliche Nutzungs- und Ausgabemuster frühzeitig zu erkennen.
Zusammen bieten diese Kontrollmechanismen sowohl eine proaktive Erkennung als auch einen automatisierten Mechanismus, um weitere Modellaufrufe zu unterbinden, sobald der konfigurierte Budgetgrenzwert überschritten wird.
Spezielles Bedrock-Inferenzprofil für die Kostenverrechnung
Um die Nutzung von Claude Code von anderen Workloads zu unterscheiden, die dieselben Modelle verwenden, hat ITGix ein eigenes Inferenzprofil erstellt, indem das globale Claude Sonnet 5-Inferenzprofil kopiert und mit einem spezifischen Tag versehen wurde.
Die BedrockDeveloper Die Berechtigungen wurden verschärft, um den Zugriff auf das vorgesehene Profil zu beschränken, und die Entwickler wurden angewiesen, Claude Code so zu konfigurieren, dass das benutzerdefinierte Inferenzprofil verwendet wird.
Dadurch stand eine eigens dafür vorgesehene, gekennzeichnete Ressource zur Verfügung, über die die Nutzung von Claude Code in der Abrechnung separat erfasst und nachverfolgt werden konnte.
Während der Tests schlugen die Anfragen fehl, da Amazon Bedrock zusätzlich die Berechtigung zum Zugriff auf das ursprüngliche globale Inferenzprofil und das zugrunde liegende Modell benötigte.
Um dieses Problem zu beheben, hat ITGix das globale Inferenzprofil „Claude Sonnet 5“ zusätzlich zum benutzerdefinierten Profil in die Berechtigungsgruppe aufgenommen. Anschließend haben die Entwickler ihr Standardmodell manuell auf das neue benutzerdefinierte Profil eingestellt.
Nach dieser Änderung funktionierte Claude Code wie erwartet. Das benutzerdefinierte Profil blieb das konfigurierte Ziel für Claude Code, sodass die Nutzung mit dem expliziten Tag versehen und dem entsprechenden Budget zugeordnet werden konnte. Der Berechtigungsumfang blieb auf Sonnet 5 beschränkt, wodurch der Zugriff auf das vorgesehene Modell und den Anwendungsfall als Codierungsassistent beschränkt blieb.
Ergebnisse
Der Kunde nutzt nun über Amazon Bedrock einen KI-Programmierassistenten mit individuellen Entwickleridentitäten, nachverfolgbaren Zugriffsrechten und einer festgelegten Kostenobergrenze.
Mit den Änderungen wurden die Sicherheits- und Kostenkontrolllücken behoben, die sich mit zunehmender Nutzung des Modells ergeben hatten.
Individueller und nachverfolgbarer Zugriff
Gemeinsam genutzte, langfristig gültige Anmeldedaten wurden entfernt. Entwickler authentifizieren sich über das AWS IAM Identity Center und erhalten temporäre Anmeldedaten, deren Gültigkeitsbereich auf die genehmigten Bedrock-Ressourcen beschränkt ist. Modellaufrufe lassen sich einzelnen Entwicklern zuordnen, und der Zugriff kann widerrufen werden, ohne dass andere Benutzer davon betroffen sind.
Eingeschränkter Zugriff auf Modelle
Der Berechtigungssatz beschränkt Entwickler auf den genehmigten Modellumfang. Das spezielle Inferenzprofil stellt eine separate, gekennzeichnete Ressource für die Nutzung von Claude Code bereit, ohne die Berechtigungen zu entfernen, die Bedrock benötigt, um das zugrunde liegende Modell und das globale Profil aufzulösen.
Vorgeschriebene Ausgabenobergrenzen
Die monatliche Budgetkontrolle unterstützt nun die automatische Sperrung weiterer Bedrock-Modellaufrufe, sobald der konfigurierte Schwellenwert überschritten wird. AWS Cost Anomaly Detection bietet eine zusätzliche Ebene zur Erkennung ungewöhnlicher Nutzungsmuster.
Verbesserte Kostenzuordnung
Das spezielle, mit Tags versehene Inferenzprofil ermöglicht es, Claude-Code-Kosten von der Modellnutzung durch andere Teile der Plattform zu unterscheiden. Dies trägt dazu bei, die Kostenüberwachung an das vorgesehene Entwicklerbudget anzupassen.
Ergebnis
Das Ergebnis ist ein sicherer und kosteneffizienter KI-Codierungsassistent, der auf AWS Bedrock bereitgestellt wird und dessen Konfiguration so ausgelegt ist, dass er auf eine größere Anzahl von Entwicklern skaliert werden kann, ohne dass wieder auf gemeinsam genutzte Anmeldedaten zurückgegriffen werden muss.
Durch die ganzheitliche Berücksichtigung von Authentifizierung, Modellberechtigungen, der Kennzeichnung von Inferenzprofilen, der Einhaltung von Budgetvorgaben und der Erkennung von Anomalien trug ITGix dazu bei, eine kontrollierte Umgebung für die KI-gestützte Entwicklung zu schaffen und gleichzeitig die bestehende AWS-Architektur sowie die Sicherheitsgrenzen des Unternehmens beizubehalten.
Weitere Blogbeiträge findest duhier.