Files stored in BOS often undergo operations related to the file lifecycle, such as archiving, sinking, and deletion. Under normal circumstances, files are frequently read and accessed in the short term after creation. As time goes by, the number of reads for the file will decrease, and it will eventually become a “cold file”, meaning it is no longer accessed frequently. In the end, the file will be permanently deleted. If users manually maintain the data lifecycle, it is time-consuming and labor-intensive; but if they do not maintain it, the data will always be stored in standard storage, resulting in considerable costs. Therefore, BOS provides lifecycle management function to help users automatically complete the lifecycle management of data, realize the automatic management process of data from creation to archiving to deletion, thereby saving manpower and storage costs.

File lifecycle management method

• To make data management more user-friendly and intelligent, in addition to the Basic Lifecycle Management feature, BOS now supports Intelligent Tiering. This feature not only sinks files to appropriate tiers based on access frequency but also intelligently transitions files between "hot" and "cold" states according to their access patterns. It can automatically upgrade files to Standard Storage or Infrequent Access Storage, providing an optimal balance between storage costs and performance.
• In Basic Lifecycle Management, beyond the ability to customize rules using prefixes, it now supports features such as setting object tags (Tag), directory exclusion (Not), file size filtering (Filesize), and lifecycle management for object versions, allowing for more refined control over the lifecycle process.

Differences between intelligent tiering and basic lifecycle management

Method	Rule configuration	Suitable scenarios	Convert mode	Convert storage class
Intelligent tiering	One-click activation	Data with variable or unpredictable access patterns	Support data cooling down and warming up on demand	Do not support archive and multi-AZ storage classes, others are supported
Basic lifecycle management	Require custom management rules	1. Predictable access patterns 2. Need for fine-grained management	One-way cooling down	All supported (multi-version does not support archive temporarily)

Function description

A bucket can only be configured with either Lifecycle Management or Intelligent Tiering, and the two cannot be enabled simultaneously.

Intelligent tiering

• When Intelligent Tiering is enabled for a bucket, the system periodically monitors data access. If there is no access for an extended time, the data is moved to a lower-cost storage tier. If the data is accessed later, it will be returned to a high-frequency access tier to ensure optimal read performance.
• It supports files to be transferred from standard storage - infrequent access storage - cold storage or cold storage - infrequent access storage - standard storage;
• It can configure regular deletion of files and fragments (unfinished file fragments in multipart upload tasks), and supports deleting them after a specified number of fixed days. The starting time in the rule is calculated based on the creation time of the object. Deletion has higher priority than conversion, and deletion will be executed when it expires;
• After configuring the rules, you can monitor the volume of sinking and warming data for a single bucket via the bucket data analysis feature on the console.

Notes on intelligent tiering

• Do not support conversion to archive storage, standard storage - multi-AZ, infrequent access storage - multi-AZ;
• A bucket can only have one rule configured at a time.

Basic lifecycle

Basic Lifecycle Management supports the following functions

• Custom time to change storage classes, from standard storage to infrequent access storage, cold storage, archive storage; or from standard storage - multi-AZ to infrequent access storage - multi-AZ;
• Automatically delete data that is no longer needed at a scheduled time;
• Clear expired data from the three-step upload process.

Divided by scenarios, Basic Lifecycle Management supports two modes

• Automatic archiving of data after reaching a certain age: For example, define that all data created more than 30 days ago is automatically converted to infrequent access storage with lower storage costs;
• Automatically delete data when it reaches a certain age. For example, define that all data created more than 30 days ago is automatically deleted.

Divided by rule configuration, Basic Lifecycle Management supports simple and complex modes

• Simple mode: The defined rules only include the setting of the scope of effective files, which only configures the prefix or all files in the bucket (excluding multi-version objects);
• Complex mode: The rules include defining the effective scope of files, such as including files with specific object tags, excluding certain files, specifying file sizes, and managing the lifecycle of historical object versions.

Functions supported by complex lifecycle rule management

• Supports setting object tags and allows specifying tags to filter and delete objects.
• Supports excluding specific directories, filtering objects outside the directory, and specifying object tags.
• Supports defining file size thresholds and filtering objects for deletion within the specified size range.
• Set multi-version lifecycle rules, which support the deletion of historical versions.

Special reminder

The differences in execution logic between complex and simple lifecycle management modes for buckets are reflected in how files are converted and deleted.

