Hoe TrueFoundry integreert met AWS: de architectuur van een Control Plane

Voor cloudarchitecten en DevOps-engineers is de grootste uitdaging bij het schalen van Generatieve AI vaak niet de beschikbaarheid van compute-resources, maar de orchestratie van die resources. AWS biedt krachtige primitives -- Amazon EKS, Spot Instances, IAM-rollen en Amazon Bedrock. Het combineren hiervan tot een samenhangend interne ontwikkelaarsplatform vereist echter vaak complexe configuratie en continu onderhoud.

TrueFoundry fungeert als die orchestratielaag en bevindt zich als een infrastructuuroverlay direct binnen uw AWS-account. Hieronder leggen we precies uit hoe het platform integreert met AWS—met aandacht voor beveiligingsgrenzen, identiteitsfederatie, netwerken en compute-optimalisatie.

Het deploymentmodel: Control Plane vs. Compute Plane

We gebruiken een gescheiden-architectuur om beheer los te koppelen van uitvoering.

• De Control Plane: Dit is de beheerlaag (API en dashboard). Deze verwerkt metadata, gebruikersauthenticatie (RBAC) en job scheduling.
• De Compute Plane: Dit is waar het daadwerkelijke werk plaatsvindt. Het bestaat uit agents en controllers die draaien op uw Amazon EKS-cluster en modelgewichten, klantgegevens en GPU-verwerking afhandelen.

Connectivity berust op een veilige, outbound-only WebSocket- of gRPC-stream. De agent die in uw cluster draait, initieert de verbinding met de Control Plane om nieuwe deploymentmanifesten op te halen en status-updates (zoals pod-status) te pushen. Omdat het verkeer uitsluitend uitgaand is, hoeft u geen inkomende poorten te openen in uw VPC-security groups—waardoor uw VPC volledig privé blijft.

‍

Architectuurdiagram: Split-Plane Security

‍

Afb. 1: De Split-Plane-architectuur zorgt ervoor dat dataresidentie binnen de VPC van de klant blijft.

Netwerktopologie en verkeersstroom

Bij het deployen van TrueFoundry in een AWS-omgeving maakt de netwerkconfiguratie gebruik van de AWS VPC CNI-plugin voor Kubernetes. Compute-resources werken binnen privé-subnets, wat ervoor zorgt dat inference-endpoints standaard niet worden blootgesteld aan het openbare internet.

Ingress- en Egress-patronen

