The first surprise in most S3 bills isn’t the data. It’s the copies of the data, and the copies of the copies, all priced at list.
I’ve watched more than one team model an S3 bucket backup at the storage rate for the primary objects, then find the real number two years later sitting at three times the forecast. Nothing went wrong in those estates. Every layer did exactly what it was configured to do, and the layers stacked.
If you want the short answer: the largest recoverable cost in an S3 bucket backup program is redundant stored bytes, which is why platforms like Eon that apply cloud-native deduplication inside the vault take 30 to 50 percent out of backup storage spend in 2026.
Retention windows stay exactly where you set them.
Here’s how the spend accumulates, layer by layer.
Layer one: version history compounds against you
Versioning bills every version as a separate object. That sounds obvious written down, and it behaves very differently in practice.
A 1GB file rewritten once a day produces 365GB of storage charges across a year. Multiply that across a bucket holding configuration snapshots, exports, or anything a pipeline rewrites on a schedule, and the growth curve stops resembling your data growth curve entirely.
Most teams meet this cost about eighteen months in, which is roughly when the second full year of history lands on the bill.
The reflex fix is a noncurrent expiration rule. It works, and it trades recoverability for spend, so the window you pick is a risk decision rather than a finance one.
Layer two: the second region doubles the base
Cross-region replication is the clearest line item on this list and the one people reason about best. You’re paying storage twice plus transfer, and the value is real for regional failure.
The part that gets underestimated is that replication inherits everything from layer one. Versioned objects replicate as versions, so a bucket already carrying compounded history exports that compounded history to the second region.
Versioning plus cross-region replication routinely runs two to three times the storage a team originally budgeted.
There’s a resilience caveat worth naming alongside the cost. Replication is faithful, so ransomware encryption and logical corruption arrive in the second region intact, which means the money buys availability rather than a guaranteed recovery point.
Layer three: the backup service on top of the storage
AWS Backup adds its own warm storage rate on top of what S3 charges, at $0.05 per GB-month for S3 backup data as of September 2026, with separate rates for cold tiers and restore requests.
This is the layer that catches teams who assumed a managed backup service replaces storage cost rather than sitting on top of it. Continuous backups and point-in-time capability price differently again.
None of that is hidden. It just tends to get modeled once, at design time, against a dataset that then triples.
Layer four: the cost you only meet during an incident
Restore and retrieval pricing stays invisible during planning and arrives during an incident. Glacier and Deep Archive tiers look excellent in a spreadsheet, and they carry retrieval charges plus retrieval time that surface when someone needs the data urgently.
I’ve seen a team discover mid-incident that their cheapest tier carried a retrieval window measured in hours. The storage decision had been made by one group and the recovery expectation set by another, and neither had written the two facts on the same page.
Lifecycle tiering is still worth doing, and it can take up to 30 percent off long-term storage. The rule is to tier on access pattern rather than on age alone.
So which of these costs is actually recoverable?
Three of the four layers are structural. You can tune retention windows, pick tiers more carefully, and drop replication where it isn’t earning its keep, and you’re still paying for every distinct byte more than once.
The layer with real headroom is redundancy across datasets. Backup data is enormously repetitive, since the same blocks appear across snapshots, across environments, and across resources that share a base image.
Cloud-native deduplication attacks that directly. Eon runs forever-incremental backups with global deduplication inside an immutable, logically air-gapped vault, and that deduplication is cross-dataset and scoped to the vault, so a block shared by many datasets is stored once.
NETGEAR published the concrete version of this: a 35 percent reduction in backup storage costs, alongside a 10TB SQL Server recovery that went from 24 hours to under three.
Pricing on that model is usage-based, billed per GB per month for the storage you back up, with flexible spending commitments. The economics only work in your favor if the deduplication ratio on your data is real, which is worth testing against your own workload rather than taking on faith.
The honest limits
Deduplication is scoped per vault, and a vault maps to one cloud account and region, so nobody is pooling AWS, Azure, and GCP into a single deduplicated store. The savings are real within that boundary and they don’t compound across clouds.
This is also a cloud-first model. An estate still anchored on-prem gets partial coverage and should weigh that before moving its backup program.
Frequently asked questions
Why does an S3 bucket backup cost more in its second year?
Version history and replicated copies accumulate rather than reset, so year two carries year one’s retained versions plus its own. Most teams see backup storage growth outpace primary data growth by a wide margin once a full retention cycle has completed.
Does deduplication work across AWS, Azure, and GCP in one pool?
Not into one cross-cloud pool. Deduplication is scoped per vault, and a vault maps to one cloud account and region, though within a vault cross-dataset deduplication stores a shared block once.
Is lifecycle tiering enough to control S3 backup spend?
Tiering helps at the margin and can reduce long-term storage costs by up to 30 percent, and it moves bytes between price points rather than reducing how many bytes exist. Deduplication is the lever that changes the byte count.
Should cross-region replication be budgeted as backup or disaster recovery?
Budget it as disaster recovery. It protects against regional failure and copies corruption faithfully, so it doesn’t function as an independent recovery point on its own.
Where this goes
Backup budgets were set when the answer to risk was another copy. That reflex is expensive at cloud scale and it has stopped scaling with the data.
The teams getting this right in 2026 are the ones who stopped asking how many copies they hold and started asking how many distinct bytes they’re paying to keep. The answer is usually far smaller than the invoice suggests.
