Wie TrueFoundry in AWS integriert wird: Die Architektur einer Control Plane

Für Cloud-Architekten und DevOps-Engineers besteht die größte Herausforderung bei der Skalierung von Generativer KI selten in der Verfügbarkeit von Rechenressourcen, sondern in deren Orchestrierung. AWS bietet leistungsfähige Bausteine – Amazon EKS, Spot Instances, IAM-Rollen und Amazon Bedrock. Diese jedoch in eine nahtlose interne Entwicklerplattform zu integrieren, erfordert oft mehraufwendige Konfigurationen und kontinuierliche Wartung.

TrueFoundry fungiert als diese Orchestrierungsschicht und liegt als Infrastruktur-Overlay direkt in Ihrem AWS-Konto. Im Folgenden schlüsseln wir detailliert auf, wie die Plattform in AWS integriert ist – von Sicherheitsgrenzen und Identitätsföderation bis hin zu Networking und Compute-Optimierung.

Das Bereitstellungsmodell: Control Plane vs. Compute Plane

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

• Die Control Plane: Dies ist die Verwaltungsschicht (API und Dashboard). Sie kümmert sich um Metadaten, Benutzerauthentifizierung (RBAC) und Job-Scheduling.
• Die Compute Plane: Hier findet die eigentliche Datenverarbeitung statt. Sie besteht aus Agenten und Controllern, die auf Ihrem Amazon EKS-Cluster laufen und Modellgewichte, Kundendaten sowie die GPU-Verarbeitung verwalten.

Die Konnektivität basiert auf einem sicheren, reinen Outbound-WebSocket- oder gRPC-Stream. Der in Ihrem Cluster laufende Agent initiiert die Verbindung zur Control Plane, um neue Deployment-Manifeste abzurufen und Status-Updates (wie die Pod-Health) zu senden. Da der Datenverkehr ausschließlich ausgehend ist, müssen Sie keine eingehenden Ports in Ihren VPC Security Groups öffnen – Ihre VPC bleibt somit vollständig privat.

‍

Architekturdiagramm: Split-Plane-Sicherheit

‍

Abb. 1: Die Split-Plane-Architektur stellt sicher, dass die Datenresidenz innerhalb der Kunden-VPC verbleibt.

Netzwerk-Topologie und Datenfluss

Bei der Bereitstellung von TrueFoundry in einer AWS-Umgebung nutzt die Netzwerkkonfiguration das AWS VPC CNI-Plugin für Kubernetes. Die Compute-Ressourcen arbeiten in privaten Subnetzen, was sicherstellt, dass Inference-Endpunkte standardmäßig nicht dem öffentlichen Internet ausgesetzt sind.

Ingress- und Egress-Muster

• Inbound-Traffic (Inference-Anfragen): Anwendungs-Traffic gelangt über einen AWS Application Load Balancer (ALB) in die VPC, der vom AWS Load Balancer Controller verwaltet wird. Der ALB terminiert TLS-Verbindungen und leitet Anfragen an das Istio Ingress Gateway innerhalb des EKS-Clusters weiter.
• Outbound-Traffic (Registry & APIs): EKS-Worker-Nodes benötigen ausgehenden Netzwerkzugriff, um Container-Images aus Amazon ECR abzurufen und mit der Control-Plane-API zu kommunizieren. Dieser Traffic wird über ein NAT Gateway geroutet, das den privaten Subnetzen zugeordnet ist.

Service-Mesh-Integration

TrueFoundry setzt Istio ein, um den Ost-West-Traffic zwischen Microservices zu verwalten. In einer RAG-Pipeline beispielsweise, in der ein Embedding-Service mit einer Vektordatenbank kommuniziert, steuert Istio das Routing und erzwingt mutual TLS (mTLS). Dadurch wird der interne Cluster-Traffic während der Übertragung verschlüsselt, ohne dass Anpassungen auf Anwendungsebene erforderlich sind.

Abb. 2: Netzwerk-Datenfluss mit Ingress für Inference und Egress für Abhängigkeiten.

Identitätsföderation und Sicherheit

Ein zentrales Sicherheitsziel in Enterprise-AWS-Umgebungen ist das Vermeiden statischer Anmeldeinformationen. TrueFoundry löst dies durch die Implementierung von IAM Roles for Service Accounts (IRSA).

Der Authentifizierungsablauf

Wenn ein Benutzer einen Workload bereitstellt, wie beispielsweise einen Fine-Tuning-Job oder einen Inference-Service, führt die Plattform folgenden Workflow aus:

1. Erstellung des Service Accounts: TrueFoundry erstellt einen Kubernetes Service Account im Namespace des Workloads.
2. Rollenverknüpfung: Der Service Account wird mit dem ARN einer vorab bereitgestellten AWS IAM-Rolle annotiert.
3. Token-Austausch: Der EKS OIDC Provider validiert das JSON Web Token (JWT), das vom Cluster an den Pod ausgestellt wurde.
4. Ausstellung der Credentials: Der Pod tauscht dieses OIDC-Token bei AWS STS (Security Token Service) gegen temporäre, rotierende AWS-Anmeldeinformationen ein.

