Caylent Launches Dedicated Anthropic Practice

Claude Platform on AWS: An Architecture Decision Guide for AWS Teams

Generative AI & LLMOps

A decision guide for AWS teams on choosing between Claude Platform on AWS, Amazon Bedrock, and Claude Enterprise, with migration considerations for existing Bedrock users.

With the general availability of Claude Platform on AWS, AWS customers have a new way to build with Claude models: direct access to Anthropic’s native Claude Platform through an AWS account. AWS announced the launch on May 11, 2026, with native Claude APIs, Claude Console access, early-access beta features, IAM credentials, consolidated AWS billing, and CloudTrail audit logging. It is a meaningful release because it brings more of the Claude Platform experience into the AWS buying, access-control, and audit model that many enterprises already use.

The launch also changes the architecture decision. AWS customers now have three practical ways to use Claude: Claude Platform on AWS for Anthropic’s native API and platform capabilities, Claude on Amazon Bedrock for AWS-operated access to Claude models inside the Bedrock platform, and Claude Enterprise in AWS Marketplace for employee access to Claude apps such as Claude Chat, Claude Code, and Claude Cowork. Those options are related, but they are not interchangeable. The right choice depends on what the organization is trying to put into production.

Claude Platform on AWS is a strong option when the application needs native Claude Platform capabilities and the organization can approve Anthropic-operated inference. Amazon Bedrock remains the stronger starting point when the architecture needs AWS-operated processing, Bedrock-native features such as Knowledge Bases, Guardrails, AgentCore, or multi-model AWS governance. Claude Enterprise belongs in the evaluation when the goal is employee access to Claude apps rather than a custom application. This article explains how to make that choice, what changes with the new Claude Platform on AWS launch, and what existing Bedrock teams need to understand before considering a migration.


Match the Claude Access Model to the Workload

The first decision is what the organization is trying to put into production. A customer-facing support assistant, an internal research agent, a document review workflow, a developer productivity rollout, and a multi-model application platform can all use Claude models, but they do not need the same AWS access model. The workload determines which part of the architecture has to be controlled most tightly: the Claude feature surface, the AWS-operated service boundary, the surrounding Bedrock platform capabilities, or the enterprise app experience for employees.

For custom applications, the choice usually starts with Claude Platform on AWS or Amazon Bedrock. Claude Platform on AWS is the stronger starting point when the application needs Anthropic’s native Claude Platform capabilities through AWS procurement, identity, and audit workflows. That includes workloads where Managed Agents, Skills, code execution, Files API, prompt caching, batch processing, Claude Console workflows, or faster access to native Claude API features are part of the product design. Amazon Bedrock is the stronger starting point when the workload needs AWS-operated inference, Bedrock-native governance, Amazon Bedrock AgentCore, or a broader AWS generative AI platform pattern around Claude.

Claude Enterprise in AWS Marketplace belongs in a different decision. It is relevant when the organization wants to give employees access to Claude Chat, Claude Code, and Cowork with enterprise controls such as SSO, SCIM, audit logs, and role-based permissions. That may be a major AWS Marketplace purchase, but it is not the architecture choice for a custom application calling Claude models in production.


What Claude Platform on AWS Changes

Claude Platform on AWS is valuable because it brings the native Claude Platform closer to the way AWS customers already govern cloud services. Teams can use AWS authentication, IAM-based access control, AWS Marketplace billing, and CloudTrail logging while building against Anthropic’s native Claude API and platform capabilities. Anthropic’s documentation describes Claude Platform on AWS as giving access to the Messages API, Agent Skills, code execution, beta features, AWS IAM or API key authentication, and AWS Marketplace billing.

That makes the service especially relevant for teams whose application design depends on the Claude Platform itself. Examples include agent workflows that need Managed Agents or Skills, applications that need code execution inside model calls, document-heavy workflows that use Files API, prompt development and evaluation workflows that benefit from Claude Console, and systems where same-day or near-native feature availability matters.

