Skip to content

AWS Updated 2026-10-07

S3 storage classes decoded: Standard, IA, One Zone, Glacier tiers, and the retrieval bills

Choose the right Amazon S3 storage class for each kind of data. See what Standard, Standard-IA, One Zone-IA and the three Glacier tiers really cost once retrieval fees, minimum storage periods and per-object overhead are added.

If you store data in Amazon S3, the AWS service that keeps files as objects in buckets, you have to decide which storage class each kind of data belongs in. This comparison is for developers and operators who set up buckets or answer for the AWS bill. A storage class is the pricing tier S3 bills an object under. The cheaper classes charge less per gigabyte stored. In exchange, they add a retrieval fee each time you read data back, and a minimum storage period you pay for even if you delete the object early. That is why a bucket moved to a “cheaper” class can end up costing more. Our recommendation is to keep frequently read or unpredictable data in S3 Standard, which has neither charge. Move data to a cheaper class only after you have measured how rarely it is read.

What you are deciding

The real question is not “which class is cheapest” — it is “how often will this data be read, by what, and in what quantity when it is”. Here is the honest rundown:

  • S3 Standard — the default. Highest per-GB storage price, zero retrieval fee, no minimum duration, replicated across three or more Availability Zones. If the data is read regularly or unpredictably, this is usually where it belongs.
  • S3 Standard-IA (Infrequent Access) — meaningfully cheaper per GB stored, but you pay a per-GB fee every time you read, there is a 30-day minimum storage duration (delete earlier and you are billed for the remainder), and objects are billed as if they were at least 128 KB.
  • S3 One Zone-IA — Standard-IA economics with an extra discount for living in a single Availability Zone. If that AZ is lost, the data is gone. Only for data you can regenerate.
  • S3 Glacier Instant Retrieval — archive-level storage price with millisecond reads. The catch: a higher per-GB retrieval fee than Standard-IA and a 90-day minimum duration.
  • S3 Glacier Flexible Retrieval — cheaper again, but reads are asynchronous: you request a restore and wait minutes to hours depending on the tier you pay for. 90-day minimum. Bulk restores are free, which matters for large planned retrievals.
  • S3 Glacier Deep Archive — the cheapest class, restore times of 12 to 48 hours, 180-day minimum. For data you hope never to touch.
  • S3 Intelligent-Tiering — moves objects between tiers automatically for a per-object monitoring fee; covered honestly in S3 Intelligent-Tiering: when it saves money.

Two mechanics people miss. First, Glacier Flexible Retrieval and Deep Archive add roughly 32 KB of index data plus 8 KB of metadata per object, and you pay to store that overhead — archiving millions of tiny files can cost more than it saves. Second, exact prices vary by region, so a class that pencils out in us-east-1 may look different in ca-central-1; check the numbers for your region in the S3 documentation and model them at calculator.aws.

What to check first

  • Actual read pattern. Not what the team believes — what request metrics show. “We never touch it” often turns out to mean a nightly job reads all of it.
  • Object size distribution. Per-object minimums and overhead punish small objects hard.
  • Versioning. If versioning is on, noncurrent versions may be most of your bill, and no class change fixes that without lifecycle rules.
  • The restore scenario. Restoring one file from Deep Archive is trivial. Restoring 40 TB after a ransomware event is a bill and a 48-hour wait — price that before you commit.
  • Region. Storage, retrieval, and transfer prices all differ by region.

How to verify

See what each bucket currently holds per class using the free CloudWatch storage metrics:

# Bytes stored in Standard-IA for one bucket (repeat per StorageType)
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 \
  --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=my-bucket Name=StorageType,Value=StandardIAStorage \
  --start-time 2026-07-01T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 86400 --statistics Average

Check a single object’s class and totals for a prefix:

aws s3api head-object --bucket my-bucket --key backups/db-2026-06-01.tar.gz

aws s3 ls s3://my-bucket/backups/ --recursive --summarize | tail -2

In the console, S3 > your bucket > Metrics shows storage by class over time, and S3 > Storage Lens > Dashboards shows it across the whole account.

The approach

  1. Leave hot and unknown data in Standard. The discount classes only pay off when the access pattern is genuinely known. Guessing wrong costs more than waiting a month for real data.
  2. Move backups and compliance data past 30 days to Standard-IA. The sweet spot: objects larger than 128 KB, kept longer than 30 days, read a handful of times a year.
  3. Use One Zone-IA only for data you can rebuild. Secondary backup copies, transcoded media, cache exports. Never the only copy of anything that matters.
  4. Pick Glacier Instant Retrieval for cold data that must stay instantly readable. Old user uploads, media libraries, audit evidence someone may click on tomorrow.
  5. Reserve Flexible Retrieval and Deep Archive for true archives. Price the full-restore case first, and decide who approves an expedited restore before you need one.
  6. Automate every transition with lifecycle rules, not application code. The patterns are in S3 lifecycle rules: cutting storage spend safely.

When this is the wrong move

If the bucket holds a few hundred gigabytes, class optimization saves lunch money and costs engineering hours — skip it. If the data is re-read close to monthly, IA retrieval fees can cancel the storage discount entirely. If the bucket is millions of small files, per-object overhead and transition request charges can make Glacier a net loss. And short-lived data (under 30 days) should simply stay in Standard, because every discount class bills you for the minimum duration anyway.

Common mistakes

  • Deleting IA or Glacier objects early and being surprised by the early-delete charge for the unused minimum duration.
  • Forgetting that retrieval bills twice: per GB retrieved and per thousand requests.
  • Sending small, numerous log files to Glacier, where per-object overhead exceeds the savings.
  • Putting the only copy of production data in One Zone-IA to save a few percent.

Keeping it under control

  • Review Storage Lens monthly — class distribution per bucket, growth trend, noncurrent version bytes.
  • Add ObjectSizeGreaterThan filters to lifecycle transitions so small objects stay put.
  • In Cost Explorer, filter on usage types containing EarlyDelete and Retrieval — those two lines are where class decisions go wrong.
  • Re-run the numbers after any large restore or delete; the right class changes as the data ages.

Storage classes are a genuinely good deal when the access pattern is measured rather than assumed, and a slow leak when they are set once and forgotten. If nobody on your team truly owns the AWS environment end to end, that is the root of most of these problems — Stack Harbor runs AWS accounts daily under AWS Operations, and you can book an AWS review.