Hyperpod Ssm

If you're working with SageMaker HyperPod, this is how you actually get onto the cluster nodes since direct SSH isn't available. It wraps AWS Systems Manager to execute commands, transfer files, and run diagnostics on instances. The implementation handles the awkward SSM target format and includes unbuffer to work around an intermittent empty output bug in the session manager plugin. Watch the 3 TPS rate limit when running commands across many nodes. The three shell scripts cover the common pattern: resolve cluster info once, then execute per node. Runs as root by default, uses JSON files for parameters to avoid quoting nightmares.

skills.sh installs: 150
GitHub stars: 938
last updated: Jun 11, 2026

View on GitHub

Install

$ npx -y skills add awslabs/agent-plugins --skill hyperpod-ssm --agent claude-code

Installs into .claude/skills of the current project.

Files

HyperPod SSM Access

Prerequisites

aws CLI v2, authenticated for the target account/Region.
session-manager-plugin — installed alongside the AWS CLI.
jq — the scripts build JSON payloads with it.
unbuffer (from the expect package) — wraps aws ssm start-session with a PTY so the session-manager-plugin flushes stdout instead of racing to close. Without it, calls intermittently return empty output with Cannot perform start session: EOF even when the command ran. Install with sudo yum install expect, sudo apt install expect, or brew install expect. ssm-exec.sh detects and uses it automatically; falls back with a warning if missing.

SSM Target Format

Target: sagemaker-cluster:<CLUSTER_ID>_<GROUP_NAME>-<INSTANCE_ID>

CLUSTER_ID: Last segment of cluster ARN (NOT the cluster name). Extract via get-cluster-info.sh.
GROUP_NAME: Instance group name — retrieve via list-nodes.sh.
INSTANCE_ID: EC2 instance ID (e.g., i-0123456789abcdef0)