S3 pricing: a practical model for storage, requests, egress, and replication
S3-like object storage pricing looks simple until you add data movement. A solid model covers four common buckets: storage, requests, egress, and replication/copy.
0) Define what you are estimating (and for which month)
- Budget month: pick a month that reflects typical usage (or define baseline + peak).
- Boundary: are you estimating "S3 only" or "S3 + delivery" (CDN, transfer, replication)?
- Regions: cross-region patterns change the bill more than many teams expect.
1) Storage (GB-month)
Use average stored GB (GB-month). If your dataset grows, average is more accurate than end-of-month GB. Tool: Object storage cost.
- Split by tier if needed (hot / warm / archive). For tiering decisions, see S3 storage classes.
- If lifecycle moves data to Glacier/Deep Archive, treat retrieval as a separate driver, not a footnote.
2) Requests (GET/PUT/LIST)
Requests are often small for large-object workloads, but can be material for millions of small objects. Tool: S3 request cost calculator.
- Prefer measured counts from billing exports or access logs.
- If you only have RPS, convert with RPS to monthly requests.
3) Egress (data transfer out)
Egress is the most common surprise cost. If you read lots of data out of storage, $/GB transfer can dominate. Tool: Data egress cost.
If you use a CDN, separate edge bandwidth from origin egress. Guide: origin egress vs CDN bandwidth.
4) Replication and cross-region copy
Replication fees are driven by changed data (replicated GB/month), not total stored GB. Estimate replication volume from writes and churn, then apply a $/GB assumption. Tools: estimate replication volume and S3 replication cost calculator.
- Include destination storage (you usually store the data twice).
- Keep a one-time backfill scenario separate from steady-state replication.
Worked estimate template (copy/paste)
- Storage = average GB-month (split by tier if needed)
- Requests = GET + PUT + LIST + other request classes (measured or derived from RPS)
- Transfer = internet egress + cross-region reads + CDN origin egress (modeled separately)
- Replication = replicated GB/month + destination storage + any one-time backfill
Common pitfalls
- Modeling only "bucket size" and missing transfer and replication.
- Using one average for requests and missing short spikes (deploys, batch, incidents).
- Double-counting CDN bandwidth and origin egress as the same GB.
- Ignoring object-count effects (small objects increase request costs and operational overhead).
- Forgetting that replication is driven by writes/churn, not total stored data.
Related calculators
S3 cost calculator Storage pricing (generic) S3 pricing explained
How to validate the estimate
- In CUR/Cost Explorer, confirm distinct usage lines for storage, requests, and transfer exist as expected.
- Validate units: GB vs GiB and request units (per 1k/10k/1M). Do not mix request classes.
- Reconcile one representative week of logs/metrics against your baseline assumptions.