• Inkomend verkeer (Inference-verzoeken): Applicatieverkeer komt de VPC binnen via een AWS Application Load Balancer (ALB), beheerd door de AWS Load Balancer Controller. De ALB beëindigt TLS-verbindingen en stuurt verzoeken door naar de Istio Ingress Gateway die binnen het EKS-cluster draait.
• Uitgaand verkeer (Registry & API's): EKS worker nodes vereisen uitgaande netwerktoegang om container-images op te halen uit Amazon ECR en te communiceren met de Control Plane API. Dit verkeer wordt gerouteerd via een NAT Gateway die is gekoppeld aan de privé-subnets.

Service Mesh-integratie

TrueFoundry zet Istio in om oost-west-verkeer tussen microservices te beheren. Bijvoorbeeld, in een RAG-pipeline waar een embedding-service communiceert met een vectordatabase, beheert Istio de routing en dwingt het mutual TLS (mTLS) af. Dit zorgt ervoor dat intern clusterverkeer onderweg is versleuteld zonder dat er wijzigingen op applicatieniveau nodig zijn.

Afb. 2: Netwerkverkeersstroom die ingress voor inference en egress voor afhankelijkheden demonstreert.

Identiteitsfederatie en beveiliging

Een primair beveiligingsdoel in enterprise AWS-omgevingen is het elimineren van statische credentials. TrueFoundry pakt dit aan door het implementeren van IAM Roles for Service Accounts (IRSA).

De authenticatiestroom

Wanneer een gebruiker een workload deployt, zoals een fine-tuning-job of een inference-service, voert het platform de volgende workflow uit:

1. Aanmaken van Service Account: TrueFoundry maakt een Kubernetes Service Account aan in de namespace van de workload.
2. Koppeling van rol: De Service Account wordt geannoteerd met de ARN van een vooraf geprovisioneerde AWS IAM-rol.
3. Tokenuitwisseling: De EKS OIDC-provider valideert het JSON Web Token (JWT) dat door het cluster aan de pod is uitgegeven.
4. Afgifte van credentials: De pod wisselt dit OIDC-token uit met AWS STS (Security Token Service) om tijdelijke, roterende AWS-credentials te ontvangen.

Dit mechanisme zorgt ervoor dat applicatiecode standaard AWS SDK's (bijv. boto3) gebruikt zonder hardcoded secrets. Als een pod gecompromitteerd raakt, blijft de potentiële impact beperkt tot de specifieke rechten die aan die IAM-rol zijn verleend, en verlopen de credentials automatisch.

Afb. 3: De IRSA-authenticatiestroom die door TrueFoundry-workloads wordt gebruikt.

Compute Engine: EKS, Karpenter en Spot-optimalisatie

Het draaien van Large Language Models (LLM's) op on-demand instances brengt aanzienlijke kostenuitdagingen met zich mee. TrueFoundry orchestreert Karpenter, het open-source Kubernetes node-provisioningsysteem, om de compute-benutting te optimaliseren.

Orchestratie van Spot Instances

TrueFoundry biedt gespecialiseerde logica voor het beheren van EC2 Spot Instances:

• Capaciteitsprovisioning: Wanneer een deployment om resources vraagt (bijv. 24 GB VRAM), stuurt het platform Karpenter aan om het meest kosteneffectieve instancetype te provisioneren dat aan de vereisten voldoet. Dit kan resulteren in een g5.2xlarge, g5.4xlarge of p3.2xlarge, afhankelijk van de actuele beschikbaarheid in de AWS-regio.
• Afhandeling van onderbrekingen: Het systeem monitort de EC2 Spot Instance Termination Notice, die twee minuten van tevoren waarschuwt voordat een instance wordt teruggevraagd.
• Proactieve vervanging: Bij het detecteren van een beëindigingssignaal via de AWS Node Termination Handler cordont het platform de getroffen node af, sluit het actieve verbindingen en geeft het Karpenter direct de opdracht een vervanger te provisioneren.

Deze orchestratie maakt het betrouwbare gebruik van Spot Instances mogelijk voor productie-inferenceworkloads, wat doorgaans leidt tot besparingen van tot wel 70% in vergelijking met On-Demand-prijzen voor spot-tolerante workloads.

De AI Gateway: Bedrock en SageMaker verenigd

Voor organisaties die eigen modellen gebruiken, dient TrueFoundry als een universele API-interface voor Amazon Bedrock en Amazon SageMaker.

Bedrock-integratiepatronen

In plaats van directe AWS SDK-calls in de applicatiecode te verwerken, routen ontwikkelaars verzoeken via de TrueFoundry Gateway. De Gateway voert de volgende taken uit:

• Authenticatie: Verifieert de interne API-sleutel tegen het Control Plane-register.
• Telemetrie: Logt het aantal in- en uitgaande tokens voor gedetailleerde kostentoewijzing en audit trails.
• Proxying: Ondertekent verzoeken met de eigen IAM-rol van de Gateway en stuurt deze door naar het Bedrock InvokeModel-endpoint.

Deze centralisatie stelt beheerders in staat om toegangsbeleid op Gateway-niveau te beheren zonder continu IAM-policies aan te passen of AWS-credentials te roteren.

SageMaker-integratiepatronen

TrueFoundry ondersteunt het deployen van modellen naar SageMaker-endpoints. Het platform biedt echter ook de mogelijkheid om modellen rechtstreeks op EC2/EKS te deployen. Dit alternatief stelt organisaties in staat om de extra kosten te vermijden die doorgaans verbonden zijn aan volledig beheerde inference-endpoints, terwijl een consistente deploymentervaring voor de ontwikkelaar behouden blijft.

Infrastructure as Code (IaC)-compatibiliteit

TrueFoundry is ontworpen om te integreren met bestaande Infrastructure as Code-workflows. Het platform biedt geverifieerde Terraform-modules om de vereiste onderliggende infrastructuur te provisioneren:

• VPC & Netwerken: Configureert privé-subnets, NAT gateways en Security Groups volgens de beste praktijken van AWS.
• EKS-cluster: Provisioneert de Kubernetes control plane, managed node groups en essentiële add-ons zoals de VPC CNI en EBS CSI driver.
• Databases: Provisioneert Amazon RDS-instances voor opslag van metadata als de Control Plane self-hosted is.

Dit zorgt ervoor dat de omgeving bestaat uit standaard AWS-resources die zijn gedefinieerd in het Terraform statefile van de klant, waardoor deze volledig auditeerbaar blijft.

Vergelijking: AWS Native vs. AWS + TrueFoundry

De volgende tabel geeft een overzicht van de operationele verschillen tussen het bouwen van een platform met behulp van ruwe AWS-primitives versus het gebruik van de TrueFoundry-overlay.

Conclusie: Architecturale afstemming

De integratie van TrueFoundry met AWS sluit aan bij het architecturale patroon om de hyperscaler te gebruiken voor infrastructuurbetrouwbaarheid, terwijl een gespecialiseerde control plane wordt geïmplementeerd voor applicatiespecifiek beheer.

Voor organisaties die in AWS hebben geïnvesteerd, biedt dit model een mechanisme om AI-operaties te moderniseren met behoud van bestaande dataresidentie en beveiligingsperimeters. De klant behoudt de controle over de VPC en beveiligingsgrenzen, terwijl TrueFoundry wordt gebruikt om de complexiteit van de AI-applicatielifecycle te stroomlijnen.

‍