A research bucket mixes two data classes under one prefix. One class must expire sooner and stay private to one role, and the other must be retained and readable by a partner role. What lets lifecycle and access differ?
Select an answer to reveal the explanation.
Short Explanation
Two kinds of mail in one slot cannot follow two different retention stamps. Your shared prefix means one lifecycle rule and one access statement hit both classes. Separate prefixes or buckets so each class can expire and be shared on its own terms.
Full Explanation
S3 lifecycle rules and access policies can filter on prefix. While both classes live under one prefix, an expiration rule on that prefix matches both, and a policy statement on that prefix grants or denies both. Moving each class to its own prefix, or to its own bucket, gives you a filter that hits only one class, so retention and the partner role can differ. One shorter expiration on the shared prefix deletes the class you meant to retain. Versioning keeps noncurrent versions and delete markers. It does not split lifecycle timing or IAM by class. A single default encryption key protects both classes with the same key. It does not create two access policies. Caveat: objects already written stay in the old prefix until you copy them, and a lifecycle rule on a parent prefix still matches a nested prefix. Operational check: with the partner role, read the shared class and confirm the private class is denied, and confirm the lifecycle configuration shows a different expiration filter on each prefix.