Pain Point

CLOUD Act Data Access

The exposure created by the US Clarifying Lawful Overseas Use of Data Act (2018), which authorizes US law enforcement to compel US-headquartered cloud providers to disclose customer data **regardless of physical storage location** — combined with GDPR Article 48 (which prohibits foreign-court-compelled transfers without an MLAT).

8 connections 3 resources 4 posts

Summary

What it is

The exposure created by the US Clarifying Lawful Overseas Use of Data Act (2018), which authorizes US law enforcement to compel US-headquartered cloud providers to disclose customer data **regardless of physical storage location** — combined with GDPR Article 48 (which prohibits foreign-court-compelled transfers without an MLAT).

Where it fits

This is one of the "three data gravity wells" (US/EU/China) that shape modern multi-region S3 architecture. With **China Data Localization** as the PRC-side counterpart and **Data Residency** as the architectural framing, CLOUD Act is what makes "AWS in eu-central-1" categorically different from "EU-headquartered provider" for some regulators and customers.

Misconceptions / Traps
  • "The bucket is in Frankfurt" does not make the data shielded from CLOUD Act compelled disclosure if the operating cloud provider is US-headquartered.
  • Sovereign cloud and "EU Data Boundary" offerings address the jurisdictional gap, not the technical gap. The technical access path may be identical; the legal access path is what changes.
  • CLOUD Act has been used in practice — it is not a hypothetical risk to wave away.
Key Connections
  • scoped_to Sovereign Storage — the architectural response
  • Drives demand for Aliyun OSS / Tencent COS / Huawei OBS as in-PRC alternatives for non-US-domiciled data
  • scoped_to S3, Object Storage

Definition

What it is

The exposure created by the **Clarifying Lawful Overseas Use of Data Act (2018, US)**, which authorizes US law-enforcement to compel US-headquartered cloud providers (AWS, Microsoft, Google, Cloudflare, Wasabi, Backblaze) to disclose customer data **regardless of where the data is physically stored**. Together with **GDPR's Article 48** (which prohibits transfers compelled by foreign court orders without an MLAT), this creates a structural conflict-of-laws for any S3 bucket holding EU, UK, or PRC-domiciled personal data on a US-headquartered provider — even when that bucket lives in an EU region.

Recent developments

Latest signals
  • EU e-evidence package takes effect August 17, 2026. New EU regulation + directive applies across all EU Member States (except Denmark) — establishes EU-side cross-border data-request mechanisms designed to bypass the unilateral CLOUD Act path, requiring formal EU-channel cooperation for non-EU law enforcement requests. Per Cross-Border Data Forum — CLOUD Act FAQs.
  • GDPR Article 48 vs CLOUD Act is a direct legal collision. GDPR Article 48: transfers of personal data to third-country authorities must go through mutual legal assistance treaties or similar international agreements — a unilateral CLOUD Act order doesn't meet this requirement. EU orgs face the bind: comply with GDPR + risk CLOUD Act violation, OR comply with US subpoena + risk GDPR penalties. Per Kiteworks — CLOUD Act European Data Protection.
  • CLOUD Act enforcement in practice is rare but consequential. Per Microsoft's H2 2024 transparency report: 173 global law-enforcement requests for enterprise cloud customer data. US authorities are rarely granted access to enterprise content stored in Europe/UK — but the structural exposure is the procurement deal-breaker, not the actual enforcement frequency. Per CMS LawNow — White Paper: CLOUD Act vs EU/UK Sovereignty.
  • US has expanded CLOUD Act reach via executive agreements. As of 2026, the US has entered executive agreements with several countries to facilitate cross-border data requests — expanding the practical reach of CLOUD Act-compatible cooperation channels beyond the original US scope. Per Wikipedia — CLOUD Act.
  • Server location is not protection — corporate-HQ-jurisdiction is what determines exposure. The key 2026 framing: AWS Frankfurt / Azure Germany / Google EU don't shield European data because Microsoft / Amazon / Google are US-headquartered and the US government can compel them regardless of where servers physically sit. Per MassiveGRID — US CLOUD Act Explained Why European Data Isn't European.
  • Non-US cloud alternatives now a procurement category. A growing category of European-headquartered cloud providers explicitly positions itself outside CLOUD Act reach. The 2026 European-alternatives guide names specific providers structurally outside US jurisdiction. Per DanubeData — Why European Businesses Need Non-US Cloud Alternatives 2026.

Connections 8

Outbound 3
scoped_to3
S3Object StorageSovereign Storage
Inbound 5
solves5
HexabyteOVHcloud Object StorageCubbit DS3Hetzner Object StorageForgetting-as-a-Service (FaaS)

Resources 3

SpecHigh
www.congress.gov/bill/115th-congress/house-bill/4943

The CLOUD Act statute itself — primary source for the compelled-disclosure scope including Section 103 on "data stored abroad."

DocsMedium
en.wikipedia.org/wiki/CLOUD_Act

Reference overview of the CLOUD Act including the Microsoft v. United States precedent that motivated it and the executive-agreement framework.

DocsHigh
commission.europa.eu/law/law-topic/data-protection_en

EU Commission's data-protection portal covering GDPR Article 48 (foreign-court-compelled transfers) — the conflict-of-laws axis with CLOUD Act.

Featured in

2026-06-16 The Whole Stack Went Open — Weights, Storage, and Sovereignty In the same quarter that a 1.6-trillion-parameter open-weights model landed on top of last year's closed frontier — and Anthropic's Claude Fable 5 promptly sprinted ahead again — the storage layer underneath it went open too: DeepSeek open-sourced its file system, Europe stood up sovereign S3, and the post-MinIO self-hosted stack matured. The frontier and the floor are pulling apart, and the pattern underneath all of it is the oldest pain point this index maps: vendor lock-in. 2026-05-10 The POSIX Gap is Closing: How S3 Quietly Became a File System The May 7 post was about why storage suddenly matters again for AI workloads. This one is about how the access model itself evolved. After a decade of failed FUSE clients trying to bolt POSIX semantics onto S3, the storage service finally absorbed the operations the filesystem world expected — and a string of 2020-2026 changes (strong consistency, Express One Zone, directory buckets, S3 Tables, GPUDirect Storage) made S3 Files possible. Plus the parallel story in China: Aliyun CPFS+OSS, Huawei OBS+MindSpore, the same shape drawn three different ways. 2026-05-08 When the Index Gained 13 Nodes: A Field Guide to the May 2026 Wave On May 7 the index added 13 new nodes — five technologies, six pain points, one architecture, one standard. Each answers a specific question engineers building on object storage are asking right now: what is China's S3 stack, why are GPUs starving, what replaced MinIO, what are the three data gravity wells, and a few more. This post walks through them by question rather than by node type, because that's how the questions actually arrive in production. 2026-05-07 When DeepSeek Made Storage Strategic: The China Direction Reshaping the S3 Ecosystem DeepSeek's $5.6M training run didn't just reset model architecture. It made object storage performance-critical, made silicon export controls a storage decision, and pushed Aliyun OSS, Tencent COS, and Huawei OBS from regional curiosities into the global S3 vocabulary. This index added 13 nodes to track what changed.