Photos uploaded by users, backups, log files, videos, generated documents: much of a modern application's data lives neither in a database nor on a server's disk, but in object storage. It is the most used storage service in the cloud, cheap and almost unlimited, but it works differently from a traditional disk, and some configuration mistakes are among the most frequent causes of data leaks.
What object storage is
In object storage data is saved as objects inside containers called buckets. Each object has three components:
- a key, that is its full name, such as
invoices/2026/march/0042.pdf; - the actual data;
- metadata, such as content type, date and custom tags.
The slashes in the key look like folders, but they aren't: the namespace is flat, and "folders" are just a way of displaying common prefixes. Objects are read and written through HTTP APIs, not by mounting a disk.
The interface introduced by Amazon S3 has become a de facto standard: many other providers and various self-hosted software products offer S3-compatible APIs, so the same tools and libraries work with different services.
Differences from disks and file systems
| Aspect | Block disk | Network file system | Object storage |
|---|---|---|---|
| Access | Mounted on one machine | Mounted on several machines | Via HTTP API from anywhere |
| Partial modification of a file | Yes | Yes | No, the whole object is rewritten |
| Capacity | Fixed, to be sized | Large | Practically unlimited |
| Cost per gigabyte | High | Medium | Low |
| Suited to | Databases, operating system | Files shared between servers | Static files, backups, archives, data for analysis |
Object storage is not suited to data that changes continuously in small parts, such as database files. It is, however, ideal for files written once and read many times.
Storage classes
Providers offer several classes priced according to expected access frequency:
- standard: for frequently used data, with the highest storage cost and no retrieval cost;
- infrequent access: cheaper storage, but you pay for every read and there is often a minimum storage duration;
- archive: very low cost, but retrieval can take minutes or hours and is charged.
Lifecycle rules automatically move objects between classes based on age, and delete expired ones. A typical rule for backups: standard class for thirty days, then archive, then deletion after a year.
Features to enable
Versioning
With versioning enabled, overwriting or deleting an object doesn't destroy it: the previous version remains recoverable. It protects against human error and programs that overwrite files by mistake. It should be paired with a rule that deletes old versions after a certain period, otherwise the space used grows without limit.
Object locking
For backups, object locking prevents changes and deletions until a set date, even by administrators. It is an effective defense against ransomware and against anyone who obtains credentials with delete permissions.
Encryption
Most services encrypt data at rest by default. For particularly sensitive data you can use keys managed by you, so the provider cannot decrypt it without your consent.
The most serious mistake: the public bucket
Many well-known data leaks originated from a bucket configured to be readable by anyone. Often the reason was trivial: serving a few images for a website, and for convenience the whole container was made public, including documents and backups that were never meant to be.
The rules to avoid it:
- Keep buckets private by default and enable account-level public access blocking, if the provider offers it.
- Separate public and private content into different buckets, never in the same one with mixed permissions.
- Serve public files through a CDN that reads from the bucket with its own credentials, instead of exposing the bucket directly.
- Use signed URLs to grant temporary access to a private file, for example to download an invoice: the link works only for a few minutes and only for that object.
- Give applications minimal permissions: a service that uploads photos doesn't need to read backups or delete objects.
Other practical details
- Request costs: besides space, operations are often charged. Millions of tiny files can cost more in requests than in storage.
- Outbound traffic: downloading large amounts of data to the Internet or another provider can be the largest item on the bill.
- Listing objects: listing buckets with millions of objects is slow. It pays to design keys with meaningful prefixes, such as date or customer identifier.
In my work, when I analyze an existing infrastructure, checking bucket permissions is among the first checks: it takes a few minutes and uncovers serious problems more often than you might think.
In short
- Object storage saves objects in buckets accessed via HTTP APIs, often S3-compatible.
- It is ideal for static files, backups and archives, not for data that changes in small parts.
- Storage classes and lifecycle rules reduce the cost of rarely used data.
- Versioning, object locking and encryption protect against mistakes, ransomware and unwanted access.
- Keep buckets private, separate public content and use CDNs and signed URLs to share files.
