Claude on AWS vs. Azure vs. Google Cloud: GDPR Data Residency Compared (2026)
A hands-on comparison of hosting Claude AI on AWS Bedrock, Azure AI Foundry, and Google Vertex AI — with DPA analysis, data residency options, and a pragmatic compliance strategy for European enterprises.
Last updated: February 2026 · Reading time: ~20 min
Legal Disclaimer: This article does not constitute legal advice. It reflects my personal assessment as an IT leader based on publicly available contracts, documentation, and over a decade of enterprise IT experience. For binding legal assessments, consult your Data Protection Officer or a qualified legal professional. Every organization's situation is different — what works for mine may not work for yours.
Key Takeaways
- AWS Bedrock is the only provider with guaranteed EU data residency for Claude (via EU Inference Profile)
- Azure AI Foundry has Claude in Preview status — meaning reduced DPA guarantees and no personal data allowed
- Google Vertex AI offers no EU data residency for Claude, but full CDPA guarantees even for preview models
- PII filters only work on plain text — they can't scan PDFs, images, or documents that Claude accepts as multimodal input
- The CLOUD Act means US authorities can access data at all three providers regardless of where it's stored
- My recommendation: Azure + Google Cloud covers all three major model families (GPT, Gemini, Claude) — model coverage beats data residency as a strategic priority
TL;DR
Claude by Anthropic is one of the most capable AI models on the market. But Anthropic doesn't offer direct EU hosting. Claude runs exclusively through AWS Bedrock, Google Vertex AI, or Azure AI Foundry. Each of these providers handles data protection differently. If you don't understand the differences, you risk either compliance violations or unnecessarily blocking your organization from using AI.
This article shows where the real risks lie, where the contracts have gaps, and how you as IT leadership can make autonomous decisions — without involving your data protection lawyer for every AI request.
1. Why Hosting Claude AI in Europe Is Complicated
Anthropic, the maker of Claude, is a US company based in San Francisco. Unlike OpenAI (via Microsoft) or Google (own cloud), Anthropic doesn't offer its own European cloud service. Instead, Claude is available as a third-party model through the marketplaces of the three major cloud providers:
- AWS Bedrock — Amazon's AI platform
- Google Vertex AI — Google's AI platform
- Azure AI Foundry — Microsoft's AI platform (formerly Azure AI Studio)
Sounds like a standard situation: sign a cloud contract, attach a DPA, done. But it's not. The three providers differ fundamentally in where data is actually processed — and that's the core of the GDPR question.
The Sub-Processor Chain
With all three providers, the contractual chain looks identical:
Your Company (Data Controller)
└── Cloud Provider (Data Processor) — DPA/CDPA + SCCs
└── Anthropic (Sub-Processor) — Sub-processor agreement
This means: you have no direct contract with Anthropic. Your data protection relationship with Anthropic runs exclusively through the cloud provider. Whether that's sufficient depends on the quality of the DPAs — and on what the DPAs actually guarantee when you read the fine print.
2. Deployment vs. Endpoint vs. Data Residency — What Actually Matters for GDPR
In conversations with the C-suite or DPO, a misunderstanding regularly occurs that can get expensive. Three terms sound similar but mean completely different things:
| Term | What It Means | GDPR Relevance |
|---|---|---|
| Deployment | The model is installed in an EU data center | Low — says nothing about data processing |
| Endpoint | The API address is in the EU (e.g., europe-west4) | Medium — the request goes to an EU server |
| Data Residency | ML processing (inference) is guaranteed to happen in the EU | High — the only guarantee that matters |
The critical insight: An EU endpoint does not automatically mean your data is processed in the EU. With "Global Standard" deployments, the actual AI computation can be routed to the US or any other country where the provider or its sub-processors operate data centers.
The Three Deployment Modes in Detail
Data Zone / Regional (EU guarantee present):
- ML processing is guaranteed to stay within defined EU regions
- Contractual assurance via DPA or product configuration
- Example: AWS Bedrock EU Inference Profile, Google Vertex AI Regional (for their own Gemini models)
Global Standard (EU endpoint, but global processing):
- API endpoint is in the EU, data at rest stays in the EU
- But: ML processing (inference) can happen worldwide
- Example: Azure AI Foundry for Claude, Google Vertex AI for Claude
EU Inference Profile (AWS-specific):
- Special AWS Bedrock mechanism with the
eu.prefix - Processing restricted to six EU regions: Frankfurt, Ireland, Paris, Stockholm, Milan, Spain
- Immutable region list — AWS cannot unilaterally change the regions
3. Claude Opus 4.6 on AWS Bedrock vs. Google Vertex AI vs. Azure AI Foundry
Here's where it gets concrete. I analyzed all three platforms — not the marketing materials, but the actual data and contracts. As of February 2026.
Claude Models: Cloud Provider Comparison
| Criterion | AWS Bedrock | Google Vertex AI | Azure AI Foundry |
|---|---|---|---|
| Claude Opus 4.6 available | Yes | Yes | Yes |
| Claude Sonnet 4.6 available | Yes | Yes | Yes |
| Deployment in EU | Yes | Yes | No* |
| EU endpoint | Yes | Yes | Yes |
| Data Residency EU | Yes (EU Inference Profile) | No (Global only) | No (Global Standard) |
| Lifecycle status | GA | GA | Preview |
| Retirement date | — | — | June 1, 2026 |
| Legal safeguards | EU Data Residency | SCCs + CDPA | SCCs + DPA |
| Schrems III risk | None | Present | Present |
* Azure: Claude is processed through Anthropic servers in the US, not in Azure data centers.
Result: AWS Bedrock is the only provider offering guaranteed EU data residency for Claude. Google and Azure process data potentially globally — which is legal today (thanks to SCCs + DPF) but poses a future risk with Schrems III.
For Comparison: Where Do the Competitors Stand?
This table also shows why a multi-cloud strategy makes sense:
| Model | AWS Bedrock | Google Vertex AI | Azure OpenAI |
|---|---|---|---|
| Claude (all versions) | EU Data Residency | Global only | Global Standard only |
| GPT-4o / 4o-mini | Not available | Not available | EU Data Residency (7 regions) |
| GPT-5.2 | Not available | Not available | Limited (1 region) |
| Gemini 2.5 Pro/Flash | Not available | EU Data Residency | Not available |
| Gemini 3.x | Not available | Global only (Preview) | Not available |
The takeaway: No single cloud provider offers EU data residency for all top models. If you want the best model and the best data protection, you need at least two providers.
4. DPA Comparison: Microsoft vs. Google vs. AWS Data Processing Agreements
I analyzed the current data processing agreements of all three providers. The results are sobering — and in one case, surprising.
Microsoft DPA (September 2025)
The Microsoft DPA is a comprehensive 27+ page document. Four sections are relevant for this use case:
Data Transfers (p. 19): The customer authorizes Microsoft to transfer data to the US or any other country where Microsoft or its sub-processors operate. The transfer occurs under the 2021 SCCs.
Storage Locations (p. 20): For core online services, Microsoft stores customer data at rest in specific geographic areas. For EU Data Boundary services, customer data and personal data are processed within the EU and EFTA. But: Azure AI with Global Standard is not an EU Data Boundary service.
Sub-processors (pp. 22-23): Microsoft notifies the customer 6 months in advance of new sub-processors. The customer has the right to object with the option to terminate.
Preview Clause (p. 24) — the critical point: Previews have limited data protection guarantees. Preview data may be transferred to, stored, and processed in the US or any other country. The storage location guarantees for customer data do not apply to Previews. Microsoft explicitly recommends not using Previews for processing personal data or regulatory-relevant data.
What this means for Claude on Azure: Since Claude on Azure currently has Preview status (retirement date: June 1, 2026), the reduced DPA conditions apply. Personal data should not be processed through Azure-Claude.
Google CDPA (Cloud Data Processing Addendum)
The Google CDPA is structurally different from the Microsoft DPA:
Data Processing (Section 10.1): Customer data may be processed in any country where Google or its sub-processors maintain facilities. Data residency is controlled through product configuration, not through the CDPA itself.
Sub-processors (Section 11): Google notifies the customer 30 days before engaging new sub-processors. The customer has a 90-day objection period with ordinary termination.
SCCs (Appendix 3): Google has its own SCC structure with multiple variants (controller-to-processor, processor-to-processor, etc.). In case of conflicts, the SCCs take precedence over the CDPA.
Preview Clause: None. This is the surprise. The Google CDPA contains no limitation on data protection guarantees for preview or beta models. The full CDPA terms apply to preview models on Vertex AI as well.
AWS DPA
The AWS GDPR Data Processing Addendum is integrated into the AWS service terms and applies automatically to all customers worldwide. AWS offers the EU Inference Profile as a technical mechanism that restricts data processing to EU regions — this is a technical guarantee, not just a contractual one.
AWS is also certified under the EU-US Data Privacy Framework and provides SCCs. For Claude models on AWS Bedrock, the preview issue is not relevant — all Claude models have GA status.
DPA Comparison Table
| Aspect | Microsoft DPA | Google CDPA | AWS DPA |
|---|---|---|---|
| SCCs included | Yes (2021) | Yes (Appendix 3, multiple variants) | Yes |
| DPF certification | Yes | Yes | Yes |
| Preview limitation | Yes — p. 24: no storage location guarantees | No — full guarantees | N/A (Claude is GA) |
| Sub-processor notice period | 6 months | 30 days | To be verified |
| Right to object | Yes + termination | Yes + termination (90 days) | Yes |
| Data zone anchored in DPA | No (product level) | No (product level) | EU Inference Profile |
| Global processing permitted | Yes (with Global Standard) | Yes (standard) | Yes (without eu. profile) |
| Contractual data deletion | 90 days after contract end | 180 days (max.) | Per contract |
5. Preview vs. GA Models: Why Claude's Status Matters for GDPR Compliance
This point is overlooked in most organizations and deserves special attention.
What Does Preview Mean?
A model in preview status:
- Is not generally available (no General Availability)
- Can be changed or discontinued at any time
- Has a fixed retirement date
- Typically offers no SLA
How Long Do Preview Phases Typically Last?
Preview phases are not indefinite — they follow a predictable pattern:
| Provider | Typical Preview Duration | Path to GA | Example |
|---|---|---|---|
| Microsoft Azure | 3–6 months | Microsoft sets a retirement date; model either goes GA or gets removed | Claude on Azure: Preview since late 2025, retirement date June 1, 2026 |
| Google Cloud | 2–4 months | Shorter cycles; Google tends to move models to GA faster | Gemini models typically reach GA within weeks to a few months |
| AWS | Rarely applicable | AWS tends to launch models directly in GA status | Claude on Bedrock: GA from day one |
The practical implication: Preview is a temporary state. If you're evaluating Claude on Azure today and the Preview status is a blocker for personal data, you're likely looking at a 3–6 month wait until GA. That's not a permanent limitation — it's a timing question. Plan accordingly: use Azure-Claude for non-personal data now, and reassess once GA is announced.
Watch out for retirement dates. A preview model with a retirement date doesn't automatically become GA — it can also be deprecated. Always check the provider's model lifecycle page before building production workflows on preview models.
Why Is This GDPR-Relevant?
The answer depends on which provider the model runs on:
| Provider | Preview Policy | Consequence for Personal Data |
|---|---|---|
| Microsoft Azure | DPA p. 24: Limited guarantees, storage location guarantees don't apply | No personal data with Previews |
| Google Cloud | CDPA contains no preview limitation | No contractual restriction |
| AWS | Claude is GA — preview issue doesn't exist | Regular DPA conditions apply |
Claude on Azure is currently Preview. Concretely: the Microsoft DPA guarantees regarding storage location and data processing do not apply to Claude on Azure. Preview data can, per the DPA, be transferred to the US or any other country without the usual protections.
Claude on Google Vertex AI also lacks EU data residency, but the full CDPA terms apply — there is no preview weakening.
Practical Recommendation
For preview models on Azure, the simple rule is: only data without personal reference. This includes:
- Source code analysis and generation
- Technical documentation
- Aggregated business data without names
- Internal knowledge bases without personal references
Not suitable for preview models on Azure:
- Documents with case worker names
- Customer communication
- HR data
- Anything directly or indirectly traceable to natural persons
6. PII Protection for AI Models: Why Filters Fail and What Works Instead
The Problem
How do you prevent personally identifiable information (PII) from reaching an AI model? Particularly relevant for:
- Preview models on Azure (where personal data is off-limits)
- Documents containing employee names, contacts, email addresses
- Business processes involving customer or employee data
The Expensive Way: PII Filters as a Proxy
There are various technical solutions for automatic PII detection:
- Azure AI Language — PII Detection: Automatically detects names, emails, phone numbers and can mask them
- Microsoft Presidio (Open Source): Local PII detection, rule-based and ML-powered
- Azure API Management (APIM) as Gateway: Central proxy in front of all AI models with PII policy
Costs and Limitations:
| Aspect | Detail |
|---|---|
| Cost | Approx. €1 per 1,000 text units; at 100k requests/month approx. €100 |
| Latency | 50-200ms additional per request |
| Plain text only | PII filters can only scan plain text input — nothing else |
| Blind to file uploads | This is the real problem: Claude is multimodal and accepts PDFs, images, and documents as input. But PII filters sit as a text proxy and cannot scan binary file uploads at all. A PDF with customer names, an image of a signed contract, a scanned invoice — all of that passes through the filter completely undetected. |
| Base64 content | Documents encoded as Base64 (common in API calls) are invisible to PII filters |
| No 100% protection | Even on plain text: false positives and false negatives are unavoidable |
This is a fundamental architectural limitation, not a minor gap. PII filters were designed for a text-only world. Modern AI models like Claude accept rich media input — and the filters simply can't keep up. You end up with a false sense of security: the filter catches "Hans Müller" in your text prompt but lets the PDF with 500 customer records pass through untouched.
The Pragmatic Way: Three Pillars Instead of Expensive Filters
In practice, a combination of three measures has proven more effective and cheaper than purely technical PII filters:
Pillar 1: Prevent at the Application Level
Instead of adding a filter downstream, build protection into your application:
- Design prompts so they don't require personal data
- For document analysis: extract relevant sections instead of sending the entire document
- For database queries: send aggregated data instead of individual records
- System prompts with explicit instructions to avoid personal data in responses
Pillar 2: IT Policy with Clear Rules
An updated IT policy (V2) should include:
- Clear distinction between Data Zone and Global Standard
- Explicit rules for Preview vs. GA models
- Approval matrix by deployment type and data category
- Responsibilities for IT leadership, DPO, and CISO
Pillar 3: Training and Awareness
- Practical training for all employees using AI tools
- Concrete examples: what can be asked, what can't?
- Regular updates when status changes (Preview to GA)
When Does a Technical PII Filter Make Sense?
| Use Case | PII Filter Recommended? |
|---|---|
| Developer tools (Claude Code, IDE plugins) | No — source code has no personal reference |
| Internal knowledge base queries | No — if the database contains no PII |
| Document analysis with customer data | Yes — invoices, contracts, correspondence |
| HR document analysis | Yes — resumes, references |
| Batch processing of large text volumes | Yes — if personal reference can't be excluded |
The bottom line: PII filters are no silver bullet. They only work on plain text while modern AI models like Claude are multimodal — accepting PDFs, images, and documents that PII filters can't scan at all. Add latency and cost on top, and it becomes clear: the better strategy is to prevent personal data from entering the AI workflow in the first place — through application architecture, clear policies, and employee training.
7. The CLOUD Act and EU Data: The Risk You Can't Contract Away
With all three cloud providers, there's a residual risk that neither contractual clauses nor technical measures can fully eliminate: the US CLOUD Act (Clarifying Lawful Overseas Use of Data Act).
What Is the CLOUD Act?
The CLOUD Act of 2018 authorizes US authorities to compel US companies to hand over data — regardless of where that data is stored. This applies even to data in EU data centers.
Who Is Affected?
All three providers are US companies:
- Microsoft (Redmond, WA)
- Amazon/AWS (Seattle, WA)
- Google/Alphabet (Mountain View, CA)
And: Anthropic as a sub-processor is also a US company (San Francisco, CA).
What Do the Providers Do About It?
All three have implemented countermeasures:
| Measure | Microsoft | AWS | |
|---|---|---|---|
| Customer notification | Yes, unless legally prohibited | Yes, where possible | Yes |
| Redirect to customer | Attempts to redirect authority to customer | Requests affected person to contact customer | Yes |
| Legal challenge | Reviews legal basis | Reviews legality | Reviews and contests |
| Encryption | Customer-managed keys available | CMEK available | KMS with customer-managed keys |
Honest Assessment
The CLOUD Act is a residual risk affecting all US cloud providers. Neither EU Data Residency nor encryption fully protects against a US court order.
But: this risk exists identically with any use of Microsoft 365, Azure, AWS, or Google Workspace. If your organization already uses these services (which nearly all do), the CLOUD Act risk from Claude is no greater than your existing risk from current cloud usage.
The pragmatic view: The CLOUD Act risk is not an argument against Claude — as long as you're already using Microsoft/Google/AWS for other services.
8. Schrems III: The Strategic Risk
Current Situation
The EU-US Data Privacy Framework (DPF) has been valid since July 2023 and forms the legal basis for data transfers to the US. All three cloud providers are DPF-certified.
The Risk
Max Schrems and his organization noyb have challenged the DPF before the CJEU. If the CJEU strikes down the DPF (as it did with Safe Harbor / Schrems I and Privacy Shield / Schrems II), the impact would be:
| Scenario | EU Data Residency | Global Standard + SCCs |
|---|---|---|
| DPF remains valid | No risk | No risk |
| DPF is struck down | No risk (data stays in EU) | Elevated risk (SCCs alone are weaker) |
| DPF struck down + SCCs tightened | No risk | High risk (Transfer Impact Assessment becomes mandatory) |
The conclusion: Those relying on EU Data Residency are unaffected by Schrems III. Those relying on Global Standard + SCCs carry a strategic risk. This isn't a current compliance problem, but a factor for medium-term planning.
9. Approval Matrix: IT Autonomy Without a Lawyer
The Real-World Problem
In many organizations, IT leadership must involve the data protection lawyer for every AI decision. This slows innovation and costs time. An approval matrix solves this by defining clear rules for when IT can decide autonomously.
The Matrix
Axis 1 — Deployment Type:
- A: EU Data Residency / EU Inference Profile
- B: Global Standard with DPA + SCCs (GA model)
- C: Global Standard with DPA + SCCs (Preview model)
Axis 2 — Data Category:
- I: No personal data (source code, technical data, aggregated numbers)
- II: Internal data with indirect personal reference (company data with contact persons)
- III: Personal data (employee data, customer data)
- IV: Special categories (Art. 9 GDPR — health data, religious beliefs, etc.)
Decision Matrix
| Cat. I (no PD) | Cat. II (indirect PD) | Cat. III (PD) | Cat. IV (Art. 9) | |
|---|---|---|---|---|
| A: EU Data Residency | IT leadership alone | IT leadership alone | IT + DPO | Not permissible* |
| B: Global Standard (GA) | IT leadership alone | IT + DPO | IT + DPO + Lawyer | Not permissible* |
| C: Global Standard (Preview) | IT leadership alone | IT + DPO | Not permissible (Azure) | Not permissible* |
* Art. 9 GDPR data always requires a DPIA and explicit legal basis.
Color code:
- IT leadership alone = IT can decide and approve autonomously
- IT + DPO = Coordination with the Data Protection Officer required
- IT + DPO + Lawyer = External data protection legal review needed
- Not permissible = Cannot be approved under the given conditions
Note the Preview Exception
This matrix shows the critical difference: with Azure preview models, processing personal data is not permissible — not because it's technically impossible, but because the Microsoft DPA's contractual guarantees don't apply to previews.
With Google, this limitation doesn't exist: the CDPA contains no preview weakening, so regular terms apply to preview models on Vertex AI as well.
10. Gaps in Existing IT Policies
Many organizations already have an IT policy for AI usage. Typically, these cover the approval process, prohibitions on sensitive data, and a list of approved systems.
What Typical V1 Policies Don't Cover
Based on my analysis, most existing policies miss four points:
-
No distinction between Data Zone and Global Standard. The policy treats all cloud services equally, despite the significant data protection difference.
-
No distinction between Preview and GA. A model in preview status has different DPA conditions on Azure than a GA model — this must be reflected in the policy.
-
No consideration of the sub-processor chain. If M365 Copilot (with full data access including Art. 9 GDPR) is approved, but Claude is integrated into Copilot as a sub-processor (since January 2026), the approval implicitly extends to Claude — without it being reviewed.
-
Claude is missing from the approved list. Models are constantly updated, new providers appear, deployment modes change. A static list becomes outdated quickly.
Recommendation: IT Policy V2
An updated policy should:
- Integrate the approval matrix from Section 9
- Include deployment types (Data Zone vs. Global Standard) as an independent criterion
- Consider Preview vs. GA as an approval criterion
- Have a dynamic appendix with the current approved list
- Define a regular review cycle (quarterly)
11. Data Protection Legal Review: Efficient and Provider-Agnostic
Formulating the Review Request Correctly
A common mistake: organizations have each cloud provider reviewed separately. That's expensive and unnecessary, because the facts are identical for all three:
EU endpoint + Global Standard + DPA/CDPA + SCCs + US sub-processor
My Thesis for the Review
- GA + Global Standard + DPA + SCCs = GDPR-compliant — even with personal data (under current law)
- Preview + Global Standard + no personal data = unproblematic — GDPR doesn't apply to data without personal reference
Questions for the Lawyer
- Confirmation that GA models in Global Standard under SCCs + DPA can be used GDPR-compliantly
- Confirmation that preview models with non-personal data have no GDPR relevance
- Transferability of the review to all three providers (one review instead of three)
- Necessity of Transfer Impact Assessment (TIA) and Data Protection Impact Assessment (DPIA)
- Assessment of the sub-processor chain: is the contract via the cloud provider sufficient?
12. Best Cloud Strategy for Claude AI in Europe: Azure + Google Cloud
Why No Single Provider Is Enough
The analysis shows: no single provider offers the optimal data protection level for all models. The recommended strategy combines two to three providers.
The Recommended Combination
Primary: Azure (Microsoft) — most organizations already have it
- M365 Copilot, Teams, Office are standard in most enterprises
- GPT-4o/4o-mini with EU Data Residency available
- Existing contract relationship and DPA in place
- For Claude: acceptable for non-personal data (note Preview status — temporary, expect GA by H2 2026)
Secondary: Google Cloud (Vertex AI) — Gemini models currently leading
- Gemini 2.5 Pro and Flash with EU Data Residency available
- Gemini models are currently leading in many benchmarks
- Claude on Vertex AI: Global Standard, but full CDPA guarantees (no preview limitation)
- The strategic play: with Azure + Google you cover GPT, Gemini, and Claude — all three major model families
Optional for strict EU Data Residency: AWS Bedrock
- Only provider with EU Data Residency for Claude — add it if your compliance requirements demand guaranteed EU processing for personal data with Claude specifically
- For most organizations, the pragmatic three-pillar approach (application-level prevention + IT policy + training) is sufficient
Timeline
Immediately actionable (Q1 2026):
- Set up Azure AI Foundry for GPT models (EU Data Residency) and Claude (non-personal data)
- Set up Google Vertex AI for Gemini models (EU Data Residency) and Claude (full CDPA guarantees)
- Start with the pragmatic PII approach: application-level prevention + IT policy update
Short-term (Q2 2026):
- Introduce IT Policy V2 with approval matrix
- Commission data protection legal review (one-time, provider-agnostic)
- Set up employee training program
Medium-term (H2 2026):
- Reassess once Claude reaches GA on Azure (expected after June 2026) — this unlocks personal data use cases
- Evaluate whether AWS Bedrock is needed as a third platform for strict EU Data Residency
- Monitor Data Zone developments at Azure and Google
Strategic (2027+):
- Monitor Schrems III ruling and adjust strategy if needed
- Assess whether Anthropic begins offering EU hosting directly
- Re-evaluate model landscape — today's best model may not be tomorrow's
13. Cloud Provider Scoring: AWS vs. Azure vs. Google for Enterprise AI
Let me be honest about the weighting here. After analyzing all the contracts, DPAs, and technical details, I've come to a pragmatic conclusion: EU Data Residency matters, but it's not the deciding factor. Why? The CLOUD Act means the US government can compel any of these providers — Microsoft, Google, Amazon — to hand over data regardless of where it's stored. Whether your data sits in Frankfurt or Virginia, a US court order trumps your DPA.
So what actually matters for choosing a cloud platform? Model coverage. The AI landscape moves incredibly fast. OpenAI leads one quarter, Anthropic the next, Google surprises with Gemini the quarter after. If you lock yourself into one provider, you will get left behind.
Cloud Provider Assessment for Claude (Enterprise Use)
| Criterion (Weight) | AWS Bedrock | Google Vertex AI | Azure AI Foundry |
|---|---|---|---|
| Model Coverage (30%) | 5/10 (Claude + OSS) | 9/10 (Gemini + Claude) | 9/10 (GPT + Claude) |
| EU Data Residency (15%) | 10/10 | 3/10 | 3/10 |
| DPA Quality (15%) | 8/10 | 8/10 | 7/10 |
| Preview/GA Status (10%) | 10/10 (GA) | 10/10 (GA) | 4/10 (Preview) |
| Existing Contract Relationship (15%) | 4/10 | 5/10 | 9/10 |
| Ecosystem & Integration (10%) | 6/10 | 8/10 | 9/10 (M365, Copilot) |
| Cost/Availability (5%) | 8/10 | 8/10 | 7/10 |
| Weighted Total Score | 6.6/10 | 7.3/10 | 7.2/10 |
Multi-Cloud Assessment (All Models)
| Strategy | Model Coverage | Data Protection | Complexity | Recommendation |
|---|---|---|---|---|
| Azure only | High (GPT + Claude) | Medium | Low | Viable, but no Gemini |
| Google only | High (Gemini + Claude) | Medium to High | Low | Viable, but no GPT |
| AWS only | Limited (Claude + OSS) | High | Low | Too narrow for most |
| Azure + Google | Maximum (GPT + Gemini + Claude) | Medium to High | Medium | Recommended |
| Azure + Google + AWS | Maximum | Maximum | High | Only if EU Data Residency for Claude is mandatory |
My Recommendation
Azure + Google Cloud. Full stop.
Here's the reasoning:
Azure — you probably already have it. Microsoft 365, Teams, Copilot are standard in most enterprises. GPT-4o and GPT-4o-mini come with EU Data Residency. You have an existing contract, an existing DPA, and your procurement team already knows the process. For Claude on Azure: acceptable for non-personal data (keep the Preview status in mind — it's temporary).
Google Cloud — this is the second platform you need. Gemini 2.5 Pro and Flash are genuinely impressive right now and available with EU Data Residency. Claude on Vertex AI runs as Global Standard but with full CDPA guarantees (no Preview limitation). And here's the strategic argument: the AI model race is far from over. Every few months, a different provider takes the lead. With Azure + Google Cloud, you have access to GPT, Gemini, and Claude — all three major model families covered. You're never locked in, never left behind.
What about AWS? AWS Bedrock is the technically strongest option for EU Data Residency with Claude — no question. If your compliance team insists on guaranteed EU processing for personal data with Claude specifically, add AWS as a third platform. But for most organizations, the added operational complexity of a third cloud provider isn't worth it when the pragmatic three-pillar PII approach (application-level prevention + IT policy + training) handles the data protection side effectively.
The bottom line: In a world where the CLOUD Act exists and AI models leapfrog each other every quarter, model coverage beats data residency as a strategic priority. Cover your bases with two platforms that give you access to everything, handle personal data pragmatically, and don't over-engineer the compliance side.
Frequently Asked Questions
Is Claude GDPR-compliant? Claude itself is an AI model, not a service — GDPR compliance depends on how and where you deploy it. On AWS Bedrock with EU Inference Profile, Claude processes data exclusively in the EU. On Azure and Google Cloud, data may be processed globally under Standard Contractual Clauses.
Can I use Claude with personal data in the EU? Yes, but only on AWS Bedrock with the EU Inference Profile (guaranteed EU data residency) or on Google Vertex AI / Azure with GA models under full DPA terms. Claude on Azure is currently in Preview, which means Microsoft's DPA storage guarantees don't apply — avoid personal data there until GA.
What is the difference between Data Residency and an EU Endpoint? An EU endpoint means your API request arrives at an EU server. Data Residency means the actual AI processing (inference) happens in the EU. Only Data Residency provides a meaningful GDPR guarantee — an EU endpoint alone does not prevent global processing.
Does the CLOUD Act override GDPR protections? The CLOUD Act allows US authorities to compel US companies (Microsoft, Google, Amazon, Anthropic) to hand over data regardless of where it's stored. This is a residual risk that applies equally to all US cloud services you already use. EU Data Residency and encryption provide layers of protection but cannot fully prevent a US court order.
How long does Claude's Preview phase last on Azure? Typically 3–6 months. Claude on Azure has been in Preview since late 2025 with a retirement date of June 1, 2026. It may transition to GA or be replaced. Always check the provider's model lifecycle page.
Which cloud provider is best for Claude in Europe? For GDPR data residency: AWS Bedrock. For model coverage (GPT + Gemini + Claude): Azure + Google Cloud combined. My recommendation is Azure + Google Cloud for strategic flexibility, with AWS as an optional add-on for strict EU data residency requirements.
References
Contracts Analyzed
- Microsoft DPA (Data Protection Addendum), last updated September 1, 2025
- Google CDPA (Cloud Data Processing Addendum)
- AWS GDPR Compliance Whitepaper and DPA
Cloud Provider Documentation
- AWS Bedrock EU Inference Profile: docs.aws.amazon.com/bedrock
- Google Vertex AI Data Residency: cloud.google.com/vertex-ai/docs/general/data-residency
- Azure AI Foundry Model Catalog: ai.azure.com
- Azure Data Residency: azure.microsoft.com/explore/global-infrastructure/data-residency
Legal Foundations
- EU GDPR (Regulation 2016/679)
- EU-US Data Privacy Framework (Adequacy Decision 2023)
- Standard Contractual Clauses (Implementing Decision 2021/914/EC)
- Art. 28 GDPR (Data Processors)
- Art. 44-49 GDPR (International Data Transfers)
Reminder: This article does not constitute legal advice. See the disclaimer at the top of this article. All assessments are based on publicly available contracts and documentation as of February 2026.