S3 Cost Optimization
Price exercises use hypothetical us-east-1 (US East, N. Virginia) rates for study on 2026-10-12, not current tariffs, unless explicitly identified as a dated published fee.
S3 costs combine storage, requests, retrieval, transitions, transfer and optional management/replication features. Compare the selected Region and access pattern rather than a static global rate table.
Class selection
| Class | Principal trade-off |
|---|---|
| Standard | Frequent access; no minimum storage-duration charge |
| Standard-IA / One Zone-IA | Retrieval fees and 30-day minimum; One Zone has single-AZ risk |
| Glacier Instant Retrieval | Millisecond access with retrieval charges and 90-day minimum |
| Glacier Flexible Retrieval | Restore workflow; 90-day minimum |
| Glacier Deep Archive | Longer restore workflow; 180-day minimum |
| Intelligent-Tiering | Monitoring/automation for eligible objects; optional archive tiers |
Intelligent-Tiering has no minimum storage duration. Objects smaller than 128 KB remain in Frequent Access and incur no monitoring/automation fee. Archive Access and Deep Archive Access must be enabled explicitly; they require restoration and are not instant-access tiers. Minimum billable size and metadata overhead differ by class.
Lifecycle design
Separate current/noncurrent versions and incomplete multipart uploads. Age-based lifecycle transitions do not reset when an object is read; Intelligent-Tiering follows access patterns. Check transition request costs, minimum durations and current small-object transition defaults before applying policies.
A monthly model must allocate each object population to one class for each time interval. For example, at assumed $0.023 and $0.0125/GB-month, a stable 1,000-GB dataset with 400 GB Standard and 600 GB Standard-IA costs $9.20 + $7.50 = $16.70 in storage before requests/retrieval. Do not charge all 1,000 GB in both classes simultaneously.
Visibility and access
Storage Lens provides aggregated storage/activity insights; Storage Class Analysis is a separate feature for transition analysis. Neither is a universal per-object last-access log. Athena with columnar formats and partition pruning can reduce scanned data; request, storage-class retrieval and query charges still apply. S3 Select is unavailable to new customers and should not be a general new-workload recommendation.
S3 offers strong consistency for supported operations without a premium consistency charge. Access frequency does not determine consistency.
Replication and transfer
Replication adds destination storage, requests and applicable transfer/features. S3 RTC is designed to replicate 99.99% of objects within 15 minutes. Its contractual monthly SLA commitment is 99.9%, evaluated per replication Region pair per account; service credits start below that threshold, subject to the SLA’s eligibility, claims and exclusions. Neither figure guarantees every object or an application’s exact recovery point. See the RTC design/commitment distinction and owning SLA. Test failure monitoring and recovery.
Not every GB leaving S3 is charged: selected same-Region service paths and S3-to-CloudFront origin transfer have exemptions. CloudFront still charges according to its pricing plan.
Lifecycle and retrieval decision table
| Population | Candidate | What can invalidate the choice |
|---|---|---|
| Hot objects | Standard | Request/transfer dominates storage |
| Unknown access, eligible size | Intelligent-Tiering | Many tiny objects or optional archive latency |
| Infrequent, fast access | Standard-IA / Glacier Instant | Retrieval volume and minimum duration/size |
| Re-creatable single-AZ data | One Zone-IA | Source loss or unacceptable rebuild time |
| Archive with hours-long recall | Glacier Flexible | Expedited availability, retrieval/restore requirements |
| Very cold long retention | Deep Archive | Urgent restore or early deletion |
Flexible/Deep Archive restore creates a temporary accessible copy under documented charges/time. Retrieval speed options are not one universal instant response. Do not make an urgent-data design depend on the cheapest archive storage row.
Corrected population and early-deletion model
Assume a hypothetical us-east-1 exercise dated 2026-10-12: 100,000 GB average data, 40,000 GB hot at $0.023/GB-month and 60,000 GB cold at $0.0125/GB-month. Storage is $920 + $750 = $1,670/month, versus $2,300 if all remains hot. The $630 difference excludes requests, retrieval, transitions, monitoring and metadata overhead.
If 10,000 GB of cold data is read at an assumed $0.01/GB retrieval rate, add $100. Do not put the same 60,000 GB simultaneously in several tiers or silently treat TB as GB.
For a simplified 100-GB Deep Archive exercise at an assumed $0.001/GB-month, deleting after 30 days can leave a remaining minimum-duration liability through 180 days. Treat early-deletion billing as part of cost; lower storage rate is not proof of savings for short retention.
Versioning, replication and analytics lab
Separate current versions, noncurrent versions, delete markers and incomplete multipart uploads. Design lifecycle actions for each rather than calling multipart cleanup an ordinary object expiration. Confirm minimum-size transition defaults, filters and conflicting rules against current documentation.
For CRR, total source and destination storage separately; add replication requests, applicable inter-Region transfer and RTC if chosen. SRR avoids inter-Region transfer but still adds destination storage and request costs. RTC’s SLA does not promise every object arrives within 15 minutes.
As a simplified SLA-reading exercise, suppose an eligible Region pair/account has 100,000 replicated objects in a billing month. If 20 miss 15 minutes, the monthly percentage is 99.98%: below the 99.99% design target, but above the 99.9% credit threshold. If 200 miss, it is 99.8%, in the SLA’s 10% credit band before claims/exclusions are evaluated. A credit is not recovered data, and the percentage says nothing about the business value of a particular late object. Monitor replication latency/pending work and late/failed-object events, and rehearse recovery for critical data instead of relying on a percentage alone.
Use Storage Lens for aggregate activity/storage trends and Storage Class Analysis for its supported transition recommendations. Validate conclusions with actual query access patterns. Athena partition pruning/columnar scans can reduce query work but do not remove storage-class retrieval charges. New customers should not plan on unavailable S3 Select.