S3 pricing explained: storage vs requests vs egress
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
If you are searching for a storage pricing calculator, you are usually trying to estimate S3-like object storage cost. The good news: most object storage bills can be explained by three buckets: storage, requests, and egress. This is the S3 pricing anatomy page.
Stay here when the main question is how one S3-style bill breaks apart. Go back to the storage parent page if the broader storage budget shape is still unclear.
Use this page when the bill structure matters more than the workflow
- Use this guide when you need the base storage, request, egress, and storage-class anatomy of one S3 bill.
- Stay here if the issue is understanding line items, not designing the broader storage operating budget.
- Move to replication or archive-transition pages only after the base bill structure is clear.
1) Storage (GB-month)
Storage is billed over time, often as "GB-month". If your storage grows over the month, use an average stored GB number, not the end-of-month peak.
Tool: Object storage cost.
2) Request fees (GET/PUT/LIST)
Many workloads treat request fees as noise, and often they are. But request fees can become meaningful when:
- You store millions of small objects.
- You have heavy LIST operations or frequent metadata reads.
- Your application pattern causes many PUT/GET operations per GB stored.
Tools: S3 request cost and object storage cost (model requests as a separate line item).
3) Egress (data transfer out)
Egress is often the biggest surprise. If you read large amounts of data out of storage (downloads, analytics, cross-region access), the $/GB transfer charge can dominate.
Tool: Data egress cost.
Hidden items to watch for
- Replication and cross-region copy: adds transfer/feature fees and duplicate storage. Start with copy storage pricing and S3 replication cost.
- Different storage classes: IA/archive tiers can introduce retrieval and transition fees.
- Growth over time: long retention or backups can turn a small daily ingest into a large monthly storage bill. Use DB storage growth as a simple estimator if you do not have a better model yet.
The biggest mistake on this page is turning S3 anatomy into a full storage strategy
This page should explain how one S3-style bill is assembled. It should not replace the broader storage parent page when copies, archive policy, or lifecycle workflow decisions are still driving the budget.
Storage classes: treat retrieval as a separate scenario
Colder storage classes often look cheap on GB-month, but they can add retrieval and minimum duration costs. The safest budgeting approach is to model a "retrieval month" separately (audits, backfills, restores) instead of smearing it across the whole year.
- Storage: GB-month by class (hot vs cold vs archive).
- Transitions: lifecycle moves can create extra requests and sometimes fees.
- Retrieval: restore GB and restore requests when you access archived objects.
Recommended modeling approach
- Estimate average stored GB.
- Estimate monthly request volume (GET/PUT/LIST).
- Estimate egress GB/month (if any).
- Add replication/copy costs if you move data.
If you want a single page that ties these together, start with storage pricing calculator.
If the real problem is still the wider storage budget map, go back to storage costs before choosing a narrower workflow page.
Related tools
Storage pricing calculator Object storage cost Copy storage pricing