AWS FSx EU Alternative 2026: GDPR, CLOUD Act, and the File Share Compliance Gap

Post #784 in the sota.io EU Compliance Series

AWS FSx is Amazon's family of fully managed file system services, covering four distinct storage architectures: FSx for Windows File Server (SMB/NTFS, Active Directory integration), FSx for Lustre (high-performance parallel file system for HPC and ML workloads), FSx for NetApp ONTAP (enterprise NAS with multi-protocol support), and FSx for OpenZFS (ZFS-based storage with snapshots). Across all four variants, AWS handles provisioning, patching, backups, and storage scaling — eliminating the operational burden of managing file servers and NAS appliances.

The GDPR exposure with AWS FSx is not limited to the standard "US corporation, CLOUD Act" problem — though that applies to every variant. Each FSx flavour adds its own structural compliance issue: automatic backup retention that survives Art.17 deletion requests, Lustre's S3 data repository that commits silent cross-border transfers, and Windows file access audit logs that stream behavioral data to AWS-controlled CloudWatch infrastructure. The compliance picture changes depending on which FSx variant you use, but the common thread is that CLOUD Act reach and data sovereignty gaps are present across the entire FSx product family.

AWS operates FSx in Frankfurt (eu-central-1), Stockholm (eu-north-1), Ireland (eu-west-1), and other European regions. Every FSx service ships with the standard AWS GDPR Data Processing Addendum and Standard Contractual Clauses. And like every AWS managed service, it is operated by Amazon Web Services, Inc., a Delaware-incorporated entity fully subject to the CLOUD Act (18 U.S.C. § 2713), regardless of the AWS region where your file system lives.

What AWS FSx Stores and Processes

AWS FSx provides file-level storage — the most unstructured data format in common enterprise use. Unlike databases with schemas, or object stores with metadata APIs, file shares accumulate everything: Word documents, PDFs, spreadsheets, design files, log archives, backups of backups, and email exports. From a GDPR perspective, this unstructured accumulation is the core compliance challenge.

Employee and HR files. Windows file shares are the most common repository for HR records: employment contracts (Art.9 adjacent — health conditions, disability accommodations), salary history spreadsheets, performance reviews, disciplinary records, and termination documentation. These files are personal data under Art.4(1), frequently contain special category data under Art.9, and are almost never deleted on schedule. An Art.30 record of processing activities that lists "HR share on FSx for Windows" is technically correct but obscures the real inventory problem: no one knows exactly which files contain PII because file shares have no schema enforcement.

Application file outputs. FSx for Lustre is purpose-built for high-throughput compute workloads: ML training pipelines, genomics analysis, financial risk modeling, media rendering. These workloads routinely process personal data — training datasets containing user behaviour, genomic sequences tied to natural persons, financial records identifying individuals. The Lustre file system itself does not distinguish personal from non-personal data, and the throughput optimizations that make Lustre valuable (aggressive caching, parallel I/O, large-stripe layouts) make it harder, not easier, to locate and erase specific personal data records within files.

Collaborative document stores. NetApp ONTAP supports SMB, NFS, and iSCSI simultaneously, making it the enterprise choice for mixed workloads where Windows clients need SMB access and Linux applications need NFS. In collaborative environments, ONTAP file shares often serve as the primary document repository for teams — accumulating PII in spreadsheets, project files, and draft communications that span years of retention.

ZFS snapshot chains. FSx for OpenZFS inherits ZFS's snapshot model: every snapshot preserves a point-in-time view of the file system, including all data that existed at that moment. Snapshots are cheap to create and cheap to retain — and organizations frequently retain months or years of snapshots without a documented lifecycle policy. Each snapshot is a separate copy of personal data under Art.17: an erasure request that deletes a file from the active file system does not remove it from the snapshot chain.

GDPR Risk 1: Automatic Backups Create Structural Art.17 Erasure Gaps

FSx for Windows File Server, ONTAP, and OpenZFS all support automated daily backups retained for 7 to 35 days by default. FSx for Lustre supports both automatic and manual backups. These backups are stored in Amazon S3, managed by AWS, and are accessible for restoration via the FSx console or API.

The Art.17 compliance gap is structural: deleting a file from the active FSx file system does not delete it from the backup. A data subject who exercises their right to erasure under Art.17 triggers an obligation to delete their personal data without undue delay. If you delete the relevant files from the active file system but FSx retains backups containing those files for the next 7, 14, or 35 days, the erasure is legally incomplete. The personal data remains recoverable — and therefore retained — in the backup layer.

