---
title: "Features"
description: "Versioning, object lock, lifecycle rules, presigned URLs, and encryption for Object Storage buckets"
---
import { ObjectStorageFeaturesNav, ObjectStorageBestPracticesCard } from './ObjectStorageCards'
# 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](/docs/tir/block-storage/) disk mounted alongside.
The mount path depends on the workload:
- **Instances and Virtual Machines** always mount the bucket at `/datasets/`, where `` 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](/docs/tir/SlurmCluster/manage/storage#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.
| Type | Who holds the key | When to use it |
| :--- | :--- | :--- |
| **E2E Managed** (SSE-KMS) | E2E | The default. No key handling on your side. |
| **User Managed** (SSE-C) | You | Compliance requirements that demand key ownership. |
:::danger 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](https://docs.e2enetworks.com/docs/myaccount/storage/object_storage/EOSEncryption/create_encrypted_eos/#option-2-encryption-through-user-managed-keys) 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.
:::warning 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.
:::danger 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](/docs/tir/DataSyncer/), which writes directly into an Object Storage bucket. For local data, use the portal uploader or an S3 CLI — see the [Quick Start](./QuickStart.mdx#upload-your-first-objects).
---