AWS Bedrock: the compliance checklist before you adopt it

AWS Bedrock is an alternative to running inference directly on each model vendor's own servers: instead of negotiating a separate contract with every provider, you get several third-party models — Anthropic, Meta, Amazon Titan and others — behind a single AWS interface. But a single interface doesn't remove the contractual caveats, it just relocates them: Bedrock is not a model, it's a shelf, and before signing, a legal team should have already read at least two documents that are not AWS's DPA.

What Bedrock is, and why it changes due diligence

Bedrock as a multi-model layer

Reviewing an AI tool usually means checking one vendor and one contract. Bedrock breaks that pattern: every model you enable comes with its own third-party provider and its own terms. The DPA you sign with AWS covers the infrastructure — it does not replace the terms of the model provider behind a given call.

Why the terms "stack": AWS plus a third-party model provider

This isn't an implicit detail — it's written into AWS's Service Terms. Section 50.12.1 classifies third-party models as "Third-Party Content" and makes their use conditional on accepting the applicable provider terms. Section 50.16, on "Claude Platform on AWS", is even more explicit: using Claude on AWS is subject to Anthropic's Commercial Terms of Service, its Data Processing Addendum and its Usage Policy — on top of the AWS terms. On Anthropic's side, its Commercial Terms of Service (effective June 17, 2025) confirm that data is processed under Anthropic's DPA, incorporated by reference — but the contract text doesn't mention AWS or Bedrock at all; the explicit link is established from the AWS side (Section 50.16), not from Anthropic's. That's why the check has to run on both sources, not just one.

The AWS DPA: what to check

Scope of the Data Processing Addendum and controller/processor roles

AWS's DPA is incorporated into its Service Terms (Section 1.14.4) and covers processing on AWS infrastructure. One point that's often missed: AWS's GDPR Center states plainly that "AWS acts as both a data processor and a data controller under the GDPR" — the role isn't fixed, it depends on the specific processing activity. Before procurement, get it in writing which role AWS takes for each data flow that runs through Bedrock — don't default to assuming "processor".

GDPR legal basis and stated purposes of processing

AWS's GDPR Center is the starting point for understanding how AWS frames its role and responsibilities — but it's a generic AWS document, not Bedrock-specific. Whoever is evaluating the service needs to ask AWS directly how it applies to the actual use case: what data flows through it, for what purpose, and on what legal basis the processing rests on the customer's side.

The model provider's terms: the layer that gets added

Example: Anthropic's terms via AWS Marketplace

Anthropic is a useful example because it's documented on both sides. One relevant technical fact, confirmed in Bedrock's documentation: third-party model providers don't have access to customer prompts and completions. AWS manages each provider through a dedicated "Model Deployment Account" — one per provider per region — owned and operated by the Bedrock service team, with no provider access. That's a useful technical safeguard, but it doesn't replace checking the provider's own contractual terms.

Questions to ask before enabling a model in production

Before turning on a model in production: who are the model providers actually involved in the pipeline, even if the code only calls "Bedrock"? Have their specific terms been read, not just AWS's? Is there a DPA on the model provider's side too, or only on AWS's? What happens to logs and data if the model is later disabled?

Where the data actually lives: EU regions and cross-region inference

EU regions where Bedrock is available

Bedrock is currently available in six European regions that are actually in the EU: Frankfurt (eu-central-1), Ireland (eu-west-1), Milan (eu-south-1), Paris (eu-west-3), Spain (eu-south-2) and Stockholm (eu-north-1). One detail that causes confusion: AWS also lists London (eu-west-2) and Zurich (eu-central-2) under the "Europe" label — but the UK and Switzerland are not EU member states. If the internal requirement is "EU region", those two need to be explicitly excluded during configuration.

The quiet risk of cross-region inference

Bedrock offers two cross-region inference modes: Geographic, which keeps routing within a chosen geographic perimeter (for example, the EU), and Global, which routes anywhere in the world for roughly a 10% cost saving. For data-residency requirements, AWS explicitly recommends the Geographic profile. One technical mitigant: data transmitted during cross-region operations stays on the AWS network, never crosses the public internet, and is encrypted in transit; every cross-region request is logged in CloudTrail with the actual inference region. Still, the underlying point holds: without an explicit choice of the Geographic profile, processing can move outside the selected region — that's not a default behaviour you can take for granted.

EU AI Act: Bedrock's role as infrastructure

Why Bedrock isn't "the model" for classification purposes — and what still falls on whoever uses it

Article 3 of Regulation (EU) 2024/1689 defines a "provider" as whoever develops an AI system or general-purpose model and places it on the market under its own name, and a "deployer" as whoever uses an AI system under its own authority. The definition most relevant to whoever builds on Bedrock is arguably "downstream provider": a provider that integrates an AI model supplied by another entity based on a contractual relationship. Article 3's text doesn't contain an explicit "infrastructure provider" category, or a direct reference to "AI-as-a-service" offerings: the role of whoever uses Bedrock has to be argued case by case — often deployer, sometimes downstream provider depending on what's built on top — rather than read directly off the regulation on this specific point.

Practical checklist: questions to bring to procurement

• Which role does AWS take (controller or processor) for each processing activity that runs through Bedrock?
• Have the terms of every enabled model provider been read separately from the AWS DPA?
• Is the configured region actually in the EU (excluding London and Zurich)?
• Is cross-region inference set to the Geographic profile, if data needs to stay within the EU?
• Where are logs, prompts and completions stored, and for how long?
• Has your role under the EU AI Act (deployer or downstream provider) been defined for this specific use case?

Conclusion

Bedrock isn't one contract to sign: it's an AWS DPA plus, for every model you turn on, a third-party provider's terms that don't disappear just because the call goes through a single API. Doing this due diligence properly isn't slower than reviewing a single vendor — it's just spread across two or more sources. Before your next Bedrock procurement round, check roles, regions and model-provider terms with the same rigor: it's an afternoon's work, and far cheaper than finding out later.

Sources

• AWS Service Terms, Sections 50.12.1 and 50.16 ("Claude Platform on AWS"); Section 1.14.4 for the Data Processing Addendum.
• Anthropic, Commercial Terms of Service, effective June 17, 2025.
• AWS GDPR Center.
• AWS, "Data protection in Amazon Bedrock" (Model Deployment Account).
• AWS, "Cross-Region inference in Amazon Bedrock".
• AWS, "Amazon Bedrock endpoints and quotas" (available regions).
• Regulation (EU) 2024/1689 (EU AI Act), Article 3, definitions.