Skip to main content

Features

What an Object Storage bucket can do, and the rules that govern each capability.

S3 Compatibility​

Object Storage is backed by a real EOS bucket, so any S3-compatible tool works against it: mc, s3cmd, s3fs, the AWS SDKs, and anything else that speaks the S3 API. The bucket's Setup tab gives you the endpoint, access key, and secret key, along with ready-made configuration commands for MinIO Client and s3cmd.

Each bucket gets its own access key pair, scoped to that bucket.

Unified Storage Access​

Buckets mount read-only on Instances (containers), Virtual Machines, and Slurm clusters. Writes have to go through an S3 client or, on an Instance or Virtual Machine, to a Block Storage disk mounted alongside.

The mount path depends on the workload:

  • Instances and Virtual Machines always mount the bucket at /datasets/<alias>, where <alias> is the bucket's alias.
  • Slurm clusters mount it at a path you choose. Enter it next to the bucket when you create the cluster, or mount a bucket later from a running cluster's Volumes tab. The path follows the Slurm cluster mount path rules, and from the Volumes tab /datasets and paths under it, /home/jovyan, and /mnt/local are also refused.

Encryption​

Encryption at rest is set when the bucket is created and cannot be changed afterwards.

TypeWho holds the keyWhen to use it
E2E Managed (SSE-KMS)E2EThe default. No key handling on your side.
User Managed (SSE-C)YouCompliance requirements that demand key ownership.
Key loss is data loss

With User Managed encryption, E2E does not hold a copy of your key. If you lose it, the data cannot be recovered. See the user-managed encryption guide for how to read encrypted objects.

Encryption is free of cost for both types. Traffic to and from EOS is secured with TLS.

Object Versioning​

With versioning on, uploading an object under an existing name creates a new version instead of replacing the old one. Every version keeps its own version ID, size, and timestamp, and can be downloaded or deleted individually.

Versioning can be turned on at creation or any time afterwards from the Object Versioning action. Turning it off suspends it: no new versions are created, but existing ones stay in place.

Key rules:

  • The bucket must be in a Ready state before versioning can be changed.
  • Versioning cannot be suspended while object lock is enabled — a locked bucket requires it.
  • Every version is stored and billed. Use a lifecycle rule to keep old versions from piling up.

Object Lock​

Object lock enforces write-once-read-many (WORM) retention: a locked object version cannot be overwritten or deleted until its retention expires. It comes in two independent forms.

Governance lock applies a retention period in days. It can be set as a bucket default — so every new upload inherits it — or on one object version at a time. Project owners and admins can bypass it; other users cannot, and they can only extend a retention period, never shorten it.

Legal hold is an indefinite lock on a single object version. It does not expire and must be cleared explicitly. A version under legal hold cannot be deleted even after its governance retention has run out.

Enable it at creation

Object lock can only be turned on while the bucket is being created. Enabling it also turns versioning on permanently. A bucket created without it has to be recreated to get it.

A bucket with locked versions cannot be emptied or fully deleted until those locks are cleared.

Lifecycle Rules​

A lifecycle rule deletes objects automatically after a set number of days, which keeps temporary data from accumulating. Rules apply either to every object in the bucket or only to objects under a prefix such as logs/ or temp/, and you can run several rules with different prefixes side by side.

Lifecycle rules are available on buckets TIR created. A pre-existing EOS bucket attached to TIR does not show the tab, because TIR does not manage that bucket's policies.

Deletion is irreversible

Objects removed by a lifecycle rule cannot be recovered. Governance-locked versions are protected from lifecycle deletion until their retention expires.

Presigned URLs​

A presigned URL grants time-limited access to one object path without handing over credentials. Generate a Download URL to let someone fetch an object, or an Upload URL to let an external application write one directly into the bucket.

  • Expiry runs from 1 minute to a maximum of 7 days.
  • The URL is shown once. If it is lost, generate a new one.
  • Several URLs can be live at the same time, each with its own expiry.

Replication​

Replication copies new objects from this bucket into a bucket in another region, which gives you a cross-region copy of incoming data.

Conditions:

  • The destination must be a bucket in the same project, in a different region.
  • Versioning must be enabled on both the source and the destination.
  • The encryption settings of both buckets must match.
  • A bucket can take part in only one rule on each side — no fan-out, chains, or two-way replication.

Data Importing​

To bring data in from another cloud, use Data Syncer, which writes directly into an Object Storage bucket. For local data, use the portal uploader or an S3 CLI — see the Quick Start.

Best Practices for Object Storage

Pick the right type

Use Object Storage for large, shared, or growing data. Use Block Storage only when a workload needs read-write access or low-latency random reads.

Decide lock at creation

Object lock can only be enabled while the bucket is being created. If the data may ever need WORM retention, enable it up front.

Pair versioning with lifecycle

Every version is stored and billed. Add a lifecycle rule so old versions do not accumulate indefinitely.

Guard your keys

Share the access and secret key only with people who need them, and prefer a short-lived presigned URL for one-off sharing.

Last updated on October 19, 2026.