Two Claude Paths Inside AWS and the Bedrock Boundary

AI 요약

• What happened: Anthropic and AWS made Claude Platform on AWS generally available.
  • It lets teams use native Claude platform features through AWS accounts, IAM, CloudTrail, and AWS Marketplace billing.
• The key split: Bedrock is operated by AWS, while Claude Platform on AWS is operated by Anthropic.
• Why it matters: Builders get faster access to Claude agent features, but the compliance and data-processing review is different from Bedrock.
  • Check CloudTrail data event logging, request ID correlation, and whether AWS compliance coverage applies before treating both paths as interchangeable.

Anthropic and AWS announced the general availability of Claude Platform on AWS on May 11, 2026. At first glance, it looks like another cloud partnership milestone: use Claude from an AWS account, control access with IAM, audit activity in CloudTrail, and consolidate spend through AWS Marketplace billing. The more important story is not simply that Claude is available through AWS. It is that AWS now has two materially different ways to run Claude.

One path is Amazon Bedrock. AWS operates the inference stack, and applications call Claude models through Bedrock Converse or InvokeModel APIs. The other path is Claude Platform on AWS. It still uses AWS accounts, IAM, Marketplace billing, and CloudTrail integration, but the actual Claude platform is operated by Anthropic. That route exposes Anthropic's first-party Messages API, Claude Console, Managed Agents, Agent Skills, MCP connector, code execution, web search/fetch, Files API, and other native platform features inside an AWS procurement and access-control wrapper.

That difference is not cosmetic. The model family may be the same, but the API surface, release cadence, audit design, data processors, and compliance boundary are different. When an infrastructure team says it is "using Claude on AWS," the next question now matters: through Bedrock, or through Claude Platform on AWS? The two choices may appear on the same cloud bill, but they do not create the same operating boundary.

Anthropic native APIs through an AWS account

AWS describes Claude Platform on AWS as a way to access Anthropic's native Claude Platform experience directly from an AWS account. The pitch is procurement and operations: reduce separate Anthropic account handling, contracts, and billing flows while keeping access inside familiar AWS Marketplace and IAM workflows. AWS also frames itself as the first cloud provider to offer this native Claude platform experience.

The feature list is the more revealing part. AWS highlights Messages API, Claude Managed Agents beta, advisor tool beta, web search and web fetch, MCP connector beta, Agent Skills beta, code execution, and Files API beta. This is broader than a model endpoint. It is Anthropic's agent platform layer: tool execution, file handling, web context, MCP integration, and managed agent primitives.

Anthropic's own documentation makes the operating model explicit. Claude Platform on AWS is accessed from an AWS account, but runs on Anthropic-managed infrastructure. AWS provides SigV4 or API key authentication, IAM access control, and Marketplace billing integration. Anthropic continues to operate the model execution and first-party Claude platform features.

The appeal is easy to understand. Enterprises already have AWS accounts, IAM roles, cost allocation processes, CloudTrail retention policies, and Marketplace procurement motion. For many AI platform teams, the slow part of adopting a model provider is not writing the first SDK call. It is vendor onboarding, billing approval, permission design, audit logging, and chargeback. Claude Platform on AWS reduces that friction while preserving access to Anthropic's native APIs and newer platform features.

But this convenience is not the same as "Claude operated by AWS." That is where the practical implications begin.

Same AWS account, different data processors

AWS documentation separates Claude Platform on AWS and Amazon Bedrock in a direct comparison. Claude Platform on AWS is operated by Anthropic. Its API surface is Anthropic Messages API, and its base URL uses aws-external-anthropic.{region}.api.aws. Rate limits and quotas are managed by Anthropic. Its data processors are Anthropic and AWS.

Bedrock is different. AWS operates the stack. Its API surface is Bedrock Converse or InvokeModel, and its base URL uses bedrock-runtime.{region}.amazonaws.com. Rate limits and quotas are managed by AWS. The data processor is AWS. AWS explicitly points teams that need AWS-operated Claude and Bedrock APIs toward Amazon Bedrock.

For legal and security teams, this is not a minor wording detail. AWS's own Claude Platform on AWS versus Bedrock documentation says Claude Platform on AWS is a third-party offering provided by Anthropic and is not covered by standard AWS compliance programs, certifications, or audit reports. It tells organizations that need FedRAMP High, IL4, IL5, SOC, ISO, HIPAA eligibility, or AWS as the sole data processor to use Bedrock.

Anthropic's documentation adds another operational detail: data may not remain entirely within AWS, inference may route to Anthropic's primary cloud, and downstream internal services may change over time. Request-level inference_geo can specify a geographic inference location, but that is still not identical to Bedrock's AWS-operated boundary.