The mitigation options are operationally costly. You can disable automated backups entirely, eliminating your disaster recovery capability. You can manually delete individual backups after processing each Art.17 request, which requires mapping the request to the backup creation timestamps and executing API calls for each relevant backup. AWS does not offer backup-level file-level deletion — you cannot delete a specific file from a specific backup without restoring the entire backup, deleting the file, and creating a new backup. For organizations processing any volume of Art.17 requests, the backup management overhead is significant.

This gap is more acute for NetApp ONTAP and OpenZFS due to their native snapshot models. ONTAP SnapVault and SnapMirror policies can create multiple snapshot copies per hour, each of which is an independent backup of personal data. An Art.17 erasure workflow that fails to enumerate and purge all snapshot copies leaves the data accessible.

GDPR Risk 2: CLOUD Act Jurisdiction Over Every FSx Variant

Every FSx variant — Windows File Server, Lustre, NetApp ONTAP, OpenZFS — is operated by Amazon Web Services, Inc., a Delaware corporation. The CLOUD Act (18 U.S.C. § 2713) requires that AWS, as a covered provider, produce electronic communications and data stored anywhere in the world when served with a valid US government legal process, regardless of the data's physical location.

This means that FSx file systems hosted in Frankfurt or Stockholm are subject to the same CLOUD Act disclosure obligations as file systems in us-east-1. AWS's Standard Contractual Clauses cover intra-EU data transfers but do not limit US government access rights under US domestic law. No EU data processing addendum with AWS removes this exposure.

For file storage specifically, the CLOUD Act exposure is broader than it might appear with databases. File shares typically accumulate data that organizations would not classify as "high sensitivity" at creation — drafts, internal communications, operational documents — but which are in aggregate a comprehensive record of organizational activity. A CLOUD Act production order targeting an AWS FSx file system can reach years of accumulated files in a single request.

GDPR Risk 3: FSx for Lustre S3 Data Repository Triggers Silent Art.44 Transfers

FSx for Lustre supports a native integration with Amazon S3 called the S3 data repository. When configured, Lustre mounts an S3 bucket as a backing store: data written to the Lustre file system is automatically exported to the linked S3 bucket, and data in the S3 bucket is lazily imported into Lustre as it is accessed. This S3 integration is one of FSx for Lustre's primary selling points for ML workflows — it bridges high-throughput Lustre compute with durable S3 storage.

The Art.44 problem arises when the S3 bucket is in a non-EU region, or when the Lustre file system is configured with auto-export policies that mirror data to S3 in us-east-1 or other US regions. In many AWS architectures, the S3 bucket exists before the Lustre file system is provisioned — it was created for other purposes, it happens to be in us-east-1, and no one reviews the data repository configuration when provisioning FSx. The result: every file written to the EU Lustre file system is silently exported to S3 storage in the United States — a continuous Art.44 cross-border transfer that is not documented in the Art.30 record and not covered by an explicit transfer mechanism beyond the DPA's SCCs.

Even when the S3 bucket is in an EU region, the data repository auto-export behavior means that FSx for Lustre is effectively a two-layer storage system with different GDPR retention implications. Art.17 erasure requests must address both the Lustre file system layer and the S3 data repository layer independently.

GDPR Risk 4: Windows File Access Audit Logs Stream Behavioral Data to CloudWatch

FSx for Windows File Server supports file access auditing: every file open, create, delete, rename, and permission change can be logged and streamed to Amazon CloudWatch Logs or Amazon Kinesis Data Firehose. AWS recommends enabling file access auditing for compliance and security monitoring — and many organizations enable it by default.

The GDPR implication of file access audit logs is often overlooked: these logs are behavioral data under Art.4(1). An audit log entry for a file access records the user identity (typically a Windows security identifier mapped to an AD account), the file path (which often encodes personal data — HR/employees/mueller_anna/contract_2024.pdf), the access type, and a timestamp. At scale, file access logs are a detailed behavioral profile of every user's activity on the file share: which documents they accessed, when, how frequently, and in what sequence.

File access audit logs streaming to CloudWatch means this behavioral data is processed by an additional AWS managed service under CLOUD Act jurisdiction. Your Art.30 record must separately account for CloudWatch as a personal data processor. The audit logs are also retained in CloudWatch for the configured log group retention period, independently of the FSx file system lifetime — creating another data retention layer that survives Art.17 erasure requests against the primary file system.

GDPR Risk 5: Active Directory Integration Adds a Personal Data Processing Layer

FSx for Windows File Server requires Active Directory for access control. You can use AWS Managed Microsoft AD (a fully managed AD service), a self-managed AD domain, or an existing on-premise AD. In all cases, AD stores user and group objects that are personal data under Art.4(1): usernames, display names, email addresses, group memberships, and security identifiers (SIDs) that are the persistent digital identity of each employee.

