Does keeping data in Frankfurt make it immune to US law?

No. Amazon, Microsoft, and Google are all US companies, and US law can compel them wherever the data sits (18 U.S.C. § 2713). When that's the customers' concern, I'd start with customer-held keys, through AWS KMS External Key Store, Azure Managed HSM, or Google Cloud External Key Manager. A sovereign offering or an EU provider comes next, each with a cost. A lot of customers ask for residency, not immunity, so it's worth asking which one they mean.

Can we use Bedrock, Azure OpenAI, or Google's models and stay in the EU?

Yes, with care, and each feature still needs a check on where it stores prompts and embeddings. On Bedrock, that means an in-region model or an EU inference profile, not a global one. On Azure, it means a regional or EU Data Zone deployment, not Global Standard. On Google's Agent Platform, formerly Vertex AI, it means an EU region or the EU multi-region endpoint, not the global endpoint. In the designs I ship, the region comes first and the model second.

We already have workloads in Virginia. How hard is the move?

It's a migration, with the same map-first approach as any other. Stateless services move in an afternoon. The data and the DNS cutover take the planning. I've done it in waves alongside a wider migration, which is often the cheaper moment for it.

Is this enough for the GDPR?

Residency is one part of the GDPR, not the whole of it. A company still needs a lawful basis, records of processing, a data processing agreement with each processor, and a way to honour data subject rights. The engineering here gives the DPO accurate facts to build those on. How confident is your DPO in the data map today?

All guides

Guide

Keeping data in the EU on AWS, Azure, and Google Cloud

How to keep customer data in EU regions on AWS, Azure, and Google Cloud, what still leaves, and the controls that prove it to a customer or auditor.

"Our data stays in the EU" is a promise I see a lot of EU startups make. On AWS, Azure, and Google Cloud it's mostly achievable and mostly a matter of configuration. The default isn't there, though, and a few services reach outside any region a team picks. Residency, meaning where the bytes sit, differs from sovereignty, meaning who a court can compel to hand them over. It's worth asking customers which one they actually want.

This guide covers what each provider gives a team, what a team has to set itself, and how to show the result to a data protection officer or a security questionnaire. The pattern is the same on all three clouds. The mechanisms and the traps differ, so I name them side by side.

This is an engineer's reading of the rules. I wrote it to help teams decide whether the rules touch their platform. It isn't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.

Does it apply to you?

If one of these lines describes your company, the rest of this guide applies. If none does, the rule probably sits outside your company. A thirty-minute call confirms that faster than the text can.

We hold personal data of EU residents, and our privacy policy, data processing agreement, or customers say it stays in the EU or EEA.
We sell to a bank, insurer, public body, or healthcare provider. Their questionnaire asks for data locations, sub-processors, and transfer mechanisms, and DORA and NIS2 both push for this.
We use a global service: IAM or CloudFront on AWS, Front Door on Azure, Cloud IAM or Cloud CDN on Google Cloud. Those control planes don't follow the region we picked.
We use managed AI services. Model availability differs by region, and some deployment types route inference across regions unless someone pins them.
Our engineers can create resources in any region. Without a guardrail, a test bucket in Virginia is one click away.

What it asks of your platform

EU regions first

AWS has EU regions in Ireland, Frankfurt, Paris, Stockholm, Milan, and Spain. Azure has them in the Netherlands, Ireland, France, Germany, Sweden, Italy, Spain, Poland, Austria, Belgium, and Denmark. Google Cloud has them in Belgium, the Netherlands, Frankfurt, Berlin, Paris, Milan, Turin, Madrid, Warsaw, Finland, and Stockholm. UK and Swiss regions sit in Europe but outside the EU on all three clouds, and Azure also has Norwegian ones. I pick one or two regions near the customers, then check that every service we need runs there.

A deny for every other region

On AWS, I put a service control policy on the organisation that denies every other region, with an exception for the global services that need us-east-1. On Azure, I assign the built-in Allowed locations policy at management group level, plus its separate policy for resource groups. That policy skips anything marked global, so those resources need their own review. On Google Cloud, the gcp.resourceLocations organisation policy does the same job, set to in:eu-locations and not the wider in:europe-locations, which admits the UK and Switzerland. That one policy turns a promise into a control a customer can see.

Keys, backups, and copies

I create encryption keys in the EU region with AWS KMS, Azure Key Vault, or Google Cloud KMS, and no key leaves it. Every replication rule, backup vault, and snapshot copy gets a check. Disaster recovery to another region works fine as long as that region is also in the EU. On Azure, geo-redundant storage follows the region pair, and on Google Cloud the EU multi-region stays out of London and Zurich.

