What object storage actually promises

Foundation⏱ ~16 mins3cmdaws

What you'll learn

State the object storage contract precisely
Contrast it with file and block semantics
Identify workloads that fit and workloads that do not
Explain why the constraints enable the scale

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

Teams arriving from filesystems try to use object storage as one, and are frustrated by the missing operations. The operations are missing deliberately — each one that is absent is a distributed-systems problem that does not have to be solved, and that is why object storage scales the way it does.

The contract

Operation	Semantics
`PUT`	store an object under a key, replacing any existing one
`GET`	retrieve an object by key
`DELETE`	remove an object by key
`HEAD`	retrieve metadata without the body
`LIST`	enumerate keys in a bucket, optionally by prefix

Each object is an opaque blob plus user metadata. There is no append, no partial in-place update, no rename, no directory, and no lock.

What you give up, and what it buys

Missing	Why it is absent	What it enables
Partial writes	would require coordinated locking	whole-object writes replicate simply
Rename	would need an atomic multi-key operation	keys are independent
Directories	hierarchy needs a consistent tree	flat namespace shards freely
Locking	distributed locks are expensive and fragile	no lock manager to fail
Append	needs a coordinated offset	writers never contend

Every absence removes a coordination point. That is the whole reason a single bucket can hold billions of objects served by any number of gateways.

Metadata

aws s3api put-object --bucket data --key report.pdf --body report.pdf \
    --metadata project=alpha,retention=7y --content-type application/pdf

aws s3api head-object --bucket data --key report.pdf

User metadata is stored with the object and returned on HEAD. It is limited in size and is not indexed — you cannot query by it, only retrieve it once you know the key.

Workload fit

Workload	Fit
Media, backups, archives	excellent
Static web assets	excellent
Data lake and analytics source data	excellent
Container image layers	excellent
Database storage	no — needs partial writes
Shared home directories	no — needs rename and hierarchy
Build scratch space	no — needs modify in place

Quiz

Knowledge check · 4 questions

Q1. How is renaming an object performed in S3-compatible object storage?

By copying the object to the new key and deleting the old one — real data movement With a rename operation on the key, which the gateway performs in the bucket index By updating the object's user metadata, since the key is held there as an attribute Rename is not possible at all, so an object's key is fixed for the object's lifetime
Q2. User metadata attached to an S3 object can be queried to find objects matching a value.

True False
Q3. Advise a team porting an application to object storage.

A team wants to move an application from NFS to S3-compatible object storage. The application maintains working files that it appends to throughout a job, renames on completion, and occasionally modifies in place.
Q4. Why does the absence of partial writes make cross-site replication tractable?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Assess a workload against the five operations object storage provides before committing to it; applications relying on append, rename, or in-place modification need a design change rather than a configuration one. Where the fit is poor, using object storage for completed output while keeping working state on a filesystem is usually the practical answer.

Cross-course references

Kubernetes: an immutable ConfigMap replaced wholesale follows the same value-not-mutation model
Linux: content-addressed stores achieve their properties through the same immutability