Using Claude on AWS: Why Your Integration Choice Matters

AWS customers now have two ways to use Claude with AWS: Claude Platform on AWS and Claude in Amazon Bedrock.

At first glance, they can look very similar. Both involve AWS, both can use AWS identity and billing, and both give teams access to Claude models. But from a security architecture point of view, they are not the same thing. The difference is not really about the model. It is about the trust boundary.

When I look at a GenAI workload from a security perspective, I do not start with the model name. I start with a simpler question:

Who receives and processes the prompt?

That question matters because with generative AI, the prompt is often the data. It might contain internal documents, source code, customer context, financial information, architecture details, incident notes, or other sensitive business information. So before talking about features, latency, or developer experience, I want to understand where that data goes and which party operates the platform that processes it.

This is where Claude Platform on AWS and Amazon Bedrock differ. Claude Platform on AWS gives AWS customers access to Anthropic's native Claude platform experience through AWS, including the Claude Console, native API behavior, and faster access to certain Claude platform features. But the platform is operated by Anthropic. Amazon Bedrock is different: it is AWS's managed foundation model service. Claude is available inside Bedrock, but the service boundary, governance model, and operating responsibility sit with AWS.

That does not make one option automatically right and the other wrong. It means the security review is different.

"Available Through AWS" Is Not the Same as "Operated by AWS"

If a team says, "We are using Claude through AWS," that can mean two different things. It can mean they are using Claude Platform on AWS, where AWS provides integration points such as account access, billing, and familiar controls, but Anthropic operates the Claude platform experience. Or it can mean they are using Claude through Amazon Bedrock, where Claude is consumed through the AWS-managed Bedrock service.

From a security review perspective, those are very different answers. For Claude Platform on AWS, the review needs to include Anthropic as a platform operator and data processor. That means looking at Anthropic's terms, privacy commitments, retention behavior, support model, and third-party risk posture. For Bedrock, the review fits more naturally into the existing AWS governance model. If your organization already uses AWS Organizations, IAM, CloudTrail, CloudWatch, VPC endpoints, central security accounts, and AWS compliance evidence, Bedrock aligns more directly with that operating model.

Data Privacy, Compliance, and Residency

For me, the privacy discussion is where this comparison becomes very practical. With Claude Platform on AWS, prompts and completions are processed by Anthropic. That means your data crosses a third-party platform boundary. For low-risk experimentation, public content, or workloads where Anthropic has already been approved as a processor, that may be acceptable. But for confidential, regulated, customer-owned, or highly sensitive data, I would not treat this as a small implementation detail. Legal, procurement, privacy, and security teams should all understand the operating model before production usage.

With Amazon Bedrock, AWS is the operating party for the service, and the model provider does not receive access to customer prompts and completions through the Bedrock service model. That makes Bedrock the more natural starting point when the requirement is AWS-operated inference or AWS as the sole data processor.

Compliance is often where this becomes less theoretical. Claude Platform on AWS is a third-party offering, so it should not automatically be treated the same as an AWS-operated service for audit evidence, compliance scope, or regulatory approval. Amazon Bedrock fits more directly into AWS compliance programs where applicable. For organizations in financial services, healthcare, public sector, or other regulated environments, that can make a major difference.

Data residency still needs design in both cases. With Claude Platform on AWS, a workspace being tied to an AWS Region does not automatically answer every residency question. Teams still need to understand where inference runs and how geography is enforced. With Bedrock, the Regional AWS service model is more familiar for AWS teams, but the full workload still matters: logging destinations, S3 buckets, CloudWatch log groups, backups, and downstream services can all affect where data ends up.

Logging Needs Intentional Design

Logging deserves its own attention. It is tempting to say "log everything" for security, but with AI workloads that can backfire. If prompts and outputs are logged, those logs may contain the same sensitive data as the original request.

That means log buckets and log groups may become sensitive data stores. They need encryption, access control, retention policies, and monitoring that match the classification of the data being processed. More logging is not automatically better security. Intentional logging is.

My Decision Rule

If I had to reduce the choice to one starting point, I would use data classification.

For public content, early experimentation, internal enablement, or teams that need the newest Anthropic-native capabilities quickly, Claude Platform on AWS can be a strong option. The native platform experience and feature velocity are real advantages. For confidential, regulated, customer-owned, or centrally governed enterprise workloads, I would usually start with Amazon Bedrock. It gives you the AWS-operated service boundary, AWS-native governance, and a cleaner path for organizations that already manage cloud risk through AWS controls.

So the trade-off is not simply innovation versus security. It is more specific than that:

native Claude platform velocity versus AWS-native governance depth.

I would consider Claude Platform on AWS when the team needs the native Claude platform experience, the data classification allows Anthropic as a processor, and the organization is comfortable completing the required third-party risk review. I would start with Amazon Bedrock when AWS-operated inference is required, AWS must be the sole data processor, the workload is regulated or highly confidential, or the organization wants GenAI workloads to stay inside its existing AWS governance model.

Both options can be valid. But they are not equivalent from a security, compliance, and data privacy perspective.

The model may be Claude in both cases. The risk decision is not the same.