Object storage is where most of a system's bytes end up: photos, videos, backups, logs, data lake tables, model weights. S3 defined the model, and Cloud Storage and Azure Blob Storage follow it closely: flat buckets of keys, objects written whole, HTTP access, and storage so durable you plan around cost rather than loss. The Object storage lesson covers the basics, and the S3 lab designs one.
On this page: where the three differ in ways that change a design (consistency, request limits, storage classes, conditional writes), what bites in production, and who left object storage for their own hardware and why.
Side by side
| AWS | Google Cloud | Azure | Self-hosted | |
|---|---|---|---|---|
| Service | Amazon S3 | Cloud Storage | Blob Storage | Ceph (RADOS Gateway), Garage, or S3-compatible appliances; MinIO's open-source repository was archived in 2026 |
| Consistency | Strong read-after-write for PUT, DELETE and listing | Strong for object reads, writes, deletes and listing | Strong, with snapshot isolation for reads | Depends on the system |
| Largest object | About 48.8 TiB (multipart) | 5 TiB | About 190.7 TiB (block blob) | Varies |
| Request limits | 3,500 writes and 5,500 reads a second per prefix, scaling with more prefixes | One write a second to the same object name | Up to 3,000 requests a second to a single blob; hot partitions return 503 | Your hardware |
| Cold classes (minimum stay) | Standard-IA and Glacier Instant Retrieval (30 and 90 days), Deep Archive | Nearline 30, Coldline 90, Archive 365 days | Cool 30, Cold 90, Archive 180 days | Your own tiers |
| You pay for | Storage per GB-month, requests, retrieval from cold classes, data out | Same shape | Same shape | Disks, servers, power, people |