The cheapest S3 class is the one you never open

A team moves a few million objects out of S3 Standard. Storage per gigabyte drops. Finance is happy. Two months later someone runs a job that reads most of the prefix. The invoice does not look cheaper. It looks like a retrieval fee with a storage class attached.

That is the usual S3 mistake. People optimize the price of keeping a byte. The bill also charges you for touching it, for deleting it too soon, and for objects that are smaller than the class wants to bill.

If you remember one thing: pick a class for how often the object is read, how fast the read must be, and whether you can rebuild the object if a zone disappears. The rest is matching those three answers to a class AWS already named.

Official reference: Understanding and managing Amazon S3 storage classes. Pricing lives on Amazon S3 pricing. This article does not quote dollar amounts. Those change by region and date. The shape of the trade-off does not.

Frequency is the whole plot

S3 Standard is the default. Upload an object, skip the storage-class header, you are in Standard. Millisecond GET. Designed for 99.99% availability across at least three Availability Zones. No minimum storage duration. No minimum billable object size. You pay more per GB stored than the archive classes, and you do not pay a per-GB retrieval fee for a normal read.

Use it when the object is part of the request path: product images, session artifacts, the dataset the API hits this week, anything you would be embarrassed to restore from an archive while a user waits.

Do not use it as a ten-year attic. You can, technically. You will pay Standard rates for data nobody opens.

The trap on the other side is dumping everything into an infrequent or Glacier class because the storage line is lower. Infrequent-access and Glacier classes add retrieval charges. Several of them also bill a minimum duration and a minimum object size. A prefix full of tiny files that you rewrite every week is a bad fit for those classes even if you "almost never" think about them.

When you do not know the access pattern

S3 Intelligent-Tiering exists for the honest answer: "I do not know yet."

AWS designed it for unknown, changing, or unpredictable access. It monitors objects and moves them between tiers as they go cold, then back to Frequent Access if they are read again. There are no retrieval fees inside Intelligent-Tiering. You pay a per-object monitoring and automation charge instead.

Automatic tiers, from the current docs:

• Frequent Access: where new objects start.
• Infrequent Access: after 30 consecutive days with no access.
• Archive Instant Access: after 90 consecutive days with no access. Still millisecond, high-throughput access.

Optional, only if your app can wait:

• Archive Access: asynchronous. Same performance shape as S3 Glacier Flexible Retrieval. Standard restore is typically 3 to 5 hours.
• Deep Archive Access: asynchronous. Same performance shape as S3 Glacier Deep Archive. Standard restore is typically within 12 hours.

Objects smaller than 128 KB are not monitored. They stay in Frequent Access. If your bucket is millions of tiny objects, the monitoring fee can dominate and the auto-tiering never starts. In that case Intelligent-Tiering is the wrong default.

Good fit: a data lake, analytics dumps, a new product prefix whose read pattern you will only learn in production.

Bad fit: a well-known hot path (just use Standard), or a known archive you will not read for years (skip the monitoring fee and put it in Glacier on purpose).

Infrequent does not mean "cheaper Standard"

S3 Standard-IA and S3 One Zone-IA keep millisecond access, like Standard. AWS describes them as long-lived data you touch about once a month. Both charge a per-GB retrieval fee. Both have a 30-day minimum storage duration and a 128 KB minimum billable object size. Delete, overwrite, or transition before 30 days and you still pay the rest of the month, prorated.

That is why "move it to IA on day two" can cost more than leaving it in Standard.

Standard-IA stores the object across at least three Availability Zones. Designed for 99.9% availability. AWS's own guidance: use this for a primary copy you cannot recreate. Backups you might restore this quarter, older app data that still has to serve a GET in milliseconds, compliance files that are quiet but not frozen.

One Zone-IA stores the object in a single Availability Zone. Designed for 99.5% availability. Cheaper storage. It is not resilient to the loss of that zone. AWS is explicit: use it for data you can rebuild, or for replicas, not as the only copy of something you cannot replace.

If the object is the company's only copy of last year's invoices, One Zone-IA is the wrong kind of cheap.

Glacier is three different products that share a mountain name

People still say "put it in Glacier" as if that were one button. It is three classes with three retrieval stories.

S3 Glacier Instant Retrieval. Archive pricing, millisecond GET. Designed for long-lived data you might touch about once a quarter. 90-day minimum. 128 KB minimum billable size. Retrieval fees apply. The object is available in real time. This is the class for "we almost never open it, but when legal asks, they want it now."

S3 Glacier Flexible Retrieval. The object is archived. A normal GET does not return the bytes until you restore it. 90-day minimum. Extra metadata is billed per object (40 KB: 32 KB at the Glacier Flexible rate, 8 KB at Standard, so S3 can still list the key). Retrieval options from the current restore docs:

Option	Typical time (Flexible Retrieval)
Expedited	1 to 5 minutes for objects under 250 MB
Standard	3 to 5 hours (minutes to 5 hours with Batch Operations)
Bulk	5 to 12 hours, lowest-cost retrieve

Bulk retrievals are free for objects in Flexible Retrieval. Expedited is a premium path. Without provisioned capacity, Expedited can be refused under load.

Use Flexible Retrieval for large restores you can plan: yearly dumps, disaster-recovery trees you hope never to touch, archives where "this afternoon" is acceptable.

