Self-hosted object storage does not make your data legally immune, but it changes every channel through which other parties reach it: the physical disk is yours, the legal process has to come to you, and the exit door has no per-GB toll. This article puts numbers on those three claims — CLOUD Act reach, GDPR fine ceilings, and S3 egress pricing — and is honest about what self-hosting costs you in return.
| Fact (sourced, checked 2026-10-12) | Value |
|---|---|
| GDPR administrative fine ceiling (Art. 83(5)) | €20,000,000 or 4% of total worldwide annual turnover of the preceding financial year, whichever is higher |
| Largest single GDPR fine to date (Meta, May 2023, EU-US transfers) | €1.2 billion |
| CLOUD Act scope for US-based providers | Data in custody or control must be produced regardless of where it is stored |
| AWS S3 data transfer out to internet | $0.09/GB after the first 100 GB/month (us-east-1) |
| Moving 5 TB out of S3 in one month | (5,000 − 100) GB × $0.09 = $441 |
| RustFS license and deployment surface | Apache 2.0; Linux, Docker, Podman, Kubernetes (Helm/Operator), macOS, Windows |
What data ownership actually means
Data ownership comes down to three channels of control. The first is physical: whose disks hold the bytes, and in which building. The second is legal: whose jurisdiction the operator answers to, and what process another government must follow to reach the data. The third is economic: what it costs you to leave, which is set almost entirely by egress pricing.
When you upload an object to a managed cloud bucket, you keep the first channel only partially — the object is on hardware you will never touch, in a region you chose from a menu. You keep none of the second and third channels: the operator's legal exposure becomes your exposure, and leaving is metered. Self-hosting collapses all three channels onto infrastructure you administer. That is the entire argument, and every section below prices one piece of it. The legal examples here draw on EU and US frameworks because they are the pair most often cited in multi-jurisdiction deals; the analysis itself travels — a UN CTED report counts 128 states with some form of data protection or privacy legislation in force.
Who can legally read your cloud bucket?
A US-based provider can be compelled to produce data in its custody or control regardless of where the data physically sits. That is the Clarifying Lawful Overseas Use of Data (CLOUD) Act, enacted March 23, 2018 (Pub. L. 115-141, Division V), and it grew out of Microsoft Corp. v. United States — the 2013 case where the FBI sought email stored on Microsoft servers in Ireland. The Department of Justice states the principle directly: a company subject to US jurisdiction can be required to produce data it controls "regardless of where it chooses to store that data at any point in time."
For a US-headquartered cloud operator, region selection inside that operator's menu does not remove this channel. It changes which building the disk is in, not who can be served a warrant. This is a fact about the operator's legal position, not a claim that any particular request will target your data.
What does GDPR expect from your storage layer?
GDPR does not care where your object storage runs; it cares who is accountable. If you self-host, you are the controller in full — the physical security of the disks, the encryption at rest, and the breach notification clock are all yours. That is more responsibility, and the fines scale to match: Article 83(5) caps administrative fines at €20,000,000 or 4% of total worldwide annual turnover, whichever is higher. The ceiling is not theoretical. In May 2023, Meta was fined €1.2 billion over EU-to-US personal data transfers, the largest GDPR fine issued to date.
So self-hosting neither guarantees compliance nor removes the exposure. What it changes is legibility: when the data center is yours, data residency is a fact you can verify with a walkthrough of the rack, not a promise in a region table. For teams whose compliance posture requires proving where bytes physically live, that difference is the point.
Egress fees are the quiet lock-in
Lock-in is usually discussed as API compatibility, but the binding constraint is the exit invoice. AWS charges $0.09 per GB for data transfer out to the internet after the first 100 GB per month, aggregated across services. Moving a 5 TB dataset out of S3 Standard in one month costs (5,000 − 100) × $0.09 = $441 before you have paid any destination storage. A 50 TB archive costs roughly $4,490. The storage itself is $0.023 per GB-month for the first 50 TB; requests add $0.005 per 1,000 PUTs and $0.0004 per 1,000 GETs.
Self-hosted storage has no egress meter. If the cluster sits on your own network, pulling 50 TB back is a file copy. This is why exit-cost modeling belongs in the original architecture decision, not the migration postmortem: the per-GB toll is the mechanism that turns "we can always move later" into "we will re-evaluate next year."
What self-hosting gives you — and what it takes back
The honest list starts with the costs. Self-host an object store and you inherit every operational duty the cloud vendor used to absorb: hardware capital, spares, power and cooling, physical security, capacity planning, disk replacement, durability engineering, patching, backup verification, and the on-call rotation when replication falls behind. You also stay the controller for legal purposes — a subpoena served on your company reaches your servers just as it would have reached your provider's, and a seizure order can take the hardware itself. Ownership is not anonymity.
What you get is decision rights over all three channels. Physical: the disks are in rooms you control, and decommissioning means shredding media, not filing a support ticket. Legal: requests arrive addressed to you, where you can see them and respond (or litigate) under your own counsel. Economic: no egress meter, no per-request meter, and a license that does not expire — RustFS is Apache 2.0, so the storage layer itself costs nothing to keep running.
The grey zone: self-hosted software on rented hardware
Between "fully cloud" and "fully self-hosted" sits the deployment most teams actually build first: the storage software runs on a rented virtual machine. RustFS on an EC2 instance is the canonical example — you administer the server, hold the keys, and set the policies, but the physical disks belong to Amazon, and the CLOUD Act reaches the data exactly as it did before, through the provider. The egress meter comes back too, because the bytes still leave AWS over a billed pipe when you migrate. The three channels follow the hardware and the operator's jurisdiction, not the software license. Colocated machines you own, or racks in a facility you control, are what actually move the channels; a VM labeled "self-hosted" does not.
Where RustFS fits in a self-hosted stack
RustFS is a distributed object storage server written in Rust, S3-compatible, and licensed under Apache 2.0. The deployment surface in its documentation covers Linux (single-node or distributed), Docker, Podman, Kubernetes via Helm chart and Operator, macOS, and Windows. This means the "own hardware" in this article can be a rack of bare-metal servers, an on-premises Kubernetes cluster, or a single workstation. The feature table in its README (checked 2026-10-12) lists versioning, object lock, server-side encryption, and IAM/policies as available, with S3 Tables and MinIO on-disk compatibility marked as preview.
Two things it does not do, stated plainly: it has no FUSE/POSIX file-system mode, and it does not come with a compliance certification — running it inside a regulated environment is your work, not a checkbox on a vendor's SOC 2 page. Version 1.0.0 reached GA on 2026-09-16; current releases are in the 1.0.x line.
How to move without betting the archive
Teams rarely regret self-hosting because of the software; they regret it when the migration plan assumed a perfect weekend. The workable pattern is incremental, and S3 compatibility is what makes it possible: stand up the self-hosted cluster, keep it secondary, and dual-write new objects to both locations while the primary stays on the cloud. Backfill historical data at whatever rate your uplink allows: a 50 TB backfill over a 1 Gbps link takes about five days, and it costs $0 in egress if it runs from a self-hosted copy, or roughly $4,490 if it must be pulled out of AWS.
Verify by checksumming the way backup tools do, not by counting objects: object counts hide partial uploads. Cut over reads per bucket, per prefix, or per application — S3 client libraries make the endpoint a configuration value, which is the one genuinely portable part of the S3 ecosystem.
A decision checklist before you sign the next cloud renewal
Work through these five questions with numbers, not adjectives. First: what is your current monthly egress invoice, and what would one full migration cost at $0.09/GB? Second: which jurisdiction is your provider headquartered in, and does your compliance team accept that channel? Third: what is the durability story for self-hosting — N disks, N servers, N sites, and who replaces hardware at 2 a.m.? Fourth: can your team run versioning, retention, and encryption policies yourself, or were you relying on the vendor console? Fifth: what is the rehearsal plan — has anyone actually restored the archive end to end?
If the answers to three or more of those are "we have not checked," the cloud invoice is not the risk. The unstated assumptions are.
One cost the checklist must not skip is total cost of ownership. This article prices the exit channel — egress — because that number is published and uniform. Hardware capital, cross-site redundancy, power, spares, and staffing dominate the self-hosted side, vary by orders of magnitude between a homelab and a datacenter presence, and cannot be modeled generically without inventing figures. If the business case needs a TCO comparison, build it from your own hardware quotes and your team's actual payroll — not from any article, including this one.
Frequently Asked Questions
Is self-hosted object storage automatically GDPR compliant?
No. Self-hosting changes where the data sits and who operates it, but you remain the data controller with the full Article 32 security obligation and the Article 83(5) fine exposure — up to €20,000,000 or 4% of worldwide turnover of the preceding financial year. Compliance comes from your controls (encryption, access, retention, breach response), not from the deployment location.
Does the CLOUD Act apply to my own servers?
The CLOUD Act compels US-based providers, not disks. If you operate your own hardware outside a US provider's tenancy, there is no provider to serve; legal process has to be addressed to you, under the laws of your jurisdiction. That is a real difference in the legal path — not a guarantee against government access, which no storage architecture provides. If your "self-hosted" cluster runs on a rented cloud VM, the answer flips back: the provider is subject to the Act, and the disks are the provider's.
How much does it cost to migrate data out of S3?
Egress is $0.09/GB after the first 100 GB per month. A 5 TB exit costs (5,000 − 100) × $0.09 = $441; a 50 TB archive costs about $4,490, charged by AWS whether or not your destination is cheaper. Migration tooling and destination storage are separate line items.
What do I lose by self-hosting object storage?
Vendor-managed durability, capacity elasticity, and the operations staff implicit in them. You inherit hardware replacement, replication monitoring, patching, and backup verification. Teams without an on-call rotation or a verified restore drill should treat that as a staffing decision before it becomes a storage decision.
Is RustFS really free for commercial use?
Yes — Apache 2.0, with no license meter and no seat count. What is not free is the infrastructure it runs on and the operational labor it requires. The README feature table lists versioning, object lock, server-side encryption, and IAM as available; S3 Tables and MinIO on-disk compatibility are marked preview.
A note on how this was verified
Article type: this is a documented-facts analysis piece, not a production deployment report. Legal texts (GDPR Art. 83, CLOUD Act / Pub. L. 115-141) were checked against primary sources in October 2026; AWS prices are published us-east-1 list rates as of 2026-10-12 and the migration examples are arithmetic derived from those rates, not measurements. RustFS deployment targets were checked against docs.rustfs.com; feature-status claims come from the project README and have not been re-tested hands-on for this article. No benchmark, latency, or durability number in this article was measured by the author. Verify current prices and the feature table before acting on any figure here.
Sources
- GDPR Article 83 — General conditions for imposing administrative fines: https://gdpr-info.eu/art-83-gdpr/
- EDPB, "1.2 billion euro fine for Facebook as a result of EDPB binding decision" (22 May 2023): https://edpb.europa.eu/news/news/2023/12-billion-euro-fine-facebook-result-edpb-binding-decision_en
- US Department of Justice, CLOUD Act resources and white paper announcement: https://www.justice.gov/opa/pr/justice-department-announces-publication-white-paper-cloud-act
- Congressional Record, Sen. Hatch on the CLOUD Act (Feb 5, 2018): https://www.govinfo.gov/content/pkg/CREC-2018-02-05/html/CREC-2018-02-05-pt1-PgS595-7.htm
- UN CTED report, "The State of International Cooperation for Lawful Access to Digital Evidence" (128-state count): https://www.un.org/securitycouncil/ctc/sites/www.un.org.securitycouncil.ctc/files/files/documents/2022/Jan/cted_trends_report_lawful_access_to_digital_data_.pdf
- Amazon S3 pricing (us-east-1 list rates): https://aws.amazon.com/s3/pricing/
- RustFS documentation — installation targets: https://docs.rustfs.com/en/
- RustFS GitHub README (license and feature status): https://github.com/rustfs/rustfs
Top comments (0)