CloudFront, Azure Front Door, and Cloud CDN all cache at edge locations around the world. A cached response with personal data in it is a copy like any other. When cached content has to stay in Europe, I limit what it caches or serve those responses uncached.

What still leaves, and how I handle it

On AWS, account metadata, billing, IAM configuration, and some service logs sit in US regions. On Google Cloud, the location policy doesn't reach every resource, and global services like Cloud IAM and billing sit outside it. Azure has the EU Data Boundary, Microsoft's commitment to store and process customer data in the EU and EFTA, with documented exceptions. EFTA includes Norway and Switzerland, so the boundary alone doesn't back a promise of EU only. Azure Resource Manager only joins the boundary on a brand new tenant, which makes that choice hard to fix later.

Each provider can also run its regions with staff outside the EU. Under the GDPR, that metadata and remote access count as transfers (arts. 44 to 46 of Regulation (EU) 2016/679). They rest on the EU-US Data Privacy Framework (Implementing Decision (EU) 2023/1795, under appeal in Case C-703/25 P) and on the standard contractual clauses (Implementing Decision (EU) 2021/914) in each provider's data processing terms. I name them in the records and move on.

When residency isn't enough

Some customers need operational independence from a US parent. AWS runs a separate European Sovereign Cloud in Germany, through an EU entity with EU-resident staff. Microsoft offers Sovereign Public Cloud in its European regions, Sovereign Private Cloud, and partner clouds such as Bleu in France and Delos in Germany. Google offers Data Boundary in its public cloud, and Dedicated on isolated infrastructure under a local operator such as S3NS in France. Each one has a cost, so I reach for it when a contract asks.

Proving it

The evidence starts with a data map that names each store, its region, and its encryption key. Next come the location policy and a screenshot of a denied cross-region call. A list of sub-processors with locations completes the paperwork. An AWS Config aggregator, Azure Resource Graph, or Google Cloud Asset Inventory then shows any resource outside the approved regions. Together they answer a lot of questionnaires in one attachment, and a quarterly check keeps them true.

How I help

The engineering behind the guide. Each one starts with a map of the platform as it runs today.

Book a call

Cloud migration

I move teams onto AWS, Azure, or Google Cloud, or out of a setup they've outgrown. I map every dependency before anything moves.

Cloud security hardening

I find the gaps in your cloud accounts, identity, network, and data, rank them by what an attacker reaches first, and close them with your team.

AI integration

I put language models to work on the problems that matter in your product and back office, and I ship them to production.

NIS2

What the NIS2 directive asks of a startup's cloud platform, how to tell whether a company is in scope or a supplier to one that is, and what to fix first.

DORA

What the Digital Operational Resilience Act asks of a fintech's cloud platform, and what its contract rules mean for suppliers to banks and insurers.

EU AI Act

How the EU AI Act sorts AI systems into risk tiers, which tier your product is likely in, when the rules apply, and what they mean for the way a team builds.

GDPR

What the GDPR asks of a startup's cloud platform in engineering terms: controller or processor, the records to keep, and the controls that prove it.

Does keeping data in Frankfurt make it immune to US law?: No. Amazon, Microsoft, and Google are all US companies, and US law can compel them wherever the data sits (18 U.S.C. § 2713). When that's the customers' concern, I'd start with customer-held keys, through AWS KMS External Key Store, Azure Managed HSM, or Google Cloud External Key Manager. A sovereign offering or an EU provider comes next, each with a cost. A lot of customers ask for residency, not immunity, so it's worth asking which one they mean.
Can we use Bedrock, Azure OpenAI, or Google's models and stay in the EU?: Yes, with care, and each feature still needs a check on where it stores prompts and embeddings. On Bedrock, that means an in-region model or an EU inference profile, not a global one. On Azure, it means a regional or EU Data Zone deployment, not Global Standard. On Google's Agent Platform, formerly Vertex AI, it means an EU region or the EU multi-region endpoint, not the global endpoint. In the designs I ship, the region comes first and the model second.
We already have workloads in Virginia. How hard is the move?: It's a migration, with the same map-first approach as any other. Stateless services move in an afternoon. The data and the DNS cutover take the planning. I've done it in waves alongside a wider migration, which is often the cheaper moment for it.
Is this enough for the GDPR?: Residency is one part of the GDPR, not the whole of it. A company still needs a lawful basis, records of processing, a data processing agreement with each processor, and a way to honour data subject rights. The engineering here gives the DPO accurate facts to build those on. How confident is your DPO in the data map today?

Let's talk.

A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?

Book a call See pricing

Prefer email or phone? hello@netninjas.eu or +31 6 45984313