Lifecycle policies are based on a prefix , not a subdirectory.
So, if objects corresponding to the foo/ prefix should be deleted after 2 months, it is not logical to request that objects with the foo/bar/ prefix be deleted after 3 months, since they will be deleted after 2 months ... since they also correspond prefix foo/ . Prefix means prefix. Separators are not a factor in life cycle rules.
Also note that keys and prefixes in S3 do not start with / . A policy that affects the entire array uses an empty string as a prefix, not / .
Also, you probably want to remember trailing slashes when specifying prefixes, because foo/bar corresponds to the file foo/bart.jpg , and foo/bar/ does not.
Iterating over objects for deletion is not as bad as you do, because calling the list objects API returns 1000 objects per request (or less if you want) and allows you to specify both a prefix and a separator (usually you will use / as a separator, if you want the answers to be grouped using the pseudo-folder model used by the console to create a hierarchical display) ... and each object key and data label are provided in the XML response. There is also an API request to delete multiple objects in one call.
Any kind of moving, transferring, copying, etc. will always reset the date the object was created. Even changing metadata, because objects are immutable. Each time you move, move, copy or βrenameβ an object (which actually copies and deletes) or change metadata (which are actually copied to the same key with different metadata), you actually create a new object.
source share