S3 Standard vs Glacier: Instant, Flexible and Deep Archive Compared

S3 Standard vs Glacier in one line: S3 Standard is the default class for data read often, with millisecond access, no retrieval fee and no minimum storage duration, while the three S3 Glacier classes trade a lower storage price for retrieval fees and minimum durations. Glacier Instant Retrieval still reads in milliseconds, Glacier Flexible Retrieval must be restored first, in minutes to hours, and Glacier Deep Archive is the cheapest and slowest, restored in hours. Lifecycle rules move objects down that ladder by age, and Intelligent-Tiering is the answer when you do not know the access pattern. Facts are from the Amazon S3 User Guide listed at the end, as of October 2026.

Class	Reading an object	Minimum storage duration
S3 Standard	milliseconds, no retrieval fee	none
Glacier Instant Retrieval	milliseconds, per-GB retrieval fee	90 days, 128 KB minimum size
Glacier Flexible Retrieval	restore first: minutes to 12 hours	90 days
Glacier Deep Archive	restore first: within 12 or 48 hours	180 days

The problem it solves

A company keeps application logs and database backups for seven years. In month one they are read every day; after a quarter, almost never; after a year, only if an auditor asks. Leaving all of it in Standard pays the top rate for data nobody reads. Throwing all of it into Deep Archive saves the most, until an incident needs last week's logs and the restore takes half a day, or a cleanup job deletes data in its first month and is billed for 180 days anyway. The classes exist so that the price follows how often you read, and lifecycle rules exist so that nobody moves the objects by hand.

The intuition

Standard is the baseline. It is designed for data accessed more than once a month, stored across at least three Availability Zones, with no minimum duration, no minimum size and no charge per gigabyte read. You pay the highest storage rate and nothing else for access beyond requests.

Glacier Instant Retrieval is cold storage that still answers immediately. A GET works exactly as in Standard, in milliseconds, so applications need no change. The price for cheaper storage is a per-GB retrieval fee, a 90-day minimum storage duration and a 128 KB minimum billable size. It is designed for data read about once a quarter: medical images, old user uploads, news archives.

Glacier Flexible Retrieval is archived. The object is still an S3 object in your bucket, listed by the S3 API, but a GET fails until you call RestoreObject, which makes a temporary copy for the number of days you ask for. The retrieval tier sets the wait: Expedited typically 1 to 5 minutes for objects under 250 MB, Standard 3 to 5 hours, Bulk 5 to 12 hours, and Bulk is free. While the copy exists you pay for both the archive and the copy. The minimum duration is 90 days, and each archived object carries 40 KB of extra metadata, 32 KB billed at the Glacier rate and 8 KB at the Standard rate.

Glacier Deep Archive is the bottom of the ladder. The lowest storage price, a 180-day minimum, the same 40 KB overhead, and no Expedited tier: Standard restores typically finish within 12 hours and Bulk within 48. It is for data you keep because you must, not because you expect to read it.

Lifecycle only moves objects down. A rule transitions objects by age, in a waterfall from Standard through the Infrequent Access and Glacier classes to Deep Archive, and can expire them at the end. Since September 2024 objects under 128 KB are not transitioned by default, because each transition is a billed request. One rule cannot leave a class before its minimum duration: a move to Instant Retrieval on day 4 cannot be followed by Deep Archive before day 94. Going back up means a restore and a copy, never a rule.

Intelligent-Tiering is the "don't know" answer. For a small monitoring fee per object and no retrieval fees, it moves each object to an Infrequent Access tier after 30 days without access and to Archive Instant Access after 90, and back to Frequent Access when it is read. Optional Archive Access and Deep Archive Access tiers behave like the Glacier classes and need a restore. Objects under 128 KB are not monitored and stay in the frequent tier.

When to use which

• Read daily or weekly, or short-lived: Standard. Anything deleted within weeks costs more anywhere else.
• Rarely read but needed instantly when it is: Glacier Instant Retrieval.
• Backups and archives where minutes or hours are fine: Glacier Flexible Retrieval.
• Compliance retention for years, read almost never: Glacier Deep Archive.
• Access pattern unknown or changing: Intelligent-Tiering, and let it decide per object.
• Mostly tiny objects: leave them in Standard, or bundle them into larger archives before moving them.

