Backup to object storage: what the egress bill does to a restore plan

The restore is the line nobody budgets for

A backup plan is priced twice. The first price is the storage bill, which arrives every month and is easy to forecast. The second is the restore, which arrives once, usually in the worst week of the year, and is billed as data transfer rather than as storage.

Amazon's S3 pricing page separates the two explicitly. It lists storage pricing, request and data retrieval pricing, data transfer and transfer acceleration pricing, data management and insights feature pricing, replication pricing, and transform and query feature pricing as distinct cost components, and states that there is no minimum charge and that you pay only for what you use.

That separation is the whole decision. A team that sizes its backup budget from the per-gigabyte storage rate alone has priced the part of the bill that does not move. The part that moves is the restore, and it moves at the moment the team can least afford to argue about it.

The reader arriving from the newsletter has a specific question: for a 50 TB backup with one full restore a year, which provider and which storage class leave the smallest total, and at what restore volume does a second copy in another tier beat paying the egress.

What Amazon S3 actually charges for

The S3 pricing page is unusually clear about the mechanics and silent on the numbers in the copy supplied here. It states that the rate charged for storing objects depends on the objects' size, how long they were stored during the month, and the storage class, and it names the classes: S3 Standard, S3 Intelligent-Tiering, S3 Standard-Infrequent Access, S3 One Zone-Infrequent Access, S3 Express One Zone, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval and S3 Glacier Deep Archive.

It also warns about a charge that surprises teams moving data in rather than out. There are per-request ingest charges when using PUT, COPY or lifecycle rules to move data into any S3 storage class, and the page tells readers to consider the ingest or transition cost before moving objects into any class.

S3 Intelligent-Tiering carries its own shape. The page describes a monthly monitoring and automation charge per object stored, states that there are no retrieval charges in that class, and states that no additional tiering charges apply when objects are moved between access tiers. It also notes that auto-tiering has a minimum eligible object size of 128 KB, so smaller objects are not monitored.

The per-gigabyte rates themselves are rendered on the page from a pricing endpoint rather than printed in the text, so this article does not quote them. A buyer should ask the account team for the current per-GB rate for each class in the region they will use, the per-1,000-object monitoring charge for Intelligent-Tiering, and the per-GB outbound data transfer rate, and get all three in writing.

The retrieval window is the real constraint

Storage classes are usually compared on price per gigabyte. For backup they should be compared on recovery time, because that is what the class actually controls. The S3 page describes S3 Glacier Instant Retrieval as being for long-lived archive data accessed once a quarter with instant retrieval in milliseconds, and S3 Glacier Flexible Retrieval as being for long-term backups and archives with retrieval options from 1 minute to 12 hours.

S3 Glacier Deep Archive is described as long-term data archiving accessed once or twice a year and restorable within 12 hours. Those three sentences set three different recovery point objectives, and a restore plan that assumes instant access while storing in Deep Archive has a documented gap between what it pays for and what it promises.

The 50 TB restore in the newsletter's scenario is the test. A full restore of that volume from a class with a 12-hour retrieval window is a planned event with a start time, not an incident response. A team whose recovery time objective is measured in hours needs the class that matches it, and pays the storage rate that goes with it.

This is where the second copy earns its place. If the primary backup sits in a cheap archive class and the restore has to be fast, the choice is between paying to move 50 TB out of the archive and keeping a second copy in a tier that restores quickly. The comparison is the egress and retrieval charge against the storage rate of the second copy, and it is arithmetic a buyer can do once they have the per-GB numbers.

Where the two-provider comparison breaks down

The newsletter's scenario asks for a comparison across two providers. Only one provider's pricing page is in front of this article, and it does not print per-gigabyte rates in its text, so a two-column price comparison would be invented. What can be compared honestly is the billing structure, because that is what the page documents.

Amazon S3 bills on six named components: storage, requests and data retrieval, data transfer and transfer acceleration, data management and insights features, replication, and transform and query features. A rival object store that folds requests into storage, or that does not charge for retrieval, will produce a different total for the same 50 TB and the same one restore a year even if the headline storage rate is identical.

The practical consequence is that the shortlist has to be built from the billing mechanics, not the sticker rate. A provider that charges per request will make a backup tool that writes many small objects expensive; a provider that charges for retrieval will make the annual restore expensive; a provider that charges for outbound transfer will make the restore expensive twice if the data leaves the region.

The question to put to each vendor is the same three-part one: the per-GB storage rate for the class that meets the recovery objective, the per-request and per-retrieval charge that applies to a full restore, and the per-GB outbound transfer rate. Any vendor that will not put those three numbers in a quote has not been compared.

What to ask before the restore is real

The S3 documentation adds a detail that matters for anyone designing the bucket layout around a restore. General purpose buckets exist in a global namespace, so each bucket name must be unique across all AWS accounts in all Regions within a partition, and AWS currently has four partitions: aws for standard Regions, aws-cn for China Regions, aws-us-gov for GovCloud, and aws-eusc for European Sovereign Cloud.

That is not a cost fact, but it is a restore fact. A plan that assumes a bucket name can be recreated in a second account or a second partition during a recovery has to check the namespace rule first, because the name may already be taken or may not exist in the partition the recovery is running in.

The cost side has a similar trap in the lifecycle rules. The S3 page states that per-request ingest charges apply when using PUT, COPY or lifecycle rules to move data into any storage class, so a lifecycle policy that ages backups into a cheaper class is itself a billable event, and a policy that churns objects between classes can cost more in requests than it saves in storage.

None of this makes object storage a bad backup target. It makes the restore the thing to price first, and the storage rate the thing to price second.

The decision rule

Choose S3 Glacier Flexible Retrieval for the primary backup copy if the recovery time objective can absorb a retrieval window of 1 minute to 12 hours, because the class is documented for long-term backups and archives and the slower window is what buys the lower storage rate.

Choose S3 Glacier Deep Archive for a second copy if the data is genuinely accessed once or twice a year and a 12-hour restore is acceptable, because at that access pattern the second copy's storage rate is the cheaper way to protect against losing the primary, and the egress is only paid if both copies are needed.

Choose S3 Intelligent-Tiering if the access pattern is unknown or changing and the objects are larger than 128 KB, because the page states there are no retrieval charges in that class and no additional tiering charges when objects move between access tiers, which removes the retrieval surprise at the cost of a per-object monitoring charge.

Wait on any of them until the vendor has quoted the per-GB storage rate, the per-request and per-retrieval charge for a full 50 TB restore, and the per-GB outbound transfer rate, because without those three numbers the annual restore is an unpriced line and the comparison is a guess.