Modeling the Cost of a Full Archive Restore
Sooner or later somebody asks what it would cost to get everything back. The question comes from a migration plan, a disaster-recovery review, or a funder wanting to know the archive is not a one-way door — and answering it with a per-gigabyte multiplication understates it by a factor that depends entirely on how the archive is laid out. This walkthrough builds the full model for a real spatial archive, including the terms that only appear at scale.
The Six Terms of a Full Restore
Retrieval pricing is the term everyone models. The other five are what turn a plausible estimate into a wrong one.
Step-by-Step Procedure
Step 1 — Model the terms explicitly
def full_restore_cost(tb, objects, days_available=30, egress=False, tier="bulk"):
gb = tb * 1024
retrieval_rate = {"bulk": 0.0025, "standard": 0.01, "expedited": 0.03}[tier]
request_rate = {"bulk": 0.025, "standard": 0.05, "expedited": 10.00}[tier] / 1000
terms = {
"retrieval": gb * retrieval_rate,
"requests": objects * request_rate,
"temp_storage": gb * 0.023 * (days_available / 30), # standard rate while available
"egress": gb * 0.085 if egress else 0.0,
"compute": tb * 0.95, # read + checksum, measured
}
terms["total"] = sum(terms.values())
return terms
for tier in ("bulk", "standard", "expedited"):
c = full_restore_cost(400, 412_000, tier=tier)
print(f"{tier:>10}: ${c['total']:>12,.0f} retrieval ${c['retrieval']:,.0f} "
f"temp ${c['temp_storage']:,.0f} requests ${c['requests']:,.0f}")Step 2 — Model time as well as money
A full restore is rate-limited, not just priced. Restore throughput per account, object count, and the availability window interact: a window too short forces re-restores, and a window too long multiplies the temporary-storage term.
Step 3 — Test the model on a slice before quoting it
# Restore 1% of the archive and measure every term against the invoice
aws s3control create-job --account-id 123456789012 \
--operation '{"S3InitiateRestoreObject":{"ExpirationInDays":14,"GlacierJobTier":"BULK"}}' \
--manifest file://restore-slice-1pct.json \
--report file://restore-slice-report.json \
--priority 5 --role-arn arn:aws:iam::123456789012:role/archive-batch --region us-east-1
# Two weeks later, isolate the actual charges and compare with the model
aws ce get-cost-and-usage --time-period Start=2026-08-01,End=2026-08-31 \
--granularity MONTHLY --metrics UnblendedCost --group-by Type=DIMENSION,Key=USAGE_TYPE \
--filter '{"Tags":{"Key":"project","Values":["restore-drill"]}}'Extrapolating a measured 1% is far more defensible than extrapolating a price list, and it captures the terms the model forgot.
Validation & Verification
python -m archive.cost restore-model --tb 400 --objects 412000 \
--window-days 14 --tier bulk --compare-actuals restore-slice-actuals.json
# modelled (1% slice) $29.73
# actual (1% slice) $31.40 (+5.6%)
# extrapolated full $3,140 ± 6%
# MODEL ACCEPTEDExpected output is agreement within roughly ten percent. A larger gap usually means a term is missing entirely — most often the temporary-copy storage, which does not appear in any retrieval price list.
Troubleshooting
| Symptom | Root cause | Fix |
|---|---|---|
| Estimate far below the invoice | Temporary-copy storage omitted | Add it; it often exceeds retrieval for long windows |
| Restore stalls partway | Account-level restore rate limits | Wave the job; lower its priority; expect days, not hours |
| Second retrieval charge appears | Availability window expired mid-processing | Size the window to the processing time plus margin |
| Egress dwarfs everything | Processing runs outside the archive’s region | Move the compute to the data; egress is avoidable, not inherent |
| Model right, timing wrong | Throughput modelled as unlimited | Measure restore throughput on the slice and extrapolate that too |
Operational Execution Checklist
The Numbers Worth Quoting Alongside the Total
A single total answers the question and rarely settles it. Four derived figures turn the model into something a decision can be made from, and each is a division away once the model exists.
Lead with the working-set figure and keep the full-restore total as the ceiling. The ceiling answers the governance question about whether the archive is retrievable at all; the working-set figure answers the operational one about what a real incident costs.
Restore Throughput Is a Constraint, Not a Cost
Money is only half the answer to “could we get everything back?”. The other half is elapsed time, and it is governed by limits that no budget removes: per-account restore rate, the number of objects the platform will process concurrently, and the availability window each wave occupies. A model that reports a dollar figure without a duration invites a plan that cannot be executed.
Restore throughput on a large archive is dominated by object count rather than by volume, because each restore is a request that enters a queue. In practice a well-parallelised job sustains a few thousand restore initiations per minute and completes waves at the tier’s latency, which puts a 400,000-object archive at somewhere between two and five days to fully restore even when nothing goes wrong. Adding workers does not compress that meaningfully — the limit is the service’s, not yours.
Two consequences follow for planning. First, a full restore is a project rather than an operation: it needs a schedule, a wave plan, and someone tracking completion against a manifest, exactly as the backlog replication described elsewhere in this section does. Second, the temporary-copy storage term scales with how long the whole project takes, not with how long one wave takes — objects restored on day one are still occupying paid temporary storage on day five unless their window was sized tightly, which pulls in the opposite direction from the safety margin each wave wants.
The practical resolution is to wave the restore by priority rather than by convenience: the working set first with a short window, then the remainder in waves sized so each is consumed before the next begins. That keeps the peak temporary-storage footprint to roughly one wave rather than the whole archive, which for a 400 TB restore is the difference between a few hundred dollars and several thousand.
Where the Model Meets the Retention Policy
A full-restore model quietly assumes that everything in the archive is restorable, and retention-locked material complicates that in one specific way: a compliance-mode object cannot be deleted, so the temporary copies produced by restoring it are additional storage on top of an object that cannot be removed to compensate. For archives where a large share of the holding is under lock, the temporary-storage term should be modelled at the full archive size rather than at the working set’s.
The second interaction is subtler and matters for migrations. Restoring an archive in order to move it elsewhere does not release the original until its minimum storage duration has elapsed, so the migration pays for both copies during the overlap. On a 180-day minimum that overlap can be most of a year, and a migration plan that models only the destination’s cost understates the total by roughly the source’s annual storage line.
Neither of these makes a full restore infeasible; both make the naive estimate wrong in the same direction. Modelling them explicitly — temporary storage against the full holding, and a stated overlap period for any migration — produces a figure that survives contact with the invoice, which is the only test a cost model has to pass.
Frequently Asked Questions
Would anyone ever restore an entire archive?
Rarely all at once, and the number still matters. It is the figure a migration plan needs, the ceiling a disaster-recovery review asks about, and the quantity that tells you whether the archive is genuinely retrievable or merely stored. Knowing it also tends to change layout decisions: an archive whose full restore is unaffordable is one whose partitioning is doing too little work.
Is expedited retrieval ever worth modelling?
For a full restore, no — the request charge alone makes it an order of magnitude more expensive, and no full-archive scenario needs minutes. It belongs in the model for targeted incident restores, where a handful of objects are needed immediately and the total is trivial.
How does this change for an archive in an instant-retrieval class?
The restore step disappears, which removes the request and temporary-storage terms entirely and leaves retrieval, compute and any egress. The retrieval rate is higher per gigabyte, so the full-restore total is often similar — the difference is that it can be done incrementally, on demand, with no window to manage.
Does the model change if the archive spans several storage classes?
Yes, and it becomes a sum rather than a single calculation. Each class has its own retrieval rate, request rate and restore latency, so a mixed archive is modelled per class and added — which usually reveals that one class dominates the total in a way the blended figure hid. The class holding the most objects, rather than the most bytes, is often the one driving the request term.
How should the compute term be estimated?
From a measured read of a representative sample rather than from an instance price. What the compute is doing — reading, checksumming, and often validating structure — runs at a rate you can measure in an hour, and multiplying that rate by the archive size is far more accurate than reasoning about instance types. In practice it is the smallest term in the model and rarely worth refining further.
Is a full restore ever the right response to an incident?
Almost never. Incidents affect a collection, a prefix or a time window, and the targeted restore that addresses them is orders of magnitude cheaper and faster. The full-restore figure exists to answer a governance question about retrievability and to price a migration — treating it as an incident-response plan is what leads to a recovery that takes days when it could have taken hours.
Two Scenarios Worth Modelling Alongside the Full Restore
The full-restore figure is the ceiling, and two scenarios below it are asked about far more often. Modelling all three from the same terms costs nothing extra and gives a much more useful answer than the ceiling alone.
The first is the collection restore: everything in one collection, typically a few percent of the archive, requested because a project needs the historical baseline or because a defect was found in a derived product and the source must be re-processed. Its cost is the full model applied to that collection’s volume and object count, and its duration is usually a single wave rather than a project. For most archives this lands between tens and a few hundred dollars, which is small enough that the answer to “can we do this?” is almost always yes and the useful part of the model is the elapsed time rather than the money.
The second is the audit restore: a stratified sample across the whole archive, requested to satisfy an integrity or compliance review. It touches many collections and few bytes, which inverts the usual cost shape — the request term dominates, and the retrieval term is negligible. That inversion is worth showing, because it is the case where consolidating small objects pays most obviously and where a naive per-gigabyte estimate is most badly wrong.
Both scenarios also stress different parts of the operational path. A collection restore exercises the wave mechanics and the availability window; an audit restore exercises per-object handling and the completion tracking that a manifest-driven job needs. Running each once a year, at small scale, keeps both paths warm and produces measured figures that make the full-restore extrapolation credible.
Report the three together, in ascending order, with the elapsed time beside each. A reader who sees that a collection comes back in six hours for forty dollars, an audit sample in a day for twelve, and the entire archive in four days for three thousand has enough to plan with — which the ceiling alone never gives them.
How does the model change for an archive that has never been fully read?
It becomes more important rather than less. An archive nobody has restored at scale has untested assumptions everywhere: restore quotas nobody has hit, credentials nobody has exercised, and an object-size distribution whose effect on request charges has never been observed. The one-percent slice test is where those assumptions meet reality, and running it on an untested archive frequently uncovers an operational problem — a missing permission, an unexpected rate limit — that matters far more than the cost figure it was run to produce.
Should the model be shown to whoever funds the archive?
Yes, with the working-set figure leading and the ceiling stated. Funders reasonably want to know that a preservation archive is retrievable, and a modelled figure supported by a measured slice is a far better answer than an assurance. It also reframes a conversation that otherwise focuses entirely on storage cost: retrievability is the thing being paid for, and pricing it makes that visible.
What does the model say about archives that are cheap to store and expensive to retrieve?
That the trade is real and should be chosen deliberately per collection rather than adopted as a default. Deep Archive is the right home for material whose retrieval would be an extraordinary event, and the wrong home for anything read even annually — and the model is what turns that judgement into an arithmetic comparison. The failure mode it prevents is an archive optimised entirely for storage cost that nobody can afford to read.
How does the model handle collections in different regions?
As separate models added together, with the egress term evaluated per region against where the processing will run. An archive spread across regions for residency reasons cannot process everything in one place, so the compute either moves or the bytes do — and the model is where that choice gets priced rather than assumed.
Should the restore model include the cost of validating what comes back?
Yes, as part of the compute term. A restore that is not validated has not established that the archive is intact, only that it is retrievable, and the structural check is a few percent of the read cost. Folding it in also means the model prices the thing the exercise is usually for: proving the archive is both there and usable.
Is the model worth building for a small archive?
Yes, and it takes an hour. The terms are the same at any scale, and a small archive gets the same benefit — a stated retrievability figure — for far less effort. What changes with scale is only whether the answer is comfortable.
How often should the model be re-run?
Annually, and after any change to the archive’s class mix or object-size distribution. Both inputs move slowly and both move the answer materially, so a figure quoted from three years ago is likely to be wrong in a direction nobody has checked.
Related
- Spatial Archive Cost Modeling — the parent reference where this model supplies the per-query column.
- Forecasting Multi-Year Storage Costs for Growing Imagery Archives — the sibling model for the storage side.
- Replicating Glacier-Class Spatial Objects Across Regions — the same restore-wave mechanics applied to replication.
- Evaluating Glacier Deep Archive for LiDAR Point Clouds — restore economics for the asset class that dominates most archives by volume.
Up one level: Spatial Archive Cost Modeling.