Watch it run

The animation from the S3 lesson follows one photo through its life. The app overwrites it and the next GET returns the new version at once, because S3 reads are strongly consistent. Then the photo goes quiet, and a lifecycle rule moves it to Standard-IA at 30 days and to Glacier Flexible Retrieval at 180, where a GET no longer just works: the app has to restore a copy and wait. At 365 days the expiration action deletes it. The rule in the code below uses Glacier Instant Retrieval as its first step instead of Standard-IA; the shape is the same.

The code

A toy lifecycle simulator, not S3. A rule is a list of (day, class) steps; check rejects a rule that leaves a class before its minimum duration, and storage_class reports where an object of a given age and size sits, keeping objects under 128 KB in Standard as the default does:

import bisect

MIN_DAYS = {"STANDARD": 0, "GLACIER_IR": 90, "GLACIER": 90, "DEEP_ARCHIVE": 180}
RULE = [(0, "STANDARD"), (60, "GLACIER_IR"), (180, "GLACIER"), (365, "DEEP_ARCHIVE")]
EXPIRE_DAYS = 7 * 365

def check(rule):
    """Each class must be kept for its minimum before the next transition."""
    return [f"{a} -> {b} after {d2 - d1} days, needs {MIN_DAYS[a]}"
            for (d1, a), (d2, b) in zip(rule, rule[1:]) if d2 - d1 < MIN_DAYS[a]]

def storage_class(age_days, size_kb, rule=RULE):
    if age_days >= EXPIRE_DAYS:
        return "expired"
    if size_kb < 128:                      # default: smaller objects do not transition
        return "STANDARD"
    days = [d for d, _ in rule]
    return rule[bisect.bisect_right(days, age_days) - 1][1]

print("rule problems:", check(RULE))
print("bad rule:", check([(0, "STANDARD"), (30, "GLACIER_IR"), (60, "DEEP_ARCHIVE")]))
objects = [("logo.png", 3, 400), ("report.pdf", 900, 45), ("scan.tiff", 9000, 120),
           ("video.mp4", 500000, 200), ("audit.log", 2000, 400), ("old.tar", 80000, 2600)]
for key, size_kb, age in objects:
    print(f"{key:11} {size_kb:>7} KB  day {age:4}  {storage_class(age, size_kb)}")
# rule problems: []
# bad rule: ['GLACIER_IR -> DEEP_ARCHIVE after 30 days, needs 90']
# logo.png          3 KB  day  400  STANDARD
# report.pdf      900 KB  day   45  STANDARD
# scan.tiff      9000 KB  day  120  GLACIER_IR
# video.mp4    500000 KB  day  200  GLACIER
# audit.log      2000 KB  day  400  DEEP_ARCHIVE
# old.tar       80000 KB  day 2600  expired

The 3 KB logo is a year old and still in Standard, which is what you want: archiving it would cost a transition request and 40 KB of overhead to save almost nothing. The second block prices early exits and checks the lookup against a brute-force walk, one day at a time, over random rules:

import random

def billed_days(entered_class, days_kept):
    """Leaving a class early still bills its minimum storage duration."""
    return max(days_kept, MIN_DAYS[entered_class])

print("deleted 10 days into GLACIER_IR, billed", billed_days("GLACIER_IR", 10), "days")
print("deleted 10 days into DEEP_ARCHIVE, billed", billed_days("DEEP_ARCHIVE", 10), "days")
print("deleted 10 days into STANDARD, billed", billed_days("STANDARD", 10), "days")

def simulate(age_days, size_kb, rule):
    """Brute force: walk the object forward one day at a time."""
    current = "STANDARD"
    for day in range(age_days + 1):
        if day >= EXPIRE_DAYS:
            return "expired"
        for start, cls in rule:
            if day == start and size_kb >= 128:
                current = cls
    return current

