Docs

Torch Object Storage

Managing lifecycle

Configuring lifecycle rules based on last access time

With TOS, you can configure lifecycle rules based on when an object was last accessed (last access time). You can instruct TOS to automatically move an object to the most cost-effective storage type when it remains unaccessed for a preset number of days. This approach allows for intelligent data tiering, helping you identify cold data and reduce storage costs. This topic introduces the use cases, notes, and steps for configuring lifecycle rules based on last access time.

Use cases

Both Intelligent Tiering and lifecycle rules allow you to transition objects based on their access frequency to reduce storage costs. However, these features are mutually exclusive and cannot be configured simultaneously. They also differ in implementation and use cases. See below for a detailed explanation of their respective characteristics and use cases.

Feature	Characteristics and use cases
Intelligent Tiering	Characteristics: Intelligent Tiering automatically moves objects between the frequent, infrequent, and flashback archive access tiers based on how often they are accessed. These transition rules are fixed and cannot be modified at this time. For more information, see Intelligent Tiering overview. Use cases: Suitable for scenarios where data access patterns are changing or unpredictable.
Configuring lifecycle rules based on last access time	Characteristics: Lifecycle rules can be used to transition objects to the desired storage type if they remain unaccessed for a preset number of days. The applicable storage types are Infrequent Access Storage, Flashback Archive, Archive, Cold Archive, and Deep Cold Archive. Lifecycle rules provide greater flexibility in configuration, allowing you to specify the number of days or time until expiration. Use cases: Suitable for scenarios where data access patterns are well understood, and more flexible data tiering policies are desired.

Notes

Category	Considerations
Supported features	You can create a lifecycle rule that transitions objects based on their last access time. However, you cannot use a lifecycle rule to delete objects based on their last access time.
Storage type	You can use a lifecycle rule to transition objects to the following storage types: Infrequent Access Storage, Flashback Archive, Archive, Cold Archive, and Deep Cold Archive. However, you cannot use a lifecycle rule to transition objects to Intelligent Tiering.
Constraints and limitations	Transitioning incomplete multipart uploads and appendable objects based on the last access time is not supported. A lifecycle rule can include policies based on either the last modified or access time, but not both.
Operations that update an object's last access time	TOS calculates the last access time of objects from the day access monitor is enabled. Operations such as overwriting or downloading an object update its last access time. However, if multiple GetObject requests are made for the same object within 24 hours, only the time of the first request is recorded as the object's last access time. For instance, if an object is downloaded at 8:00 a.m. on January 1, its access time will be recorded as 8:00 a.m. on January 1. Any subsequent download requests before 8:00 a.m. on January 2 will not update the access time. The access time will only update if the object is downloaded after 8:00 a.m. on January 2. Other operations update the object's last access time based on the time of the operation. For more information, see Which operations update an object's last access time?.
Permissions required	Before you begin, ensure that your account has the necessary permissions to enable access monitor and configure lifecycle rules. Specifically: Enable access monitor: tos:PutBucketAccessMonitor and tos:GetBucketAccessMonitor Configure lifecycle rules: tos:PutLifecycleConfiguration and tos:GetLifecycleConfiguration For more information, see Bucket policy overview.

Step 1: Enable access monitor

Before creating a lifecycle rule based on last access time, you must enable the Access monitor feature. Starting from the day this feature is enabled, TOS will automatically begin tracking the last access time of all objects in the bucket.

In the left navigation pane, click Buckets. In the Buckets list, click the bucket you want to manage.

In the left navigation pane, select Basic configurations > Lifecycle.

On the Lifecycle page, switch on Access monitor next to Create rule.

In the box that appears, click OK.

tip

Though TOS currently does not charge for this service, enabling the access monitor feature will generate monitoring-related costs.

Before disabling access monitor, you must first delete all lifecycle rules based on last access time. Otherwise, this feature cannot be disabled.

Step 2: Create a lifecycle rule

In the left navigation pane, click Buckets. In the Buckets list, click the bucket you want to manage.

In the left navigation pane, select Basic configurations > Lifecycle.

On the Lifecycle page, click Create rule.

On the Create Lifecycle page, configure the following parameters:

