Mit einer gut ausgearbeiteten Spezifikation dauert der Bau eines Proof-of-Concept Gen-AI-Apps auf AWS ein bis zwei Tage. Eine produktionsreife Generative AI auf AWS zu bauen, die eine DSGVO oder SOC 2 Prüfung übersteht und dabei skalierbar und stabil ist, ist eine ganz andere Aufgabe.
AWS Services für GenAI Workloads
Amazon bietet eine breite Palette an Services für GenAI Workloads an, wobei Amazon Bedrock und SageMaker zu den bekanntesten zählen.
Allerdings solltest du bedenken, dass AWS viele weitere Services bietet, die bestimmte Probleme mit weniger Programmieraufwand und operativem Overhead lösen können, als wenn du eine eigene Lösung mit Bedrock oder SageMaker aufbaust.
Wenn du zum Beispiel einen Chatbot für dein System bauen musst, funktionieren Amazon Lex und Amazon Connect in vielen Fällen bereits out of the box und reduzieren so den nötigen Engineering-Aufwand erheblich.
Ein weiteres Beispiel ist die Verarbeitung medizinischer Notizen. Wenn du einen HIPAA-konformen Service benötigst, der medizinische Informationen aus klinischem Text extrahiert, kann Amazon Comprehend Medical die bessere Wahl sein, als ein eigenes KI-basiertes Extraktionssystem zu bauen. In vielen Fällen ist der Einsatz eines zweckgebundenen AWS Service einfacher und effizienter, als dieselbe Funktionalität von Grund auf selbst zu entwickeln.
Aber bei anderen komplexen agentischen KI-Systemen, benötigst du unter Umständen Bedrock oder SageMaker.
Hier ist eine Liste der KI-Services von AWS, die du in deiner Anwendung nutzen kannst.
Umgebungsstruktur und Deployments
Bevor du mit der Entwicklung beginnst, solltest du zunächst deine AWS High-Level-Architektur und Umgebungen verstehen. Das beginnt damit, wie du Tests durchführst, welche Umgebungen du benötigst und wie Tests und Pipelines ablaufen sollen.
Umgebungen – Dev, Staging, Production
Bei der Entwicklung von GenAI Systemen auf AWS musst du diese testen und verifizieren, bevor du sie in Production veröffentlichst und für Endnutzer verfügbar machst. Dafür benötigst du unterschiedliche Umgebungen für dein System. In den meisten Fällen brauchst du mindestens drei: Development, Staging und Production.
Die Development-Umgebung wird für die tägliche Entwicklung und das Testen genutzt. Sie hat in der Regel eine kleinere Kapazität und kann häufig verändert werden. Die Staging-Umgebung dagegen ist stabiler und ähnelt der Production-Umgebung sehr stark, auch wenn ihr meist weniger Ressourcen wie vCPU und Arbeitsspeicher zugewiesen sind.
Wichtig ist, dass jede Umgebung in einem separaten AWS Account isoliert wird, wobei die Accounts unter einem gemeinsamen Billing Account verwaltet werden. Dieses Setup erleichtert es, weitere Umgebungen hinzuzufügen und sie konsistent mit Infrastructure as Code (IaC) zu deployen. Außerdem kann es Compliance-Anforderungen wie DSGVO und SOC 2 unterstützen, da es die logische Trennung und Zugriffskontrolle für jede Umgebung erleichtert.
Infrastructure as Code – IaC
Du solltest deine Infrastruktur und Ressourcen mit IaC erstellen, damit deine Infrastruktur reproduzierbar ist und je nach Umgebung konsistent deployt werden kann.
Bei der Erstellung der Infrastruktur hast du mehrere Optionen für IaC-Tools, und es lohnt sich zu überlegen, welches davon besser passt und warum.
Die wichtigsten Optionen sind Terraform, CloudFormation und AWS CDK.
Terraform / Terragrunt
Terraform lässt sich problemlos für die Definition von IaC verwenden und passt gut zu vielen Teilen deiner AWS Infrastruktur. Für agentische KI Workloads auf AWS ist es jedoch nicht immer die praktischste Option.
Der Hauptgrund dafür ist, dass sich die GenAI Services auf AWS schnell weiterentwickeln, wodurch einige neuere AWS Ressourcen oder Features in Terraform teils umständlicher zu verwalten sind. Zum Beispiel kann die Verwaltung von Dingen wie OpenSearch Serverless, Bedrock-bezogenen Ressourcen, Policies oder neu eingeführten Funktionen manchmal zusätzliche Konfiguration oder Workarounds erfordern.
Das bedeutet nicht, dass du Terraform komplett ersetzen solltest. Deine Hauptinfrastruktur wie EKS/ECS, Networking, IAM, Datenbanken und andere gemeinsam genutzte Ressourcen kannst du weiterhin in Terraform oder Terragrunt verwalten.
Für den agentischen KI-Teil der Infrastruktur kann es jedoch sinnvoll sein, Tools zu verwenden, die nativer in AWS integriert und leichter zu warten sind, während sich die AWS Services weiterentwickeln.
CloudFormation
CloudFormation ist ebenfalls eine gute Option, da es nativ von AWS unterstützt wird.
Du definierst deine Ressourcen in YAML oder JSON, referenzierst sie untereinander, und CloudFormation übernimmt das Deployment und den Lifecycle dieser Ressourcen.
Der Vorteil ist, dass neue AWS Services und Funktionen in der Regel direkt über CloudFormation unterstützt werden. Der Nachteil ist, dass größere Templates schnell umfangreich und schwerer zu warten werden.
For relatively small infrastructure stacks, CloudFormation can work perfectly well.
AWS CDK
AWS CDK wäre für den agentischen KI-Teil des Deployments wahrscheinlich meine Wahl.
Unter der Haube generiert CDK weiterhin CloudFormation, aber statt große YAML Templates zu schreiben, definierst du deine Infrastruktur in einer Programmiersprache wie TypeScript.
Das erleichtert es, wiederverwendbare Komponenten zu erstellen, Konfigurationen zwischen Umgebungen zu teilen, Bedingungen hinzuzufügen und komplexere Infrastruktur übersichtlich zu halten.
Deine Hauptinfrastruktur wie ECS/EKS, Networking, IAM und andere gemeinsam genutzte Komponenten kann weiterhin in Terraform oder CloudFormation bleiben. Für Bedrock, OpenSearch, Knowledge Bases, Agents, agentenbezogene Lambdas und andere GenAI-spezifische AWS Ressourcen kann CDK die Entwicklung jedoch oft schneller und wartungsfreundlicher machen.
CDK Umgebungen müssen vor dem Deployment gebootstrapt werden, das ist jedoch normalerweise ein einmaliger Setup-Schritt für die Umgebung und kein Vorgang, den du bei jedem Deployment wiederholen musst. Ist das einmal erledigt, fügt sich CDK ziemlich natürlich in einen CI/CD Workflow ein.
Ci/CD Pipelines
Für CI/CD Pipelines gibt es meines Erachtens ein paar Optionen.
Dein Git Host
Egal ob du GitHub, Bitbucket, GitLab oder ein anderes Git Repository zum Hosten deines Codes nutzt, in der Regel bieten diese eigene Pipelines an, die du verwenden kannst. GitHub bietet zum Beispiel GitHub Actions an, und auch andere Anbieter haben ihre eigenen Alternativen.
Das erscheint mir als die naheliegendste Option, da du Reviews direkt in deine Pipeline einbinden kannst und dein Abo meist bereits eine kostenlose Nutzung beinhaltet.
Wenn du dies auf deinem eigenen Host statt auf geteilter Infrastruktur ausführen möchtest, müsstest du deine AWS Infrastruktur so einrichten, dass sie die Pipelines ausführen kann.
AWS CodePipeline
Eine weitere Option ist AWS CodePipeline zusammen mit CodeBuild und CodeDeploy. Das kann ebenfalls eine gute Alternative sein, wenn du deine Infrastruktur AWS-nativ halten möchtest. Für mich erscheint jedoch die Nutzung der Pipeline-Lösung deines eigenen Code-Hosts in den meisten Fällen die naheliegendere Option zu sein.
AWS CodePipeline eignet sich möglicherweise besser, wenn du Lambda-Funktionen einsetzt und Dinge wie Canary Deployments nutzen möchtest. Auch wenn du dasselbe mit deinem eigenen Git Host erreichen kannst, geht das mit AWS-nativen Tools oft deutlich einfacher.
Ein weiterer Vorteil ist, dass du die Pipeline innerhalb deines eigenen VPC statt außerhalb davon ausführen kannst.
Drittanbieter-Tools
Eine weitere Option wäre die Nutzung von Drittanbieter-Pipeline-Tools wie CircleCI. Diese bieten teils nützliche Integrationen, zum Beispiel wenn du eine große Codebasis hast und Tests parallel ausführen musst, um die Pipeline schneller abzuschließen.
Aber sofern du keinen wirklich guten Grund dafür hast, sehe ich keinen Anlass, warum du deine Pipeline nicht mit AWS CodePipeline oder dem CI/CD Tooling deines Git Hosts betreiben solltest.
Alles in allem: Wenn du dich dafür entscheidest, deine Pipelines außerhalb von AWS CodePipeline auszuführen, achte darauf, OIDC-basierten Zugriff für die Authentifizierung zu verwenden statt langlebiger IAM Secrets.
Sicherheit
Für Gen-AI-Anwendungen ist Compliance ein weiteres wichtiges Thema. Entscheidend ist dabei vor allem, was du erreichen möchtest.
Wenn du in der EU tätig sein wirst, ist die DSGVO ein Muss. Möglicherweise möchtest du zusätzlich SOC 2 oder ISO 27001 Compliance erreichen, was ein anderes Maß an Konfiguration und operativen Kontrollen erfordert.
Alles in allem solltest du unabhängig davon, ob du eine bestimmte Compliance erreichen möchtest, sicherstellen, dass du deine KI Workloads sicher auf AWS betreibst. Um das zu erreichen, gibt es einige Punkte, um die du dich kümmern solltest.
Allgemeine Sicherheit
Achte darauf, deine Secrets im AWS Secrets Manager zu speichern, oder im Parameter Store, wenn es einen guten Grund dafür gibt. Der Parameter Store unterstützt über SecureString ebenfalls verschlüsselte, sensible Werte.
Achte außerdem darauf, keine sensiblen Informationen zu loggen, wie zum Beispiel Zugangsdaten, personenbezogene Daten, Prompts oder Modellantworten, die vertrauliche Informationen enthalten.
Es gibt außerdem einige AWS Services, die du für das Security Monitoring konfigurieren kannst:
- Security Hub – zur Zentralisierung von Security Findings und zur Verwaltung deiner allgemeinen Sicherheitslage.
- GuardDuty – für kontinuierliche Bedrohungserkennung und Überwachung.
- Amazon Inspector – für Schwachstellen-Scans und Schwachstellenmanagement.
- CloudTrail – zur Nachverfolgung, welche Aktionen in deiner AWS Umgebung von wem durchgeführt wurden.
Compliance
Je nachdem, ob du Anforderungen wie SOC 2, ISO 27001 oder DSGVO erfüllen musst, kann deine Sicherheitslage ganz unterschiedlich aussehen.
Möglicherweise musst du zusätzliche Kontrollen für Zugriffsmanagement, Incident Management, Logging, Datenaufbewahrung, Verschlüsselung und Change Management einrichten.
Möglicherweise benötigst du außerdem zusätzliche Tools wie Vanta oder Drata zur Evidenzsammlung und Compliance-Überwachung. In diesem Fall solltest du sicherstellen, dass deine Kontrollen auch auf deine Gen-AI-Services und Workloads abgebildet werden, nicht nur auf deine klassische Infrastruktur.
Für Gen-AI-Anwendungen solltest du zusätzlich bedenken, wo Prompts und Modellantworten gespeichert werden, ob sensible Daten an das Modell gesendet werden, wer Zugriff auf diese Daten hat und wie lange sie aufbewahrt werden.