Amazon SageMaker AI now fully supports an OpenAI-compatible API for developers

Amazon SageMaker AI now supports an OpenAI-compatible API. Developers can use the OpenAI SDK, LangChain and other tools without rewriting their code. All they need to do is change the endpoint URL. The change makes it easier to move between cloud platforms and reduces vendor lock-in.

AI-processed from AWS Machine Learning Blog; edited by Hamidun News
Amazon SageMaker AI now fully supports an OpenAI-compatible API for developers
Source: AWS Machine Learning Blog. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceAWS Machine Learning Blog ↗
Editor-in-Chief
Teams using LangChainSageMaker is now a full-fledged model choice alongside OpenAI
Those building multi-cloud systemsworking with several providers at once gets easier
AWS teamsembedding SageMaker models into existing code becomes trivial

Amazon SageMaker AI now supports an OpenAI-compatible API for real-time endpoints. Developers can use familiar tools such as the OpenAI SDK, LangChain and Strands Agents by simply changing the endpoint URL.

How it works

Previously, integrating with SageMaker required custom clients and AWS SigV4 signatures. That added layers of complexity and meant developers either had to learn AWS-specific details or write wrappers around standard tools. That complexity is now going away.

If you already use the OpenAI API in your code, you can point it at a SageMaker endpoint instead of OpenAI, and it just works. No logic rewrites, no new dependencies in package.json or requirements.txt. From your application's point of view, SageMaker simply "pretends" to be the OpenAI API.

This is possible because the OpenAI API has become the de facto standard in the ML community. When large providers support such an interface, engineers gain real flexibility: they can switch between cloud platforms and pick the best option for each task without being tied to a single API.

A concrete example

Say you have a Python application that uses OpenAI. Switching to SageMaker used to mean rewriting most of the code. Now one change is enough:

client = OpenAI( api_key="unused", base_url="https://your-sagemaker-endpoint-url" )

The rest of the code stays completely unchanged. This works for LangChain, Strands Agents and any other framework built on the OpenAI API.

Who benefits

The change helps several groups of developers:

  • Teams using LangChain: SageMaker is now a full-fledged model choice alongside OpenAI
  • Those building multi-cloud systems: working with several providers at once gets easier
  • AWS teams: embedding SageMaker models into existing code becomes trivial
  • Startups avoiding lock-in: they can use AWS infrastructure without being tied to its API

It is especially valuable for companies that have already invested in the AWS ecosystem but want to stay flexible in their choice of LLM provider.

Why it matters more broadly

The OpenAI API is the de facto standard in the industry. When major providers (AWS, Google, Meta*) add compatibility, it means the LLM services market is becoming more competitive and mature. Developers no longer choose between competing integrations; they simply pick the best option on price, latency, quality and reliability.

It is a signal that cloud platforms have realized the era of lock-in is ending. The future belongs to hybrid setups, standardization and freedom of choice.

What it means

SageMaker becomes more competitive in the ML services market. For developers it is a clear win: less boilerplate, more flexibility, and an easier path to the optimal solution. For AWS it is a step toward becoming a neutral AI platform rather than just a proprietary service. When API standards win, the whole industry wins.

*Meta has been designated an extremist organization and is banned in Russia.

Story

Key Questions Answered

How it works?

Previously, integrating with SageMaker required custom clients and AWS SigV4 signatures. That added layers of complexity and meant developers either had to learn AWS-specific details or write wrappers around standard tools. That complexity is now going away. If you already use the OpenAI API in your code, you can point it at a SageMaker endpoint instead of OpenAI, and it just works. No logic rewrites, no new dependencies in package.json or requirements.txt. From your application's point of view, SageMaker simply "pretends" to be the OpenAI API. This is possible because the

What are the key details on A concrete example?

Say you have a Python application that uses OpenAI. Switching to SageMaker used to mean rewriting most of the code. Now one change is enough: client = OpenAI( api_key="unused", base_url="https://your-sagemaker-endpoint-url" ) The rest of the code stays completely unchanged. This works for LangChain, Strands Agents and any other framework built on the OpenAI API.

Who benefits?

The change helps several groups of developers: Teams using LangChain: SageMaker is now a full-fledged model choice alongside OpenAI Those building multi-cloud systems: working with several providers at once gets easier AWS teams: embedding SageMaker models into existing code becomes trivial Startups avoiding lock-in: they can use AWS infrastructure without being tied to its API It is especially valuable for companies that have already invested in the AWS ecosystem but want to stay flexible in their choice of LLM provider.

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
What do you think?
Loading comments…