Object storage is the dominant storage model for cloud-native applications. AWS S3, Google Cloud Storage, and Azure Blob Storage all implement the same core idea: store data as objects in flat namespaces called buckets, and access each object by a unique key over HTTP. There is no directory hierarchy, no file locking, and no in-place mutation. An object is a blob of bytes plus metadata, retrieved or replaced as a whole unit.

The Key-Value Model

Every object has a key (a string like images/profile/user-42.jpg) and a value (the raw bytes). The slash in the key is cosmetic. S3 does not have folders. The key is a flat lookup in a distributed hash table. This is why S3 can store trillions of objects without degrading performance: there is no directory tree to traverse, no inode table to scan. Each GET request maps a key to a storage location in constant time.

1PUT /my-bucket/images/profile/user-42.jpg   -> Store object
2GET /my-bucket/images/profile/user-42.jpg   -> Retrieve object
3DELETE /my-bucket/images/profile/user-42.jpg -> Remove object
4HEAD /my-bucket/images/profile/user-42.jpg   -> Get metadata only

This simplicity is the point. Object storage does not support append, partial read (range requests aside), or rename. You cannot open a file, seek to byte 1000, and overwrite 50 bytes. To change an object, you upload the entire new version. This constraint enables massive scale: objects are immutable once written, which means they can be replicated, cached, and distributed without coordination locks.

Durability and Availability

S3 Standard delivers 99.999999999% durability (11 nines). That means if you store 10 million objects, you statistically lose one object every 10,000 years. AWS achieves this by automatically replicating each object across at least three Availability Zones within a region, using erasure coding to reconstruct data from partial replicas.

Availability is different from durability. S3 Standard offers 99.99% availability (about 53 minutes of downtime per year). Your data is safe (durable) but the service might be temporarily unreachable (unavailable). Design your application to handle transient 503 errors with exponential backoff.

Object Versioning

Versioning is a safety net against accidental deletions and overwrites. When you enable versioning on a bucket, every PUT to the same key creates a new version instead of replacing the old one. A DELETE does not remove the object. It inserts a delete marker as the latest version. The previous versions remain intact and recoverable.

This protects against human error (someone runs a script that deletes the wrong prefix) and application bugs (a deployment writes corrupt data over valid objects). To restore, you delete the delete marker or copy a previous version to the current key. The cost is storage: every version occupies space. Combine versioning with lifecycle rules to expire old versions after a retention period.

Pre-Signed URLs

Your application server should not proxy large file uploads and downloads. Pre-signed URLs let clients interact directly with the object store, bypassing your servers entirely. The server generates a URL containing a cryptographic signature, an expiration time, and the allowed operation (GET or PUT). The client uses this URL to upload or download directly to S3.

This pattern eliminates your application server as a bandwidth bottleneck. A server generating pre-signed URLs consumes almost no CPU or memory. The heavy lifting (transferring gigabytes of video) happens between the client and S3 directly. The URL expires after the configured duration (typically 15 minutes to 1 hour), so even if it leaks, the exposure window is small.

Multipart Upload

For objects larger than 100 MB, multipart upload is essential. You split the file into parts (5 MB to 5 GB each), upload them in parallel, and S3 assembles them into a single object. If one part fails, you retry only that part, not the entire upload.

The workflow has three API calls: CreateMultipartUpload returns an upload ID, UploadPart sends each chunk with its part number, and CompleteMultipartUpload tells S3 to assemble the parts. If the upload is abandoned, the parts remain as incomplete fragments consuming storage. Configure a lifecycle rule to abort incomplete multipart uploads after a set number of days to avoid phantom storage costs.

Cross-Region Replication

For disaster recovery and low-latency global access, cross-region replication copies objects asynchronously from a source bucket in one region to a destination bucket in another. When a user in Tokyo uploads a photo to us-east-1, replication copies it to ap-northeast-1 within minutes. If the US East region goes down, your application can failover to the Tokyo copy.

Replication is asynchronous, so there is a lag (typically seconds to minutes). It does not provide strong consistency across regions. If your application reads from the replica immediately after writing to the source, it may get stale data. Design for eventual consistency: use the source region for writes and the replica for reads, or accept that cross-region reads may lag.