Evaluating Glacier Deep Archive for LiDAR Point Clouds

Evaluating Glacier Deep Archive for LiDAR point clouds is a decision about whether the cheapest archive class actually fits large LAZ and COPC collections, weighing a roughly twelve-hour restore latency against how often the points must be read, and comparing it honestly against Glacier Instant Retrieval and simply keeping COPC on a warm tier. This guide is for cloud architects and GIS archivists sitting on terabytes of aerial and terrestrial LiDAR who see Deep Archive’s sub-penny storage price and want to know the catch before they move a survey there. The catch is that point clouds are not write-once-read-never assets the way scanned paper is: reprocessing campaigns, re-classification, and derivative DEM generation pull the raw points back out on unpredictable schedules, and a Deep Archive restore that blocks a project for half a day plus a retrieval bill can dwarf the storage saved. The right answer depends on object sizing, retrieval cadence, and the analytical half-life of the collection.

Framing the Decision #

There is no single correct class for LiDAR; there is a correct class per collection given its read pattern. The matrix below compares the realistic candidates across the dimensions that actually move the total cost:

Restore Latency Against Analytical Need #

The first filter is blunt: can the workflow tolerate a half-day wait? Deep Archive’s standard retrieval returns objects in roughly twelve hours, and bulk retrieval can stretch toward forty-eight. For a legal-hold survey that will only ever be produced in response to a discovery request, that is irrelevant — nobody is blocked. For a raw point cloud that feeds a quarterly DEM refresh or an on-demand re-classification, twelve hours is a hard stop that stalls an entire pipeline. Measure the real read cadence first, ideally from the same access telemetry you would use for Setting Lifecycle Transition Thresholds from Query Telemetry; if a prefix shows any read within the last analytical cycle, it is not a Deep Archive candidate yet.

The COPC format complicates the picture in a useful way. A Cloud-Optimized Point Cloud supports HTTP range reads, so an analyst can pull a single octree node — one small spatial window — without downloading the whole tile. That advantage evaporates the instant the object sits in Deep Archive or Glacier Flexible, because the object must be fully restored before any byte is readable. Deep Archive throws away the entire benefit of having converted to COPC. If a collection is stored as COPC specifically so it can be windowed on demand, its natural homes are Glacier IR or a warm tier, never Deep Archive.

What a LiDAR Restore Actually Looks Like #

Point-cloud archives are unusual in that a “single dataset” is often tens of thousands of tiles, and a realistic request is for a contiguous block of them. That shape — many objects, all needed at once, each of moderate size — is exactly where restore request charges and per-object overhead become visible.

Retrieval cost is identical because it is priced per gigabyte, so the consolidation argument rests entirely on request charges, overhead, and the operational simplicity of tracking two hundred restores rather than three thousand. The counter-argument is selectivity: a query needing four tiles restores a whole 3.9 GB block. Block by acquisition area rather than by arbitrary count, so that the coarser unit still matches how the data is asked for.

Object Sizing and Retrieval Economics #

LiDAR archives fail Deep Archive economics through fragmentation. A single flight line tiled into thousands of small .laz files incurs a per-object overhead and a per-request retrieval charge on every restore, and Deep Archive bills a 180-day minimum duration on each object regardless of size. A collection of many small tiles restored together generates thousands of retrieval requests and, if any tile is deleted or overwritten before 180 days, a full early-deletion charge per object.

Consolidate before you cold-tier. Merge per-swath tiles into larger aggregated objects sized in the hundreds of megabytes to low gigabytes so the per-object overhead amortizes:

# Merge per-swath tiles into a single archive-grade LAZ before cold transition
pdal merge \
  s3://spatial-archive/lidar/2023/region_north/swath_*.laz \
  s3://spatial-archive/lidar/2023/region_north_merged.laz \
  --writers.las.compression=true

# Then transition the consolidated object, not the fragments
aws s3api copy-object \
  --bucket spatial-archive \
  --key lidar/2023/region_north_merged.laz \
  --copy-source spatial-archive/lidar/2023/region_north_merged.laz \
  --storage-class DEEP_ARCHIVE --metadata-directive COPY

Fewer, larger objects turn a punishing per-request restore into a handful of large transfers, and they make the 180-day minimum a rounding error rather than a repeated penalty. Compression choice compounds this: LAZ is already entropy-coded, so layering additional container compression buys little, but for the derivative GeoParquet and raster products the tuning in ZSTD Level Configuration for Spatial Files still moves the stored footprint. Price the full picture — storage plus restores plus request charges — with Spatial Archive Cost Modeling rather than comparing the headline per-gigabyte number alone.

Recommendation by Scenario #

