"Because it is S3 compatible, you can migrate simply by swapping endpoints and keys." With GPU procurement costs driving proposals to offload AI workloads to alternative clouds, this sentence has become increasingly common.
Furthermore, this statement is not a lie. SDKs work out of the box, and both PutObject and GetObject return expected results. If you verify behavior in a staging environment, it naturally passes.
The catch is that passing tests and achieving equivalent defense are two entirely different matters. In an investigation published by Wiz in August 2026, those discrepancies were laid bare across specific feature names.
Compatibility applies to APIs, not defense mechanisms
What services advertising S3 compatibility provide is the shape of requests and responses: creating buckets, storing objects, and issuing presigned URLs. Everything visible from the application layer behaves identically.
Conversely, the mechanisms that ensure secure S3 operations on AWS lie outside the API: account-wide prohibitions against making buckets public, records of who accessed which object, and the expressive power of conditional policies to restrict privileges. These are AWS-side implementations, not S3 API specifications.
Scott Piper, Principal Cloud Security Researcher at Wiz, described this by stating that "S3 compatibility creates a dangerous illusion of portability." His point is that the real issue lies in mistaking the feasibility of migration for the capability to defend.
What empirical testing revealed was missing
The survey evaluated managed object storage across six providers primarily focused on GPU clouds: Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare R2, and DigitalOcean. Comparisons against S3 revealed the following gaps:
| Features | Measured status |
|---|---|
| Bulk public access blocking | No service offered an equivalent to S3 Block Public Access |
| Data plane logging | Only Nebius and DigitalOcean supported object-level access logs |
| Fine-grained IAM | Limited or absent; only Cloudflare, DigitalOcean, and Nebius offered read-only or bucket-level restrictions |
Each of these three has distinct operational implications.
Lacking public access blocking means organizational settings cannot proactively prevent buckets from becoming public due to misconfigurations. Organizations accustomed to relying on this feature in S3 often fail to anticipate operating without it.
Lacking data plane logs means that when an incident occurs, you cannot determine what was exfiltrated after the fact. Setting aside whether an intrusion can be detected, you cannot establish the scope of damage. In incidents carrying mandatory reporting obligations, this is fatal.
Lacking fine-grained IAM means you cannot enforce least privilege. If you cannot issue a key that grants read access solely to a specific prefix within a specific bucket, every key you issue will grant broader access than necessary. While restricting privileges granted to contractors and external vendors was discussed in Designing JIT Access Instead of Standing Privileges, that architecture cannot function in environments where restriction mechanisms do not exist in the first place.
Implementation gaps have already manifested as vulnerabilities
Differences in IAM behavior across products are not merely theoretical. Vulnerabilities stemming from authorization logic itself have been reported in S3-compatible implementations.
In MinIO, flaws permitting privilege escalation have been confirmed. In RustFS, issues breaking tenant isolation and authorization semantics were reported. Both demonstrate that policies written with the assumption of S3 behavior can be interpreted with different semantics on compatible products.
There is one practical conclusion to draw from this: never skip verification when porting policy syntax that worked on S3 to compatible products. Even if the exact same JSON is accepted, requests that should be denied might still be permitted.
Five questions to ask before deciding on migration
When evaluating a migration proposal motivated by cost, these are the items you should verify before conducting functional testing:
- Can public bucket exposure be prohibited at the organization level? If not, you must build an in-house mechanism to detect public exposure. Decide who will perform regular audits.
- Can object-level access logs be captured, and what is the retention period? If unavailable, you cannot justify storing personal data or client deliverables in that bucket.
- Can permissions be restricted at the bucket or prefix level? If not, recalculate costs under the premise of separating accounts or buckets per use case.
- How are key rotation and revocation handled? The ability to invalidate issued keys immediately is vital when handing credentials to contractors.
- What encryption and retention policies are available? Beyond encryption at rest, whether deletion prevention (equivalent to Object Lock) exists fundamentally alters ransomware defense architecture.
If two or more of these five items are absent, you do not necessarily need to reject the migration, but you must be selective about what data resides there. Offloading only data with limited exposure impact—such as model weights or intermediate build artifacts—is a realistic setup. Conversely, migrating entire buckets containing customer data is not worth the risk.
Cost comparisons for migrations often fail to factor in these operational differences as added engineering overhead. A framework for what you assume ownership of in exchange for portability is detailed in Deciding How to Avoid Vendor Lock-In.
What to do next
First, if you are currently using S3-compatible storage, compile an inventory of those buckets and what data each contains. If any bucket holds customer data, reviewing the vendor documentation against the five items above is your first priority.
If you are evaluating migration now, add three lines to your cost comparison: Public Access Blocking, Access Logging, and Fine-Grained IAM. Any comparison table listing only unit prices fails as a decision-making tool as long as these three lines are omitted.
GleamHub offers consultations on cloud storage architecture reviews, permission modeling, and AI workload migrations through our Development, AI, and Automation consulting services. Because the approach depends on data sensitivity and existing infrastructure, please consult with us individually. Feel free to reach out via Contact Us.
