A common enterprise journey: a team prototypes against the Anthropic API directly (the "1P" route — an API key, quick setup, fast iteration), the project succeeds, and then procurement, security, or cloud strategy says production traffic should run through your cloud provider instead. The good news is that the SDK was designed for exactly this move. The Messages API — the request you build, the response you parse, streaming, tool use, vision — keeps the same shape on every platform. What changes is how your client authenticates and connects, plus one naming quirk. This article walks through each change.
Change one: authentication
On the 1P API you authenticate with an Anthropic API key. On a cloud platform you authenticate the way that cloud authenticates everything else — which is precisely why enterprises make this move. On Amazon Bedrock, standard AWS credentials and IAM policies apply. On Google Vertex AI, it's GCP Application Default Credentials. On Microsoft Foundry, a Foundry resource plus API key. On Claude Platform on AWS, requests are signed with AWS SigV4 and scoped by a workspace (via AWS_REGION and ANTHROPIC_AWS_WORKSPACE_ID environment variables).
For most organizations this is an upgrade, not a chore: model access now flows through the identity, secret-management, and audit machinery you already govern, instead of a standalone vendor key. There is no separate Anthropic account to secure, and access can be scoped by team and environment with the tools your cloud administrators use every day. Plan for it accordingly — the auth change is where migration effort actually lives, in IAM policies and credential plumbing rather than in application code, so involve the platform team early rather than treating this as a developer-only task.
Change two: the client class
In the Python SDK (package anthropic), each platform has its own client class; everything after construction looks the same. A Bedrock migration, before and after:
# Before — direct Anthropic API (1P)
from anthropic import Anthropic
client = Anthropic() # uses ANTHROPIC_API_KEY
# After — Amazon Bedrock (pip install -U "anthropic[bedrock]")
from anthropic import AnthropicBedrockMantle
client = AnthropicBedrockMantle(aws_region="us-east-1")
# The call itself is unchanged apart from the model ID:
message = client.messages.create(
model="anthropic.claude-sonnet-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Hello, Claude"}],
)The other platforms follow the same pattern: AnthropicVertex(project_id="...", region="global") for Vertex AI (installed with anthropic[vertex]), AnthropicFoundry(api_key="...", resource="...") for Foundry, and AnthropicAWS() for Claude Platform on AWS. Note what did not change in the example above: the messages.create call, the message structure, and the response you get back are identical. In a well-factored codebase, client construction lives in one place, so this change is a handful of lines plus configuration — and if it doesn't live in one place yet, consolidating it is worth doing as the first step of the migration.
Change three: model IDs (Bedrock only)
Only Bedrock prefixes model IDs with anthropic. — so claude-sonnet-5 becomes anthropic.claude-sonnet-5, and likewise anthropic.claude-opus-4-8 and anthropic.claude-haiku-4-5-20251001-v1:0. Every other platform, including Claude Platform on AWS, uses the same bare IDs as the 1P API. Keep model IDs in configuration rather than scattered through code and this becomes a one-line change; the background is in why model IDs differ across platforms.
What to verify before cutover
Same API shape does not mean zero due diligence. Check three things. Feature availability: the core — Messages, streaming, tool use, vision, extended thinking, prompt caching — is on all four platforms, but the Batch API, Files API, and several tools are not on Bedrock or Vertex AI; if your 1P code uses them, that's a real migration item, not a rename (see the feature gaps). Quotas: your new platform's rate limits are set by that platform and start at defaults unrelated to your 1P usage — size them before production traffic arrives. Behavioral parity: the models are the same, but run your evaluation set against the new platform anyway before cutover, and roll traffic over gradually rather than all at once. It is cheap insurance, and it establishes the baseline you'll want for future model upgrades.
Where to go next
If you haven't settled on a destination platform, the platform decision framework is the natural starting point; once you're running on a cloud, switching clouds shows how the same three-change pattern applies between platforms. The platform overview and quickstart cover first-call setup on each.