Object storage (S3-style buckets)
Object storage is a place to keep files -- photos, backups, videos, app downloads -- without renting a whole server to hold them. The customer drops files into a "bucket" and pulls them back out by name. You bill them for how many gigabytes they store and how many requests they make, so a quiet archive costs almost nothing and a busy photo site pays its way.
Real buckets are read-heavy: lots of GETs (download this photo), a trickle of PUTs (save this one). That shapes the bill and the load -- a backup tenant writes huge blobs at night and almost never reads them, while a photo app reads constantly. Great for static website assets, user uploads, and anything you want close to a CDN.
Customers trust you with the only copy of a wedding album or a year of backups, so durability matters more than speed. Object storage keeps several copies of each file on different machines -- that's the replication factor. More copies means the data survives a server dying; it also means you pay to store the same bytes more than once.
Detailed explanation
Storage billed at logical_GB x replication_factor; requests billed per-operation. Workload is overwhelmingly GET-dominant (a photo tenant ~85% GETs at ~800 KB; a backup tenant ~10% GETs at 64 KB). Egress on reads is the variable cost that bites -- pairing a bucket with a CDN edge collapses origin egress by serving hot objects from cache.
DurabilityTier maps to replication factor: Standard=1, High=2, Mission=3. A bucket survives N-1 host failures. Real S3 uses erasure coding for the same durability at lower overhead (deferred). The data-loss event is the one churn trigger these tenants never forgive -- a Mission-tier backup provider lost-data once is gone for good, so right-size the replication factor to the tenant, not the cheapest option.