So the product is closer to "buying Anthropic through AWS" than to "moving Anthropic completely inside AWS." AWS provides identity, access, billing, and an audit entry point. Anthropic operates the Claude platform. Missing that distinction creates risk, especially when teams assume that anything billed through AWS inherits Bedrock-like data handling.

The tradeoff is feature speed versus compliance simplicity

Why have two paths at all? The answer is feature velocity. Anthropic is building a platform above the model API: Managed Agents, Agent Skills, MCP connector, code execution, Files API, web search/fetch, and advisor tooling. These features are not just alternative model names. They involve tools, files, long-running sessions, external systems, prompt development, and evaluation workflows.

Bedrock is a multi-provider managed model platform built in the AWS style. Its strengths are AWS-operated inference, consistency with AWS services, Bedrock-native features such as Guardrails and Knowledge Bases, and enterprise data-boundary options. The tradeoff is structural: newly released Anthropic beta features do not automatically appear in the same shape on the same day.

Claude Platform on AWS narrows that gap. Teams can keep AWS billing and IAM while getting closer to Anthropic's first-party feature surface. AWS's announcement shows environment-variable examples for pointing Claude Code, Claude Cowork, and SDK clients at a workspace. Developers can work closer to Anthropic's native API model while platform teams retain AWS account-level controls and spend management.

The cost is the data boundary. If Bedrock's core advantage is AWS-operated inference and AWS compliance coverage, Claude Platform on AWS's advantage is native Claude API parity and faster access to agent capabilities. Neither is universally better. Experimental agents, internal developer tools, and early feature validation may fit Claude Platform on AWS well. Regulated production workloads, sensitive customer data, or contracts requiring AWS as the only processor may fit Bedrock better.

This is the broader shift: model platform selection is now a bundle of product capability and operating control.

CloudTrail helps, but logging still needs design

One of Claude Platform on AWS's practical strengths is CloudTrail integration. AWS says Claude Platform activity can be captured in CloudTrail so teams can monitor, audit, and investigate AI usage alongside other AWS services. For security operations teams, that is useful. They do not have to rely only on a separate provider console to find Claude activity.

The details still matter. AWS monitoring documentation explains that CloudTrail can capture all requests, but workspace and vault operations are recorded as management events by default, while inference, batch, file, skill, model, user profile, and Claude Managed Agents operations are data events. Data events require explicit configuration and can add CloudTrail cost. In other words, "CloudTrail support" does not mean every inference or agent action is automatically logged by default.

Request IDs also reveal the split boundary. Responses include both x-amzn-requestid and request-id. The first supports AWS tooling and AWS support investigation. The second connects to Anthropic support. In an incident, billing anomaly, or abuse investigation, teams may need to correlate AWS-side events with Anthropic-side requests.

That correlation becomes more important for agent workloads. A simple chat request can often be understood as one model call. Managed Agents, MCP connector, code execution, and Files API can involve sessions, uploaded files, tool calls, execution output, approvals, and cost across more than one surface. Teams need to decide which CloudTrail data events to enable, how to tag workspaces for cost allocation, how to join Anthropic usage views with AWS Cost and Usage Reports, and whether application logs should persist both AWS and Anthropic request IDs.

Community reaction has focused on the same tension. A Reddit discussion in r/ClaudeAI framed IAM authentication, AWS billing integration, CloudTrail visibility, and the removal of separate account handling as clear advantages, while warning that customer data may be processed outside the AWS security boundary. Commenters also noted that web search/fetch alone does not solve the full agent execution problem; logged-in browser state, DOM visibility, visible actions, and review points become important as agents take on longer tasks.

The point is not that CloudTrail is inadequate. It is that agent platforms make audit design a first-class architecture choice.

Migrating from Bedrock is not just changing an endpoint

It would be easy to misread this announcement as another AWS endpoint option. AWS's migration documentation says otherwise. Moving from Bedrock to Claude Platform on AWS changes the integration across signing context, base URL, API format, model IDs, SDK clients and packages, streaming format, request headers, and regional availability.

With Bedrock, the base URL is bedrock-runtime.{region}.amazonaws.com, and applications use Bedrock Converse or InvokeModel. With Claude Platform on AWS, the base URL is aws-external-anthropic.{region}.api.aws, and applications use Anthropic Messages API. Model IDs are not the same Bedrock-style anthropic. identifiers. The SDK path changes too, with platform-specific clients such as AnthropicAWS instead of a Bedrock runtime client.

That creates different developer ergonomics depending on where a team starts. If a team already uses Anthropic's direct API, Claude Platform on AWS can feel natural: keep the Claude API shape while adding AWS procurement, IAM, and billing. If a team has invested in a Bedrock abstraction across multiple model providers, moving to Claude Platform on AWS means adapting streaming, model identifiers, client libraries, and request formats. The payoff is faster access to Anthropic's native features; the cost is leaving some of the Bedrock abstraction behind.

