---
title: "What is S3-compatible storage?"
canonical: https://enum.co/learn/what-is-s3-compatible-storage
locale: en
topic: Storage
publishedAt: 2026-10-15
updatedAt: 2026-10-15
author: "Max Heyer"
summary: "S3-compatible storage is object storage that accepts the S3 API, so existing S3 tools, SDKs and backup software work after you change the endpoint and keys."
---

# What is S3-compatible storage?

S3-compatible storage is object storage that accepts the S3 API, so existing S3 tools, SDKs and backup software work after you change the endpoint and keys.

After reading this you will be able to:

- Explain what the S3 API defines: buckets, objects, keys and signed requests
- Check which S3 features a compatible provider actually supports
- Plan a switch by changing endpoint, credentials and addressing style

## What is S3-compatible storage?

S3-compatible storage is object storage that speaks the S3 API, the HTTP interface most object storage tools are written against. You store objects in buckets, address each one by a key, and sign every request with an access key. Any client built for the S3 API can use it once you point it at a different endpoint.

Think of a standard power plug. Any lamp with that plug works in any socket that follows the standard, whoever built the house. The S3 API is the plug shape, and S3-compatible providers are the sockets.

## What does the S3 API define?

The S3 API is a REST interface over HTTPS. It uses standard HTTP methods, headers and status codes, so a plain HTTP client can talk to it, though most people use an SDK or a command-line tool.

### Buckets, objects and keys

A bucket is a container with a unique name. An object is a sequence of bytes plus metadata, stored under a key such as `backups/2026/db.tar.gz`. The slashes are part of the name, not real folders, and listing by prefix makes them look like a directory tree.

### Signed requests

Each request carries a signature computed from the request details and your secret key, using Signature Version 4. The secret key itself never travels over the network. The server repeats the calculation and accepts the request only if the signatures match.

### Large uploads

Multipart upload splits a large object into parts that upload in parallel and in any order. A failed part can be sent again without restarting the whole file.

## What does "compatible" cover?

Almost every provider handles the basic calls: create a bucket, then put, get, list and delete objects. Beyond that, support varies, and the gaps show up when your tool depends on a feature the provider lacks.

Check these before you move:

- Versioning and Object Lock, if your backups rely on them
- Lifecycle rules for expiring objects and old versions
- Presigned URLs for time-limited access without sharing keys
- Bucket replication, event notifications and static website hosting
- Path-style versus virtual-hosted-style addressing, where the bucket sits in the path or in the hostname

### Switching providers

For most applications the switch is three settings: the endpoint URL, the access key and the secret key. Some tools also need a region name, because the signature is scoped to a region, or path-style addressing turned on. Copy existing data with a sync tool such as rclone or s5cmd, and re-run the sync until you cut over.

## How enum handles S3-compatible storage

[enum Object Storage](/object-storage) speaks the S3 API, so rclone, s3cmd, s5cmd and the S3 SDKs work after you change the endpoint. It has versioning, Object Lock, lifecycle expiration rules and SigV4 presigned URLs. There is no bucket replication, event notifications, static website hosting or SSE-KMS, and data sits in one zone.

## FAQ

**Do I need to change my application code?**
Usually not. Most applications read the endpoint, access key and secret key from configuration. You change those three values, and possibly the region or addressing style, and the existing SDK calls keep working.

**Is S3-compatible storage the same as a file system?**
No. An object is replaced as a whole on every write, and there is no in-place editing or file locking. Tools that mount buckets as drives exist, but they turn file operations into S3 API calls.

**How do I test whether a provider is compatible enough?**
Run your real workload against a test bucket: your backup tool, your SDK calls and your sync jobs. Then check the features you depend on, such as versioning, Object Lock or lifecycle rules, one by one.
