Object storage looks simple from the outside — put a file in, get it back by name — but the architecture underneath is what makes it scale to petabytes cheaply and survive hardware failure. Here's a clear tour of how it's actually built.

The building blocks

Objects

The unit of storage. An object is a blob of data plus its metadata (content type, size, custom key-value tags) plus a unique key. Unlike a file, you generally write or replace a whole object rather than editing it in place — which is exactly why object storage suits write-once, read-many data.

Keys and the flat namespace

Every object lives under a key — its unique name within a bucket. Crucially, the namespace is flat: there are no real folders. A key like photos/2026/beach.jpg looks hierarchical, but the slashes are just part of the name. Providers let you list by prefix (photos/2026/) to imitate folders, but under the hood it's one big namespace, which is part of what lets it scale without a filesystem's limits.

Buckets

A bucket is a top-level container for objects, with a name, a location (region), and policies — access control, versioning, lifecycle rules. Buckets are where you set the rules that apply to everything inside them.

The API layer

You never touch the disks directly. Everything goes through an HTTP API — and in practice, the S3 API, the de-facto standard. PUT, GET, DELETE, LIST, multipart uploads for big objects, presigned URLs for sharing, and operations for versioning and lifecycle. Because this API is standard, your tools work against any compatible provider.

How durability is built in

Behind the API, the data is stored across a distributed system: each object is spread across many nodes via replication or erasure coding, across independent failure domains, with continuous integrity checking and self-healing. That's what produces the high durability figures providers quote. (For the details, see how distributed object storage keeps data safe.)

Features that ride on the architecture

• Versioning — keep previous versions of an object, so you can roll back an accidental overwrite or delete.
• Lifecycle rules — automatically move objects to colder tiers or expire them after a set time.
• Presigned URLs — grant temporary, scoped access to a single object without exposing credentials.
• Access policies — control who and what can read or write each bucket.

Why the architecture matters when choosing a provider

Because the architecture (flat namespace, S3 API, distributed durability) is shared across providers, the things that actually differ are operational: egress cost, data residency, feature depth, and support. That's where your decision really lives.

Internetport's object storage gives you the standard architecture — S3 API, buckets and keys, redundant distributed storage — with EU data residency, no egress fees, and a free 10 GB tier. For the full evaluation, start with choosing an object storage provider.