Claude Platform on AWS is accessed through AWS, but Anthropic operates the service. Anthropic’s documentation distinguishes it from Amazon Bedrock by stating that AWS provides the authentication layer, IAM-based access control, and billing integration, while Anthropic operates Claude Platform on AWS.


Claude Platform on AWS vs Amazon Bedrock

Claude Platform on AWS and Amazon Bedrock both make Claude models available to AWS customers, but they expose different feature systems. Claude Platform on AWS brings the native Claude Platform surface into an AWS commercial and access-control flow: Anthropic’s Messages API, Claude-specific tools, beta features, Claude Console workflows, AWS IAM or API key authentication, and AWS Marketplace billing. Amazon Bedrock brings Claude into AWS’s broader generative AI platform: model choice, agent development, customization, safety and guardrails, Knowledge Bases, evaluations, monitoring, logging, and AgentCore-managed operations.

“Agents,” “files,” “retrieval,” “evaluation,” and “code execution” can appear in both ecosystems, but they do different jobs and create different application shapes. The table below compares the different options across Claude Platform on AWS and Amazon Bedrock.


Feature Area
Claude Platform on AWS
Amazon Bedrock
Architecture Implication

Document handling and retrieval

The Files API lets the application upload and manage files for use with Claude without re-uploading the same content on each request. This is useful for Claude-centered workflows involving uploaded documents, datasets, generated outputs, and code execution.

Bedrock Knowledge Bases are part of the AWS-managed retrieval and customization stack, alongside Bedrock Data Automation.

These are not equivalent features. Claude Files are better for file reuse inside Claude workflows. Bedrock Knowledge Bases are better when managed RAG over enterprise data is part of the architecture.

Agent design

Claude Platform on AWS supports Claude Managed Agents, Agent Skills, code execution, tool use, credential vaults (rather than full identity management), memory stores, and Claude-specific agent workflows. Skills package instructions, metadata, scripts, templates, and resources that Claude can load when relevant.

Bedrock AgentCore includes features such as Runtime, Gateway, Memory, Identity via IAM, Browser, Code Interpreter, Observability, Evaluations, and Policy, and is designed to work with any framework and model.

Choose Claude Platform on AWS when the agent should be built around Claude’s own agent capabilities and reusable Claude Skills. Choose Bedrock when the agent architecture needs AWS-managed runtime, identity, tool gateway, memory, observability, evaluation, and policy controls.

Code and data work

Claude’s code execution tool runs Python and bash in a sandboxed environment inside the API conversation, enabling calculations, visualizations, file manipulation, and data analysis with uploaded files.

Bedrock AgentCore includes a Code Interpreter as part of a broader AWS agent platform, alongside browser, gateway, memory, identity, policy, and observability capabilities.

Choose Claude Platform on AWS when code execution is part of Claude’s reasoning and file workflow. Choose Bedrock when code execution belongs inside an AWS-managed agent runtime with broader agent controls.

Safety and policy controls

Claude Platform on AWS can be used with application-level controls and Claude-native workflows.

Bedrock Guardrails provides configurable safeguards for inputs and responses, including content filters, prompt attack detection, denied topics, PII handling, contextual grounding, and Automated Reasoning checks. Guardrails works consistently across foundation models and some self-hosted and third-party models.

Choose Bedrock when safety and policy enforcement should be a managed AWS feature applied consistently across applications or models. Choose Claude Platform on AWS when you just need application-level controls.

Evaluation and iteration

Claude Console provides Claude-specific prompt generation, prompt improvement, and evaluation workflows. This is useful when teams are tuning a Claude-specific application and want the development loop close to Anthropic’s platform.

Bedrock evaluations can assess models, Knowledge Bases, and RAG sources, including automatic evaluations, judge-model evaluations, and human evaluations. AgentCore recently launched an optimization feature that lets you evaluate and optimize prompts and tool descriptions for agents running on AgentCore.

