Bucket object lifecycles
With object lifecycles, you can configure automatic actions on individual objects or groups of objects in a bucket at specified points in time.
Note
In buckets with logging enabled, actions performed on objects as part of the object lifecycle are not logged.
Types of actions include:
-
Change the storage class of objects or their non-current versions to a colder one. You can configure the change to the
ICEclass using the Yandex Cloud CLI, AWS CLI, Terraform, and the API.Warning
Changing the storage class for already uploaded objects is charged as a
TRANSITIONoperation. For more information, refer to Data operations in the Object Storage pricing policy. -
Delete objects or their non-current versions.
-
Delete incomplete multipart uploads.
-
Delete non-current delete markers (only using the Yandex Cloud CLI, Yandex Cloud REST, and Yandex Cloud gRPC).
Tip
If you do not want to configure lifecycle rules manually, use INTELLIGENT_TIERING storage that automatically optimizes costs by moving objects across access tiers based on access frequency.
Filters for grouping objects include:
- Object key prefix.
- Minimum or maximum object size.
- Object label; unavailable in the management console.
- AND logical operator that allows you to group objects using a combination of multiple filters.
You can only specify one filter per lifecycle rule. To specify more than one filter type for a lifecycle at a time, use the logical AND. For more information, see Lifecycle configuration.
If you use the S3 API, specify the lifecycle configuration in XML format. Various tools with the S3 API support may require other configuration formats. The AWS CLI, for example, uses the JSON format.
You can only configure object lifecycles for each individual bucket, not for a bucket group, folder, or cloud.
Object lifecycles are updated daily at 00:00 UTC. This operation takes a few hours to complete.
Useful links
The non-current object version that has been deleted gets marked by a non-current delete marker (NoncurrentDeleteMarker). This happens when a new object version is loaded on top of a deleted one. In which case the object becomes available again, and the marker which used to mark the deleted version moves to the version history.