Object Storage tiers and lifecycle: two redundancy classes, no archive tier
Quick answer
Worldstream Object Storage has two tiers, and both are redundancy classes: Distributed Storage and Geo-Redundant Storage. There is no cold or archive tier and no Glacier-style product, so there is no cheaper tier to age data into and no transition rule to write. Archiving is something you do on Object Storage, not a separate storage class you buy.
Two tiers, both about redundancy
When people say "tier" in object storage they usually mean one of two different things. One is access frequency: hot data on fast storage, cold data on something cheaper and slower. The other is redundancy: how many copies exist and what failure they survive. Worldstream Object Storage only has the second kind.
| Tier | What it protects against | Positioned as |
|---|---|---|
| Distributed Storage | Redundant servers, disks and network within one datacenter. Becomes read-only if that datacenter is lost. | Standard |
| Geo-Redundant Storage | Multi-site replication. Can survive a full datacenter outage. | Premium |
You pick one per project, at the moment you create the project, and both are currently offered in the eu-west-1 region. Reads and writes behave the same way on both. Nothing about either tier makes your data slower to retrieve or holds it behind a restore step.
What changes if you come from Amazon S3
On Amazon S3 you would expect a ladder of storage classes, Standard through Infrequent Access down to Glacier, with lifecycle rules stepping objects down that ladder as they age. Worldstream Object Storage has no equivalent ladder. There is no archive class, no cold class, and nothing that requires a restore before you can read an object again.
That has two practical consequences. First, a transition rule has nowhere to send an object, so the cost pattern of "keep it, but cheaply" does not exist as a product feature here. Second, you never get caught by the other side of that bargain: no retrieval delay, no restore request, no surprise when the compliance archive you have not touched in three years is suddenly needed today.
"Archival" on Worldstream Object Storage is a use case, not a storage class. Long-term archives live on the same storage as everything else, and you choose a redundancy class for them like you would for anything else. If you are planning a move, Migrating from AWS S3 to Worldstream Object Storage covers the rest of the differences.
Lifecycle rules on Object Storage
One thing is certain: no lifecycle rule can move an object to a cheaper tier, because there is no cheaper tier to move it to. Anything you have written on another platform that transitions between storage classes has no counterpart here.
Which lifecycle rules the S3-compatible API does accept, expiry rules included, is not documented in this knowledge base, and guessing at it would cost you a deployment. Check Portal's own Object Storage CLI & SDK guide under Support → Documentation for the current picture, or open a support ticket, before you build a policy that your cleanup depends on.
Test the policy, don't assume it: Coverage of the wider S3 API surface varies. If you do apply a lifecycle configuration, read it back with
aws s3api get-bucket-lifecycle-configurationand confirm the platform kept what you sent, rather than assuming a call that did not error did what you meant.
Managing data growth without a cold tier
Without tiering, the levers that are left are the ordinary ones, and they work:
| Lever | How it works here |
|---|---|
| Delete what you no longer need | On Pay per use you are billed on what you actually store, so removing data you have aged out is the most direct saving available. |
| Run retention where the data is produced | Let your backup tool or log shipper expire its own old generations rather than expecting the bucket to do it for you. |
| Split by redundancy class | Nothing stops you running one Geo-Redundant project for what must survive a site loss and a Distributed project for what does not. That is the closest thing to a tiering decision available. |
| Lock what must not be deleted | Object Lock is set when you create a bucket and cannot be disabled afterwards. It is the right tool for a compliance archive, and it is a decision you make before the first object lands. |
How long to keep which backup generation is a separate question from where it sits. How many backups do you actually need? A retention strategy guide covers the retention side.
Next step: open Object Storage in Portal, check which redundancy class your existing projects use, and if the split is wrong for what you are storing, create a second project with the other class. Bucket and key defaults per project are listed in Object Storage limits and quotas explained.