All cheat sheets
Storagecheat sheet

S3 Glacier Select

Run SQL directly against archived Glacier data and retrieve only the matching rows — skip the restore-everything-then-query dance. A 100 GB archive queried for 2 GB of records: ~$0.43 instead of a full restore plus temporary storage.

Last reviewed: July 11, 2026

TL;DR: Glacier Select runs SQL against data while it's still archived — AWS filters inside Glacier and returns only matching rows, so a quarterly audit pull no longer means restoring a 100 GB archive to fish out 2 GB of records. The catch that bites everyone: it only works if you archived queryable formats (CSV, JSON Lines, Parquet; server-side encryption only) — a decision you make before archiving, not after.

The numbers

Querying 2 GB of records out of a 100 GB archive:

Path Cost
Full restore + temp Standard storage + query ~$1.00 restore + ~$2.30/mo temp storage + egress
Glacier Select (scan + return) ~$0.43

Retrieval tiers still apply to Select jobs: expedited 1–5 min, standard 3–5 h, bulk 5–12 h (cheapest — right for non-urgent audits). Field example: a fintech's quarterly audit pulls dropped ~90% in retrieval cost when "restore the whole month" became one WHERE customer_id = … query.

Do this

  1. Design archives to be queryable before you archive — this is 80% of the value:

    • Plain CSV, JSON Lines, or Parquet (Parquet best: size + queryability)
    • Whole-object GZIP at most; never per-record compression or ZIP bundles
    • Server-side encryption only — client-side encryption blocks Select forever
  2. For an existing queryable archive, query instead of restoring:

    aws s3api select-object-content --bucket archive-bucket \
      --key logs/2025-11.jsonl.gz \
      --expression "SELECT * FROM s3object[*] s WHERE s.customer_id = '12345'" \
      --expression-type SQL \
      --input-serialization '{"JSON":{"Type":"LINES"},"CompressionType":"GZIP"}' \
      --output-serialization '{"JSON":{}}' out.json
    

    Pick the bulk tier for anything plannable — audit and forensics requests rarely need the expedited premium.

  3. Keep an index of what's archived where (S3 Inventory) so incident-response can target the right three days of logs instead of scanning a year.

Gotchas

  • The #1 failure is format, discovered too late: ZIPped bundles, per-record compression, client-side encryption, or multi-line JSON archived years ago mean falling back to full restores anyway. Fix the pipeline now, not at audit time.
  • SQL is the same subset as S3 Select: filters, projections, simple aggregates — no JOINs, one object at a time.
  • Scan fees scale with archive size, not result size. Unselective queries on huge archives erode the win — selectivity is the whole point.
  • Latency is still Glacier latency. Even expedited is minutes; this is not an interactive query engine.

Skip this if

  • You need most of the archive anyway — a plain restore is simpler and comparable in cost.
  • You query the same archive repeatedly — that data doesn't belong in Glacier at all; move it to Glacier Instant Retrieval or Intelligent-Tiering.
  • The data is unstructured (images, video, binaries) — nothing for SQL to parse.

Run this audit with your AI assistant

Paste this into Claude, ChatGPT, or any agent that can run the AWS CLI with read-only credentials. It audits your account for exactly the waste this sheet describes — and changes nothing.

You are auditing an AWS account for Glacier Select opportunities and
query-readiness of its archives. Work READ-ONLY; report findings and
recommended (unapplied) changes only.

1. Locate archived structured data: buckets/prefixes with objects in
   GLACIER / DEEP_ARCHIVE storage classes (S3 Inventory if available,
   else list-objects-v2 samples with --query on StorageClass), filtered
   to queryable extensions (.csv, .json, .jsonl, .parquet).
2. Query-readiness check per archive family:
   - Format: plain CSV / JSON Lines / Parquet? Whole-object GZIP is OK;
     per-record compression, ZIP bundles, client-side encryption, or
     proprietary formats are NOT queryable — flag these, because the
     fix (re-archiving in a queryable format) must happen before the
     next audit needs them.
3. Identify restore-then-query patterns worth replacing: past restore
   activity (aws s3api list-objects-v2 --query for ongoing restores is
   limited — rely on user knowledge / Cost Explorer Glacier retrieval
   line items) where only slices of archives were needed.
4. Cost model for the report: full-restore path (restore fee + temp
   Standard storage + egress) vs Select path (~$0.01/request +
   ~$0.004/GB scanned bulk-tier + ~$0.01/GB returned; standard tier
   scan ~$0.008/GB). Same retrieval-tier latencies apply: expedited
   1–5 min, standard 3–5 h, bulk 5–12 h.

Report: archives table (prefix | class | size | format | queryable? |
est. $ full-restore vs Select for a 2% slice), the non-queryable
archives that need format fixes, and 2 example Glacier Select queries
for the top use case. Change nothing.
Works with any assistant that can run shell commands.

Want the guided version?

The S3 Glacier Select walkthrough covers this topic interactively — it asks about your setup, branches to what’s relevant, and quizzes you on the tricky parts. Free and anonymous.

Start the walkthrough