Dieser Mechanismus stellt sicher, dass der Anwendungscode standardmäßige AWS SDKs (z. B. boto3) ohne fest codierte Secrets verwendet. Sollte ein Pod kompromittiert werden, beschränkt sich der potenzielle Schaden auf die spezifischen Berechtigungen dieser IAM-Rolle, und die Anmeldeinformationen laufen automatisch ab.

Abb. 3: Der IRSA-Authentifizierungsablauf für TrueFoundry-Workloads.

Compute Engine: EKS, Karpenter und Spot-Optimierung

Der Betrieb von Large Language Models (LLMs) auf On-Demand-Instanzen bringt erhebliche Kostenherausforderungen mit sich. TrueFoundry orchestrirt Karpenter, das Open-Source-System zur Bereitstellung von Kubernetes-Nodes, um die Compute-Auslastung zu optimieren.

Orchestrierung von Spot-Instanzen

TrueFoundry bietet spezialisierte Logik zur Verwaltung von EC2 Spot Instances:

• Kapazitätsbereitstellung: Wenn ein Deployment Ressourcen anfordert (z. B. 24 GB VRAM), weist die Plattform Karpenter an, den kosteneffizientesten Instanztyp bereitzustellen, der die Bedingungen erfüllt. Dies kann je nach aktueller Verfügbarkeit in der AWS-Region eine g5.2xlarge, g5.4xlarge oder p3.2xlarge sein.
• Handhabung von Unterbrechungen: Das System überwacht die EC2 Spot Instance Termination Notice, die eine Vorwarnung von zwei Minuten vor der Rückforderung einer Instanz ausgibt.
• Proaktiver Ersatz: Sobald ein Beendigungssignal über den AWS Node Termination Handler erkannt wird, setzt die Plattform den betroffenen Node auf "Cordon", baut bestehende Verbindungen ab ("Drain") und veranlasst Karpenter, sofort einen Ersatz bereitzustellen.

Diese Orchestrierung ermöglicht die zuverlässige Nutzung von Spot-Instanzen für Produktions-Inference-Workloads, was bei spot-toleranten Workloads typischerweise zu Einsparungen von bis zu 70 % gegenüber den On-Demand-Preisen führt.

Das AI Gateway: Bedrock und SageMaker vereinen

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

Bedrock-Integrationsmuster

Anstatt direkte AWS SDK-Aufrufe im Anwendungscode zu verankern, leiten Entwickler Anfragen über das TrueFoundry Gateway. Das Gateway übernimmt dabei:

• Authentifizierung: Überprüft den internen API-Schlüssel gegen das Register der Control Plane.
• Telemetrie: Erfasst Input- und Output-Token-Zahlen für eine präzise Kostenzuordnung und Audit-Trails.
• Proxying: 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 direkt auf Gateway-Ebene zu verwalten, ohne ständig IAM-Policys anpassen oder AWS-Credentials rotieren zu müssen.

SageMaker-Integrationsmuster

TrueFoundry unterstützt die Bereitstellung von Modellen auf SageMaker-Endpunkten. Darüber hinaus bietet die Plattform jedoch die Möglichkeit, Modelle direkt auf EC2/EKS bereitzustellen. Diese Alternative erlaubt es Unternehmen, die typischen Aufpreise voll verwalteter Inference-Endpunkte zu umgehen und gleichzeitig eine konsistente Bereitstellungserfahrung für Entwickler beizubehalten.

Kompatibilität mit Infrastructure as Code (IaC)

TrueFoundry ist so konzipiert, dass es sich nahtlos in bestehende Infrastructure as Code-Workflows einfügt. Die Plattform bietet verifizierte Terraform Modules zur Bereitstellung der erforderlichen zugrundeliegenden Infrastruktur:

• VPC & Networking: Konfiguriert private Subnetze, NAT Gateways und Security Groups gemäß den AWS Best Practices.
• EKS Cluster: Stellt die Kubernetes Control Plane, verwaltete Node-Gruppen und essenzielle Add-ons wie den VPC CNI und EBS CSI-Treiber bereit.
• Datenbanken: Richtet Amazon RDS-Instanzen für die Metadaten-Speicherung ein, falls die Control Plane selbst gehostet wird.

Dies stellt sicher, dass die Umgebung aus Standard-AWS-Ressourcen besteht, die im Terraform-State des Kunden definiert sind und vollständig auditierbar bleiben.

Vergleich: AWS Nativ vs. AWS + TrueFoundry

Die folgende Tabelle zeigt die operationalen Unterschiede zwischen dem Aufbau einer Plattform mit reinen AWS-Bausteinen und der Nutzung des TrueFoundry-Overlays.

Fazit: Architektur im Einklang

Die Integration von TrueFoundry mit AWS folgt dem Architekturmuster, den Hyperscaler für die Zuverlässigkeit der Infrastruktur zu nutzen, während eine spezialisierte Control Plane das anwendungsspezifische Management übernimmt.

Für Unternehmen, die auf AWS setzen, bietet dieses Modell die Möglichkeit, den AI-Betrieb zu modernisieren und gleichzeitig bestehende Datenresidenzen sowie Sicherheitsgrenzen zu wahren. Der Kunde behält die Kontrolle über die VPC und die Sicherheitsgrenzen, während TrueFoundry die Komplexität des AI-Anwendungslebenszyklus vereinfacht.

‍