SageMaker Studio now lets users manage HyperPod Spaces from the browser

From command line to a visual interface

Amazon SageMaker HyperPod provides infrastructure for foundation model training and inference at scale. With Amazon Elastic Kubernetes Service (Amazon EKS) orchestration, teams can run distributed training jobs across hundreds of accelerators with built-in resiliency and automatic fault recovery, according to AWS.

Earlier this year, AWS launched Amazon SageMaker Spaces for HyperPod, an add-on for creating interactive development environments on HyperPod EKS clusters. Organizations can run interactive workloads alongside training jobs and model deployment on the same infrastructure, with support for fractional GPU allocations.

Until now, creating and managing Spaces relied primarily on the HyperPod CLI or kubectl commands. AWS says this gives infrastructure administrators granular control, but data scientists who prefer a visual interface can now skip command-line tools.

What the new capability offers

Data scientists can create, configure, start, stop and open Spaces from SageMaker Studio. A new IDE and Notebooks tab on the HyperPod cluster detail page provides the interface for day-to-day Space operations.

• Create Spaces through a guided form with configurable compute, namespaces, storage, HyperPod Task Governance for compute quota management, and image settings.
• View all Spaces in a searchable table showing name, application type, status, access type, storage, GPU and vCPU allocations.
• Start and stop Spaces with a single selection to free compute resources when they are not in use.
• Open Spaces in the browser (JupyterLab or Code Editor) or connect through a remote IDE such as VS Code.

AWS says a Space typically reaches the Running status in a few minutes on a cold cluster, and in approximately 30, 40 seconds with over-provisioning.

A JupyterLab Space includes Python 3 notebooks with ipykernel, Glue PySpark and Glue Spark consoles, SparkMagic PySpark and Spark kernels, terminal access and a file browser with persistent storage. Work is kept on the attached Amazon Elastic Block Store volume, so Spaces can be stopped and restarted without losing progress.

Code Editor Spaces offer a VS Code-style web IDE with syntax highlighting, IntelliSense, an integrated terminal, extension support, Git integration and direct access to the cluster file system and mounted Amazon FSx volumes.

With Open in VS Code, users can connect a local Visual Studio Code to a Space using SSH-over-SSM tunneling. According to AWS, this avoids managing SSH keys or exposing port 22. The AWS Toolkit for Visual Studio Code also lists Spaces under SageMaker AI > HyperPod.

Setup for administrators

Setup involves two roles. Administrators install the SageMaker Spaces add-on on the HyperPod EKS cluster, using either Quick install (one-click with optimized defaults) or Custom install. Custom install is required to enable web browser access.

Administrators then attach three managed policies to the IAM roles used by data scientists: AmazonSagemakerHyperpodSpacePolicy, AmazonSagemakerHyperpodUserClusterPolicy and AmazonSagemakerHyperpodSpaceTemplatePolicy.

Studio domains created before the integration was rolled out need per-user identity propagation to the HyperPod EKS cluster. AWS says this attributes each user's actions, such as creating, stopping or deleting a Space, to their user profile in EKS access entries and AWS CloudTrail. It also enforces Space ownership and determines whether a Space is private or shared across the domain. The setting is applied once per domain with the aws sagemaker update-domain command. Existing running apps are unaffected, and users pick up the setting at their next sign-in.

Several capabilities are optional and composable: web browser access through an Application Load Balancer and Amazon Route 53, admin-defined Space templates, Task Governance with namespace-level quotas through Kueue, and Karpenter autoscaling and over-provisioning.

What it means for teams

For teams that share HyperPod clusters, the change moves routine Space management out of the CLI and into Studio. Administrators keep control over the cluster setup, templates and quotas, while data scientists handle starting, stopping and opening their own environments. Stopping idle Spaces frees compute for other workloads on the same cluster.