Glossary

What Is S3 Compatible Storage?

S3 compatible storage is any storage system that can be read from and written to using the Amazon S3 API, without being Amazon S3. Applications address it with the same requests, the same authentication scheme, and the same bucket-and-object model they would use against AWS — but the data sits in a system you choose, in a location you choose, priced on terms you choose.

The S3 API has become the default language for storing unstructured data at scale. Amazon launched it in March 2006, and in the two decades since, backup software, analytics engines, media pipelines, and cloud-native applications have all standardized on it. That standardization is what makes compatibility valuable: a storage system that speaks S3 inherits an ecosystem of applications that already know how to talk to it, with no integration work and no custom connector to maintain.

The important nuance is that “S3 compatible” is not a certification. No standards body defines it and no one audits claims to it. Two products can both advertise S3 compatibility and differ substantially in which operations they implement, how faithfully they behave under edge cases, and whether the features your application actually depends on are present. Understanding where those gaps tend to appear is most of the work in evaluating one.

What “S3 compatible” actually means

At its core, S3 is a REST API over HTTP. Data is organized into buckets, which hold objects, and each object is identified by a key. There are no real directories — a key like 2026/q1/report.pdf is a single flat string, and the folder-like browsing you see in tools is produced by asking the API to group keys by prefix and delimiter.

A system is S3 compatible when it accepts requests shaped that way and responds the way an application expects. In practice that means three things working together:

• The wire format. Requests and responses use S3’s URL structure, headers, and XML response bodies — including its specific error codes, which many client libraries branch on.
• The authentication scheme. Requests are signed with AWS Signature Version 4, using an access key ID and secret access key issued by the storage system rather than by AWS.
• The data model. Buckets, keys, prefixes, metadata, and the semantics of what happens when you overwrite or delete something.

Pointing an application at a compatible system is usually a matter of changing the endpoint URL and swapping in new credentials. That is the whole appeal — the application does not need to know it is no longer talking to AWS.

The operations a compatible system needs to support

A small set of operations carries the overwhelming majority of real traffic. Any system claiming compatibility should handle all of them well:

Beyond these sit the features that separate a basic implementation from a production one: object lock for write-once-read-many retention, lifecycle policies for automatic tiering and expiry, bucket policies and IAM-style access control, server-side encryption, cross-region replication, object tagging, and CORS configuration.

Where compatibility usually breaks down

Gaps rarely show up in a proof of concept and frequently show up in production. The recurring ones are worth naming:

• Consistency semantics. Amazon S3 has provided strong read-after-write consistency for all requests since December 2020 — write an object, and a subsequent read is guaranteed to return it. Older or geographically distributed compatible systems may still be eventually consistent, which breaks applications written after 2020 that assume the guarantee.
• Object lock fidelity. Many systems implement the object lock API surface without enforcing it at the storage layer, or allow a sufficiently privileged administrator to remove a lock. For compliance and ransomware-recovery use cases, the API accepting the call is not the same as the retention actually holding.
• Listing at scale. Pagination behavior, delimiter handling, and latency on buckets containing tens of millions of keys vary enormously between implementations.
• Access control depth. Bucket policies, IAM users and roles, and temporary credentials via STS are frequently partial or absent, which matters as soon as more than one team shares the system.
• Error codes. Returning a generic error where AWS returns a specific one causes client libraries to retry incorrectly, or to fail where they should recover.
• Newer additions. Capabilities added to AWS more recently are the least consistently implemented across the market.

Why organizations choose S3 compatible storage on premises

Adopting the S3 API without adopting AWS is usually driven by a handful of concrete pressures rather than by a preference for on-premises infrastructure as such:

• Egress and retrieval cost. Public cloud object storage charges to read data out. Workloads that write once and read often — media, analytics, active archive — can cost more to use than to store.
• Data residency and sovereignty. Regulation or contract may require that data remain within a jurisdiction, or outside the reach of a foreign legal regime, in ways a public cloud region does not satisfy.
• Restore performance. Recovering hundreds of terabytes over a wide-area link is bounded by bandwidth. On-premises storage on the same network as the systems being restored is bounded by the array instead.
• Ecosystem access without lock-in. Keeping the S3 API means keeping the application ecosystem. Changing where the data lives becomes an endpoint change rather than a migration project.

The same reasoning applies in reverse for hybrid designs: a system that speaks S3 on both sides can tier or replicate between on-premises capacity and public cloud without an intermediate translation layer. See multi-cloud for how that pattern is typically structured.

Common use cases

• Backup and recovery targets. Veeam, Commvault, Rubrik, Veritas, and most other enterprise backup platforms write to S3 endpoints natively, and use object lock to make backup copies immutable. This is the largest single category of on-premises S3 deployment.
• Data lakes and analytics. Spark, Presto/Trino, and the Hadoop-lineage tools all read S3-addressed data directly, so a compatible system can serve as the storage layer for analytics without a copy step.
• Media repositories. Large files, high throughput, long retention, and ecosystem tools that already speak S3.
• Active archive. Data too valuable to delete and too infrequently accessed to keep on primary storage — the classic case for nearline storage.
• Cloud-native application storage. Applications built against the S3 SDK that need to run somewhere other than AWS.

Where a workload is better served by a shared filesystem than by object access, the tradeoffs are covered in object storage vs. NAS and distributed file systems.

How to evaluate a vendor’s S3 compatibility claim

Because the term is unregulated, evaluation has to be empirical. A practical sequence:

1. Ask for the supported-operations list — the actual API reference, not a marketing statement. Absence of a documented list is itself informative.
2. Test with your own applications, not a generic tool. The question is never “is this S3 compatible” in the abstract; it is “does my backup software, my analytics engine, my application work against this.”
3. Run an open compatibility suite as a baseline. Ceph’s s3-tests is the most widely used, and vendors who have run it will usually say so.
4. Test at realistic scale. List a bucket with millions of objects. Upload something large enough to exercise multipart. Measure, do not assume.
5. Verify object lock by trying to break it. Set a retention period, then attempt to delete the object as an administrator. If it succeeds, the lock is decorative.
6. Confirm the SDK path. Your applications will use the AWS SDKs; make sure they work against the endpoint unmodified, including region and path-style addressing settings.

S3 compatible storage and Amazon S3 compared

Neither is strictly better. The decision turns on how much data you hold, how often you read it, how tightly residency is constrained, and how much operational capacity you have. Organizations operating at petabyte scale tend to find the economics favor owning the capacity; organizations with bursty, smaller, or short-lived datasets tend to find the opposite.

Scality’s own platforms — RING and ARTESCA, the former for large-scale deployments and the latter for cyber-resilient backup targets — both present S3 as their primary interface, which is why compatibility depth rather than compatibility-in-principle is the distinction worth pressing any vendor on.