Object Storage Explained: S3, Blob, GCS and S3-Compatible Options

Storage That Behaves Like a Key/Value Store, Not a Disk

Object storage keeps whole files as opaque blobs, each one addressed by a key inside a bucket. There are no directories, no partial writes, no file handles. You put an object, you get an object, you delete an object.

That restriction is the whole point. Because an object is immutable once written, the service can replicate it across many machines, serve it over HTTP, and grow capacity without anyone planning a volume size in advance.

Almost every cloud workload eventually needs one: user uploads, static site assets, database dumps, build artifacts, logs, machine learning datasets. This article covers the model, the major implementations, the tier systems, and the S3 API dialect that ties them together.

Buckets, Keys and Metadata

A bucket is a container with a name and a region. A key is the full string that identifies an object inside it, for example invoices/2026/09/inv-4821.pdf. Slashes carry no structural meaning; the console draws folders by splitting on them, but the namespace underneath is flat.

This matters when you list. A listing is a prefix scan over sorted keys, so invoices/2026/09/ is cheap, while asking which objects changed last Tuesday is not. Design keys around the queries you will actually run, and keep searchable attributes in a database rather than in the key.

Every object carries system metadata such as content type, size and entity tag, plus user metadata you attach at upload. Several services also support tags, which lifecycle rules and access policies can read without rewriting the object itself.

Naming rules differ. In Amazon S3 and Google Cloud Storage the bucket name lives in a global namespace, so a name someone else took is gone for everyone. Azure inverts it: the storage account name is globally unique and containers are scoped inside it.

The Services You Will Meet

Azure Blob Storage is the outlier in both vocabulary and structure. It distinguishes block blobs, append blobs and page blobs, and its native REST interface is not the S3 interface, although plenty of tooling and gateway layers translate between them.

The developer clouds tend to bundle a content delivery layer with the bucket. Spaces, for example, exposes a CDN endpoint in the same panel, which removes one integration step for a static site. If that pairing appeals, a DigitalOcean account gives you the bucket and the edge cache together, while an AWS account brings the deepest feature set and the largest body of third party tooling written against it. The AWS and DigitalOcean comparison sets out where that trade falls.

Tiers, and the Cost Shape Behind Them

Every mature service splits capacity into tiers that trade storage cost against retrieval cost and retrieval speed. S3 offers Standard, Intelligent-Tiering, Standard-Infrequent Access, One Zone-Infrequent Access and the Glacier family. Azure Blob Storage has Hot, Cool, Cold and Archive. Cloud Storage uses Standard, Nearline, Coldline and Archive. OCI Object Storage has Standard, Infrequent Access and Archive.

The pattern repeats: colder tiers charge less per stored byte and more per read, and the coldest ones require a restore step before the data is readable at all. Minimum storage durations also apply, so an object deleted early can still be billed as though it had stayed.

Lifecycle rules automate the movement. A rule can transition objects past a chosen age into a colder tier, abort incomplete multipart uploads, and expire noncurrent versions. Write those rules on day one, because the cleanup nobody schedules becomes the line item nobody understands later.

Why Everything Speaks S3

The S3 REST interface became the de facto standard, so most competitors implement a compatible subset. In practice that means the same client libraries work everywhere once you override the endpoint and the region string.

With the AWS CLI, pointing at another provider is a flag: aws s3 ls --endpoint-url https://nyc3.digitaloceanspaces.com. Application SDKs take the same idea through a configuration object, and rclone treats every S3-compatible target as a remote you can sync between.

Compatibility is a subset, not a promise. Multipart upload, signed URLs and basic bucket policies are widely supported. Object Lock, cross region replication, encryption with customer managed keys and event notifications are where implementations diverge. Check the provider documentation before you depend on one, and read the S3 API reference to know what the baseline actually contains.

Amazon S3 now provides strong read-after-write consistency for new objects and for overwrites, which removed a long standing source of subtle bugs. Other implementations vary. If your code writes an object and immediately expects another process to read it, confirm that behaviour rather than assuming it.

Getting Data In and Out Without Opening the Bucket

The default posture on every serious provider is private. Leave it that way. Public buckets remain a common source of accidental data exposure, and the fix is almost never to make the whole container readable.

For downloads, generate a time limited signed URL. S3 calls them presigned URLs, Azure uses shared access signatures, Cloud Storage calls them signed URLs. The browser then fetches the object directly, your application never proxies the bytes, and the link expires on its own.

For uploads, issue a signed URL or a presigned POST policy that constrains content type and size, so the client talks to the bucket without holding a long lived credential. On the server side, prefer a role or workload identity over a static key pair. Where a static key is unavoidable, keep it in a secret store as described in the guide to managing API keys and secrets.

Turn on versioning for anything you would miss, and pair it with a rule that expires old versions. Versioning converts an accidental overwrite or a bad deploy into a recoverable event, which is why it belongs in the wider picture drawn by the cloud backup strategies article.

Common Questions