Platform teams can also split the decision by workload. Production inference involving regulated data or customer PII may stay on Bedrock. Internal developer tools and agent experiments may use Claude Platform on AWS for faster access to Managed Agents, Skills, code execution, and MCP. A product whose core feature depends on Claude's native agent stack may choose Claude Platform on AWS, but route sensitive input through redaction and policy gateways first.

The useful rule is simple: an AWS invoice does not define an architecture boundary.

AI infrastructure competition is moving up the stack

This announcement is interesting because it shows how model competition is turning into platform competition. In 2024 and 2025, the conversation was dominated by benchmark scores and model family comparisons. In 2026, enterprise AI teams have a longer checklist. How quickly do new model and agent features arrive? Does the provider fit existing IAM? Can cost be allocated by team? Can tool calls be audited? Where is data processed? How do cloud logs and model-provider support IDs connect during an incident?

Anthropic is expanding Claude's native platform surface quickly. Managed Agents handle long-running agent work. Agent Skills package reusable task knowledge. MCP connector links external tools. Code execution and Files API move Claude beyond pure text generation into execution and document workflows. These features have a much wider operational footprint than a single completion endpoint, which makes the AWS account integration significant.

AWS is not offering one Claude route. Bedrock is the AWS-operated model platform. Claude Platform on AWS is an Anthropic-operated native Claude platform made available through AWS accounts. They compete for some workloads and complement each other for others. Bedrock is stronger when the priority is AWS service integration, data-boundary clarity, and AWS compliance coverage. Claude Platform on AWS is stronger when the priority is the first-party Claude API and fast access to newer agent features.

For developers, the upside is more choice. The downside is a harder abstraction problem. Behind the phrase "call Claude" there may be Bedrock, Anthropic direct API, Claude Platform on AWS, Vertex AI, Microsoft Foundry, or another route. Each can differ in model IDs, feature support, rate limits, logs, cost surfaces, and data processors. Internal gateways and AI SDK layers should not hide those differences so completely that compliance and incident response lose the details they need.

What teams should check now

First, define the data boundary before the API. If a workload requires AWS compliance programs, regional data residency, or AWS as the sole data processor, Bedrock may be the better fit. If native Claude platform features such as Managed Agents, Agent Skills, MCP connector, and code execution matter more, Claude Platform on AWS is worth evaluating, but its Anthropic-operated infrastructure and data-processing terms need to be documented.

Second, do not assume audit defaults. CloudTrail support is real, but data-plane events require explicit setup and can add cost. Decide whether inference, file, skill, and agent operations need to be tracked, whether workspace scopes should be separated, and how to configure the AWS::AWSExternalAnthropic::Workspace resource type. At minimum, application logs should retain both AWS and Anthropic request IDs.

Third, estimate the integration cost. Moving from Bedrock to Claude Platform on AWS changes base URL, API format, model IDs, SDK, streaming, and request headers. Teams with a mature Bedrock abstraction should compare feature velocity against migration work. Teams already using Anthropic's direct API may see Claude Platform on AWS as a lower-friction path to AWS procurement and IAM.

Fourth, treat agent features as a wider permission surface. Managed Agents, code execution, Files API, and MCP connector involve more than text generation. Teams need to know which IAM principals can use which workspace, tools, files, and execution features; where tool results and uploaded files are logged; and where human approval belongs in the workflow.

Conclusion: "on AWS" is no longer specific enough

Claude Platform on AWS is a meaningful product for both Anthropic and AWS. Anthropic can bring its native Claude platform into the enterprise AWS operating model. AWS can capture demand for first-party Claude APIs and newer agent features that Bedrock may not expose in the same form or at the same speed. Developers get IAM, CloudTrail, and Marketplace billing while testing Claude's latest platform capabilities sooner.

But the convenience does not make it equivalent to Bedrock. Bedrock is the AWS-operated path. Claude Platform on AWS is the Anthropic-operated native Claude path made available through AWS accounts. AWS documents the distinction plainly because it affects the questions that now matter most in AI infrastructure: who operates the stack, who processes the data, which audit logs exist by default, and which compliance scope applies.

The practical takeaway is straightforward. Before saying "we use Claude on AWS," name the route. Bedrock, Claude Platform on AWS, and direct API access may involve the same model family, but they create different responsibilities. Faster access to agent features and a simpler data boundary are not always the same choice. Claude Platform on AWS makes that tradeoff visible, which is why it is an important moment in the 2026 AI infrastructure race.

Sources: Anthropic announcement, Anthropic Claude Platform on AWS documentation, AWS announcement, AWS Claude Platform on AWS versus Bedrock documentation, AWS monitoring documentation, AWS migration documentation.