• Simple mode: For conflicting simple rules, the “refined execution” logic is applied. For example: Rule 1 - Files in the a/b/ directory will be deleted 180 days after creation; Rule 2 - Files in the a/b/c/ directory will be deleted 365 days after creation. In this case, the file a/b/c/1.txt will be deleted 365 days after creation, while a/b/2.txt will be deleted 180 days after creation.
• Complex mode: For conflicting complex rules, the “global optimal execution” logic is applied, giving deletion higher priority. For example: Rule 1 - Files in the a/b/ directory (excluding historical versions) will be deleted 180 days after creation; Rule 2 - Files in the a/b/ directory will be deleted 365 days after creation but excludes the a/b/test/ directory. In this scenario, the file a/b/c/1.txt will be deleted 180 days after creation, and the file a/b/test/2.txt will also be deleted 180 days after creation.
• If a bucket has a complex rule created, the bucket lifecycle management will overall apply the complex rule execution

Notes on basic lifecycle

General notes

• Each bucket can have up to 1,000 rules;
• BOS lifecycle rules will take effect within one day after being set;
• After the rules take effect, BOS will process eligible objects accordingly, but the processing requires some time, so the results may not be immediately visible. Under normal circumstances, the time for sinking or deletion is a few hours, but if the amount of sinking data is large, it may take several days or even longer to complete the sinking or deletion;
• The time calculated in the rules (i.e., the "age" of an object) is based on the object's creation time, not the creation/modification time of the lifecycle rule;
• BOS only stores the last modified time of files, i.e., the last-modified time. If Meta is not updated or files are not overwritten, the last-modified time will be the creation time. Therefore, the "creation time" in the lifecycle is actually the last-modified time.
• Policies based on file access time are currently supported only in the Beijing and Suzhou regions.
• The minimum storage period for infrequent access, cold storage, and archive storage is 30, 60, and 180 days respectively. The lifecycle sinking/deletion rules you configure must adhere to these minimum storage durations. If your configuration is below the minimum duration, the console will prompt you with an error. Please adjust accordingly as per the prompt.
• Files of single AZ type can only be sunk to single AZ type files, and cannot be sunk to multi-AZ type files; Standard storage - multi-AZ type files can only be sunk to infrequent access storage - multi-AZ type files.
• When lifecycle sinking occurs, restoring the original storage type will incur restoration fees. Additionally, after sinking, the original file type will be deleted, which will result in a request fee. For instance, if a file from the infrequent access storage class is moved to cold storage, BOS will first retrieve the file from infrequent access storage, incurring a restoration fee. Once successfully moved to cold storage, the original file will be deleted, incurring a delete request fee that is part of the write request fees.
• Currently, lifecycle management does not support tier conversion for Appendable Objects created through append uploads.

Notes on complex lifecycle rules

• Tag rule settings: Each rule can define up to 10 object tags, with each key being ≤ 128 characters and each value being ≤ 256 characters long.
• Each rule has only one excluded directory. When the Not option is enabled, at least one of the prefix and tag must exist, that is, set both prefix and tag, or set only prefix or tag. There is only one prefix or tag in Not; the excluded prefix must be under the set prefix and have the same structure as the prefix. For example, if the prefix is bucket/prefix, the not prefix can be bucket/prefix1
• Specify the minimum file size for the lifecycle rule to apply. The minimum file size must be ≥ 0 bytes and < 5 TB.
• Specify the maximum file size for the lifecycle rule to apply. The maximum file size must be ≥ 0 bytes and < 5 TB.

Execution-level difference between simple and complex lifecycle rules:

• The simple lifecycle rule follows the longest prefix principle—once the longest prefix is matched, other rules are disregarded.
• The complex lifecycle rule determines the global optimal rule, identifying the earliest executable rule based on prefix, exclusions, file size, and tags.
• For more function details, refer to the Developer Guide - Basic Lifecycle Management.

Configuration method

1. Console operations

• For basic lifecycle, refer to Configure Basic Lifecycle Management;
• For intelligent tiering, refer to Configure Basic Intelligent Tiering.

2. Related API operations

• PutBucketLifecycle API: Use the PutBucketLifecycle API to create lifecycle management rules.
• GetBucketLifecycle API: Use the GetBucketLifecycle API to retrieve detailed information about defined lifecycle management rules.
• DeleteBucketLifecycle API: Use the DeleteBucketLifecycle API to delete defined lifecycle management rules.