What is object storage? S3-compatible storage, explained

Object vs file vs block storage

Block storage is a raw disk: fast, attached to one machine, and the unit your database wants. File storage (NFS and friends) is a shared folder tree: familiar, but locking and metadata become the bottleneck as it grows. Object storage drops the tree entirely — every object lives in a flat namespace inside a bucket, addressed by a key like "invoices/2026/08/1234.pdf". That key looks like a path, but it is just a name; nothing has to be "inside" anything.

That one design choice is why object storage scales so calmly. There is no directory to lock, no filesystem to fsck, no volume to resize. You pay for what you store, and the store grows from megabytes to terabytes without a migration. The trade-off: objects are replaced whole, not edited in place, and there are no POSIX semantics — which is exactly why it is the wrong home for a live database and the right home for nearly everything else your app serves or archives.

What "S3-compatible" actually means

Amazon S3 shipped in 2006, and its HTTP API became the de-facto standard for object storage the way SQL did for databases. An S3-compatible service implements that same API, so the entire ecosystem built for S3 — AWS CLI, every language SDK, rclone, restic, MinIO's mc, backup plugins, static-site deployers — works against it unchanged. You point the tool at a different endpoint URL and keep your muscle memory.

This is the practical meaning for you: no vendor lock-in at the tooling level. Code written against the S3 API moves between providers by changing two lines of configuration — the endpoint and the credentials. It also means you can test locally against one S3 implementation and deploy against another without touching application code.

Buckets, keys and endpoints — the three words that matter

A bucket is the top-level container, and its name is unique within the service — think of it as the "drive" you create per project or per purpose (uploads, backups, assets). An access key pair is how a program authenticates: the access key ID identifies it, the secret key signs each request. Treat the secret like a password — it is shown once at creation, so store it in your secret manager, not in code.

The endpoint is the URL the S3 API lives at. On AWS it is region-shaped (s3.eu-central-1.amazonaws.com); on other providers it is theirs — on cdn.com.tr it is s3.cdn.com.tr. Every S3 tool accepts an endpoint override; that single flag is what "S3-compatible" looks like in practice.

The same AWS CLI you already know — only the endpoint changes

# create a bucket
aws --endpoint-url https://s3.cdn.com.tr s3 mb s3://app-uploads

# upload and list
aws --endpoint-url https://s3.cdn.com.tr s3 cp ./photo.jpg s3://app-uploads/2026/photo.jpg
aws --endpoint-url https://s3.cdn.com.tr s3 ls s3://app-uploads/2026/

# sync a whole folder (deploys, backups)
aws --endpoint-url https://s3.cdn.com.tr s3 sync ./public s3://app-uploads/site

What to put in it (and what to keep out)

Object storage earns its keep wherever files are written once and read many times: user uploads and media, images and video, build artifacts and release downloads, log archives, database dumps and backups, and the static half of your website. It is also the natural place for anything you must keep but rarely touch — the storage equivalent of a well-organised warehouse.

Keep out anything that needs in-place edits or locking: live database files, hot caches with sub-millisecond expectations, and files a process appends to continuously. Those belong on block storage or in a managed database; object storage picks up the durable artifacts they produce.

Why a CDN belongs in front of public objects

Storage and delivery are different jobs. Storage keeps the canonical copy durable; a CDN answers the same request thousands of times from edge locations near your users. Serve a popular file straight from any storage backend and every download travels to the origin; put an edge in front and the origin answers roughly once per unique file while the edge absorbs the crowd.

On cdn.com.tr the two are parts of one platform: buckets can be bound to your container apps, and public content is served through the same global edge that fronts the rest of your account — one panel, one bill, no cross-provider egress surprise between your storage and your CDN.

The mistakes that cost people money

Three patterns account for most object-storage pain. First, the public bucket: leaving a bucket world-readable when it holds private data. Default to private, make individual prefixes public only when they are meant to be. Second, serving high-traffic files directly from storage on providers that bill egress per gigabyte — that invoice grows with your success; an edge cache in front flattens it. Third, credentials in code: a leaked secret key is a full-access token to everything in the account. Use per-purpose keys, keep them in environment variables or a secret manager, and rotate any key you even suspect has leaked.