{
	"id": "f4a46a88-05da-44be-8a9d-c9d9d8a14689",
	"created_at": "2026-04-06T00:21:49.904594Z",
	"updated_at": "2026-04-10T03:20:06.127241Z",
	"deleted_at": null,
	"sha1_hash": "88391d0f584cea02264aa5ab61a7f55c3e93ee1e",
	"title": "Object Lifecycle Management",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 139042,
	"plain_text": "Object Lifecycle Management\r\nArchived: 2026-04-05 15:55:34 UTC\r\nSetup Object Lifecycle Management Configuration samples\r\nTo support common use cases like setting a Time to Live (TTL) for objects, retaining noncurrent versions of\r\nobjects, or \"downgrading\" storage classes of objects to help manage costs, Cloud Storage offers the Object\r\nLifecycle Management feature.\r\nThis page describes the feature as well as the options available when using it. For the general format of a lifecycle\r\nconfiguration file, see the bucket resource representation for JSON or the lifecycle configuration format for XML.\r\nIntroduction\r\nIn order to use Object Lifecycle Management, you define a lifecycle configuration, which must be set on a bucket.\r\nThe configuration contains a set of rules which apply to current and future objects in the bucket. When an object\r\nmeets the criteria of one of the rules, Cloud Storage automatically performs a specified action on the object. Here\r\nare some example use cases:\r\nDowngrade the storage class of objects older than 365 days to Coldline storage.\r\nDelete objects created before January 1, 2019.\r\nKeep only the 3 most recent versions of each object in a bucket with versioning enabled.\r\nLifecycle configuration\r\nEach lifecycle management configuration contains a set of rules. Each rule contains one action and one or more\r\nconditions.\r\nAn object has to match all of the conditions specified in a rule for the action in the rule to be taken.\r\nIf you specify multiple rules that contain the same action, the action is taken on an object when that object\r\nmatches the conditions in any of the rules.\r\nIf multiple rules have their conditions satisfied simultaneously for a single object, Cloud Storage performs\r\nthe action associated with only one of the rules, based on the following considerations:\r\nThe Delete action takes precedence over any SetStorageClass action.\r\nThe SetStorageClass action that switches the object to the storage class with the lowest at-rest\r\nstorage pricing takes precedence.\r\nFor example, if you have one rule that changes the object's class to Nearline storage and another rule that\r\nchanges the object's class to Coldline storage, but both rules use the exact same condition, the object's class\r\nalways changes to Coldline storage when the condition is met.\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 1 of 9\n\nYou should test your lifecycle rules on development data before applying to production to ensure your rules\r\ndon't perform actions under unintended sets of conditions. If that's not possible, you should test on a small\r\nsubset of your production data by using the matchesPrefix or matchesSuffix conditions in your rules.\r\nChanges to a bucket's lifecycle configuration can take up to 24 hours to go into effect, and Object Lifecycle\r\nManagement might still perform actions based on the old configuration during this time.\r\nFor example, if you change an age condition from 10 days to 20 days, an object that is 11 days old could\r\nbe deleted by Object Lifecycle Management up to 24 hours later, due to the criteria of the old\r\nconfiguration.\r\nFor use cases, see Configuration examples for Object Lifecycle Management.\r\nLifecycle actions\r\nA lifecycle rule specifies exactly one of the following actions:\r\nDelete\r\nSetStorageClass\r\nAbortIncompleteMultipartUpload\r\nDelete\r\nThe Delete action deletes an object when the object meets all conditions specified in the lifecycle rule. By\r\ndefault, when you delete a live object, it becomes soft-deleted, and Cloud Storage retains it for a duration of seven\r\ndays. You can restore this soft-deleted object within the soft delete retention duration.\r\nException: In buckets with Object Versioning enabled, deleting the live version of an object causes it to become a\r\nnoncurrent version, while deleting a noncurrent version deletes that version from the bucket. See the configuration\r\nfor deleting objects for an example of using the Delete action along with Object Versioning.\r\nThe Delete action does not take effect on an object while the object has an object hold placed on it or a retention\r\npolicy that it has not yet fulfilled. As long as the conditions in the Delete action remain satisfied for the object,\r\nthe Delete action occurs after any object hold is removed and any retention policy is fulfilled.\r\nSetStorageClass\r\nThe SetStorageClass action changes the storage class of an object and updates the object's modification time\r\nwhen the object meets all conditions specified in the lifecycle rule.\r\nSetStorageClass supports the following storage class transitions:\r\nOriginal storage class New storage class\r\nDurable Reduced Availability (DRA) storage Nearline storage\r\nColdline storage\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 2 of 9\n\nOriginal storage class New storage class\r\nArchive storage\r\nMulti-Regional storage/Regional storage1\r\nStandard storage, Multi-Regional storage, or Regional storage\r\nNearline storage\r\nColdline storage\r\nArchive storage\r\nNearline storage\r\nColdline storage\r\nArchive storage\r\nColdline storage Archive storage\r\n1\r\n For buckets in a region, the new storage class cannot be Multi-Regional storage. For buckets in a multi-region or\r\ndual-region, the new storage class cannot be Regional storage.\r\nCloud Storage does not validate correctness of the storage class transition. This means that you can specify a\r\nstorage class transition not listed in the above table, but the transition will not occur. You should verify that your\r\nlifecycle rules use one of the listed storage class transitions.\r\nAbort incomplete multipart uploads\r\nThe AbortIncompleteMultipartUpload action aborts an incomplete multipart upload and deletes the associated\r\nparts when the multipart upload meets the conditions specified in the lifecycle rule.\r\nOnly the following lifecycle conditions can be used with this action:\r\nage\r\nmatchesPrefix\r\nmatchesSuffix\r\nAttempting to create a rule that uses the AbortIncompleteMultipartUpload action in combination with other\r\nconditions results in an error.\r\nLifecycle conditions\r\nA lifecycle rule includes conditions which an object must meet before the action defined in the rule occurs on the\r\nobject. Lifecycle rules support the following conditions:\r\nage\r\ncreatedBefore\r\ncustomTimeBefore\r\ndaysSinceCustomTime\r\ndaysSinceNoncurrentTime\r\nisLive\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 3 of 9\n\nmatchesStorageClass\r\nmatchesPrefix and matchesSuffix\r\nnoncurrentTimeBefore\r\nnumNewerVersions\r\nAll conditions are optional, but at least one condition is required. If you attempt to set an invalid lifecycle\r\nconfiguration, such as by using an action or condition that does not exist, you receive a 400 Bad request error\r\nresponse, and any existing lifecycle configuration remains in place.\r\nage\r\nThe age condition is satisfied when a resource reaches the specified age (in days). Age is measured from the\r\nresource's creation time.\r\nFor objects, the creation time is the time when the object is successfully written to the bucket, such as when\r\nan upload completes.\r\nThe age of an object is unaffected by the object becoming a noncurrent version.\r\nFor multipart uploads, the creation time is the time when the upload is initiated.\r\nIf the age condition is set to a value of 0 , the condition is satisfied at midnight UTC after the object is\r\ncreated.\r\nFor example, if a resource is created at 2022/01/10 10:00 UTC and the age condition is 10 days, then the\r\ncondition is satisfied for the resource on and after 2022/01/20 10:00 UTC.\r\ncreatedBefore\r\nThe createdBefore condition is satisfied when an object is created before midnight of the specified date in UTC.\r\ncustomTimeBefore\r\nThe customTimeBefore condition is satisfied when the date portion of an object's Custom-Time metadata is\r\nearlier than the date specified in this condition. This condition is set using the date format YYYY-MM-DD .\r\ncustomTimeBefore is never satisfied for an object with no Custom-Time metadata set.\r\ndaysSinceCustomTime\r\nThe daysSinceCustomTime condition is satisfied when the specified number of days have passed since the date\r\nand time specified in an object's Custom-Time metadata field. For example, if an object's Custom-Time is 2020-\r\n05-16T10:00:00Z and the daysSinceCustomTime condition is 10 days, then the condition is satisfied for the\r\nobject on and after 2020/05/26 10:00 UTC.\r\ndaysSinceCustomTime is never satisfied for an object with no Custom-Time metadata set.\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 4 of 9\n\ndaysSinceNoncurrentTime\r\nThe daysSinceNoncurrentTime condition is typically only used in conjunction with Object Versioning. The\r\ncondition is satisfied when the specified number of days have passed since the object became noncurrent, either\r\nbecause the live version was deleted or replaced. For example, if an object became noncurrent at 2020/07/08\r\n15:00 UTC and the daysSinceNoncurrentTime condition is 10 days, then the condition is satisfied for the object\r\non and after 2020/07/18 15:00 UTC.\r\nisLive\r\nThe isLive condition is typically only used in conjunction with Object Versioning. When set to false , this\r\ncondition is satisfied for any noncurrent version of an object. When set to true , this condition is satisfied for the\r\nlive version of an object. If you don't use versioning, all your objects are considered live and match when isLive\r\nis true .\r\nmatchesPrefix and matchesSuffix\r\nThe matchesPrefix and matchesSuffix conditions are satisfied when the beginning or end of an object's name\r\nis an exact case-sensitive match with the specified prefix or suffix. You can specify multiple strings as a list (for\r\nexample, \"matchesSuffix\": [\".jpg\", \".png\"] ).\r\nWhen using matchesPrefix , don't include the bucket name or the / that precedes object names in most request\r\npaths. For example, in the Google Cloud CLI, the path to an object in a bucket named my_bucket has a format\r\nsimilar to gs://my_bucket/pictures/paris_2022.jpg . To match the object, you would use a condition such as\r\n\"matchesPrefix\":[\"pictures/paris_\"] .\r\nYou can have up to 1000 prefixes and suffixes in total specified across all rules. In the Google Cloud console, you\r\ncan copy and paste up to 1000 prefixes or suffixes in total. A prefix or suffix cannot be used twice in a single\r\ncondition.\r\nmatchesStorageClass\r\nThe matchesStorageClass condition is satisfied when an object in the bucket is stored as the specified storage\r\nclass. You can use the following values for matchesStorageClass : STANDARD , NEARLINE , COLDLINE ,\r\nARCHIVE , MULTI_REGIONAL , REGIONAL , and DURABLE_REDUCED_AVAILABILITY .\r\nGenerally, if you intend to use the matchesStorageClass condition on Standard storage objects, you should also\r\ninclude the following:\r\nIf the bucket is in a region, include REGIONAL and DURABLE_REDUCED_AVAILABILITY in the condition.\r\nIf the bucket is in a multi-region or dual-region, include MULTI_REGIONAL and\r\nDURABLE_REDUCED_AVAILABILITY in the condition.\r\nIncluding these additional classes ensures the lifecycle rule covers older objects in your buckets which might be\r\nset to legacy storage classes.\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 5 of 9\n\nnoncurrentTimeBefore\r\nThe noncurrentTimeBefore condition is typically only used in conjunction with Object Versioning. The\r\ncondition is satisfied for objects that became noncurrent on a date prior to the one specified in this condition. The\r\ncondition is set using the date format YYYY-MM-DD . noncurrentTimeBefore is never satisfied for a live object.\r\nnumNewerVersions\r\nThe numNewerVersions condition is typically only used in conjunction with Object Versioning. If the value of\r\nthis condition is set to N, an object version satisfies the condition when there are at least N versions (including the\r\nlive version) newer than it. For a live object version, the number of newer versions is considered to be 0. For the\r\nmost recent noncurrent version, the number of newer versions is 1 (or 0 if there is no live object version), and so\r\non.\r\nObject lifecycle behavior\r\nWhen Object Lifecycle Management is configured for Cloud Storage buckets, Cloud Storage regularly inspects all\r\nthe objects and performs all actions applicable according to the bucket's rules. Cloud Storage performs an action\r\nasynchronously, so there can be a lag between when the conditions are satisfied and when the action is taken. Your\r\napplications shouldn't rely on lifecycle actions occurring within a certain amount of time after a lifecycle\r\ncondition is met.\r\nFor example, if an object meets the conditions for deletion, the object might not be deleted right away, and you see\r\nthe object until the lifecycle action is executed on the object.\r\nApplicable charges still apply while the object remains in its original state, with the exception of at-rest storage\r\ncosts, which are waived if the object meets all of the following criteria:\r\nThe object is in a bucket with soft delete disabled.\r\nThe object is subject to a rule with a Delete action.\r\nThe only condition for the rule is either an age condition or a combination of the age and\r\nmatchesStorageClass conditions.\r\nThe age condition is satisfied for the object in rules with only age condition. Both the age and\r\nmatchesStorageClass conditions should be satisfied for the object if the delete rule has both conditions.\r\nThe object does not have any object holds.\r\nObject lifecycle behavior on versioned objects\r\nIn buckets with Object Versioning enabled, a live object that gets deleted according to lifecycle rules will exist in a\r\nnoncurrent state for some amount of time. If the noncurrent version of the object also satisfies the delete rule's\r\nconditions, the noncurrent version of the object will also get deleted after the time elapses.\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 6 of 9\n\nFor example, say there's a lifecycle rule that deletes objects older than 180 days. If a live object is 200 days old, it\r\ngets deleted and becomes noncurrent. The now noncurrent object is still older than 180 days, so the noncurrent\r\nobject also gets deleted after some time passes.\r\nSetStorageClass cost considerations\r\nSimilar to changing an object's storage class manually, using SetStorageClass counts as a Class A operation and\r\nis billed at the rate determined by the destination storage class.\r\nUnlike changing an object's storage class manually, using SetStorageClass does not rewrite an object. This\r\ngives Object Lifecycle Management certain pricing advantages:\r\nThere are never inter-region replication charges, retrieval fees, or early deletion fees associated with the\r\nstorage class change. However, early deletion fees apply if objects in a storage class with a specified\r\nminimum storage duration are deleted before the duration ends.\r\nThe object's time spent set at the original storage class counts towards any minimum storage duration that\r\napplies for the new storage class.\r\nFor example, say you upload an object as Nearline storage, and 20 days later your lifecycle configuration changes\r\nthe storage class of the object to Coldline storage. This change incurs no retrieval or early deletion fees. If you\r\nthen delete the object 60 days after the storage class change, there is only a 10-day early deletion charge, since\r\nColdline storage has a 90-day minimum storage duration, and the object existed for a total of 80 days.\r\nIn comparison, say you upload an object as Nearline storage, and 20 days later change the storage class using a\r\nrewrite (again to Coldline storage). This change incurs both a retrieval fee and a 10-day early deletion charge. If\r\nyou then delete the object 60 days after the rewrite, there is a 30-day early deletion charge.\r\nIn both these examples, if soft delete is enabled on the bucket, the storage charges increase, but the early deletion\r\ncharges reduce based on the length of the soft delete retention period.\r\nObject creation time\r\nIn many cases, an object's upload completes soon after it begins; however, for uploads that occur over multiple\r\nrequests, such as resumable uploads, there can be days between when the initial upload request is sent and when\r\nthe final upload request is sent. In such cases, you should keep in mind the following:\r\nAn object is not subject to lifecycle rules until after its upload completes.\r\nAn object's creation time is based on when the upload completes. This impacts the age and\r\ncreatedBefore lifecycle conditions.\r\nWhen you set a Custom-Time for the object, you do so at the beginning of the upload. If you set a\r\nCustom-Time based on the time of the request, the Custom-Time could be much earlier than the object's\r\ncreation time. This impacts the customTimeBefore and daysSinceCustomTime lifecycle conditions.\r\nExpiration time metadata\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 7 of 9\n\nIf a Delete action is specified for a bucket with the age condition (and no other conditions besides\r\nmatchesStorageClass ), then some objects might be tagged with expiration time metadata. An object's expiration\r\ntime indicates the time at which the object becomes (or became) eligible for deletion by Object Lifecycle\r\nManagement. The expiration time might change as the bucket's lifecycle configuration or retention policy change.\r\nNote that the absence of expiration time metadata does not necessarily mean the object will not be deleted, but\r\nrather that not enough information is available to determine when or if it will be deleted. For example, if the\r\nobject creation time is 2020/01/10 10:00 UTC and the age condition is set to 10 days, then the object expiration\r\ntime is 2020/01/20 10:00 UTC. However, the expiration time is not available for the object if:\r\nThere are other conditions specified in the Delete rule, with the exception of matchesStorageClass .\r\nYou use a matchesStorageClass condition that does not include the object's storage class.\r\nThe object is under a hold, because Cloud Storage cannot know when the hold will be removed.\r\nSoft delete is enabled on your bucket.\r\nYou are not charged for storage after the object expiration time even if the object is not deleted immediately. You\r\ncan continue to access the object before it is deleted and are responsible for other charges (request, network\r\nbandwidth). If the expiration time is not available for an object, the object is charged for storage until the time it is\r\ndeleted.\r\nWhen working with expiration times, keep in mind the following:\r\nIf the bucket has a retention policy, the expiration time is the later of the Object Lifecycle Management\r\nage condition and the time the object satisfies the retention period specified by the retention policy.\r\nIf there are multiple conflicting expiration times applicable for an object due to different lifecycle\r\nmanagement rules, then the earliest applicable expiration time is used.\r\nOptions for tracking Lifecycle actions\r\nTo track the lifecycle management actions that Cloud Storage takes, use one of the following options:\r\nUse Cloud Storage usage logs. This feature logs both the action and who performed the action. A value of\r\nGCS Lifecycle Management in the cs_user_agent field of the log entry indicates the action was taken by\r\nCloud Storage in accordance with a lifecycle configuration.\r\nEnable Pub/Sub Notifications for Cloud Storage for your bucket. This feature sends notifications to a\r\nPub/Sub topic of your choice when specified actions occur. Note that this feature does not record who\r\nperformed the actions.\r\nWhat's next\r\nEnable Object Lifecycle Management.\r\nExplore lifecycle configuration examples.\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 8 of 9\n\nReview the general format of a lifecycle configuration in JSON API requests and XML API requests.\r\nSource: https://cloud.google.com/storage/docs/lifecycle\r\nhttps://cloud.google.com/storage/docs/lifecycle\r\nPage 9 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://cloud.google.com/storage/docs/lifecycle"
	],
	"report_names": [
		"lifecycle"
	],
	"threat_actors": [],
	"ts_created_at": 1775434909,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/88391d0f584cea02264aa5ab61a7f55c3e93ee1e.pdf",
		"text": "https://archive.orkl.eu/88391d0f584cea02264aa5ab61a7f55c3e93ee1e.txt",
		"img": "https://archive.orkl.eu/88391d0f584cea02264aa5ab61a7f55c3e93ee1e.jpg"
	}
}