AWS har udgivet en teknisk vejledning, der viser, hvordan SageMaker AI Spaces kan installeres som et add-on direkte på en eksisterende Amazon EKS-klynge. Det giver data scientists mulighed for at starte managed JupyterLab og Code Editor på den samme klynge, hvor træning og pipelines kører. Ifølge blogindlægget tager en Space cirka 5 minutter at starte, hvor et selvhostet JupyterHub-setup med GPU, storage og auth ofte sluger 3–5 dage for et platformteam. Det er forfatternes tal, ikke en uafhængig måling, og bør læses som et eksempel snarere end en norm.
Hvem rammer det her? Platform‑ingeniører og MLOps‑ledere, der vil reducere kontekstskift og dobbelt drift, samt sikkerhedsansvarlige, der ønsker samlet kontrol over RBAC, IAM og hemmeligheder i én klynge fremfor spredte værktøjssiloer.
Hvad add-on’et gør — og ikke gør
SageMaker AI Spaces kører managed JupyterLab og Code Editor som pods på din eksisterende EKS‑klynge. Det minimerer behovet for en separat notebook‑flåde med selvbetjent patching, certifikater og adgangslogik. Ifølge AWS‑bloggen kan konsolidering holde GPU‑noder varme mellem jobs og øge udnyttelsen, i deres eksempel op til 30 procent. Metodik og baseline er ikke dokumenteret i detalje, så betragt det som en rettesnor, ikke et løfte.
Det ændrer ikke kravene til fundamentet: netværk, TLS, routing, IAM‑roller til pods og storage‑valg skal stadig på plads. Add-on’et skærer tid af IDE‑delen, men disciplinen skal løftes i klyngen.
Arkitektur i tre lag
Løsningen er beskrevet i tre lag: Network og access, Cluster routing samt Compute og storage. Route 53 peger et wildcard‑domæne mod en internetvendt Application Load Balancer. TLS leveres via AWS Certificate Manager. For Code Editor kan man omgå ALB ved at bruge SSH‑over‑SSM direkte til Space‑podden, hvilket hjælper i strammere netværk.
I klyngen provisionerer AWS Load Balancer Controller ALB’en, og Traefik ruter på hostname. En auth‑middleware validerer tokens, og AWS Key Management Service bruges til at kryptere JSON Web Tokens for central nøglestyring med audit og rotation.
Compute, storage og identitet
Spaces‑pods kører på worker‑nodes i private subnets. Persistent volumes leveres via Amazon EBS CSI‑driveren, mens delte eller høj‑throughput behov kan bruge Amazon EFS eller Amazon FSx. Valget EFS vs. FSx er et performance‑ og prismæssigt tradeoff, ikke blot en featurebeslutning — mål på jeres egne workloads, da bloggen ikke giver talbaserede sammenligninger.
Identitet håndteres med EKS Pod Identity, så pods får snævert scope’ede IAM‑roller. Det giver mulighed for at give en notebook præcis de tilladelser, der behøves — og ikke mere. Kombinér det med Secrets Manager til hemmeligheder frem for ConfigMaps eller generelle Kubernetes Secrets, som Snilld‑briefen anbefaler (erfaring, ikke et AWS‑udsagn).
Adgang og netværk i praksis
Wildcard‑domæner giver unikke subdomæner per Space. Det kræver en offentlig hosted zone i Route 53 og et gyldigt certifikat i ACM. Hvis certs roteres automatisk i andre systemer, så sikr, at ACM‑rotation og DNS‑opdateringer ikke afbryder aktive sessions.
Brugere kan tilgå deres Space via presigned URL i browseren. VS Code‑brugere kan forbinde via SSH‑over‑SSM, der tunneler direkte til podden. Bemærk omkostningen: SSM i advanced‑tier faktureres per time per Space‑pod, som bloggen også nævner — regn den ind ved langlivede sessions og mange samtidige brugere.
Sikkerhed, auth og grænser
Auth‑laget validerer tokens og anvender KMS til JWT‑kryptering, hvilket giver AWS‑native nøglelivscyklus og CloudTrail‑sporbarhed. Platformteams bør afklare håndtering af udløbne tokens for langlivede notebook‑sessions, sign‑out‑flow og effekter ved KMS‑nøglerotation i drift. Bloggen dækker principper, men ikke alle edge‑cases.
IRSA og stram RBAC er grundpillerne. Supplér med namespaces per team eller projekt, NetworkPolicies og en klar politik for hemmeligheder. Snilld‑briefen anbefaler Secrets Manager og Git‑baseret versionering af notebooks for at efterleve compliance og reproducibilitet (ikke et AWS‑udsagn).
Drift, skalering og omkostninger
Når interaktive og træningsworkloads samles i én klynge, kan autoscaling udnytte GPU‑noder mere kontinuerligt. Gevinsten kræver, at Cluster Autoscaler eller Karpenter justeres til jeres mix, herunder tolerations og prioriteter for interaktive pods kontra batch.
Spot kontra on‑demand: Overvej preemption‑strategi for notebooks, eller kør interaktive pods på on‑demand og baggrundsjobs på spot. EBS sikrer persistens, men brugere accepterer sjældent, at en session dør pga. preemption — afklar politikken, før I åbner bredt op.
Reproducerbarhed og governance
At flytte IDE’er ind i klyngen samler IAM, storage og GPU‑allokering. Det gør det nemmere at genkøre eksperimenter i samme miljø som produktion. Snilld‑briefen fremhæver, at eksterne notebooks kan underminere reproducibilitet, sikkerhed og driftseffektivitet; in‑cluster IDE’er adresserer en del af det (erfaring, ikke AWS‑udsagn).
Men reproducibilitet kræver praksis: CI\/CD for notebooks, versionering af dataudtræk og miljøer samt telemetry, der binder commit, image‑hash, datatidsstempel og modelartefakter sammen.
Implementeringscheckliste
Bloggens walkthrough: installer SageMaker AI Spaces‑add‑on på EKS, opsæt de støttende add‑ons og IAM‑roller, deploy AWS Load Balancer Controller, udsted et TLS‑certifikat og opret en KMS‑nøgle. Kravene omfatter Kubernetes 1.30+ på EC2‑backede noder og Spaces‑add‑on i version 0.1.4 eller nyere. Tidligere versioner var kun til SageMaker HyperPod.
Praktiske tilføjelser fra MLOps‑drift: fastlæg wildcard‑domæne og TLS‑plan, vælg identitetskilde til OIDC (bloggen demonstrerer Cognito; migrering fra virksomhedens IdP kræver plan for grupper og provisioning), definér en IRSA‑politik per Space‑rolle, beslut storage‑profil pr. team (EBS til persistens, EFS eller FSx til deling og throughput), sæt quotas for GPU og ephemeral storage, og få logning og metrics ind i jeres standard‑stack før piloten.
Tre reelle tradeoffs
Én klynge, flere liv: Når interaktive miljøer deler plads med træning og inference, bliver cluster‑opgraderinger mere følsomme. Rolling upgrades kan ramme aktive sessions. Håndter det med vinduer, PDB’er og tydelig kommunikation.
Større angrebsflade: En hostet IDE‑pod med brede rettigheder er et oplagt mål. Hvis RBAC, IRSA og secrets‑styring halter, bliver blast radius stor. Hold roller små, brug namespaces disciplineret, og overvåg brugerkontekster for mistænkelig adfærd.
Storage‑latens og throughput: Delte filer via EFS eller FSx kan mærkes i workloads med mange små filer. Bloggen lister mulighederne, men ikke tallene. Profilér jeres IO, før I vælger — det er dyrt at skifte bagefter.
Hvad platformteams bør prioritere
Start med netværk og TLS. Uden wildcard‑DNS og gyldigt cert bliver oplevelsen skrøbelig. Dernæst auth og IRSA, så notebooks ikke ender med brede service‑konti. Tredje skridt er storage‑politikken: hvem får EBS‑persistens, og hvor skal EFS eller FSx bruges.
Sæt derefter autoscaling og GPU‑prioriteter. Definér klasser af workloads og preemption‑regler. Etabler en lille CI‑pipeline for notebooks fra dag ét og tilføj telemetry. Hvis commit og image ikke kan spores til en model, er gevinsten ved in‑cluster IDE’er kun halv.
Fra JupyterHub til Spaces uden nedetid
En pragmatisk migration: kør JupyterHub og Spaces parallelt. Opret teams som namespaces i EKS med kvoter og IRSA‑roller. Giv brugerne en guide til at synkronisere notebooks til Git og et script, der starter en Space med samme base‑image og requirements.
Flyt de første teams og mål GPU‑udnyttelse, pod‑levetid og storage‑IO før og efter. Når tallene er stabile, luk for nye projekter i JupyterHub og kør dem i Spaces. Sluk først den gamle løsning, når backup og eksport af brugermapper er testet end‑to‑end.
Uafklarede spørgsmål
To praksispunkter mangler moden dokumentation i bloggen: enterprise‑opgraderinger af Spaces‑add‑on’et med mange samtidige IDE‑pods, samt backup\/restore‑mønstre for brugerdata på EBS\/EFS i stor skala. Desuden er integration til eksisterende IdP’er, rolle‑mapping og gruppesynk ikke fuldt beskrevet.
Estimater som 3–5 dage vs. ~5 minutter og “op til 30 procent” GPU‑løft bør valideres mod jeres kontekst (workload‑mix, baseline og automation). Brug dem som pejlemærker, ikke facit.
Konklusion
SageMaker AI Spaces som add‑on på EKS lukker hullet mellem interaktiv udvikling og produktionsnære miljøer. Gevinsterne er reelle: mindre friktion for brugere og mulighed for bedre GPU‑udnyttelse. Til gengæld kræver det stram styring af netværk, identitet, storage og omkostninger. Det er en god handel, hvis udrulningen sker med en klar plan.
Start i en dev‑klynge med rigtige certs, IRSA, en enkel notebook‑CI og to pilotteams. Mål før og efter — og flyt først derefter til produktion.