• Raw LAZ under regulatory hold, no analytical reads expected for years — Deep Archive wins decisively once tiles are consolidated into large objects. The twelve-hour restore is acceptable because production is rare and deadline-driven, not interactive.
• Point clouds reprocessed on a quarterly or annual campaign — Glacier Flexible is the balance point: three-to-five-hour restores fit a planned campaign, and per-gigabyte storage is a fraction of warm without Deep Archive’s minimum-duration rigidity.
• COPC read sporadically for windowed analysis — Glacier IR keeps millisecond range reads alive at near-Glacier storage cost; Deep Archive would defeat the format’s entire purpose.
• Actively analyzed collections feeding live derivatives — keep COPC on STANDARD-IA warm. The storage premium is real but smaller than the retrieval fees and stalls that cold-tiering an active collection would generate.

The substrate decision underneath these classes — integrity APIs, egress pricing, and multipart thresholds — is itself a choice covered in Object Storage Selection for GIS Archives, and the same LiDAR that suits Deep Archive on one provider may price differently on another.

A subtlety that trips up first-time Deep Archive adopters is that restore is not free storage relief: the restored copy lives in a temporary bucket location and bills at the reduced-redundancy retrieval tier for its requested lifetime, on top of the retrieval charge, while the underlying object keeps accruing its Deep Archive rate. Restore only what a campaign genuinely needs, scope the restore Days to the campaign window rather than a generous default, and let the temporary copy expire on schedule. Treating a restore as a project-scoped, time-boxed event rather than a permanent un-archiving is what keeps the class economical.

Verifying a Restore Path Before You Commit #

Never move a collection to Deep Archive without proving you can get it back within the window your operations assume. Initiate a test restore and confirm the timing and the restored-copy expiry.

aws s3api restore-object --bucket spatial-archive \
  --key lidar/2023/region_north_merged.laz \
  --restore-request '{"Days":7,"GlacierJobParameters":{"Tier":"Standard"}}'

aws s3api head-object --bucket spatial-archive \
  --key lidar/2023/region_north_merged.laz \
  --query "{restore:Restore, class:StorageClass}"

Expected output while the restore is in progress, then once complete:

{
  "restore": "ongoing-request=\"true\"",
  "class": "DEEP_ARCHIVE"
}
# ~12 hours later:
{
  "restore": "ongoing-request=\"false\", expiry-date=\"Wed, 22 Jul 2026 00:00:00 GMT\"",
  "class": "DEEP_ARCHIVE"
}

The ongoing-request=\"false\" with a populated expiry-date confirms a temporary readable copy now exists; the underlying class stays DEEP_ARCHIVE. If the restore has not completed within your operational SLA, the collection is mis-tiered for its read pattern.

The 180-Day Clock #

Deep Archive bills a minimum of 180 days per object regardless of how long it actually stays. That clock is what punishes an over-eager transition, and it compounds when a correction moves the object again before the clock expires.

The asymmetry — cheap to wait, expensive to be wrong — is why transition thresholds for point-cloud archives should be set conservatively and revisited annually rather than tuned aggressively. It is also why a re-survey schedule, if one exists, belongs in the tiering decision: an area due for re-survey in four months should not enter Deep Archive today.

Diagnosing Mis-Tiered LiDAR #

Operational Execution Checklist #

• Measure the collection’s real read cadence from access telemetry before assuming it is cold.
• Consolidate per-swath tiles into large aggregated objects so per-request and minimum-duration costs amortize.
• Keep any collection stored as COPC for windowed reads out of Deep Archive and Glacier Flexible.
• Model storage plus restore plus request charges together, not the headline per-gigabyte price alone.
• Run a timed test restore and confirm it completes inside your operational SLA before committing the collection.
• Cold-tier only stabilized, final point clouds; stage active reprocessing on warm to avoid early-deletion penalties.
• Match the class to the scenario: Deep Archive for unread legal-hold LAZ, Glacier IR for sporadic COPC, warm for active analysis.

Frequently Asked Questions

Related #

• Up: Object Storage Selection for GIS Archives — the parent reference for matching spatial workloads to a storage substrate.
• AWS S3 vs Azure Blob for GIS Cold Storage — cross-provider comparison of the cold classes evaluated here.
• Setting Lifecycle Transition Thresholds from Query Telemetry — deriving the read cadence that decides whether LiDAR is truly cold.
• Tuning ZSTD Compression for GeoParquet Archives — compression tuning for the derivative products these point clouds generate.
• Spatial Archive Cost Modeling — pricing storage, restore, and request charges as one total rather than a per-gigabyte headline.

Part of the Spatial Data Archival knowledge base.