When using AWS Managed Microsoft AD, you are adding another AWS managed service — another Delaware corporation processor — to your processing chain. The AD objects are personal data independently of the FSx file system content. An Art.17 erasure request for a departing employee requires not only deleting their files from the FSx share but also managing their AD account lifecycle: disabling the account, archiving or deleting the AD object, and handling the tombstone and replication delay in the AD database (a different kind of tombstone problem from Cassandra, but structurally analogous).

For organizations using FSx for Windows with AWS Managed Microsoft AD, the full processor chain for a single Art.17 request spans: the FSx file system, FSx automated backups, AWS Managed Microsoft AD, CloudWatch Logs (if file access auditing is enabled), and any S3 data repository (if configured). Each layer requires independent remediation.

GDPR Risk 6: File Shares Structurally Resist Art.5(1)(e) Storage Limitation

Art.5(1)(e) requires that personal data be kept in a form that permits identification of data subjects for no longer than is necessary. This storage limitation principle is notoriously difficult to enforce in file shares — and FSx provides no tooling to address it.

Unlike databases (where schema enforcement, foreign keys, and query languages make it feasible to identify and delete records by data subject), file shares store data as opaque bytes in files. FSx has no awareness of which files contain personal data, which data subjects are represented in which files, or how long each file should be retained. There is no API for "delete all files containing PII for user ID 12345." The DPA has no mechanism for automated storage limitation enforcement.

This means that FSx file systems grow monotonically in practice. Files are added constantly; files are rarely deleted; and the PII inventory embedded in the file system expands without bound. An Art.30 record that lists "employee file shares" as a processing activity cannot, without additional tooling, enumerate what personal data is actually stored, for how long, or whether retention limits have been exceeded. The compliance obligation exists, but FSx provides no mechanism to fulfill it.

Compliance Summary

EU-Sovereign File Storage Alternatives

Self-Hosted Samba on Hetzner (SMB/CIFS, Windows-Compatible)

The closest operational equivalent to FSx for Windows File Server is a self-hosted Samba server on Hetzner dedicated hardware. Samba provides full SMB 3.x protocol support, including DFS namespaces, Windows ACL-compatible permissions, and optional Active Directory domain controller functionality via Samba AD DC. You retain nodetool compact equivalent control: file deletion is immediate, snapshot schedules are configurable, and you define your own backup retention policy.

A Hetzner AX101 (32 cores, 256 GB RAM, 4x NVMe) provides storage server performance sufficient for most enterprise workloads at approximately €250/month. Samba with CTDB clustering across two nodes adds high availability. The entire deployment is under German jurisdiction; there is no Delaware corporation in the processing chain; and the servers cannot be served CLOUD Act production orders under US law.

Configuration for Art.17 compliance: disable VSS shadow copies by default (or with short retention), implement a documented backup policy with explicit retention limits, and use Samba audit module to log file access events to a local SIEM instead of a US cloud logging service.

Self-Hosted NFS Server on Dedicated Hardware

For Linux-based workloads that don't require Windows compatibility, NFS v4.1 or v4.2 on a Hetzner dedicated server is a direct replacement for FSx for Lustre and FSx for NetApp ONTAP (NFS access mode). NFS v4.2 supports COPY_FILE_RANGE, sparse file operations, and server-side data labeling — sufficient for HPC and ML pipeline workloads.

For high-throughput ML training workloads, a cluster of Hetzner AX102 servers (128 cores, 512 GB RAM, 8x NVMe per node) with BeeGFS (parallel file system, Fraunhofer-developed, German origin) or GPFS-replacement BeeParallel provides Lustre-class throughput without the FSx data repository complexity. BeeGFS is an EU-origin parallel file system used in European HPC environments.

Nextcloud with External Storage for Collaborative File Access

For the collaborative document use case (employees accessing files from Windows and Mac clients), Nextcloud provides an EU-sovereign alternative to FSx for Windows File Server in collaborative environments. Nextcloud supports:

• WebDAV, SMB gateway, and desktop sync client (Windows, Mac, Linux)
• Server-side encryption with self-managed keys
• File versioning with configurable retention
• User lifecycle management with immediate account deletion and file transfer
• Activity log to local database (no external log streaming)

Nextcloud Hub is open source; Nextcloud GmbH is a Stuttgart-based company with enterprise support contracts. Self-hosted deployment on Hetzner keeps all data under German law. Art.17 compliance: Nextcloud's user deletion workflow removes all files, versions, and shares associated with a user account — a complete erasure path unavailable in FSx.

TrueNAS Scale for ZFS-Based Enterprise NAS

For organizations currently using FSx for NetApp ONTAP or FSx for OpenZFS, TrueNAS Scale is the self-hosted equivalent. TrueNAS Scale provides:

