Security researchers at Wiz recently reviewed S3-compatible object storage services across six popular neoclouds and uncovered substantial security shortcomings compared to Amazon S3. The study examined managed services from Nebius, Crusoe, Vultr, Lambda Labs, Cloudflare R2, and DigitalOcean, finding that while S3 has become the standard for object storage, most alternatives lack several of AWS's security protections. Organizations using S3 clones can't depend on AWS security assumptions and must prepare for weaker protections and more limited least-privilege capabilities, according to principal cloud security researcher Scott Piper.
The study reveals that S3-compatible services differ widely in their handling of public buckets. Crusoe and Lambda Labs don't offer public-access features at all, while others provide fewer safeguards and controls than AWS S3's Block Public Access functionality. Nebius and Cloudflare R2 permit public buckets but block anonymous object listing, whereas DigitalOcean allows publicly listable buckets and Vultr supports both ACLs and bucket policies for public access. Access keys pose another challenge: S3-compatible services frequently lack the organized access-key formats and secret-scanning support that AWS offers, making credentials tougher for security teams and tools like GitHub to identify. IAM capabilities and semantics vary considerably among S3-compatible implementations, an issue that has emerged through multiple reported vulnerabilities, including one in MinIO that allowed unauthorized privilege escalation and a recent one in RustFS that compromises tenant isolation and authorization semantics.
Scott Piper explains that S3 compatibility generates a misleading impression of portability, noting that nearly 300 APIs are associated with AWS S3 and related services like S3 tables, S3 vectors, and S3 express. Over more than 20 years, specialized functionality has been layered onto S3, which now stores trillions of objects and hundreds of exabytes of data—not all of that functionality has been duplicated, and some clones behave in unexpected ways. Corey Quinn, chief cloud economist at The Duckbill Group, summarizes the problem: every neocloud ships an S3-compatible endpoint, and your muscle memory follows whether the APIs behave properly or not. On one service, the `delete-bucket-policy` command deleted the entire bucket. As S3-compatible services inherit presigned URLs from the S3 API, all the clones support this capability and its associated security implications.
The research points to serious operational risks for teams assuming AWS-level security in alternative environments. Because credentials for S3-compatible services often lack recognizable patterns, they aren't commonly detected by secret scanners beyond GitHub's limited coverage for DigitalOcean and Cloudflare. Rishi Raj Singh, senior solutions engineer at Wiz, recommends that teams leveraging S3-compatible storage in neoclouds explicitly audit API behavior, verify permissions models, and validate what happens when standard AWS tooling interacts with these endpoints. Wiz's review doesn't cover several other major S3-compatible implementations, including Backblaze B2, Wasabi, and Google Cloud Storage—the S3-compatible storage providers directory currently lists more than 90 providers, while Awesome Object Storage compares 21 providers across hyperscalers, alternatives, edge options, self-hosted, and decentralized solutions. The portability promise that draws organizations to S3-compatible services may introduce blind spots that leave critical data exposed. As neoclouds proliferate and teams chase cost savings or specialized infrastructure, security teams face a growing burden of validating each platform's actual behavior rather than relying on familiar AWS patterns.