Claude Platform on AWS vs Amazon Bedrock: which should you use?

Short answer: choose Claude Platform on AWS when you want Anthropic's newest native API features with AWS identity and billing. Choose Amazon Bedrock when data must stay inside the AWS boundary, AWS must be the sole data processor, or AWS compliance coverage is mandatory.[1][2]

This is not a speed or model-intelligence comparison. Both routes provide Claude access; the decision turns on the operating model, data boundary, and platform features.[1]

Quick decision table

• Same-day access to new Claude API features: Claude Platform on AWS.[1][3]
• AWS as the sole data processor, regional data residency, or FedRAMP, SOC, ISO, and HIPAA eligibility: Amazon Bedrock.[1]
• Anthropic's native platform with IAM, CloudTrail, and one AWS bill: Claude Platform on AWS.[2]
• AWS-managed Guardrails, Knowledge Bases, or PrivateLink: Amazon Bedrock.[2]
• A small solo product with no AWS contract dependency: evaluate the direct Anthropic API first; adding AWS solely for Claude may offer little benefit.

The main difference: who operates the model path and processes the data?

AWS's comparison says Anthropic operates Claude Platform on AWS, with Anthropic and AWS as data processors. AWS operates Bedrock and is the data processor.[1] These are AWS's own product descriptions.

That distinction changes the contract and compliance review. AWS explicitly says Claude Platform on AWS is not covered by standard AWS compliance programs or audit reports.[1] AWS also says customer data and metadata on this route are processed by Anthropic outside the AWS boundary.[2]

"It runs through AWS" is therefore not a complete data-residency answer. Legal, security, and procurement teams should inspect the actual data flow and governing terms, not the product name.

Choosing by API and feature needs

AWS documents Claude Platform on AWS as using the Anthropic Messages API surface and receiving new Claude API features on the same day. Bedrock features depend on AWS's integration timeline.[1] Anthropic repeats same-day access as its own product claim.[3]

Bedrock is not limited to an opaque AWS-only message format. AWS documents access through the Anthropic request and response format on Bedrock Runtime and recommends the bedrock-runtime endpoint for new applications.[4] The useful question is not merely whether the Anthropic format exists, but where the features and governance you need are available.

If a native Claude feature is part of the product plan, check the current support matrix first. If you only need basic message generation, API surface alone may not justify a migration.

Identity, audit, and billing

Claude Platform on AWS can use existing AWS credentials and IAM policies. AWS says activity is recorded in CloudTrail and usage appears on the consolidated AWS bill.[2] Those are AWS product claims; verify account visibility, cost allocation, and logs in a pilot.

AWS says Claude Platform on AWS pricing matches direct Claude API pricing.[2] That does not guarantee equal total cost. Private discounts, data transfer, operational work, and existing AWS commitments can change the result.

Anthropic tells customers with an existing Bedrock private offer to contact their AWS or Anthropic account executive before moving, because discounts are not retroactive.[3] Treat that as vendor guidance, not a universal pricing guarantee.

Which one would I choose?

I would choose Claude Platform on AWS when the team wants AWS identity, auditing, and billing; same-day native Claude features matter to the product; and the contract permits Anthropic to process data outside the AWS boundary.

I would choose Amazon Bedrock when data must be processed only in AWS infrastructure; AWS compliance coverage is mandatory; Guardrails, Knowledge Bases, or PrivateLink are part of the architecture; or I want to manage several model providers through one AWS layer.[1][2]

I would keep the direct Anthropic API in the comparison for a small solo product with no AWS commitment and a preference for the shortest integration path. That third option can prevent an unnecessary choice between two AWS products.

Five checks before migrating

1. List every required feature and inspect the current support matrix rather than relying on launch copy.
2. Run a small compatibility test for request bodies, streaming, tool use, and error behavior.
3. Diagram the data flow, then confirm processors, regions, logs, and retention terms in writing.
4. Test IAM, CloudTrail, budget alerts, and cost allocation tags before production.
5. Confirm private offers and AWS commitment treatment with your account representative in writing.

The execution location is a separate decision. The local vs cloud coding-agent guide covers where work should run, while the coding-agent output verification checklist covers result checking. For model-family selection, use the GPT-5.6 Sol, Terra, and Luna pillar guide.