• ZFS with user-configurable snapshot schedules and retention policies
• Multi-protocol access (SMB, NFS, iSCSI, S3-compatible object storage via MinIO)
• Active Directory integration with self-hosted Windows AD
• Built-in replication to a secondary node (EU jurisdiction)
• Zero-cost for the base software; hardware cost only

Art.17 compliance: ZFS snapshot lifecycle is fully configurable. You can set snapshot retention to 0 (no automatic snapshots), configure short-retention snapshots for DR only, and execute zfs destroy on specific snapshots as part of an Art.17 workflow. Unlike AWS automated backups, you have direct API and CLI control over the snapshot chain.

Deployment: TrueNAS Scale on Hetzner dedicated hardware with ZFS mirroring or RAIDZ2 depending on workload. The ixSystems foundation is US-based, but TrueNAS Scale is open source — your deployment is under the jurisdiction of your chosen EU provider.

MinIO for Object-First Workloads (S3-Compatible)

For FSx for Lustre use cases that are primarily driven by ML training pipeline access to S3-stored datasets, MinIO on Hetzner is a direct replacement. MinIO provides S3-compatible object storage with:

• S3 API compatibility — drop-in replacement for boto3, AWS SDK clients
• WORM and object lock for compliance storage
• Server-side encryption with KMS integration
• Erasure coding with configurable redundancy
• Object lifecycle management (including time-based deletion — Art.5(1)(e) enforcement)

The Lustre data repository pattern (FSx Lustre + S3 bucket) can be replaced by MinIO as the S3 layer plus a local BeeGFS or GPFS mount for the high-throughput compute layer. Both layers remain under EU jurisdiction.

Hetzner Storage Box for Simple File Access

For workloads that only need SFTP, FTP, SMB, or WebDAV access to bulk file storage, Hetzner Storage Box provides up to 20 TB of dedicated storage starting at €3.19/month — under German jurisdiction, no Delaware corporation involved, SFTP and backups included. For simple archival, document storage, or backup targets, Storage Box eliminates the operational overhead of self-managing a file server while keeping all data in Germany.

Migration from AWS FSx to EU-Sovereign Storage

Data Migration

For FSx for Windows File Server to Samba:

# robocopy (Windows) — preserves NTFS ACLs
robocopy \\fsx-endpoint\share \\new-samba-server\share /E /COPYALL /MIR /LOG:migration.log

# rsync (Linux client) — for large flat directories
rsync -avz --progress /mnt/fsx/ /mnt/new-server/

For FSx for Lustre to BeeGFS:

# parallel copy with GNU parallel for large datasets
find /mnt/lustre -type f | parallel -j 8 rsync -av {} /mnt/beegfs/{}

# or use aws s3 sync if data is primarily in the S3 data repository
aws s3 sync s3://your-data-repo/ /mnt/beegfs/

For FSx for OpenZFS to TrueNAS:

# ZFS send/receive preserves snapshots and data integrity
zfs send -R fsx-pool/data@latest | ssh truenas-server zfs recv pool/data

Art.17 Workflow After Migration

1. Identify all files containing personal data for the data subject. This requires either a dedicated PII scanning tool (Microsoft Presidio, Elastic search over the file system, or manual inventory) or a strict file naming convention that maps files to data subjects.
2. Delete files from the active file system.
3. Purge all snapshot copies and backup archives. On self-hosted systems, this means listing snapshots (zfs list -t snapshot, Samba VSS shadow copy list), identifying which contain the deleted file, and destroying them.
4. Verify deletion. Restore from the oldest relevant backup to a sandboxed environment and confirm the file is absent.
5. Document the erasure. Record the request date, files deleted, backups purged, and verification step in your Art.30 supplementary log.

Summary

AWS FSx provides managed file storage with operational convenience — but each variant introduces its own GDPR compliance gaps on top of the foundational CLOUD Act jurisdiction problem. Automatic backups create Art.17 erasure gaps across all variants; Lustre's S3 data repository can silently commit Art.44 cross-border transfers; Windows file access audit logs stream behavioral data to CloudWatch; and file shares' unstructured nature makes Art.5(1)(e) storage limitation enforcement nearly impossible without additional tooling.

EU-sovereign alternatives — Samba on Hetzner, BeeGFS for HPC workloads, TrueNAS Scale for enterprise NAS, Nextcloud for collaboration, MinIO for S3-compatible object access — eliminate the CLOUD Act exposure, provide configurable snapshot and backup lifecycle policies that support Art.17 compliance, and keep the entire processing chain under EU jurisdiction. The migration path is well-documented; the operational overhead of self-managed file storage on dedicated EU hardware is real but bounded; and the compliance posture is unambiguously stronger than any AWS FSx deployment can achieve.

Part of the sota.io EU Cloud Compliance Series — practical GDPR analysis for engineering teams replacing AWS managed services with EU-sovereign infrastructure.