Claude on AWS: Bedrock vs Platform Security Checklist

Your team just asked to add Claude to a production workflow, and someone in security needs to sign off by Friday. Before you approve anything, you need to answer one question that most requests skip entirely: which Claude are they actually asking for?

AWS customers can now reach Claude two different ways. Claude Platform on AWS gives you Anthropic's native console and API experience, with billing and account access running through AWS. Amazon Bedrock gives you Claude through AWS's own managed foundation model service.

These two options look similar in a Slack message. They are not similar in a security review. Use this checklist to figure out which one fits your workload, and what to verify before you approve either one.

Step 1: Classify the Data Before You Classify the Tool

Start with the prompt, not the product. Generative AI workloads are unusual because the prompt itself is often the sensitive asset, not just the output. Source code, customer PII, financial figures, incident notes, architecture diagrams described in text: all of that can end up inside a Claude request.

Write down, in plain language, what categories of data this workload will send to the model. Then apply your existing data classification tiers (public, internal, confidential, regulated) to that list, before anyone picks a platform.

If the answer is "public content or early-stage experimentation," your risk tolerance is wider. If the answer includes regulated or customer-owned data, you've just narrowed your options considerably, and that narrowing should happen now, not during an incident review.

Step 2: Identify the Actual Trust Boundary

Here's where the two options diverge. With Claude Platform on AWS, Anthropic operates the platform, and your prompts and completions cross into a third-party system even though billing and account access run through AWS. With Amazon Bedrock, AWS operates the service boundary, and the model provider does not receive access to your prompts and completions through that service model. See more on how to read open-source code like a senior engineer for additional background.

Ask your team directly: "When we say we're using Claude through AWS, do we mean Anthropic is processing this data, or does it stay inside AWS's operating boundary?" If nobody can answer that question with confidence, stop the review there. That ambiguity is the actual risk, not the model itself.

Step 3: Run Third-Party Risk Review If Anthropic Is the Processor

If your workload uses Claude Platform on AWS, treat Anthropic as a processor and run your standard third-party risk process against it. Pull Anthropic's terms of service, data retention policy, and support model into your review — don't assume AWS's compliance posture covers it by extension.

Check these items specifically:

1. Retention behavior: how long are prompts and completions stored, and can you configure or disable that retention for your workspace?
2. Support access: can Anthropic support staff view request content during troubleshooting, and under what conditions?
3. Subprocessor list: does Anthropic use any downstream vendors for infrastructure or logging, and are those disclosed?
4. Contractual terms: does your organization have a signed data processing agreement or equivalent with Anthropic, separate from your AWS agreement?

Loop in legal, procurement, and privacy teams here. Skipping this step because "it's just AWS" is the single most common mistake teams make with Claude Platform on AWS.

Step 4: Map IAM and Logging Requirements for Bedrock

If the workload points to Amazon Bedrock instead, your review shifts into familiar AWS territory. That familiarity is not a reason to move faster without checking specifics.

Confirm IAM policies scope Bedrock model invocation permissions tightly. Grant bedrock:InvokeModel only to the roles and services that need it, and avoid wildcard resource ARNs across model IDs. Check whether your account uses VPC endpoints for Bedrock so traffic doesn't traverse the public internet, and verify CloudTrail captures Bedrock API calls and routes those logs to a centralized security account, consistent with how you already handle CloudTrail for other services.

Then look at CloudWatch. Bedrock can log invocation data, including prompts and model responses, if you enable it. That's useful for debugging and audit trails, but it also means those log groups now hold the same sensitive content as the original request. Apply encryption at rest, restrict IAM access to those log groups, and set retention periods that match your data classification rather than your default logging policy.

Step 5: Verify Compliance Scope Actually Covers Your Use Case

Don't assume either option automatically satisfies your compliance obligations. Claude Platform on AWS is a third-party offering sitting on top of AWS infrastructure — don't treat it as equivalent to an AWS-operated service for audit evidence or regulatory approval. If your organization needs SOC 2, HIPAA, or FedRAMP-aligned evidence for this specific workload, confirm Anthropic's own compliance attestations cover it, separate from AWS's.

Amazon Bedrock fits more directly into AWS's existing compliance programs where those programs apply to your account and region. That's a real advantage for regulated industries like financial services, healthcare, or public sector, but confirm the specific Bedrock features and model you're using fall within the compliance scope you're relying on. Not every AWS compliance certification automatically extends to every feature.

Step 6: Nail Down Data Residency Beyond the Region Selector

Selecting a region in the console doesn't close this question. For Claude Platform on AWS, a workspace tied to a region doesn't automatically guarantee inference happens only in that geography. Ask directly where inference execution occurs and how that's enforced contractually, not just operationally.

For Bedrock, the regional service model is more familiar to AWS teams, but trace the entire data path: where do logs land, which S3 buckets store any cached data, which CloudWatch log groups get created, and do backups replicate outside your intended region? Residency requirements fail more often because of a forgotten backup or log destination than because of the model provider itself.

Step 7: Match the Platform to the Workload, Not the Team's Preference

Once you've worked through classification, trust boundary, third-party review, IAM, logging, and residency, the decision usually becomes clear. Public content, internal enablement, and teams that need Anthropic's newest platform features quickly are reasonable candidates for Claude Platform on AWS, provided the third-party risk review is complete. Confidential, regulated, or centrally governed workloads should start with Amazon Bedrock, where AWS holds the operating boundary and your existing AWS governance controls apply directly.

Document that decision and the reasoning behind it. The next audit, the next new hire on the platform team, and the next workload that wants to reuse this pattern will all need to know why you chose what you chose.

Expect this decision to come up again soon, and not just for Claude. As more foundation models ship both a native platform offering and a hyperscaler-managed version, this same checklist — classify the data, find the trust boundary, verify third-party terms, confirm IAM and logging scope — will apply well beyond Anthropic and AWS.