random.seed(4)
ok = True
for _ in range(300):
    cuts = sorted(random.sample(range(1, 1500), 3))
    rule = [(0, "STANDARD")] + list(zip(cuts, ["GLACIER_IR", "GLACIER", "DEEP_ARCHIVE"]))
    age, size = random.randint(0, 3000), random.choice([5, 127, 128, 4096])
    ok &= storage_class(age, size, rule) == simulate(age, size, rule)
print(ok)
# deleted 10 days into GLACIER_IR, billed 90 days
# deleted 10 days into DEEP_ARCHIVE, billed 180 days
# deleted 10 days into STANDARD, billed 10 days
# True

The complexity

• Storage price falls down the ladder, and access cost rises: retrieval fees per gigabyte, restore waits, and for the archive classes a temporary copy billed at the Standard rate while it exists.
• Minimum durations turn early deletes and early transitions into charges for the remaining days.
• Per-object costs grow with object count, not size: a request per transition and 40 KB of overhead per archived object.
• Restores at scale are limited to 1,000 restore requests per second per account, with throughput up to 1 to 2 PB per day; S3 Batch Operations submits them in bulk.
• The simulator is a binary search over the rule's steps, logarithmic in their number; the brute force is linear in the object's age.

Where it goes wrong

• Archiving millions of tiny objects. Transition requests and per-object overhead can exceed the savings. Bundle them first, or filter by size.
• Deep Archive for data an incident might need. The fastest restore is about 12 hours. Keep recent data in a class you can read now.
• Short-lived data in a Glacier class. Deleted after a month, it is billed for 90 or 180 days.
• Forgetting that a restore is temporary. When the copy expires, GET fails again with InvalidObjectState; copy the object to another class if it must stay readable.
• Glacier Instant Retrieval for data that turns hot. Retrieval fees on every read can cost more than Standard would have.
• Expecting lifecycle to move data back up. It only moves down; going up is a restore plus a copy.

When it shows up in interviews

As the storage part of a cost question, "the S3 bill keeps growing, what do you do?", and constantly in certification scenarios that hinge on one phrase: "within milliseconds" means Instant Retrieval, "within 12 hours" means Deep Archive, "unknown access pattern" means Intelligent-Tiering. For the choice between S3 and block or file storage in the first place, see S3 vs EBS vs EFS.

How to say it in an interview

"Standard is for data read often: milliseconds, no retrieval fee, no minimum. The Glacier classes are cheaper to store and charge on the way out. Instant Retrieval still reads in milliseconds, with a retrieval fee and a 90-day minimum. Flexible Retrieval must be restored first, minutes with Expedited up to 12 hours with Bulk, also 90 days. Deep Archive is cheapest, restored within 12 or 48 hours, with a 180-day minimum. I put a lifecycle rule on the bucket to move data down by age and expire it, keep small objects out of the archive tiers, and use Intelligent-Tiering when I cannot predict access."

Frequently asked questions

What is the difference between S3 Standard and S3 Glacier?

S3 Standard stores frequently read data with millisecond access, no retrieval fee and no minimum storage duration. The S3 Glacier classes cost less to store but charge per-GB retrieval fees and bill minimum durations of 90 or 180 days, and two of them, Flexible Retrieval and Deep Archive, must be restored before an object can be read.

How long does it take to retrieve data from S3 Glacier?

Glacier Instant Retrieval returns objects in milliseconds. Glacier Flexible Retrieval restores typically take 1 to 5 minutes with Expedited, 3 to 5 hours with Standard and 5 to 12 hours with Bulk. Glacier Deep Archive restores typically finish within 12 hours with Standard and within 48 hours with Bulk.

When should I use S3 Intelligent-Tiering instead of Glacier?

When you cannot predict how often objects will be read. Intelligent-Tiering moves each object between tiers by its own access history, charges a small monitoring fee per object and no retrieval fees. If you know data goes cold at a fixed age, a lifecycle rule to a Glacier class is simpler and avoids the monitoring fee.

Sources

• Understanding and managing Amazon S3 storage classes — Amazon S3 User Guide
• Understanding archive retrieval options — Amazon S3 User Guide
• Transitioning objects using Amazon S3 Lifecycle — Amazon S3 User Guide
• How S3 Intelligent-Tiering works — Amazon S3 User Guide