Google Cloud Storage Archive vs AWS Glacier for GIS Archives
Both platforms will store a petabyte of imagery for a few thousand dollars a month, and the headline per-gigabyte prices are close enough that they should not decide anything. What differs — and what actually shapes a spatial archive — is the retrieval model, the minimum-duration rules, and how each behaves when an archive is made of many medium-sized objects rather than a few enormous ones. This comparison is for the cloud architect choosing between them for a new geospatial holding.
The Difference That Matters Most: Retrieval Model
GCS Archive is a storage class with no restore step: objects are read directly, at millisecond latency, at a higher per-gigabyte retrieval charge. Glacier Flexible Retrieval and Deep Archive require a restore that takes hours. That single distinction reshapes everything downstream — range reads, COG and COPC access patterns, catalogue design, and the recovery-time objective a disaster-recovery plan can promise.
Comparing on the Terms That Move the Bill
Per-gigabyte storage is within a factor of two across the archive classes on both platforms. The terms that separate them for a spatial archive are minimum duration, minimum billable size, per-object overhead and retrieval pricing — and they interact with object size, which for a partitioned spatial archive is a design choice rather than a given.
| Dimension | GCS Archive | S3 Glacier Flexible | S3 Deep Archive |
|---|---|---|---|
| Storage $/GB-month | ~$0.0012 | ~$0.0036 | ~$0.00099 |
| Minimum duration | 365 days | 90 days | 180 days |
| Minimum billable size | none | 40 KB | 40 KB |
| Per-object overhead | none | 32 KB + 8 KB | 32 KB + 8 KB |
| Retrieval $/GB | ~$0.05 | ~$0.01 | ~$0.0025 |
| Restore latency | none | 3–5 h | up to 12 h |
The minimum-duration row is the sharpest difference and the one most often missed: GCS Archive bills a full year per object regardless of how long it stays, so an archive that re-tiers or corrects objects within their first year pays for storage it did not use. Glacier’s ninety days is far more forgiving of a tiering policy still being tuned.
Which Platform Suits Which Archive
Validating the Choice Before Committing
Model both platforms against your own object-size distribution and query rate, then test the operational behaviours that pricing pages do not describe.
# Same test corpus on both platforms: 500 objects, real size distribution
gsutil -m cp -r bench/ gs://spatial-archive-bench/ && \
gsutil rewrite -s ARCHIVE "gs://spatial-archive-bench/**"
aws s3 cp bench/ s3://spatial-archive-bench/ --recursive --storage-class GLACIER
# The behaviour that matters: a windowed read from the archive class
time gdalinfo -json /vsigs/spatial-archive-bench/ortho_n5432.tif | jq .size
# GCS Archive: returns in ~180 ms
time gdalinfo -json /vsis3/spatial-archive-bench/ortho_n5432.tif | jq .size
# S3 Glacier: fails — InvalidObjectState, restore requiredThat contrast is the comparison in one command, and it is worth running rather than reading: it decides whether the archive’s access pattern survives the storage class at all.
Troubleshooting the Comparison Itself
| Symptom | Root cause | Fix |
|---|---|---|
| Cost model favours whichever platform was modelled second | Object-size distribution not applied to both | Use one corpus and one distribution across both models |
| GCS looks far cheaper on retrieval | Retrieval rate modelled as zero | Archives are read; use the measured query rate from access logs |
| Glacier looks cheaper and the workload stalls | Restore latency not represented in the model | Model time as well as money; a stalled analysis has a cost |
| Migration estimate looks affordable | Egress from the current platform omitted | Egress dominates any cross-platform migration at petabyte scale |
| Minimum duration ignored | Modelled as monthly storage only | Multiply by the minimum duration for objects that may move again |
Operational Execution Checklist
Revisiting the Decision Without Migrating
A platform choice made for a growing archive should be reviewed periodically, and review does not have to mean migration. Three lighter moves capture most of the benefit of a reconsideration while the bulk of the archive stays where it is.
Keep the review itself cheap — an afternoon against current prices and the archive’s own measured object-size distribution and query rate. The value is in knowing whether the original reasoning still holds, which is a different question from whether to act on it.
Frequently Asked Questions
Is a multi-cloud archive worth the complexity?
Rarely, and only for a specific reason — a regulator or funder requiring provider independence, or a genuine commercial hedge at a scale where it moves the budget. The costs are two IAM models, two lifecycle implementations with different semantics, and a synchronisation job whose silent failure is a copy nobody can trust. For most institutions, a second account and region on one provider covers the realistic risks.
How do the immutability features compare?
Both offer write-once retention: S3 Object Lock in governance and compliance modes, and GCS bucket lock with retention policies plus per-object holds. The practical differences are granularity and reversibility — Object Lock’s per-object retention dates and the distinction between its two modes give finer control than a bucket-wide retention policy, which matters when one bucket holds material under several different mandates.
Does GDAL support both equally well?
Both have mature virtual filesystem drivers with range-read support, and neither is a friction point in normal use. The differences are in configuration detail — credential handling, request concurrency defaults, and how each surfaces a class that cannot be read directly. Test with your actual GDAL version rather than assuming parity, particularly for writes.
How do the two platforms compare on lifecycle rule expressiveness?
Both support age-based transitions and prefix filters; the differences are in the details that matter for spatial data. Object tags as a filter dimension, the granularity of noncurrent-version rules, and how each handles multi-part upload cleanup all differ enough that a rule set does not translate mechanically. Rewriting them is a day of work and a source of subtle differences, which is a real migration cost that pricing comparisons omit.
Which is easier to audit?
Both produce inventory reports adequate for a fixity programme, and the practical difference is in what fields those reports carry by default. Check specifically that the checksum, storage class and retention state fields are available before committing, since those three drive the audit design described elsewhere in this section.
Does the choice constrain future format decisions?
Not meaningfully. Both store opaque objects and both support ranged reads in their instant-access classes, so COG, COPC, GeoParquet and FlatGeobuf all behave the same way on either. The constraint that does bite is the restore model, which decides whether range-readable formats are usable in the coldest class at all — and that is a class choice rather than a platform one.
Does either platform have an advantage for public data distribution?
Both support requester-pays and public access, and the meaningful difference is in the ecosystem around them rather than in the storage. Where the archive’s users already work predominantly on one platform, colocating removes egress from their side of the transaction entirely, which is often worth more than any storage-price difference. That is a question about the audience rather than about the platform.
How should the comparison be documented?
As a dated decision record naming the inputs — object-size distribution, query rate, access pattern, residency constraints — and the conclusion. The inputs are what change; the conclusion follows from them. A record structured that way makes the annual review a matter of checking whether the inputs still hold rather than repeating the whole analysis.
Is there a hybrid arrangement worth considering?
One: keeping the archive of record on the platform that prices deep storage best, and the served delivery copies on whichever platform the archive’s users already work in. It costs a synchronisation job for a small fraction of the volume and removes egress from the user’s side entirely, which for a public archive is often the largest single improvement available.
Related
- Object Storage Selection for GIS Archives — the parent topic covering class selection independently of provider.
- AWS S3 vs Azure Blob for GIS Cold Storage — the sibling comparison, including the rehydration difference.
- Evaluating Glacier Deep Archive for LiDAR Point Clouds — the restore economics for the largest asset class.
- Spatial Archive Cost Modeling — the model both platforms should be evaluated in.
Up one level: Object Storage Selection for GIS Archives.