So lässt sich TrueFoundry in AWS integrieren: Die Architektur einer Steuerungsebene

Für Cloud-Architekten und DevOps-Ingenieure besteht die größte Herausforderung bei der Skalierung generativer KI oft nicht in der Verfügbarkeit von Rechenressourcen, sondern in der Orchestrierung dieser Ressourcen. AWS bietet leistungsstarke Primitive — Amazon EKS, Spot-Instances, IAM-Rollen, und Amazonas Bedrock. Die Kombination dieser Elemente zu einer kohärenten internen Entwicklerplattform erfordert jedoch häufig eine komplexe Konfiguration und laufende Wartung.

TrueFoundry fungiert als Orchestrierungsebene und befindet sich als Infrastruktur-Overlay direkt in Ihrem AWS-Konto. Im Folgenden werden wir genau aufschlüsseln, wie die Plattform in AWS integriert ist. Dabei werden Sicherheitsgrenzen, Identitätsverbund, Netzwerke und Rechenoptimierung behandelt.

Das Einsatzmodell: Control Plane vs. Compute Plane

Wir verwenden eine Split-Plane-Architektur, um das Management von der Ausführung zu entkoppeln.

• Die Kontrollebene: Dies ist die Verwaltungsebene (API und Dashboard). Sie verarbeitet Metadaten, Benutzerauthentifizierung (RBAC) und Auftragsplanung.
• Die Rechenebene: Hier findet die eigentliche Arbeit statt. Es besteht aus Agenten und Controllern, die laufen auf dein Amazon EKS-Cluster, der Modellgewichte, Kundendaten und GPU-Verarbeitung verarbeitet.

Die Konnektivität basiert auf einem sicheren, nur ausgehenden WebSocket- oder gRPC-Stream. Der in Ihrem Cluster ausgeführte Agent stellt die Verbindung zur Control Plane her, um neue Bereitstellungsmanifeste abzurufen und Statusaktualisierungen (wie den Zustand des Pods) zu übertragen. Da der Datenverkehr nur ausgehend erfolgt, müssen Sie keine eingehenden Ports in Ihren VPC-Sicherheitsgruppen öffnen, sodass Ihre VPC vollständig privat bleibt.

‍

Architekturdiagramm: Split-Plane Security

‍

Abbildung 1: Die Split-Plane-Architektur stellt sicher, dass die Daten in der Kunden-VPC gespeichert bleiben.

Netzwerktopologie und Verkehrsfluss

Bei der Bereitstellung von TrueFoundry in einer AWS-Umgebung nutzt die Netzwerkkonfiguration die ALS PVC-CNI Plugin für Kubernetes. Rechenressourcen werden in privaten Subnetzen betrieben, wodurch sichergestellt wird, dass Inferenzendpunkte nicht standardmäßig mit dem öffentlichen Internet verbunden sind.

Eingangs- und Austrittsmuster

• Eingehender Verkehr (Inferenzanfragen): Der Anwendungsdatenverkehr gelangt über eine AWS-Anwendungslastenausgleich (ALB), verwaltet vom AWS Load Balancer Controller. Das ALB beendet TLS-Verbindungen und leitet Anfragen an das Istio Ingress Gateway weiter, das im EKS-Cluster ausgeführt wird.
• Ausgehender Verkehr (Registrierung und APIs): EKS-Worker-Knoten benötigen ausgehenden Netzwerkzugriff, um Container-Images abzurufen Amazon ECR und kommunizieren Sie mit der Control Plane API. Dieser Verkehr wird über ein NAT-Gateway geleitet, das den privaten Subnetzen zugeordnet ist.

Service Mesh-Integration

TrueFoundry stellt bereit Istio um den Ost-West-Verkehr zwischen Microservices zu verwalten. In einer RAG-Pipeline, in der ein Einbettungsdienst mit einer Vektordatenbank kommuniziert, verwaltet Istio beispielsweise das Routing und erzwingt gegenseitiges TLS (mTLS). Dadurch wird sichergestellt, dass der interne Cluster-Verkehr während der Übertragung verschlüsselt wird, ohne dass Änderungen auf Anwendungsebene erforderlich sind.

Abbildung 2: Netzwerkverkehrsfluss, der den Eingang für Inferenz und den Ausgang für Abhängigkeiten zeigt.

Identitätsverbund und Sicherheit

Ein primäres Sicherheitsziel in AWS-Unternehmensumgebungen ist die Entfernung statischer Anmeldeinformationen. TrueFoundry begegnet diesem Problem durch die Implementierung IAM-Rollen für Dienstkonten (IRSA).

Der Authentifizierungsablauf

Wenn ein Benutzer einen Workload bereitstellt, z. B. einen Feinabstimmungsjob oder einen Inferenzdienst, führt die Plattform den folgenden Workflow aus:

1. Erstellung eines Dienstkontos: TrueFoundry erstellt ein Kubernetes-Dienstkonto im Workload-Namespace.
2. Rollenzuweisung: Das Servicekonto ist mit dem ARN einer vorab bereitgestellten AWS-IAM-Rolle annotiert.
3. Token-Austausch: Das EKS OIDC-Anbieter validiert das vom Cluster für den Pod ausgegebene JSON Web Token (JWT).
4. Ausstellung von Zugangsdaten: Der Pod tauscht dieses OIDC-Token mit AWS STS (Security Token Service) aus, um temporäre, rotierende AWS-Anmeldeinformationen zu erhalten.

Dieser Mechanismus stellt sicher, dass der Anwendungscode standardmäßige AWS-SDKs (z. B. boto3) ohne fest codierte Geheimnisse verwendet. Wenn ein Pod kompromittiert wird, beschränken sich die potenziellen Auswirkungen auf die spezifischen Berechtigungen, die dieser IAM-Rolle gewährt wurden, und Anmeldeinformationen laufen automatisch ab.

