S3-Compatible Object Storage, Explained

What "S3-compatible" actually means

Object storage keeps data as discrete objects in flat containers called buckets, rather than as files in a tree of folders or as blocks on a disk. Each object has a unique key (its name), the data itself, and metadata. There are no real directories. A key like backups/2026/db.sql just looks like a path; the slashes are part of the key, and the bucket is one big flat namespace.

Amazon launched S3 in 2006, and over time its HTTP API became the de facto industry standard. "S3-compatible storage" means a storage product that speaks that same API, so the same SDKs, CLIs, and tools that talk to Amazon S3 also talk to it. You change an endpoint URL and your credentials, and the rest of your code stays the same.

The practical payoff is portability. Because hundreds of tools, libraries, and backup utilities already know how to speak S3, building on the S3 API means you are not locked into one vendor's proprietary protocol. You can move providers by swapping a few config values.

How the S3 API works under the hood

At its core, the S3 API is a small set of HTTP operations against buckets and objects. The everyday ones are PutObject (upload), GetObject (download), DeleteObject, ListObjectsV2 (list keys, usually filtered by a prefix), and HeadObject (fetch metadata only). Requests are authenticated with an access key ID and secret key using a signature scheme called SigV4 — the same scheme every compatible provider implements.

Two features do most of the heavy lifting in real apps. Presigned URLs let your backend generate a temporary, signed link so a browser or mobile client can upload or download an object directly, without ever seeing your secret keys. The link carries a built-in expiry (anywhere from minutes up to seven days). This keeps large file transfers off your own servers.

Multipart upload handles big files. Instead of one giant PUT, the client splits the object into parts, uploads them in parallel (often via presigned URLs), and then sends a final CompleteMultipartUpload call listing each part and its ETag. The service assembles them into one object. If a part fails mid-transfer, you retry just that part instead of restarting the whole upload.

• Buckets hold objects; objects are identified by a unique key and carry metadata.
• Core verbs: PutObject, GetObject, DeleteObject, ListObjectsV2, HeadObject.
• Presigned URLs move uploads/downloads directly between client and storage.
• Multipart upload makes large, resumable transfers reliable.

What it costs — and the egress trap

Object storage pricing has three components: storage (per GB stored per month), requests (per thousand API calls), and egress (data transferred out to the internet). Storage is usually the smallest surprise; egress is where bills explode.

As a ballpark in 2026: Amazon S3 Standard runs about $0.023 per GB/month for the first 50 TB, with 11 nines (99.999999999%) of durability by storing data across at least three availability zones. Independent S3-compatible providers tend to be cheaper on storage — roughly $0.006–$0.015 per GB/month is common — and several charge little or nothing for egress.

Egress is the line item to watch. Amazon S3 gives you the first 100 GB/month free, then charges tiered rates that start around $0.09 per GB and fall to roughly $0.05 per GB at very high volume. That means serving 10 TB of downloads can cost hundreds of dollars a month in bandwidth alone, often more than the storage itself. If you serve a lot of public traffic — media, downloads, a busy CDN origin — a provider with flat-rate or zero egress can be dramatically cheaper. Run your own numbers: estimate GB stored, requests per month, and especially GB downloaded.

• Three cost levers: storage, requests, egress.
• 2026 ballpark — S3 Standard storage ~$0.023/GB/mo; alternatives ~$0.006–$0.015/GB/mo.
• Egress is the hidden cost: ~$0.05–$0.09/GB on hyperscalers, often free on independents.
• Model your monthly downloads before choosing — egress frequently dwarfs storage.

When to use object storage (and when not to)

Object storage is the right tool for large, relatively static blobs that you read and write whole: backups and archives, user uploads (images, video, documents), build artifacts and container layers, data-lake files, static website assets, and logs. It scales to petabytes, is durable, and is cheap per gigabyte.

It is the wrong tool when you need to modify part of a file in place, when you need a real filesystem with locking and POSIX semantics, or when you need transactional, low-latency random access. Those are jobs for a block volume or a database. Objects are immutable in practice — to "edit" one you overwrite the whole key.

A useful mental model: if your access pattern is "write once, read many, replace whole," object storage fits. If it is "update a few bytes deep inside a large structure, repeatedly, with low latency," reach for a database or block storage instead.

Choosing a provider and migrating safely

Compatibility is a spectrum, not a checkbox. Every provider implements the core verbs, but coverage of advanced features — versioning, object lock and immutability, lifecycle rules, server-side encryption with customer keys, bucket policies, event notifications — varies. List the specific features your application actually calls, then confirm each one is supported before you commit.

Beyond the feature list, weigh region/latency (store data near your users or compute), durability and redundancy guarantees, egress pricing for your traffic profile, and the credibility of support when something breaks at 3 a.m. A provider on fast NVMe in a region close to your servers will feel noticeably snappier for request-heavy workloads.

Migration is usually low-drama precisely because the API is shared. Tools like rclone or the AWS CLI can sync buckets between providers; in your app you point the SDK at the new endpoint, swap credentials, and run a verification pass on object counts and checksums. Keep both endpoints live during cutover so you can roll back instantly.

• Map your required features (versioning, object lock, lifecycle, SSE) against the provider's support.
• Prioritize region/latency, durability, and egress pricing for your real traffic.
• Migrate with rclone or aws s3 sync; verify counts and checksums before cutover.

Getting started with NordicVentures

If you want S3-compatible storage that is fast, predictable, and close to your users, that is exactly what we built. NordicVentures runs object storage on NVMe-backed infrastructure across Stockholm, Frankfurt, and Ashburn, so you can keep data near your compute and your audience.

You get the full S3 API your existing SDKs and tools already speak, transparent pricing with no surprise egress math, free migration help to move your existing buckets, and 24/7 human support when you need a real person. Point your endpoint at us and keep your code as-is.

When you are ready to try it, head to our object storage page to get S3-compatible storage and spin up your first bucket.