Object Storage: How S3-Style Storage Works

Three kinds of storage

Block storage works like a disk that one server reads and writes in small blocks. File storage works like a shared folder. Object storage works like a huge key-to-file store. In the table, EBS, NFS and EFS are block and file services (Amazon Elastic Block Store, the Network File System, and Amazon Elastic File System). A data lake is a large store of raw data kept for later analysis.

The object model

• Bucket: a top-level container, like myapp-user-uploads.
• Key: the object's name, like users/42/avatar.jpg.
• Object: the data (from a few bytes up to many terabytes) plus metadata (information about the data, such as content type, size and custom tags).

There are no real folders. users/42/avatar.jpg is just a key that happens to contain slashes. Tools show it like folders by grouping keys with the same prefix (the first part of the key, such as users/42/).

You work with objects through a simple HTTP API (a set of web requests). PUT means save, GET means read and DELETE means remove:

PUT    /myapp-user-uploads/users/42/avatar.jpg     (upload)GET    /myapp-user-uploads/users/42/avatar.jpg     (download)DELETE /myapp-user-uploads/users/42/avatar.jpg     (delete)GET    /myapp-user-uploads?prefix=users/42/        (list keys)

Objects are usually replaced whole, not edited in place. To change one byte of a video, you upload the whole object again (or a new version).

Why it's so durable

Durability is the chance that your data is not lost over time. Object stores are designed so data is almost never lost:

• Each object is stored on many disks, in multiple data centres. An availability zone is one separate data centre (or group of them) inside a cloud region, with its own power and network.
• Many systems use erasure coding: data is split into pieces plus extra "parity" pieces, so the original can be rebuilt even if several pieces are lost. It's a bit like being able to finish a jigsaw even with a few pieces missing. It uses less space than keeping three full copies.
• Background processes constantly check for damaged copies and repair them.

Amazon S3 is designed for 99.999999999% durability ("eleven nines"). In practice, you're far more likely to lose data by deleting it yourself than through S3 losing it. That's why versioning and backups still matter.

Consistency

Consistency describes whether every reader sees the latest data. Since December 2020, Amazon S3 provides strong read-after-write consistency: after a successful upload or overwrite, any read gets the new version. Before that, you could sometimes read an old version shortly after updating. Other providers offer similar guarantees today, but check the documentation of the one you use.

Uploads and downloads without your servers

A key pattern: don't send file bytes through your app servers. Instead, use pre-signed URLs. A pre-signed URL is a temporary web link, signed by your server, that lets a client upload or download one specific object directly. The signature proves your server allowed it.

The benefits:

• Your servers never handle heavy file traffic, so they stay small and fast.
• Uploads scale with the storage service, not with your app.
• Files stay private. Only people with a valid, short-lived link can access them.

For large files, use multipart upload: split the file into parts (say 10 MB each), upload them in parallel (at the same time), and retry only failed parts. For video playback, clients can use range requests (HTTP requests that ask for only a byte range of a file) to download just the part they need.

Serving files to users

For public content (product images, avatars), put a CDN in front of the bucket (post 14). A CDN is a group of servers around the world that keep copies of files close to users. Users get fast, nearby copies, and you pay less for bandwidth. For private content, give out pre-signed download URLs, or have the CDN check access.

What goes in the database vs object storage

• Object storage: the file itself. users/42/avatar.jpg is 2 MB.
• Database: the metadata. Who owns it, the key, size, type, upload time, maybe a thumbnail key.

photos table
┌────┬─────────┬───────────────────────────────┬────────┬─────────────┐
│ id │ user_id │ storage_key                   │ size   │ uploaded_at │
├────┼─────────┼───────────────────────────────┼────────┼─────────────┤
│ 17 │ 42      │ users/42/photos/17-orig.jpg   │ 2.1 MB │ 2026-11-01  │
└────┴─────────┴───────────────────────────────┴────────┴─────────────┘

Why not store images as BLOBs in the database?

• They make the database huge, backups slow, and replicas expensive.
• They waste the database's precious memory and I/O (reading and writing the disk) on data that doesn't need queries or transactions (groups of changes that succeed or fail together).
• Object storage is much cheaper per GB and built for exactly this.

Storage classes and lifecycle rules

Not all files are used equally. Object stores offer storage classes at different prices:

• Standard: frequently accessed. Higher storage price, cheap to read.
• Infrequent access: cheaper storage, but a fee each time you read.
• Archive (like S3 Glacier): very cheap storage, but retrieval can take minutes to hours (some archive classes are faster).

Lifecycle rules are rules you set that move or delete objects automatically. For example: "move logs to infrequent access after 30 days, to archive after 90 days, and delete after 7 years". This can cut storage bills a lot.

Other useful features

• Versioning: keep old versions when objects are overwritten or deleted. It protects against accidents.
• Event notifications: a message such as "a new object was uploaded", which triggers a function or queue to create thumbnails, scan for viruses or transcode videos (convert them to other formats and sizes).
• Encryption at rest: the stored data is scrambled so it is unreadable without a key. This is usually on by default.
• Access policies: control who can read and write each bucket.

How an S3-like system is built (simplified)

          ┌──────────────────┐
Client ──►│  API / front end │  auth, routing
          └───┬─────────┬────┘
              ▼         ▼
   ┌────────────────┐  ┌──────────────────────┐
   │ Metadata store │  │   Data nodes         │
   │ key → location │  │ (disks storing       │
   │ size, version  │  │  object pieces,      │
   └────────────────┘  │  replicated/erasure- │
                       │  coded across zones) │
                       └──────────────────────┘

• The metadata service (the part that stores information about objects) is like a giant index: "users/42/avatar.jpg is stored as pieces on nodes 17, 203 and 881".
• The data nodes store the actual bytes.
• Separating them lets each scale independently, which is the same design idea behind many large storage systems.