Choose Claude Platform on AWS when evaluation is centered on Claude prompt and workflow iteration. Choose Bedrock when evaluation needs to compare models, RAG sources, or Knowledge Bases inside the AWS platform, or needs to optimize for tool descriptions taking into account end to end agent metrics.

Batch and offline processing

Message Batches support large asynchronous Claude Messages workloads and can reduce cost for work that does not need immediate responses.

Bedrock also supports batch and cost-optimization patterns, including broader Bedrock pricing and routing features across supported models.

Both options are very similar, this point won't be a deciding factor for you. It is an important cost lever though, so keep this in mind.

Data-processing approval

Claude Platform on AWS is Anthropic-operated. AWS provides authentication, IAM-based access control, and billing integration; Anthropic is the data processor for inference inputs and outputs.

Bedrock is AWS-operated. Model providers do not have access to Bedrock logs, customer prompts, or completions because model deployment accounts are operated by the Amazon Bedrock service team.

Feature fit likely comes first for architecture design. This point is only likely to be a differentiator for heavily-regulated industries.

A system that needs to reuse uploaded PDFs, spreadsheets, and generated artifacts inside Claude conversations is more likely to benefit from Claude Files and the code execution model. A system that needs managed retrieval over a governed enterprise corpus is a better fit for Bedrock Knowledge Bases. A system that needs reusable Claude task packages for document work is going to greatly benefit from Skills. A system that needs an AWS-managed agent runtime with identity, integration (including through a gateway to MCP servers), memory, observability, evaluations, and policy should use Bedrock AgentCore.

Security and data processing should be treated as an approval filter, rather than a feature comparison. Define your required security features and your data processing requirements first, and consider whether both Claude Platform on AWS and Amazon Bedrock are viable options. This should not be a problem for most workloads, but certain regulated industries come with many restrictions.

Migration Planning for Existing Bedrock Teams

Teams already using Claude through Amazon Bedrock should not assume Claude Platform on AWS is a drop-in replacement. The model family may be familiar, but the integration path changes.

A migration can involve different endpoints, signing behavior, model identifiers, SDKs, request headers, streaming behavior, workspace configuration, rate-limit ownership, cost reporting, and support paths. The amount of change depends on how the current application uses Bedrock. A team using newer Messages-style request bodies may have less request-shape work than a team using older invocation patterns, but it still has to validate authentication, model IDs, headers, logging, and operating ownership.

Migration should be justified by a workload need. Good reasons include native Claude Platform features, Claude Console workflows, Managed Agents, Skills, code execution, Files API, prompt caching patterns, batch processing, or release velocity. Weak reasons include treating Claude Platform on AWS as a general upgrade when the current Bedrock implementation already satisfies the workload’s security, governance, and feature requirements.

A useful migration spike should test four things together: application behavior, IAM and workspace design, audit and cost visibility, and security approval. A successful request in a development environment is not enough evidence that the access model will work in production.


Migration Guide for Existing Claude on Bedrock Applications

Teams already using Claude through Amazon Bedrock should treat a move to Claude Platform on AWS as a migration, not an endpoint update. The first step is to identify which Bedrock integration is in production. There are two Bedrock paths: the current Claude in Amazon Bedrock integration, which uses the Messages API at bedrock-mantle.{region}.api.aws, and the legacy Bedrock integration, which uses InvokeModel or Converse through bedrock-runtime.{region}.amazonaws.com. The migration work is different for those two starting points.


Migration Area
From Current Claude in Amazon Bedrock
From Legacy Bedrock InvokeModel / Converse
To Claude Platform on AWS
Required migration work

Base URL

bedrock-mantle.{region}.api.aws

bedrock-runtime.{region}.amazonaws.com

aws-external-anthropic.{region}.api.aws

Update the endpoint or SDK base URL.

API format

Anthropic Messages API at /anthropic/v1/messages

Bedrock Converse / InvokeModel

Anthropic Messages API at /v1/messages

