Memory hook: Measure access, choose an economical storage class, automate aging, and make event consumers tolerate retries.
Must remember
Storage cost is more than the monthly rate
- Standard suits frequent access and has no minimum storage duration. Intelligent-Tiering responds to changing access patterns; monitoring charges and small-object eligibility matter. Its optional archive tiers require restore workflows.
- Standard-IA and One Zone-IA: 30-day minimum storage duration; retrieval charges; 128 KB minimum billable object size. One Zone-IA fits recreatable data because it does not survive loss of its AZ.
- Glacier Instant Retrieval: immediate access, but a 90-day minimum. Glacier Flexible Retrieval: restore before reading, with minutes-to-hours retrieval choices and a 90-day minimum. Deep Archive: hours-scale restore and a 180-day minimum.
- Those minimums are billing commitments, not deletion locks. Deleting or transitioning early can leave a remaining-duration charge. This is why a short lab uses Standard even when an archive class has a lower advertised storage price. Storage-class comparison
Lifecycle, observation and bulk actions
- Lifecycle filters by prefix, tags or size, then transitions or expires matching objects. Treat current versions, noncurrent versions, delete markers and incomplete multipart uploads as separate cleanup concerns.
- In a versioned bucket, ordinary expiration can create a delete marker while old versions remain billable. Noncurrent-version expiration removes those older versions.
- Current lifecycle defaults do not transition objects smaller than 128 KB. Explicit size filters can change eligibility, but many tiny transitions may cost more than they save. Do not confuse the storage-class minimum billing duration with the object's age before a lifecycle transition is eligible. Lifecycle constraints
- Storage Class Analysis observes access patterns to inform Standard-to-IA choices; it does not perform the transition. Storage Lens aggregates usage/activity across buckets and accounts; advanced metrics can cost extra.
- Batch Operations uses a manifest and an execution role to apply supported actions across large existing object sets. Think “managed bulk job,” not “event notification for future writes.”
- Requester Pays makes authenticated requesters pay qualifying requests and downloads; the owner still pays storage. It is not anonymous public access and does not shift every possible charge.
Notifications and throughput
- S3 events can target SNS, SQS standard queues or Lambda; EventBridge adds filtering and more destinations. Direct S3 notifications cannot target SQS FIFO.
- Expect duplicate and potentially out-of-order notifications. Make processing idempotent; use separate subscriber queues when each consumer needs its own retry history. Avoid a function repeatedly triggering itself by writing back to its input prefix. Notification destinations
- Multipart upload sends large objects as independent parts, allowing parallelism and retrying only failed parts. Unfinished parts keep consuming storage until the upload is completed or aborted.
- Byte-range GET fetches selected bytes and can parallelize downloads. Transfer Acceleration improves long-distance client-to-S3 transfer paths through edge networking; evaluate its additional cost.
- S3 scales per partitioned prefix. Parallel requests and sensible prefix distribution improve throughput; KMS quotas can also constrain SSE-KMS workloads. Randomizing every object-name prefix is not a universal requirement. Performance guidance
See storage foundations for versioning, replication and durability versus availability, and S3 access controls for encryption and policy evaluation.
Choose under exam pressure
| Requirement in the question | Best direction |
|---|---|
| Predictable aging and expiration | Lifecycle |
| Unknown or changing object access | Evaluate Intelligent-Tiering |
| Rare data must be readable immediately | IA or Glacier Instant, depending on retention/access pattern |
| Millions of existing objects need one supported action | Batch Operations |
| Independent processing and audit consumers | Fan-out with separate queues |
| Distant clients upload large objects | Test acceleration and multipart upload |
| Investigate storage growth across accounts | Storage Lens |
Traps
- Cheap archival storage can be expensive for objects deleted tomorrow or retrieved frequently.
- Lifecycle is asynchronous; it is neither an exact timer nor a complete replacement for explicit teardown.
- A prefix is part of an object key, not a filesystem directory with independent throughput hardware.
- Delivering an event once and applying a business side effect once are different guarantees.
Active recall
1. Daily temporary exports live for two days. Should the lowest archive storage rate determine the class?
No. Compare the full lifecycle cost. A 90- or 180-day billing minimum, transition charges and retrieval needs can make Standard cheaper for short-lived exports.
2. A lifecycle expiration rule ran, but the versioned bucket still has a storage bill. Why?
Older versions may remain after a delete marker hides the current object. Inspect noncurrent-version rules, delete markers and unfinished multipart uploads; they have distinct lifecycle actions.
3. Two applications must independently process every upload. Is one shared SQS queue sufficient?
No. Workers on one queue compete. Fan out to separate queues so each application receives its own event copy, retries independently and handles duplicates safely.
4. A large upload fails near completion on a distant connection. Which two features address different parts of the problem?
Multipart upload limits retry work to failed parts; Transfer Acceleration can improve the long-distance network path. Neither eliminates the need to abort abandoned multipart uploads.
5. All existing objects need a supported bulk operation. Should you wait for new-write notifications?
No. Use a suitable Batch Operations job over an explicit manifest. Notifications concern events; they do not retroactively process every pre-existing object.
Terraform anchor: Use stable for_each keys for object identities and explicit dependencies when notification readiness must precede object creation.