S3 Glacier Deep Archive. Lowest storage cost in this family. 180-day minimum. Same style of extra metadata billing. Restore first, then read. Expedited is not available. Standard restore is typically within 12 hours (about 9 to 12 hours with Batch Operations). Bulk is typically within 48 hours.

Use it for data you are keeping because a policy said "seven years," not because an engineer will curl it on a Tuesday.

A restore is not a copy sitting next to the archive forever. You restore for a number of days, then the temporary copy expires. If the runbook says "just GET the object," Deep Archive will fail that runbook.

A decision you can make in one pass

Walk the object (or the prefix) through these questions:

1. Will something block on this GET? User request, API, pipeline step. Stay in Standard, Intelligent-Tiering's instant tiers, Instant Retrieval, or Express One Zone. Do not put it in Flexible Retrieval or Deep Archive.
2. Do I know the access pattern? No: Intelligent-Tiering, if objects are large enough to monitor. Yes, hot: Standard. Yes, cold but instant: Standard-IA or Instant Retrieval. Yes, cold and async: Flexible Retrieval or Deep Archive.
3. Can I recreate it if one AZ is gone? No: do not use One Zone-IA (or Express One Zone) as the only copy.
4. How long will it live, and how big is it? Under 30 days or lots of sub-128 KB objects: IA and Instant Retrieval will bill you as if the objects were larger and older than they are.
5. Who pays if we read the whole prefix? If a monthly job scans everything, retrieval-priced classes can beat Standard on storage and lose on the job.

Class	Access	Restore first?	Min duration	Min billable size	Zones
Standard	Millisecond, frequent	No	None	None	>= 3
Intelligent-Tiering	Millisecond in the automatic tiers	Only in optional archive tiers	None	None (under 128 KB stays Frequent)	>= 3
Standard-IA	Millisecond, infrequent	No	30 days	128 KB	>= 3
One Zone-IA	Millisecond, infrequent	No	30 days	128 KB	1
Glacier Instant Retrieval	Millisecond, rare	No	90 days	128 KB	>= 3
Glacier Flexible Retrieval	Minutes to hours	Yes	90 days	Metadata overhead	>= 3
Glacier Deep Archive	Hours	Yes	180 days	Metadata overhead	>= 3

Designed-for durability for these classes is 99.999999999%, per the same comparison table. Availability is not the same number. Standard and Flexible Retrieval (after restore) are designed for 99.99%. Standard-IA, Intelligent-Tiering, and Instant Retrieval are designed for 99.9%. One Zone-IA is designed for 99.5%.

Concrete piles of objects

Read every day. Thumbnails, current config, the working set of a service. S3 Standard. Lifecycle later, not on day one.

Read now and then, still need a fast GET. Last quarter's reports, "download invoice" on an old order. Standard-IA if the objects are large enough and will live past 30 days. Instant Retrieval if the read is closer to once a quarter than once a month.

Backups. If restore is a fire drill and has to be fast, Standard-IA or Instant Retrieval. If restore is a planned weekend, Flexible Retrieval. If restore is "we keep this because audit said so," Deep Archive. One Zone-IA only if another region or another system already has a copy you trust.

Keep it for years, almost never open it. Deep Archive. Put a lifecycle on the prefix so you do not rely on a human remembering.

A job that might scan the prefix. Prefer Standard or Intelligent-Tiering. Retrieval fees on IA and Instant Retrieval are priced for rare reads, not for "we reprocessed the lake."

Unknown access, objects not tiny. Intelligent-Tiering as the default class on PutObject (x-amz-storage-class: INTELLIGENT_TIERING). Leave the optional async archive tiers off until the application can restore.

One more class if latency is the actual problem

The current docs also list S3 Express One Zone: single-digit millisecond access in one Availability Zone, directory buckets, built for latency-sensitive compute next to the data. Designed for 99.95% availability. Not a replacement for Standard in a multi-AZ API. Not an archive class. If the pain is "Standard is too slow for this tight loop," read that page. If the pain is the bill, it is the wrong page.

AWS still documents Reduced Redundancy Storage. The same page says not to use it. Standard is the replacement.

How teams usually get this wrong

They set one class on the bucket in their head. Classes are per object. Lifecycle rules move prefixes as they age: Standard for 30 days, Standard-IA after that, Instant Retrieval or Flexible Retrieval a year later. You do not need a new bucket for each class.

They forget that overwrite and delete count toward minimum duration. A "cheap" IA prefix that is replaced every deploy is not infrequent. It is Standard with extra fees.

They treat Glacier as a folder. The object stays in S3. Flexible Retrieval and Deep Archive just will not GET until RestoreObject finishes.

They optimize storage and ignore listing, monitoring, and restore. Intelligent-Tiering's per-object fee and Glacier's metadata bytes are real. They matter most when objects are small and numerous.

A default you can defend

• Hot path, known: Standard.
• Unknown, objects worth monitoring: Intelligent-Tiering, automatic tiers only.
• Cold, must GET now, multi-AZ: Standard-IA or Instant Retrieval, depending on how rare the read is.
• Cold, must GET now, you can rebuild it: One Zone-IA.
• Cold, you can wait hours: Flexible Retrieval.
• Cold, you can wait a day, you will keep it for years: Deep Archive.

If that still feels like a guess, do not guess Glacier. Guess Intelligent-Tiering or Standard, then add a lifecycle when you have a real access log. The expensive class is the one that surprises you when someone finally opens the object.