Current Bedrock Messages users keep the request body shape. Legacy users rewrite request and response handling to Messages API format.

Model IDs

anthropic.claude-opus-4-6 style IDs

anthropic.claude-opus-4-6-v1 style IDs, with optional us. or global. prefix

claude-opus-4-6 style IDs

Remove Bedrock prefixes and Bedrock versioning patterns. Claude Platform on AWS uses the same model IDs as the first-party Claude API.

SDK client

AnthropicBedrockMantle

AnthropicBedrock or AWS SDK

Claude Platform on AWS client, such as AnthropicAWS

Replace the Bedrock client with the Claude Platform on AWS client. Anthropic lists those SDK clients as beta.

SDK package

Bedrock Anthropic package, such as anthropic[bedrock] or @anthropic-ai/bedrock-sdk

Bedrock Anthropic package or AWS SDK

AWS Anthropic package, such as anthropic[aws] or @anthropic-ai/aws-sdk

Change the package/module and client construction.

SigV4 service name

bedrock-mantle

bedrock

aws-external-anthropic

Update request signing configuration and IAM policy actions.

Streaming format

SSE

AWS EventStream

SSE

Current Bedrock Messages users keep SSE streaming. Legacy users replace AWS EventStream handling with SSE handling.

Workspace header

Not applicable

Not applicable

anthropic-workspace-id required

Add workspace ID handling to every data plane request.

Region availability

Bedrock Regions

Bedrock Regions

All AWS commercial Regions

Revalidate Region selection against Claude Platform on AWS workspace and endpoint behavior.

Several things stay the same, but they do not stay identical in implementation. AWS IAM authentication with SigV4 remains supported. AWS remains the invoicing party, although the billing channel changes from the native Bedrock service path to AWS Marketplace.

For current Bedrock Messages users, the Messages API shape and SSE streaming remain familiar. Claude in Amazon Bedrock uses the Messages API at /anthropic/v1/messages with standard SSE streaming, and Claude Platform on AWS also uses the Anthropic Messages API with SSE streaming. Legacy Bedrock users do not keep the streaming format because the legacy path uses AWS EventStream.

The account setup also changes. Signing up for Claude Platform on AWS through the AWS Console provisions a new Anthropic organization tied to the AWS account. That organization is separate from existing first-party Anthropic organizations and Claude Enterprise organizations procured through AWS Marketplace; API keys, workspaces, and Claude Console settings from those organizations do not carry over. A default workspace is provisioned at setup, and the workspace ID is required for data plane calls.

Authentication has to be rebuilt against the Claude Platform on AWS rules. Claude Platform on AWS supports AWS IAM with SigV4 as the primary authentication method and API key authentication as an alternative. API keys must be created in the AWS Console under Claude Platform on AWS; first-party Claude API keys and Amazon Bedrock API keys do not work against the Claude Platform on AWS endpoint. Every data plane request must include anthropic-workspace-id; the SDK can read it from ANTHROPIC_AWS_WORKSPACE_ID or receive it through client configuration.

Data residency has to be revalidated. On Claude Platform on AWS, the AWS Region for the workspace controls the gateway endpoint and AWS-side resources such as IAM, CloudTrail, and billing, but it does not pin where model inference runs. Claude Platform on AWS uses request-level inference_geo; omitted inference_geo defaults to global. The parameter is supported on Claude Opus 4.7, Claude Sonnet 4.6, and later models, while requests using it on Claude Opus 4.5, Sonnet 4.5, or Haiku 4.5 return a 400 error.

Logging moves to the Claude Platform on AWS event model. AWS CloudTrail can capture Claude Platform on AWS requests, but workspace and vault operations are management events by default, while inference, batch, file, skill, model, user profile, and Claude Managed Agents operations other than vaults are data events that require explicit data event logging configuration and additional CloudTrail charges. Each response includes an AWS request ID, indexed in CloudTrail, and an Anthropic request ID for Anthropic support.

