S3 replication pricing: estimate replicated GB/month and total impact
Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.
This is the storage copy-path economics page. Use it when changed bytes, destination storage, one-time backfills, and CRR versus SRR are the real decision boundary.
Go back to the storage parent page if the broader storage budget shape is still unclear.
The biggest input in S3 replication pricing is replicated GB/month. That volume is driven by writes and churn, not by total stored data.
Replication inputs
- Replicated GB: data copied per month.
- Request costs: replication requests and PUTs.
- Destination storage: GB-month in target bucket.
What to model (replication is not one number)
- Replicated GB/month: changed data replicated (steady-state driver)
- One-time backfill: initial copy of existing objects (migration/enablement event)
- Destination storage: replica storage GB-month (often the largest ongoing cost)
- Request overhead: extra PUT/COPY/LIST and control-plane activity can show up for high-churn buckets
- Region boundary: CRR can introduce transfer-like costs compared to SRR
1) Estimate replication volume from writes (steady-state)
Use this guide to estimate replicated GB/month from GB/day writes or PUT counts and object size.
Replication volume tracks changed bytes. If your workload rewrites objects often (churn), replicated GB/month can be much larger than "new data added".
2) Price the per-GB replication line item (and keep backfill separate)
Use a per-GB assumption that matches your plan (feature fee, transfer-like pricing, or both):
- Create a backfill scenario for the initial copy (bucket size at enablement time).
- Create a steady-state scenario for replicated GB/month from writes/churn.
3) Don't forget destination storage
Replication typically means storing the data twice. Add destination storage as a separate line item using object storage cost.
4) CRR vs SRR: when the option changes cost
If you're deciding between cross-region replication (CRR) and same-region replication (SRR), use this checklist: S3 CRR vs SRR cost.
Common pitfalls
- Using total bucket size as the monthly replication input (unless you are modeling a one-time backfill).
- Missing churn: frequent overwrites and deletes create replicated bytes that do not show up as "growth".
- Forgetting destination storage GB-month (replication is usually double storage).
- Not separating CRR transfer-like effects from SRR.
- Assuming replication is "free" operationally: backlog and retries during incidents can create peaks.
How to validate the estimate
- After enablement, reconcile replicated bytes and replica storage in CUR/Cost Explorer.
- Validate replication volume by sampling writes/day and object sizes for a representative week.
- Track one-time events separately (backfills, migrations, reprocessing).
Related tools
S3 replication cost calculator Copy storage pricing S3 replication cost