Parameter	Description
Rule name	Used to identify the lifecycle rule. Lifecycle names must: Be between 1 and 255 characters long. Be unique within the bucket.
Status	Determines when the rule takes effect. The options are: Enable: The rule takes effect immediately after creation. Disable: The rule is created but remains inactive.
Impact Scope	Defines the scope of objects affected by the lifecycle rule. The options are: Entire bucket: The rule applies to the entire bucket. Specify prefix: The rule applies to objects with the specified prefix. The prefix cannot include the bucket name. For example, if you want to apply the rule only to objects starting with the prefix prefix, select Specify prefix and set Prefix to prefix. Follow these guidelines when specifying a prefix: Prefixes can contain Chinese characters, letters, numbers, and common symbols. Length must be between 1 and 1,024 characters. Prefixes cannot start with a forward slash (/) or backslash (\). Consecutive forward slashes (/) are not allowed. .. cannot be used as a directory name. Regular expressions are not supported for prefix matching.
Tag	TOS allows you to configure lifecycle rules for objects with specific tags, supporting up to ten tags. For more information, see Managing object tags. warning For a lifecycle rule to take effect, an object must match both the tag key and value specified in the rule.
Not	Enabling this option will prevent the lifecycle rule from applying to objects with the specified prefix and tag. Follow these guidelines when specifying a prefix or tag: The total length of a prefix cannot exceed 1,023 characters. The valid characters for a tag include uppercase and lowercase letters, numbers, spaces, and symbols (: + - = ._ : /). warning After enabling Not, you will no longer be able to delete incomplete multipart uploads using this lifecycle rule. You can only add one Not configuration to a lifecycle rule. The Not prefix must start with the prefix provided in the Impact Scope section. For example, if the prefix provided in the Impact Scope section is a/, then the Not prefix must be a/xxx. The Not tag key must differ from those defined in the Tag section. For example, if the tag "key1":"value1" is provided in the Tag section, then you cannot specify the tag as "key1":"value1" or "key1":"value2" in the Not section.
File size	Specifies the size range of objects to which the lifecycle rule applies. Valid range: [1 B, 5 TiB]. The options are: Specify the minimum file: The smallest size of an object to which the rule applies. Specify the maximum file: The largest size of an object to which the rule applies. If both Specify the minimum file and Specify the maximum file are selected, the lifecycle rule only applies to objects whose sizes fall within this range. warning If both are configured, the maximum size must exceed the minimum size. The rule will apply to all objects regardless of size if the file size is not specified, as long as other policy conditions are met. A minimum charge applies to objects in Infrequent Access Storage, Flashback Archive, Archive, Cold Archive, and Deep Cold Archive based on file size. Objects smaller than 64 KiB are charged as if they were 64 KiB. To optimize storage costs, we recommend transitioning only objects larger than 64 KiB.
Effective policy	Select Last access time. tip Before setting Effective policy to Last access time, you must switch on Access monitor. If Access monitor is not enabled on the Lifecycle page, you can enable it quickly below Last access time.
Latest file version expiration policy	Transitions latest object versions. This policy only supports Specify days. Once the desired number of days has been set, TOS will automatically transition any latest version that remains unaccessed for the preset duration to the target storage type. warning If versioning is enabled for your objects, this rule applies to the latest versions. To clear historical versions, enable File history version expiration policy. If you select multiple expiration policies, make sure the time interval between any two policies is greater than or equal to the minimum storage duration for each respective storage type. Otherwise, early deletion charges may apply. The minimum storage durations are as follows: Infrequent Access Storage: 30 days Flashback Archive: 90 days Archive: 90 days Cold Archive: 180 days Deep Cold Archive: 180 days For example, if the number of days after which in-scope objects will automatically transition to Flashback Archive is set to 90, the transition to Archive must occur after at least 180 days to avoid early deletion charges.
File history version expiration policy	Transitions historical object versions. This policy only supports Specify days. Once the desired number of days has been set, TOS will automatically transition any historical version that remains unaccessed for the preset duration to the target storage type. warning If you select multiple expiration policies, make sure the time interval between any two policies is greater than or equal to the minimum storage duration for each respective storage type. Otherwise, early deletion charges may apply. The minimum storage durations are as follows: Infrequent Access Storage: 30 days Flashback Archive: 90 days Archive: 90 days Cold Archive: 180 days Deep Cold Archive: 180 days For example, if the number of days after which in-scope objects will automatically transition to Flashback Archive is set to 90, the transition to Archive must occur after at least 180 days to avoid early deletion charges.
Part expiration policy	This policy is turned off by default. Once enabled, you can set an expiration period in days. Any uploaded but unmerged parts will be automatically deleted after the expiration period elapses.

Click Create.

In the box that appears, click OK.

After creating a lifecycle rule, you can view it in the rules list.

tip

After creating a lifecycle rule, you can copy or search for the rule:

Copy a lifecycle rule: On the Lifecycle page, click ... > Replication rule in the Actions column of the rule you want to copy. The system will automatically populate the content of the original rule. Based on this, you can adjust the rule parameters to meet your current requirements.

Search for a lifecycle rule: On the Lifecycle page, click the search icon next to the Rule name or Scope of application column. You can search for specific lifecycle rules by name or scope.

Related operations

You can retrieve and analyze access logs generated during your interactions with TOS through Torch Log Service. When the log field RequestSourceType is lifecycle, it indicates that the request is a lifecycle rule request. You can use this field to query the request time, object key, and other lifecycle rule request information. For instructions, see Log analysis.

Last updated: 2026.06.29 18:52:01