How should we isolate SageMaker environments for users in a shared AWS account?

SageMaker Studio domains are designed to provide logically separated workspaces. Within a domain, user profiles can be configured with separate execution roles and settings, so users do not automatically share the same runtime identity. Use project- or team-specific domains or profiles when their data and permissions differ significantly.

If the requirement is strong data privacy or regulatory isolation, separate AWS accounts by team, business unit, or sensitivity level are easier to secure and audit than a single account with complex ABAC policies. You do not necessarily need one account per person, but an account-per-team boundary can be the safer choice for higher-risk workloads.

Use federation as the identity source, but map groups or claims to AWS permission sets and roles rather than sending everyone into one administrator-style role. Restrict allowed SageMaker instance types and other resources with IAM conditions, and keep broad administrative permissions separate from user execution roles.

The immediate issue is the shared privileged role, not necessarily the identity provider. Create separate SageMaker domains or user profiles and give each profile its own execution role. Then use IAM policies, session tags, and attribute-based access control to limit S3 prefixes, projects, and approved instance types. This keeps administration centralized while preventing notebooks and jobs from all running with the same identity.

For storage, give each user or team a controlled S3 prefix or bucket and write policies that derive the allowed path from a principal or session tag. You can also require matching resource tags for project access. The important part is ensuring the federated login passes reliable attributes into the AWS session and that users cannot change those attributes themselves.