What Is S3-Compatible Storage? How It Works and What to Test

S3-compatible storage is object storage that accepts the same API requests as Amazon S3. Tools built for AWS, like the AWS CLI, boto3 and rclone, work with another provider once you change the endpoint and keys. Support differs at the edges, so test before you move data.

TL;DR:

• S3-compatible means a provider speaks the Amazon S3 REST API: buckets, objects, keys and signed HTTPS requests.
• Switching usually takes four settings: endpoint URL, access keys, signing region and addressing style.
• Core calls (put, get, list, delete) match almost everywhere. Versioning, Object Lock, lifecycle rules and policies vary by provider.
• On AIOZ Storage you use https://s3.aiozstorage.network, region us-east-1 and path-style addressing, with data spread across AIOZ DePIN nodes.

Updated Oct 19, 2026: rewritten from a general overview into a definition, a pre-migration test list and AIOZ Storage's exact settings. Corrected the encryption claim (AIOZ encrypts server-side by default), added the upload checksum setting AIOZ's endpoint needs, and added a diagram, FAQ and references.

What Does S3-Compatible Mean?

The AIOZ Storage docs define an S3-compatible service as one that "adheres to the same application programming interface (API) specifications and functionality as Amazon Simple Storage Service (S3)". Put simply, your code sends the HTTP requests it would send to AWS, and the provider answers in the same format.

Amazon S3 is the reference design: it keeps data as objects inside buckets, and each object has a key, its bytes and some metadata. If you want a refresher on that model first, start with our explainer on how S3 object storage works.

So the label describes a contract between the client on your side and the server on the provider's side. It says nothing about where your data lives, how it is protected or what it costs, since each provider decides those.

How Does S3-Compatible Storage Work?

Every S3 call is an HTTPS request to an endpoint, and the AWS SDKs and CLI sign it with your secret key using Signature Version 4 (SigV4). A compatible provider checks that signature, runs the operation on its own backend and returns the response an S3 client expects.

That is why switching rarely needs code changes, since you only edit configuration, and the table shows the four values that move.

Addressing style trips people up most, because AWS puts the bucket in the hostname by default while path-style puts it after the endpoint, as in endpoint/bucket/key. AWS says its own path-style URLs "will be discontinued in the future". Many compatible providers still expect them, and rclone's S3 backend uses path-style unless the provider needs the other form.

Is AWS S3-Compatible Object Storage the Same as Amazon S3?

No. A compatible service matches the calls you make every day, but it doesn't have to copy every AWS feature around them, and the usual gaps fall into four areas:

• Access control. AWS combines IAM policies, bucket policies and ACLs (see bucket policy vs IAM policy). Many providers use their own permission model instead.
• Data protection. Object versioning, Object Lock and lifecycle rules can be missing or partial.
• Encryption. AWS offers SSE-S3, SSE-KMS and SSE-C. Other providers often apply one scheme to everything.
• Storage classes and pricing. AWS sells many storage classes and charges per request. A compatible provider may have one flat rate, so compare price per GB and per request side by side.

The physical design can differ as well, and AWS states that S3 Standard stores objects across at least three Availability Zones in a Region. A decentralized provider spreads data over independent nodes instead, yet your client sees the same API.

Even plain uploads can differ. Recent AWS SDKs and the AWS CLI add a checksum to uploads by default and can send the body in aws-chunked encoding. Some compatible endpoints reject that, and AIOZ Storage's endpoint answered with MissingContentLength when we checked on Oct 19, 2026. One client setting fixes it, as the AIOZ section below shows.

What to Test Before You Switch

Run these checks against a test bucket before you send production traffic to a new provider. Each item below is a common reason an S3 tool that works on AWS fails on a new endpoint.

1. Addressing style. Turn on path-style if the provider needs it: addressing_style in boto3, forcePathStyle in the JavaScript SDK, UsePathStyle in Go.
2. Signature and region. Confirm SigV4 works and find the region string the provider expects. A wrong region tends to fail as an authorization error.
3. Default checksums. Upload a small file with a current SDK. If it fails, set request checksum calculation to "when required" and try again.
4. Large files. Upload a file above your SDK's multipart threshold (8 MB by default in boto3) and check that it completes. The S3 multipart upload guide explains the parts.
5. Presigned URLs. Generate one and open it in a browser, as in presigned URLs with Python.
6. Features you rely on. List every AWS feature your app calls, such as versioning, lifecycle rules or event notifications, and look each one up in the provider's docs.
7. Integrity after a copy. Compare source and destination with rclone check, which matches sizes and hashes. The checksum explainer covers why that matters.
8. Rate limits. Find the request limit and run your busiest job against it. Our AIOZ Storage rate limit guide shows one way to stay under it.

