Claude Platform on AWS vs Amazon Bedrock
Two different products, constantly confused
Both run Claude on AWS, and they are not the same thing. Who operates each, how the API surfaces differ, which Claude features you lose on one of them, and how to choose before it becomes a rearchitecture.
What is the difference between Claude Platform on AWS and Amazon Bedrock?
Claude Platform on AWS is operated by Anthropic and delivered through AWS infrastructure: SigV4 authentication, AWS IAM access control, AWS Marketplace billing, and same-day feature parity with the direct Anthropic API. Amazon Bedrock is operated by AWS as a partner service, with its own release cadence and a meaningful subset of Claude features. They also differ in model ID format and SDK client. For agent work the gap matters most: several capabilities agents rely on are not available on Bedrock.
Key Facts:
- Claude Platform on AWS: Anthropic-operated, same-day parity with the direct API
- Amazon Bedrock: AWS-operated partner service, feature subset, own release cadence
- Model IDs differ: bare on Claude Platform on AWS, provider-prefixed on Bedrock
- Each has its own SDK client; do not point the standard client at a new base URL
- For agents, Bedrock lacks Managed Agents, MCP connector, code execution and more
Why This Confusion Is So Common
The names are similar, both involve Claude, both involve AWS, and both let you pay through an AWS relationship. It is entirely reasonable to assume they are the same offering described two ways. They are not.
The distinction that actually explains every difference downstream is who operates the service. Amazon Bedrock is AWS's product: AWS runs it, decides its release schedule, and exposes the subset of Claude capabilities it has integrated. Claude Platform on AWS is Anthropic's product delivered through AWS infrastructure: Anthropic runs it, so it tracks the direct API with same-day parity, while authentication, access control and billing are AWS-native.
Everything else, the model ID format, the client class, the feature gaps, follows from that one fact. Once you have it, the rest stops being arbitrary.
One sentence worth remembering: Bedrock is AWS reselling Claude; Claude Platform on AWS is Anthropic selling Claude through AWS.
The Operational Differences
| Claude Platform on AWS | Amazon Bedrock | |
|---|---|---|
| Operated by | Anthropic | AWS |
| Feature parity with direct API | Same-day | Subset, own cadence |
| Model ID format | Bare, e.g. the same string as the direct API | Provider-prefixed |
| SDK client | Dedicated AWS platform client | Dedicated Bedrock client |
| Authentication | AWS SigV4 (short-term API keys also supported) | AWS credentials |
| Access control | AWS IAM | AWS IAM |
| Billing | AWS Marketplace, at Anthropic standard API rates | AWS, partner-operated pricing |
| Required config | AWS region and a workspace identifier, both mandatory | AWS region |
Neither client should be simulated by pointing the standard Anthropic client at a different base URL. Use the platform's own client class; after construction, both expose the same message-creation surface, so the rest of your code is largely unchanged.
Feature Availability, Where It Actually Diverges
The capabilities below are the ones that differ. Core inference is equivalent on both, so this table covers the decision-relevant gaps rather than everything Claude can do.
| Capability | Claude Platform on AWS | Amazon Bedrock |
|---|---|---|
| Messages, streaming, tool use | Yes | Yes |
| Adaptive thinking and effort | Yes | Yes |
| Prompt caching | Yes | Yes |
| Automatic prompt caching | Yes | No |
| Structured outputs, PDF, citations | Yes | Yes |
| Bash, text editor, memory tools | Yes | Yes |
| Web search and web fetch | Yes | No |
| Server-side code execution | Yes | No |
| Programmatic tool calling | Yes | No |
| MCP connector | Beta | No |
| Managed Agents | Beta | No |
| Agent Skills | Beta | No |
| Files API | Beta | No |
| Message Batches | Yes | No |
| Models API | Yes | No |
| Data residency controls | Yes | No |
Availability moves as features graduate from beta and as AWS integrates more of the surface, so verify against current documentation before committing an architecture to it. The shape of the gap has been stable though: the agent and orchestration layer is where Bedrock trails, while core inference is equivalent.
What This Means for an Agent Build
The gaps that actually change an architecture.
No Managed Agents on Bedrock
If you wanted Anthropic to run the agent loop and host a per-session sandbox, that option does not exist on Bedrock. You would build and host the harness yourself, which is a different project with different operational cost.
No MCP connector on Bedrock
Connecting to MCP servers through the API is not available. If your integration strategy is built on MCP, that needs rethinking, or the platform does.
No server-side code execution, search or fetch
Anthropic-hosted code execution, web search and web fetch are unavailable, so anything relying on them has to be reimplemented as your own client-side tools with your own sandboxing.
No Files API or Batches
Files uploaded once and referenced across requests, and asynchronous batch processing at reduced cost, are both absent. For high-volume document workloads that is a meaningful economic difference.
How to Actually Choose
Start from the architecture, not the procurement
The temptation is to pick based on which contract is easier to sign. That works fine for straightforward inference, where the two are equivalent, and badly for agent work, where the feature gap can invalidate a design.
The useful sequence is to sketch the architecture first, list the capabilities it depends on, and only then check which platforms offer all of them. That takes an hour and routinely saves a rearchitecture.
Reasonable defaults
If you are on AWS and building agents, Claude Platform on AWS is the safer default: it keeps AWS-native identity and billing without constraining what you can build, and guidance written for the direct API applies unchanged.
Amazon Bedrock is a good choice when your workload is inference-shaped rather than agent-shaped, when it fits comfortably inside the available feature set, and when your governance or procurement strongly favors a service AWS itself operates.
And if neither constraint binds, calling the Anthropic API directly remains the simplest path with the fewest surprises. Cloud-native billing is a real benefit, but it is worth being honest that it is the benefit you are buying, rather than assuming the platform version is otherwise superior.
If you might move later
The code cost of switching is small: a client class and a model ID string. The risk is directional. Building on the fuller platform and later moving to the narrower one means designing around missing capabilities under deadline. Building on the narrower one and moving to the fuller one is straightforward.
So if there is genuine uncertainty, the asymmetry argues for keeping your dependencies inside the intersection of the two, or accepting up front that you are choosing the platform for the long term.
Claude on AWS, FAQ
Common questions about the two ways to run Claude on AWS.
Deciding where to run it?
We architect and build production Claude systems across Anthropic direct, AWS, and the other cloud platforms. Tell us what you are building and we will tell you which platform actually fits it.
Related Services
Explore our other technical consulting services
Tell us what you're building.
Bring us the problem you're solving. We'll tell you how we'd build it, what it takes, and how Simple Engineers can help your business scale its technology.
Get in Touch
hello@simpleengineers.com
We typically respond within 2-4 hours
Phone
+1 (888) 966-0773
Mon-Fri 9AM-6PM EST
Location
Global Remote Team
Serving clients worldwide
Response Time
Within 24 hours
Emergency support available
Why Partner with Simple Engineers?
- Senior engineers who build and ship, not just advise
- We stay on to run and grow what we build
- You own everything: your code, your cloud, your keys
- Scaling companies from startup to enterprise since 2016
Send Us a Message
Tell us about your project or goals and we'll get back to you within one business day.