SageMaker vs. SageMaker AI: What AWS's Rename Means for Your Team

If you searched for "SageMaker" in 2023, you got one product. Search today and you get two names, two consoles, and a fair amount of confusion. At re:Invent in December 2024, AWS announced the next generation of Amazon SageMaker and, in the same breath, renamed the service everyone had been using. This post explains what moved where, what actually changes for a team with workloads in production, and what to do about it.

The rename in one paragraph

The service you knew as Amazon SageMaker, with Studio, training jobs, endpoints, Pipelines, JumpStart, and the rest, is now Amazon SageMaker AI. The name Amazon SageMaker now refers to a broader, unified data-and-AI platform that wraps SageMaker AI together with analytics and data tooling. AWS's own URLs tell the story: aws.amazon.com/sagemaker/features/ now redirects to the SageMaker AI features page, and the next-generation SageMaker documentation lives in its own guide.

What is in the unified platform

Three new pieces sit alongside SageMaker AI:

• SageMaker Unified Studio. A single development environment that brings together data engineering (Glue-based ETL and Spark), SQL analytics (Athena and Redshift), machine learning (SageMaker AI), and generative AI app building (Bedrock) behind one login and one project model. Projects, not IAM users, are the unit of collaboration; a project owns its data, compute, and artifacts.
• SageMaker Lakehouse. A unified view over Amazon S3 data lakes and Amazon Redshift warehouses, exposed through Apache Iceberg-compatible APIs so Spark, Athena, Redshift, and third-party engines can query the same tables with the same permissions.
• SageMaker Catalog. Built on Amazon DataZone: data discovery, governance, and access workflows across the lakehouse, with AI-generated descriptions and fine-grained permissions.

None of these replace anything in SageMaker AI. They sit on top of it.

What did not change

This is the part worth reading twice if you have production workloads:

• APIs and SDKs. The sagemaker service endpoint, boto3 client names, the SageMaker Python SDK, and the CLI are unchanged. Existing pipelines, training jobs, endpoints, and Model Registry packages run exactly as before.
• Studio. SageMaker Studio (the 2023 "new Studio" with JupyterLab and Code Editor spaces) is still the development environment inside SageMaker AI. Unified Studio is an additional environment, not a forced replacement.
• Pricing. SageMaker AI pricing did not change with the rename. Unified platform components are priced by the underlying services they use.
• Console. The SageMaker AI console is the old SageMaker console with a new name in the header.

In short, for a team that builds, trains, and deploys models, the rename is a documentation and vocabulary change, not a migration.

What does change, in practice

• Search and documentation. Half the blog posts, Stack Overflow answers, and internal wiki pages now use the wrong name. Expect new hires and vendors to be confused for a while; write the mapping down.
• Console entry points. Some links that used to land in the SageMaker console now land on a platform overview page. Bookmarks and runbooks may need an update.
• Naming inside your own code and docs. Tags, CDK construct names, and Confluence pages that say "SageMaker" are now ambiguous. Decide on a convention ("SageMaker AI" for the ML service, "SageMaker platform" for the unified layer) and apply it.
• Vendor and partner claims. "SageMaker expert" now means something broader than it did. If you are evaluating a consultancy, ask which side of the line their experience is on. (Ours is both, and we say so on the services page.)

Should you adopt the unified platform?

It depends on who else is in the building.

Adopt it when your organization has data engineers, analysts, and ML engineers working on the same data and fighting over permissions, copies, and tooling. Unified Studio's project model and the Lakehouse's single-permission view across S3 and Redshift solve a real, expensive problem there, and the generative AI app builder is a reasonable on-ramp for Bedrock-based assistants.

Do not rush it when your team is an ML group with its own data pipeline, already productive in SageMaker Studio, with CI/CD around Pipelines and the Model Registry. You gain little in the short term and pick up a new project and permission model to learn. Revisit when the platform team decides to standardize data access.

Either way, nothing forces your hand. SageMaker AI continues to be developed at full speed (HyperPod, inference improvements, JumpStart models all shipped under the new name), so staying on it is not staying behind.

Action checklist

1. Update internal documentation and onboarding to use "SageMaker AI" for the ML service, and explain the unified platform in one paragraph.
2. Check runbook links and console bookmarks; fix the ones that now land on a landing page.
3. Audit anything that calls itself a "SageMaker" resource in tags or IaC names; rename only if the ambiguity causes real confusion.
4. If you have data engineering and analytics teams on AWS, schedule a half-day evaluation of Unified Studio and the Lakehouse with them in the room.
5. If you are still on legacy pieces of SageMaker AI itself (notebook instances, MXNet containers, Edge Manager), that is the migration worth budgeting for, and it is independent of the rename. See our legacy ML modernization page.

Confused about where your workloads sit, or whether the unified platform is worth it for your organization? Talk to us.