Rate-limit ownership also changes. Claude Platform on AWS assigns Tier 1 limits when the customer subscribes, applies limits per workspace, and manages those limits through Anthropic rather than AWS quota systems. Higher limits are requested through an Anthropic account representative with the workspace ID and desired throughput.

Cost reporting changes from Bedrock billing to AWS Marketplace billing through Claude Consumption Units. Anthropic rates token usage in USD, applies any negotiated discount, converts the result to CCUs at $0.01 per CCU, and reports CCU quantity to AWS Marketplace hourly. The AWS bill shows a CCU line item, AWS Cost Explorer shows aggregated CCU cost, and Claude Console provides real-time usage and cost breakdowns. Existing Bedrock private offers do not transfer automatically to Claude Platform on AWS, and discounts cannot be applied retroactively to usage incurred before the private offer is accepted.


Conclusion

Claude Platform on AWS is a strong option for AWS customers that want the native Claude Platform experience without moving procurement, access control, and audit workflows completely outside AWS. It is especially relevant for applications that rely on Claude Platform capabilities such as Managed Agents, Skills, Files API, prompt caching, and Claude Console workflows.  Code execution, batch processing, credentials management, and memory are available already on AWS through Bedrock AgentCore, but also have Claude Platform equivalents. 

The right access model still comes from the workload. Start with Claude Platform on AWS when native Claude Platform features drive the design and Anthropic-operated inference is approved. Start with Amazon Bedrock when AWS-operated processing, Bedrock-native governance, or multi-model AWS platform architecture drives the design. Use Claude Enterprise when the goal is employee access to Claude apps rather than a custom application.

As a charter member of Anthropic’s Claude Partner Network and an AWS Premier Tier Services Partner, Caylent helps organizations design and implement production-ready Claude workloads on AWS, including access model selection, security and data-boundary review, IAM and audit design, cost modeling, Claude Platform migration planning, and agentic SDLC enablement. Learn more at caylent.com/Anthropic.  

Generative AI & LLMOps
Guille Ojeda

Guille Ojeda

Guille Ojeda is a Senior Innovation Architect at Caylent, a speaker, author, and content creator. He has published 2 books, over 200 blog articles, and writes a free newsletter called Simple AWS with more than 45,000 subscribers. He's spoken at multiple AWS Summits and other events, and was recognized as AWS Builder of the Year in 2025.

View Guille's articles

Learn more about the services mentioned

Caylent Catalysts™

Generative AI Strategy

Accelerate your generative AI initiatives with ideation sessions for use case prioritization, foundation model selection, and an assessment of your data landscape and organizational readiness.

Caylent Services

Artificial Intelligence & MLOps

Apply artificial intelligence (AI) to your data to automate business processes and predict outcomes. Gain a competitive edge in your industry and make more informed decisions.

Accelerate your cloud native journey

Leveraging our deep experience and patterns

Get in touch

Related Blog Posts

From Prompt Edits to Performance Loops: Hands-On with Amazon Bedrock AgentCore Optimization

Amazon Bedrock AgentCore now gives teams a native way to generate, validate, and test changes to agent behavior using traces, evaluations, configuration versions, and gateway-based A/B experiments. Caylent evaluated the feature through private-beta access. This article presents the results of those evaluations and what they mean for teams building on Bedrock.

Generative AI & LLMOps

Claude Opus 4.7 Deep Dive: Capabilities, Migration, and the New Economics of Long-Running Agents

Explore Claude Opus 4.7, Anthropic’s most capable generally available model, with stronger agentic coding, high-resolution vision, 1M context, and a migration story that matters almost as much as the benchmark scores.

Generative AI & LLMOps

The Heirloom Syntax: Why AI Monocultures Threaten the Future of Innovation

Explore how the rise of AI-generated content is creating a fragile monoculture of ideas, and why preserving human originality and diverse thinking is essential for long-term innovation and resilience.

Generative AI & LLMOps