Build1 publisherNot yet confirmed elsewhere2 min readPublished
Three managed IAM policies decide who launches HyperPod Spaces from SageMaker Studio
AWS now lets SageMaker Studio users launch JupyterLab and Code Editor Spaces on HyperPod EKS clusters from the browser, with no kubectl step. On a shared GPU cluster, who may launch them comes down to three managed IAM policies and a per-user identity setting that older Studio domains must switch on.
The Engineer · Build desk
What happened
- A new IDE and Notebooks tab on the HyperPod cluster detail page handles creating, configuring, starting, stopping and opening Spaces.
- Spaces open in the browser as JupyterLab or Code Editor, or connect to a remote IDE such as VS Code.
- A searchable table lists every Space with its application type, status, access type, storage, GPU and vCPU allocation.
- After installing the Spaces add-on, administrators set up namespaces and Space templates and manage access through EKS access entries.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Launch rights follow the IAM role, so teams sharing a cluster have to decide which roles get Space permissions before data scientists start clicking Create.
- capability With identity propagation on, a platform team can trace any Space create, stop or delete in CloudTrail to a named Studio user when GPU contention starts.
- cost Idle notebooks now compete with training for capacity on a shared cluster, because the post's way to free compute from a Space is its user selecting stop.
I think the command line was acting as an informal gate on shared HyperPod clusters. Until this release, creating and managing Spaces went mainly through the HyperPod CLI or kubectl [2]. Whoever launched a notebook was already working with cluster tooling [2]. Spaces run interactive work on the same EKS infrastructure as training jobs and model deployment, with fractional GPU allocations [3]. HyperPod's training side is built to spread jobs across hundreds of accelerators [15]. A Space started from a browser tab draws on that same pool [17].
The replacement gate lives in EKS [10]. The three managed policies are AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy and AmazonSagemakerHyperpodSpaceTemplatePolicy, and administrators attach them to the IAM roles data scientists use [11]. Ownership attaches to the person. The identity mapping records which user created a Space and whether it is private or shared across the Studio domain [14]. I think that split is the right design. A group can share one role, and the platform team can still see whose Space is holding which GPU allocation [6][14].
The install defaults need a careful read. Quick install is one-click with optimized defaults, and Custom install is the option required for web browser access [9]. The button labelled Quick is the one that leaves out the browser feature this release is about [9]. Studio domains created before the integration rolled out must also switch on per-user identity propagation to the cluster [12]. The post does not say what an older domain does if that step is skipped.
Quota is the other control on who can launch what. The create form puts HyperPod Task Governance for compute quota management next to the compute, namespace, storage and image settings [5]. AWS says the change cuts the time from cluster access to productive development to a few clicks [16]. That figure applies to a given team only after its administrator has finished the one-time setup: a Custom install, the policies on the right roles, and identity propagation on an older domain [9][11][12].
What to watch
- Whether AWS documents how a pre-integration Studio domain behaves if per-user identity propagation is never enabled.
- Whether Space templates or Task Governance quotas can limit which GPU sizes a given IAM role can request in the Studio form.
- An idle-timeout setting for Spaces would change the cleanup picture, since stop is a user selection in the post.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Insufficient
- Hype gap+10
- Incentives70
- Confidence60
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
AWS introduced the ability to create and manage Amazon SageMaker Spaces on SageMaker HyperPod EKS clusters directly from the SageMaker Studio UI, so data scientists and ML engineers can launch JupyterLab and Code Editor environments without leaving the browser or using command-line tools.
- [2]
Previously, creating and managing Spaces relied primarily on the HyperPod CLI or kubectl commands, an approach AWS describes as giving granular control for infrastructure administrators.
- [3]
SageMaker Spaces for HyperPod, launched earlier this year as an add-on, lets organizations run interactive workloads alongside training jobs and model deployment on the same infrastructure, with support for fractional GPU allocations.
- [4]
A new IDE and Notebooks tab on the HyperPod cluster detail page lets data scientists create, configure, start, stop, and open Spaces from SageMaker Studio.
- [5]
Spaces are created through a guided form with configurable compute, namespaces, storage, HyperPod Task Governance for compute quota management, and image settings.
- [6]
Studio shows all Spaces in a searchable table with name, application type, status, access type, storage, GPU, and vCPU allocations.
- [7]
Spaces can be started and stopped with a single selection to clear up compute resources when they are not used.
- [8]
Spaces can be opened directly in the browser as JupyterLab or Code Editor, or connected through a remote IDE such as VS Code.
- [9]
Administrators install the Spaces add-on with either Quick install (one-click with optimized defaults) or Custom install; Custom install is required to enable web browser access.
- [10]
After installing the add-on, administrators configure namespaces, create Space templates, and manage access through EKS access entries.
- [11]
Administrators must attach three managed policies, AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy, and AmazonSagemakerHyperpodSpaceTemplatePolicy, to the IAM roles used by their data scientists.
- [12]
Studio domains created before the Studio and HyperPod Spaces integration was rolled out must enable per-user identity propagation to the HyperPod EKS cluster.
- [13]
Per-user identity propagation attributes each Studio user's actions on the cluster (create, stop or delete Space) to their user profile in EKS access entries and AWS CloudTrail.
- [14]
The identity mapping enforces strict Space ownership, tracking which user created the environment and whether the Space is private or shared across the SageMaker Studio domain.
- [15]
With EKS orchestration, HyperPod teams can run distributed training jobs across hundreds of accelerators with built-in resiliency and automatic fault recovery.
- [16]
AWS says the Studio capability reduces the time from cluster access to productive development to a few clicks.
- [17]
A Space launched from the Studio browser interface runs on the same HyperPod cluster accelerators that training jobs use.
Sources
1 independent publisher whose own reporting we read for this story.
- aws.amazon.comManage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio
1 article · October 6, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Entities
- Amazon Web ServicesFollow
- Amazon SageMaker HyperPodFollow
- Amazon SageMaker StudioFollow
- Amazon SageMaker SpacesFollow
- Amazon EKSFollow
- AWS IAMFollow
- AWS CloudTrailFollow
- JupyterLabFollow