Picking an EU region of a US cloud provider does not put your data outside the reach of the US CLOUD Act. The Act follows the provider, not the disk. It compels a provider of electronic communication or remote computing services that US courts can reach to hand over data in its “possession, custody, or control”, and the statute says explicitly that this applies “regardless of whether such communication, record, or other information is located within or outside of the United States” (18 U.S.C. 2713, added by the CLOUD Act, enacted in 2018 as Division V of Pub. L. 115-141). So eu-central-1 changes where the bytes sit. It does not change who can be served with a warrant.
That is the part most vendor writing on this topic skips, which is understandable, because most vendors are reselling hyperscaler capacity. This piece is about what the law reaches, what the evidence shows about how often it gets used, and which questions genuinely change your position. It is not legal advice, and if the answer matters to a contract you are signing, get a lawyer who does this for a living.
Does the CLOUD Act apply to an EU region of AWS, Azure or Google Cloud?
Yes, and you do not have to take a competitor’s word for it, because the providers say so in their own compliance documentation. AWS states that the CLOUD Act “applies to all electronic communication service or remote computing service providers that operate or have a legal presence in the U.S.” (AWS CLOUD Act FAQ). Microsoft’s own transparency reporting says the Act “made clear that law enforcement may compel service providers with minimum contacts with the U.S. to disclose data that is in their ‘possession, custody, or control’ regardless of where the data is located” (Microsoft Government Requests for Customer Data Report).
The clearest statement on record came under oath. In June 2025, Anton Carniaux, Director of Public and Legal Affairs at Microsoft France, appeared before a French Senate committee of inquiry into public procurement. Asked whether he could guarantee that French citizens’ data entrusted to Microsoft through the public procurement body Ugap would never be handed to the US government without French authorisation, he answered: “Non, je ne peux pas le garantir, mais, encore une fois, cela ne s’est encore jamais produit.” No, I cannot guarantee it, but, once again, that has never yet happened (Sénat, commission d’enquête sur la commande publique, 10 June 2025).
Both halves of that sentence matter here. The first concedes the legal exposure, and the second, which is usually cut when the quote circulates, is broadly supported by the public record, with the caveat in the next section.
How often does this actually happen?
Rarely, but not never, and the difference matters if you are writing a risk register.
Amazon’s Government Request Report for the first half of 2026 covers 2,310 requests to AWS from all governments worldwide. Of those, 2,309 produced non-content responses and exactly one produced content. Asked how many requests resulted in disclosure to the US government of enterprise or government content located outside the United States, Amazon’s answer is “None” (Amazon Government Request Report, H1 2026).
Microsoft’s numbers for the second half of 2025 are different, and they are the ones worth reading carefully. On the consumer side, 115 warrants sought content stored outside the United States. On the enterprise side, Microsoft reports providing content data to US law enforcement relating to three non-US enterprise customers whose data was stored outside the US, and says that one of those three was located in the EU or EFTA (Microsoft Government Requests for Customer Data Report).
The two are not quite like for like. The periods differ, and Microsoft’s enterprise bucket covers Microsoft 365, Exchange and the rest of its business estate, where a content warrant is far more likely than it is against raw infrastructure, while Amazon’s AWS figure is infrastructure only. Read them together and the picture is three enterprise customers in six months at one very large provider, one of them European, against none at another. That is a long way from routine, and it is not zero either.
What the numbers do not tell you is anything about future risk, and that is the actual concern in European procurement right now. Bitkom’s 2025 study of German business found trust in the USA as a technology partner down to 38 percent, with 96 percent of German companies dependent on imported digital technology and only 4 percent able to keep operating if those imports stopped (Bitkom, Digitale Souveränität 2025). Procurement teams are not pricing what happened last year. They are pricing what a change of US administration policy could mean for a system they cannot move in a hurry.
Does GDPR Article 48 protect you?
It protects you less than almost everyone assumes, and this is where the popular understanding sits furthest from the text.
Article 48 says a third-country court or administrative decision requiring disclosure “may only be recognised or enforceable in any manner if based on an international agreement, such as a mutual legal assistance treaty”. Read on its own, it sounds like a blocking statute aimed squarely at the CLOUD Act.
The EDPB’s adopted guidance says two things that complicate that reading. First, Article 48 is not a transfer ground at all: “Unlike the other provisions of Chapter V, Article 48 is not a ground for transfer. The provision itself contains no data protection safeguards.” Second, and more importantly, the guidance explicitly puts the classic CLOUD Act pattern outside Article 48’s scope. Where a third-country authority serves a parent company in its own territory, and that parent then asks its EU subsidiary for the data, the guidance states that “this scenario does not fall under the scope of Article 48” (EDPB Guidelines 02/2024 on Article 48 GDPR, version 2.1, adopted 4 June 2025, para 8).
The guidance names the CLOUD Act only in its footnotes, which point at the 2019 EDPB and EDPS joint response on it, so reading paragraph 8 onto a CLOUD Act order is our mapping rather than the EDPB’s. It is the shape such an order usually takes. The order goes to the US parent, and the data moves from the EU subsidiary to the parent. That leaves two questions, neither of which is Article 48: a Chapter V transfer question, which the current adequacy decision may answer, and an Article 6 legal-basis question, which a foreign legal obligation does not answer on its own.
Where an order is served directly on the European entity instead, Article 48 does apply, and Microsoft’s own description of the Act reaching “providers with minimum contacts with the U.S.” leaves that door open. The EU-US Data Privacy Framework survived its first annulment challenge when the General Court dismissed Latombe v Commission in September 2025, and an appeal was filed with the Court of Justice on 31 October 2025. It is valid and usable in the meantime.
One more correction while we are here, because it comes up constantly: the EU Data Act’s Article 32 on international governmental access applies to non-personal data. Keycloak user records are personal data, so it does not help you there.
Does a European provider get you out of scope?
On paper it removes the specific US hook, which is the main one. It does not make your data unreachable by any government, and a provider that tells you otherwise is overselling.
OVHcloud, a French company headquartered in Roubaix and listed on Euronext Paris, states that the European commercial entities of the OVHcloud Group “fall under the exclusive jurisdiction of European Union member states” with “no dependency links to any entity or organisation subject to the jurisdiction of states that do not provide an adequate level of data protection” (OVHcloud).
Apply this article’s own first question to that claim and you find OVH US, a US subsidiary of the same group. The separation argument sits in the European post quoted above: the European entities are controlled by OVH Groupe under French law with no dependency on entities under other jurisdictions. The US entity’s own FAQ is blunter, and quoted here because it cuts the other way: “OVHcloud will comply with lawful requests from public authorities. Under the CLOUD Act, that could include data stored outside of the United States” (OVHcloud US CLOUD Act FAQ). The same FAQ notes the Act creates no obligation to decrypt.
That is a coherent position, and it is untested. We are not aware of a reported ruling under the Stored Communications Act on whether corporate separation defeats “possession, custody, or control”, in either direction, and US civil-discovery law on a parent’s practical ability to obtain a subsidiary’s documents is what a prosecutor would argue from.
The useful counter-example is Canadian, not American. In November 2025, The Register reported that the RCMP had served a production order on OVH’s Canadian subsidiary in April 2024 seeking account data held on OVH servers in France, the UK and Australia, going around the mutual legal assistance treaty with France (The Register). An Ontario court declined to revoke the order in September 2025 and OVHcloud is contesting it. The mechanism is the same one this article is about, under a different flag: a state reaching data held abroad through a local corporate presence. The CLOUD Act is the biggest version of that pattern because of how much of the market is American, and it is not the only version.
One more thing about the hyperscalers’ sovereign offerings too: none of them claims legal immunity. AWS launched its European Sovereign Cloud in Brandenburg in January 2026 with an EU parent company, EU-resident operators and no operational control outside EU borders, and the launch announcement makes no claim of CLOUD Act immunity. Microsoft’s European Digital Commitments promise to “promptly and vigorously contest” any order to suspend European operations, and to challenge demands for EU public sector or enterprise customer data “where we have a legal basis for doing so”. Those are commitments about how the company will behave, which is a different thing from a statement about which courts can reach it.
The questions that change your exposure
Take these into the procurement meeting. They are more useful than asking which region a provider offers.
Who controls the entity that operates the service? This is a question about corporate structure rather than geography. Which company holds the contract, who owns that company, and does any entity in that ownership chain have a US legal presence. This is the question the statute turns on.
Where does the control plane run, and what does it hold? A provider can host your workload in Frankfurt while its management console, support tooling and account records live somewhere else entirely. Ask for both answers separately, because a lot of “EU hosted” claims describe only the data plane.
Who can reach production, and from where? Operations staff with credentials are part of the custody chain. If support is staffed from a jurisdiction you are worried about, the datacentre location is doing less work than you think.
Who holds the encryption keys? This is the one genuinely actionable technical lever. AWS states that the Act “does not create any new authority for law enforcement to compel service providers to decrypt communications”, and OVHcloud says the same in its own terms. A provider compelled to produce ciphertext it cannot read is in a different position from one holding your plaintext.
What does the transparency report say, and does one exist? Request volumes, disclosure rates, and whether extraterritorial content warrants are broken out separately for enterprise customers. A provider that publishes nothing has left the question open.
What is the exit, and have you tested it? A sovereignty claim is worth little if leaving takes six months of re-implementation. For Keycloak specifically the bar is concrete: can you export your realms and run them yourself tomorrow.
Where this leaves Keycloak
Keycloak is where this question lands hardest, because an identity system holds the data that identifies your users by definition. Email addresses, names, group membership, authentication events, sometimes national identifiers. An identity provider has no anonymised mode to fall back on.
It is also the part where you have the most room to act, because Keycloak is open source. You can run it yourself on infrastructure you choose, and the export path out of any managed offering is a realm export rather than a migration project. Check that before you believe anyone’s sovereignty story, ours included.
For our own part, Skycloak runs EU customer deployments on OVHcloud in Germany. Each customer’s Keycloak runs in its own workspace on that cluster, which is where their realms, users and sessions live. We picked a French operator rather than an EU region of an American one for the reason this whole article is about.
Now the parts that our own six questions turn up, because it would be a poor article that applied them to everyone else and stopped there.
Skycloak is a Canadian company, and Canada has its own lawful access regime, as the OVH production order above shows. Not being American is a narrower claim than being beyond reach, and we would rather you read it that way.
Our control plane, meaning the console you log into and the records behind it, runs in the United States, on a US provider. It holds account logins, organisation and billing records, and the configuration of your deployments. It does not hold your realms, your end users, your sessions or your Keycloak logs, which stay on the German cluster. So your users’ identity data stays in Germany and our record that your workspace exists does not, and it sits with exactly the kind of provider the first half of this article is about.
Our operations team can reach the German cluster from outside the EU, which puts people in the custody chain as well as machines. We hold the encryption keys for that cluster. There is no customer-managed key option today, so by the test in question four above, we are the provider holding your plaintext rather than your ciphertext.
Cloudflare is the default edge, providing DDoS protection, WAF and TLS termination, which is listed in our security documentation. On the default setup that means TLS terminates at a US company’s edge before traffic reaches Germany, and we would rather say that here than let you find it in a subprocessor list.
For teams that need no US provider in the request path, we can build the ingress on a non-US edge instead, on the EU clusters and the Canadian ones. That is a bespoke setup rather than a plan option, and it has to be agreed before the cluster is provisioned, since it changes how the ingress is built.
None of that is unusual for a managed service, and all of it is the sort of thing you should be asking us and every other vendor about rather than reading a region name off a pricing page. If you need a different answer on any of the three, that is a conversation to have before you sign, not after.
FAQ
Does storing data in an EU datacentre protect it from the CLOUD Act?
No. The Act reaches providers with a US legal presence based on possession, custody or control of the data, and explicitly applies regardless of where the data is stored. Location answers a physical question, and the Act turns on a legal one about the provider.
Has the US government obtained EU-stored enterprise data this way?
Yes, though rarely on the published numbers. Microsoft reports that in the second half of 2025 it gave US law enforcement content belonging to three non-US enterprise customers whose data sat outside the US, one of them in the EU or EFTA. Amazon’s answer for AWS over the first half of 2026 is “None”.
Does GDPR Article 48 block a CLOUD Act request?
Not in the usual pattern. EDPB Guidelines 02/2024 state that where a third-country authority serves a parent company and the parent then requests data from its EU subsidiary, the scenario falls outside Article 48’s scope. It becomes an ordinary Chapter V transfer question instead.
Can a US provider’s EU subsidiary refuse an order served on its US parent?
That question is untested. No court has ruled on whether corporate separation defeats the “possession, custody, or control” standard. Providers’ sovereign cloud offerings promise operational separation and a commitment to contest orders, not legal immunity.
Does encryption help?
It is the most useful technical lever available. AWS says the Act creates no new authority to compel a provider to decrypt, and OVHcloud says the same. A provider holding only ciphertext can be compelled to produce ciphertext.
Is a European provider automatically out of reach?
Out of reach of the CLOUD Act specifically, most likely, though the question is untested. Not out of reach generally: the RCMP production order served on OVH’s Canadian subsidiary for data held in France used the same mechanism under a different flag.
Related reading
- Keycloak, Quebec Law 25 and PIPEDA: a practical compliance guide
- Keycloak GDPR data erasure and retention
- Is self-hosting Keycloak worth it in 2026
This article is general information about how the law is written and what it implies for an architecture decision. It is not legal advice, and jurisdiction questions turn on facts specific to your contracts and your corporate structure.