AWS: sharing one HyperPod GPU cluster across teams needs network rules too
AWS's reference design for sharing one SageMaker HyperPod GPU cluster across teams adds quotas and per-team cost reports, and warns namespaces do not isolate traffic.
AWS published a reference architecture on 8 October 2026 for letting several teams share one Amazon SageMaker HyperPod cluster orchestrated by Amazon EKS. It is vendor-published guidance, not a customer case: it reports no utilisation, savings or cost figures, and Amazon Managed Grafana and Kubecost are assembled around it.
The building blocks
- Identity: AWS IAM Identity Center federates with an existing directory (the post uses Microsoft Entra ID) and syncs team groups by SCIM, so team membership is managed in one place.
- Access: each team gets its own IAM role and SageMaker AI domain, plus a permission set for command-line access, scoped to that team's Kubernetes namespace.
- Fair share: HyperPod Task Governance sets compute quotas and scheduling priorities per namespace.
- Visibility: Kubecost groups spend by namespace for showback (reporting usage) or chargeback (billing it), with per-namespace budgets and alerts.
The part teams skip
AWS says Kubernetes networking is flat by default: a pod in hyperpod-ns-team-a can open a connection to a pod in hyperpod-ns-team-b unless controls are added. Its recommended pattern is default-deny ingress per namespace, then explicit allows for what each team needs. That only works if the container network plugin enforces NetworkPolicy; on EKS, AWS says that means enabling network policy support in the Amazon VPC CNI.
AWS also says namespaces and RBAC reduce accidental access rather than provide hard isolation. Where regulation demands strict separation, it points to separate clusters or accounts, dedicated node pools and runtime sandboxing.
Reading this at work? Get one story like it explained every morning.
A five-minute read every morning at 7am ET: one story explained, two in brief, what else happened, one number. Unsubscribe in one click.
What to check
If you run GPU capacity for more than one team, the useful test is whether your per-team spend view and your network rules were set up before the second team arrived. The post leaves out what the Kubecost and Task Governance layers cost to run, and it is HyperPod-specific. Verify the details against the full post before building.
Questions this article answers
How can multiple teams share one SageMaker HyperPod cluster?
AWS's reference design gives each team a Kubernetes namespace, its own IAM role and SageMaker AI domain, a HyperPod Task Governance compute quota, and Kubecost reporting by namespace.
Do Kubernetes namespaces isolate network traffic between teams?
No. AWS says networking is flat by default, so pods in one namespace can reach pods in another unless you add default-deny NetworkPolicy rules and a network plugin that enforces them.
When are namespaces not enough for isolation?
For strict regulatory isolation, AWS points to separate clusters or accounts, dedicated node pools and runtime sandboxing instead of namespaces alone.
AWS: 'hours saved' overstates agent ROI; price exceptions and oversight too
An AWS post says RPA-style ROI misses agents' exception, oversight and upkeep costs; its claims example turns $1.26M of freed time into about $630K.
Get the briefing by email
A five-minute read every morning at 7am ET: one story explained, two in brief, what else happened, one number. Unsubscribe in one click.
Who sees the per-team cost of your shared GPU or inference capacity today, and did the network rules between teams exist before the second team moved in?
The short version
✎ Select any line in the article to quote it straight into your comment.
Wren AI editorA modest find rather than a headline: an AWS how-to, but its warning that namespaces do not isolate traffic is the line most shared-cluster setups need.