Manage Amazon SageMaker HyperPod Spaces directly from SageMaker Studio

We recently introduced the ability to create and manage Amazon SageMaker Spaces on Amazon SageMaker HyperPod EKS clusters directly from the Amazon SageMaker Studio UI. Data scientists and machine learning (ML) engineers can now launch JupyterLab and Code Editor environments on HyperPod clusters without leaving their browser or using command-line tools, reducing the time from cluster access to productive development to a few clicks. Background Amazon SageMaker HyperPod provides purpose-built infrastructure for foundation model (FM) 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. In addition to training, HyperPod extends this EKS orchestrated infrastructure to serve low-latency, scalable inference for multi-billion-parameter foundation models. Earlier this year, we launched Amazon SageMaker Spaces for HyperPod , an add-on ML developers can use to create interactive development environments directly on HyperPod EKS clusters. Organizations could then maximize their GPU investments by running interactive workloads alongside training jobs and model deployment on the same infrastructure, with support for fractional GPU allocations. Previously, creating and managing Spaces relied primarily on the HyperPod CLI or kubectl commands. While this approach provides powerful, granular control for infrastructure administrators, data scientists who prefer a visual interface can now use this new SageMaker Studio capability to bypass command-line tools and focus entirely on model development. What’s new With this new capability, data scientists can now create, configure, start, stop, and open Spaces directly from SageMaker Studio. The new IDE and Notebooks tab on the HyperPod cluster detail page provides a complete user interface for Space management, eliminating the need for CLI tools for day-to-day Space operations. Key capabilities available through Studio include: Create Spaces with configurable compute, namespaces, storage, HyperPod Task Governance for compute quota management and image settings through a guided form. 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 clear up compute resources when Spaces aren’t used. Open Spaces directly in the browser (JupyterLab or Code Editor) or connect through a remote IDE of your choice (for example, VS Code). Figure 1: The IDE and Notebooks tab on the HyperPod cluster detail page shows all Spaces with their status, compute allocation, and quick actions to stop, open, or open in a remote IDE Getting started Setup involves two roles: administrators prepare the cluster, and data scientists create and open Spaces. The following sections cover each. For administrators Administrators install the SageMaker Spaces add-on on their HyperPod EKS cluster using either the Quick install (one-click with optimized defaults) or Custom install option (required to set up web UI access) from their SageMaker HyperPod EKS cluster’s IDE and Notebooks tab. After it’s installed, the administrator can configure namespaces, create Space templates, and manage access through EKS access entries. The following is a one-time setup that administrators must do: Install the Spaces add-on: From the Amazon SageMaker AI console, open your HyperPod cluster, go to the IDE and Notebooks tab, and choose either Quick install or Custom install (Custom install is required to enable web browser access). See the AWS documentation for full instructions. Configure EKS access entries: Attach the three managed policies AmazonSagemakerHyperpodSpacePolicy , AmazonSagemakerHyperpodUserClusterPolicy , and AmazonSagemakerHyperpodSpaceTemplatePolicy to the AWS Identity and Access Management (IAM) roles used by your data scientists. Enable per-user identity propagation on the Studio domain: If your Studio domain was created before the SageMaker Studio and HyperPod Spaces integration was rolled out, you must enable per-user identity propagation to the HyperPod EKS cluster. This ensures each Studio user’s actions on the cluster (create, stop or delete Space) are attributed to their user profile in EKS access entries and AWS CloudTrail. Furthermore, this identity mapping enforces strict Space ownership. It tracks which user created the environment and determines whether the Space is private or shared across the SageMaker Studio domain. Run the following command once per Studio domain: aws sagemaker update-domain \ --domain-id $DOMAIN_ID \ --default-user-settings '{ "StudioWebPortalSettings": { "ExecutionRoleSessionNameMode": "USER_IDENTITY" } }' After updating the domain, verify that the following command returns “USER_IDENTITY”: aws sagemaker describe-domain --domain-id $DOMAIN_ID \ --query 'DefaultUserSettings.StudioWebPortalSettings.ExecutionRoleSessionNameMode' Existing running apps are unaffected. Users pick up the new setting on their next sign-in. Optionally turn on additional capabilities: Enable any of the capabilities from the following Optional capabilities table. For data scientists After the add-on is installed and access is configured, data scientists navigate to their HyperPod cluster in SageMaker Studio under Compute → HyperPod and select the IDE and Notebooks tab to see the Spaces management interface (see Figure 1). Learn more about creating and managing Spaces: Create and manage Spaces on HyperPod . After the Space status shows Running (typically a few minutes on a cold cluster, approximately 30–40 seconds with over-provisioning), choose Open to launch JupyterLab or Code Editor in your browser (Figures 2 and 3), or Open in VS Code to connect from your local editor through SSH-over-SSM (Figure 4). Figure 2: A JupyterLab Space accessed through the web browser, showing the Launcher with available notebook kernels, consoles, and terminal access Working in a JupyterLab Space After you open a JupyterLab Space, you get a fully configured development environment with access to: Python 3 notebooks with ipykernel. Glue PySpark and Glue Spark consoles. SparkMagic PySpark and Spark kernels. Terminal access for running commands. File browser with persistent storage. Built-in chat and contextual help. Your work persists on the attached Amazon Elastic Block Store (Amazon EBS) volume, so you can stop and restart Spaces without losing progress. Figure 3: A Code Editor Space running on HyperPod, showing the VS Code-style web interface with file explorer, editor, and integrated terminal Working in a Code Editor Space For developers who prefer a VS Code-style experience in the browser, Code Editor Spaces provide a lightweight, web-based IDE with: Full file editing with syntax highlighting and IntelliSense. Integrated terminal for running shell commands, submitting training jobs, or interacting with cluster resources. Extension support for language servers, linters, and formatters. Git integration for version control workflows. Direct access to the cluster file system and mounted Amazon FSx volumes. Code Editor Spaces are well-suited for writing and debugging training scripts, managing experiment configurations, and working with code repositories, all without leaving the browser. Figure 4: A local VS Code instance connected remotely to a HyperPod Space, showing the remote connection indicator and full IDE capabilities running on cluster compute Remote IDE connection (VS Code) Choose Open in VS Code from the Spaces table to connect your local Visual Studio Code to the Space running on HyperPod. This uses SSH-over-SSM tunneling internally, providing a secure connection without requiring you to manage SSH keys or expose port 22. You get the full power of your local VS Code environment, including extensions, themes, and keybindings, while executing code on HyperPod cluster compute. You ca