The payoff is that you keep your scripts, SDKs and backup tools, and you can leave a provider later without rewriting code. That is the main reason teams pick S3-compatible storage for backups, static assets, media libraries and datasets.

How AIOZ Storage Handles It

AIOZ Storage runs an S3-compatible API on top of AIOZ DePIN, a peer-to-peer network that the homepage puts at 191,285 edge nodes. We encrypt each object on the server side, then split it with Reed-Solomon erasure coding into data and parity pieces on different nodes. No single node holds a complete copy. The SDK and CLI examples in the docs all use the values in this table:

With the AWS CLI, you add one flag to the commands you already know, and this line from the CLI docs lists your buckets:

aws s3 --endpoint-url https://s3.aiozstorage.network ls

In boto3, the same settings go into the client, as in this version adapted from the Python SDK page:

import boto3
from botocore.config import Config

s3 = boto3.client(
    "s3",
    endpoint_url="https://s3.aiozstorage.network",
    region_name="us-east-1",
    aws_access_key_id="YOUR_ACCESS_KEY_ID",
    aws_secret_access_key="YOUR_SECRET_ACCESS_KEY",
    config=Config(
        request_checksum_calculation="when_required",
        response_checksum_validation="when_required",
        s3={"addressing_style": "path"},
    ),
)
print([b["Name"] for b in s3.list_buckets()["Buckets"]])

The two checksum options matter because the endpoint rejects the aws-chunked uploads that current AWS tools send by default (checked Oct 19, 2026). For CLI uploads, set the same behavior with an environment variable and turn on path-style addressing:

export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
aws configure set default.s3.addressing_style path
aws s3 --endpoint-url https://s3.aiozstorage.network cp ./report.pdf s3://bucket-name/

We did not run these snippets for this article, so no output is shown. The same idea extends past files: the AIOZ Storage Vector Database speaks the AWS S3 Vectors API, so the AWS vector SDKs work against it too.

What the docs don't cover yet: support for versioning, Object Lock, lifecycle rules, bucket policies and event notifications. The docs also describe end-to-end encryption through a self-hosted gateway, but that gateway is announced and not yet available to download. Test anything on this list before your app depends on it.

Next step: read the S3 Compatibility page in the AIOZ Storage docs, create an access grant, and run the CLI line above against your account.

Frequently Asked Questions

What is S3-compatible storage in simple terms?
It is object storage from any provider that accepts Amazon S3 API calls, so tools written for S3 work after you change the endpoint and keys.

Do I need to change my code to use S3-compatible storage?
Usually you only change configuration: the endpoint URL, access keys, signing region and, for many providers, path-style addressing.

What is the difference between path-style and virtual-hosted-style requests?
Virtual-hosted style puts the bucket name in the hostname, while path-style puts it in the URL path after the endpoint. AWS defaults to virtual-hosted style, and many compatible providers expect path-style.

Can I use the AWS CLI with S3-compatible storage?
Yes, add --endpoint-url with the provider's URL to each command, or set the endpoint in your AWS CLI profile.

Does AIOZ Storage support the full Amazon S3 API?
Its docs cover bucket and object operations through the AWS CLI and the AWS SDKs for Python, JavaScript and Go. They don't list versioning, Object Lock, lifecycle rules or bucket policies, so test those first.

Is my data encrypted on AIOZ Storage?
Yes, AIOZ Storage encrypts data on the server side by default, before it is stored on AIOZ DePIN nodes.

Related Reading

• What Is S3 Object Storage? How It Works, Explained - the bucket, object and key model behind the API.
• What Is AIOZ Storage? - the product, its pricing and its feature list in one place.
• Migrate from Amazon S3 to AIOZ Storage with rclone - a full copy and check, step by step.
• AIOZ Storage CLI Quickstart - every AWS CLI command with the custom endpoint.
• AIOZ Storage Developer Platform - the SDKs, CLI and tools that share these settings.

References

• AIOZ Storage Docs: Definitions
• AIOZ Storage Docs: CLI
• AIOZ Storage Docs: Python SDK
• AIOZ Storage Docs: Server-Side Encryption and End-to-End Encryption
• AIOZ Storage Docs: Usage Limit
• AWS: Virtual hosting of general purpose buckets
• AWS: Signature Version 4 for API requests
• AWS: Data protection in Amazon S3
• rclone: Amazon S3 storage providers