Abbildung 3: Der von TrueFoundry-Workloads verwendete IRSA-Authentifizierungsablauf.

Compute Engine: EKS, Karpenter und Spot-Optimierung

Die Ausführung von Large Language Models (LLMs) auf On-Demand-Instances ist mit erheblichen Kostenproblemen verbunden. TrueFoundry orchestriert Karpenter, das Open-Source-System zur Bereitstellung von Kubernetes-Knoten, zur Optimierung der Rechenauslastung.

Spot-Instance-Orchestrierung

TrueFoundry bietet spezielle Logik für die Verwaltung EC2-Spot-Instances:

• Bereitstellung von Kapazitäten: Wenn eine Bereitstellung Ressourcen (z. B. 24 GB VRAM) anfordert, weist die Plattform Karpenter an, den kostengünstigsten Instance-Typ bereitzustellen, der die Einschränkungen erfüllt. Dies kann je nach aktueller Verfügbarkeit in der AWS-Region zu einem Wert von g5.2xlarge, g5.4xlarge oder p3.2xlarge führen.
• Umgang mit Unterbrechungen: Das System überwacht die Mitteilung zur Kündigung der EC2 Spot-Instance, das vor der Rückforderung der Instanz eine zweiminütige Warnung ausgibt.
• Proaktiver Ersatz: Wenn über den AWS Node Termination Handler ein Terminierungssignal erkannt wird, sperrt die Plattform den betroffenen Knoten ab, leitet Verbindungen ab und veranlasst Karpenter, sofort einen Ersatz bereitzustellen.

Diese Orchestrierung ermöglicht die zuverlässige Verwendung von Spot-Instances für Inferenz-Workloads in der Produktion, was in der Regel zu Einsparungen von bis zu 70% im Vergleich zu On-Demand-Preisen für punkttolerante Workloads.

Das KI-Gateway: Die Vereinigung von Bedrock und SageMaker

Für Unternehmen, die proprietäre Modelle verwenden, dient TrueFoundry als einheitliche API-Schnittstelle für Amazonas Bedrock und Amazon SageMaker.

Bedrock-Integrationsmuster

Anstatt direkte AWS-SDK-Aufrufe in den Anwendungscode einzubetten, leiten Entwickler Anfragen über das TrueFoundry Gateway weiter. Das Gateway führt Folgendes aus:

• Authentifizierung: Überprüft den internen API-Schlüssel anhand der Control Plane-Registrierung.
• Telemetrie: Protokolliert die Anzahl der Eingabe- und Ausgabetokens für eine detaillierte Kostenzuweisung und Prüfprotokolle.
• Stellvertretung: Signiert Anfragen mit der eigenen IAM-Rolle des Gateways und leitet sie an den Bedrock InvokeModel-Endpunkt weiter.

Diese Zentralisierung ermöglicht es Administratoren, Zugriffsrichtlinien auf Gateway-Ebene zu verwalten, ohne ständig die IAM-Richtlinien zu ändern oder die AWS-Anmeldeinformationen zu wechseln.

SageMaker-Integrationsmuster

TrueFoundry unterstützt die Bereitstellung von Modellen auf SageMaker-Endpunkten. Die Plattform bietet jedoch auch die Möglichkeit, Modelle direkt auf EC2/EKS bereitzustellen. Diese Alternative ermöglicht es Unternehmen, die Prämien zu umgehen, die normalerweise mit vollständig verwalteten Inferenzendpunkten verbunden sind, und gleichzeitig ein einheitliches Bereitstellungserlebnis für den Entwickler aufrechtzuerhalten.

Kompatibilität mit Infrastruktur als Code (IaC)

TrueFoundry wurde für die Integration in bestehende Infrastructure-as-Code-Workflows entwickelt. Die Plattform bietet verifizierte Terraform-Module zur Bereitstellung der erforderlichen zugrunde liegenden Infrastruktur:

• VPC und Netzwerk: Konfiguriert private Subnetze, NAT-Gateways und Sicherheitsgruppen gemäß den Best Practices von AWS.
• EKS-Cluster: Stellt die Kubernetes-Steuerungsebene, verwaltete Knotengruppen und wichtige Add-Ons wie den VPC-CNI- und EBS-CSI-Treiber bereit.
• Datenbanken: Bestimmungen Amazon RDS Instanzen für die Metadatenspeicherung, wenn die Control Plane selbst gehostet wird.

Dadurch wird sichergestellt, dass die Umgebung aus AWS-Standardressourcen besteht, die in der Terraform-Statusdatei des Kunden definiert sind und vollständig überprüfbar bleiben.

Vergleich: AWS Native gegen AWS + TrueFoundry

In der folgenden Tabelle werden die betrieblichen Unterschiede zwischen der Erstellung einer Plattform mit unformatierten AWS-Primitiven und der Verwendung des TrueFoundry-Overlays beschrieben.

Fazit: Architektonische Ausrichtung

Die Integration von TrueFoundry mit AWS entspricht dem architektonischen Muster, den Hyperscaler für die Zuverlässigkeit der Infrastruktur zu verwenden und gleichzeitig eine spezielle Steuerungsebene für das anwendungsspezifische Management zu implementieren.

Für Unternehmen, die in AWS investiert haben, bietet dieses Modell einen Mechanismus zur Modernisierung des KI-Betriebs unter Beibehaltung der bestehenden Datenspeicherorte und Sicherheitsgrenzen. Der Kunde behält die Kontrolle über die VPC- und Sicherheitsgrenzen und nutzt TrueFoundry, um die Komplexität des KI-Anwendungslebenszyklus zu optimieren.

‍