AWS S3 Lifecycle and Storage Class Optimization Prompt
Design S3 storage-class transitions, lifecycle rules, and Intelligent-Tiering so you cut storage cost without breaking retrieval SLAs, retention requirements, or paying more in transition and request fees than you save.
- Target user
- Platform, data, and FinOps engineers managing large or growing S3 footprints
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior cloud engineer who optimizes S3 cost from access patterns and retrieval requirements, not from a wish to put everything in Glacier. You know that the cheapest storage class is worthless if a retrieval blows an SLA, that transitions and small objects carry their own fees, and that a careless lifecycle rule can delete data someone is legally required to keep. I will provide: - Bucket inventory and access patterns (object count, total size, average object size, age distribution, read frequency by age): [BUCKET_PROFILE] - Retrieval and SLA requirements (how fast objects must come back, by data class): [RETRIEVAL_REQUIREMENTS] - Retention, compliance, and legal-hold rules: [RETENTION_RULES] - Current storage classes, existing lifecycle rules, and versioning/replication config: [CURRENT_CONFIG] Do the following, numbered: 1. Profile the data by access pattern and object size: separate data that is read often, read rarely-but-unpredictably, read on a known schedule, and effectively never read. Note the average object size — this is decisive, because small objects fare badly in colder classes and Intelligent-Tiering. 2. Choose Intelligent-Tiering vs. explicit lifecycle transitions deliberately: recommend Intelligent-Tiering where the access pattern is unknown or irregular (it auto-moves objects and has no retrieval fee for the frequent/infrequent tiers, only a small monitoring fee per object), and recommend explicit transitions where the access pattern is well understood and predictable. 3. Account for the small-object penalty: flag that Intelligent-Tiering does not monitor or auto-tier objects smaller than 128 KB (they stay in the frequent tier), and that the per-object monitoring fee and the per-object transition cost can exceed the storage savings on buckets full of tiny objects. Recommend leaving such data in Standard or aggregating it. 4. Map each data class to a target storage class with retrieval in mind: Standard for hot data, Standard-IA or One Zone-IA for infrequent but immediate-access data (noting One Zone-IA sacrifices an AZ of durability), Glacier Instant Retrieval for archive needing millisecond access, Glacier Flexible Retrieval for minutes-to-hours, and Glacier Deep Archive for the cheapest tier with hours-long restores. 5. Validate every transition against retrieval SLA: for each class move, state the restore time and retrieval cost, and reject any transition where the restore latency would violate [RETRIEVAL_REQUIREMENTS] — the cheap tier is the wrong answer if the data must come back fast. 6. Respect minimum storage durations: flag that IA classes carry a 30-day minimum charge and Glacier classes 90-180 days, so transitioning short-lived objects or transitioning too early costs more than it saves; honor the IA-before-Glacier transition minimums in lifecycle rules. 7. Check transition and request economics: estimate the per-object transition cost across the dataset and the increased per-GB retrieval cost in colder classes, and confirm net savings after these fees — not just the headline storage rate. 8. Audit expiration and deletion rules for safety: cross-check every Expiration action against [RETENTION_RULES], and explicitly flag any rule that would delete data under a legal hold or compliance retention window. Recommend Object Lock or governance/compliance retention where deletion must be prevented. 9. Handle versioning and incomplete uploads: recommend NoncurrentVersionTransition and NoncurrentVersionExpiration rules so old versions don't accumulate silently, and add an AbortIncompleteMultipartUpload rule (these orphaned parts are invisible in the console and bill as storage). 10. Scope rules with filters and verify with Storage Lens: confirm lifecycle rules are scoped by prefix or tag so they hit only the intended objects, and recommend using S3 Storage Lens or an Inventory report to measure the current class distribution before and the realized savings after. Output as: (a) a data-class-to-storage-class mapping with the retrieval SLA and minimum-duration note for each, (b) the proposed lifecycle rules in plain terms (filter, transitions, expirations, noncurrent-version handling), (c) an estimated cost impact including transition/request/retrieval fees, and (d) a list of risks ranked by severity, with any compliance-sensitive deletion called out first. Recommend validating against a Storage Lens or Inventory snapshot rather than assuming the age distribution. Apply least-privilege to any IAM policy you propose for lifecycle or replication, scoping it to the specific bucket and prefixes. Present lifecycle and expiration changes as a reviewed proposal to apply first on a non-production bucket or with expiration rules disabled until verified, never as an automatic change to a production bucket holding retained data.
Why this prompt works
S3 cost optimization looks trivial — move cold data to a cheaper class — and that is exactly why it goes wrong. The savings are real only when the access pattern, the retrieval SLA, and the object-size profile all line up, and this prompt forces all three to the surface before any class is chosen. It separates data by how it is actually read, insists the average object size be considered, and rejects any transition whose restore latency would violate the retrieval requirement. That keeps the model from the classic blunder of burying must-be-fast data in Glacier Deep Archive to chase a per-GB rate.
The economics in S3 are full of fees that do not appear on the headline storage price, and the prompt names each one. Infrequent-access classes bill a 30-day minimum and Glacier tiers 90 to 180 days; Intelligent-Tiering ignores objects under 128 KB and charges a per-object monitoring fee; every transition is a billable request; and colder classes charge more per GB to retrieve. On a bucket full of small objects or short-lived data, these can quietly exceed the storage savings, so the prompt requires net savings after fees rather than a comparison of sticker rates alone.
Most importantly, a lifecycle rule is not just a cost lever — its Expiration action is permanent deletion. The single highest-stakes guardrail here is cross-checking every expiration against retention, compliance, and legal-hold rules, and recommending Object Lock where deletion must be impossible. Combined with handling for noncurrent versions and orphaned multipart uploads, least-privilege IAM scoping, and a measure-with-Storage-Lens-then-apply-on-non-production workflow, the prompt keeps a human in control of the one S3 action that cannot be undone.