Object storage

Amazon S3 is the interface most tools copy. You put an object under a key in a bucket. You get it back by that key. You do not open it and seek around it as you would a file on a mounted disk.

That shape is why large transfers land here. A client can PUT an object, or send it in parts and complete it when every part has arrived. A second client can GET the same key, often through a signed URL, without an account on the sender's machine. The sender's laptop can sleep after the upload. The object remains until a lifecycle rule or a delete removes it.

A lab writes `studies/2026-10/scan-14.dcm` as one 8 GB object in a bucket in one region. The uploader uses a multipart upload: 80 parts of 100 MB, completed with a final call that assembles the key. A reviewer in another office downloads through a presigned URL. There is no shared folder and no SMB mount. If the lab overwrites the key, the old bytes are gone unless versioning was on. A filesystem copy would have left a previous filename. An object store does not, unless you asked for versions.

Object storage is not block storage. Block storage is a disk volume a server formats and mounts. It is not a file share with locks and byte-range edits in place. You typically replace an object; you do not patch the middle of it. Blob storage is the same pattern under another vendor's name. Treat "blob" and "object" as the same idea unless a contract names a specific API.

Encryption at rest is a property of the bucket or of the client before the PUT. The object model does not imply it. Region is a placement choice, not a transfer protocol. A bucket in another country still needs an upload path, a download path, and a rule for who may sign URLs.