Storage Lifecycle Transitions and Minimum Durations

Archival storage classes advertise a price per gigabyte per month that is a small fraction of the standard class, and the arithmetic that follows from that number is usually wrong. The price applies to bytes, but an object in an archival class also carries charges that scale with the number of objects rather than their size, that are incurred on every transition, and that apply as a penalty when an object is removed before a minimum period has elapsed. A plan to move a large dataset to the cheapest class can increase the bill if the objects are small, short-lived, or frequently rewritten.

Each class is a different set of meters

A storage class is not a discount applied to the same service. It is a distinct set of physical media, retrieval paths, and billing meters. The standard class charges for bytes held and for requests, and retrieval is immediate and unmetered beyond the request charge. An infrequent-access class keeps the same latency but adds a per-gigabyte retrieval charge that applies whenever bytes are read. An archival class stores objects on media that cannot be read without a job that takes minutes to hours, charges a retrieval fee per gigabyte, and charges a per-request fee for the restoration job.

The consequence is that the classes trade a lower storage rate for higher access cost. A dataset read once a month is cheaper in an infrequent class because the storage saving exceeds one retrieval charge per month. A dataset read daily is cheaper in the standard class, because the retrieval charges accumulate faster than the storage rate falls. The crossover depends on the ratio of the two rates and on the access frequency, and it can be computed exactly for a given workload:

def monthly_cost(size_gb, requests, std, ia):
    """std/ia: dicts with storage_per_gb, per_request, retrieval_per_gb."""
    std_cost = size_gb * std["storage_per_gb"] + requests * std["per_request"]
    ia_cost  = (size_gb * ia["storage_per_gb"]
                + requests * ia["per_request"]
                + size_gb * ia.get("retrieval_per_gb", 0.0))   # every object read once
    return std_cost, ia_cost

The comparison only holds if the access count is known and if the objects are large enough that the per-object charges are negligible. Both conditions fail often.

Per-object metadata is charged per object, and small objects lose

Every object stored in a class carries a fixed metadata charge per month, independent of its size, in addition to the per-gigabyte charge. The charge exists because the class must maintain an index entry, and index entries cost the same whether they point at a kilobyte or a gigabyte. For large objects the charge is irrelevant. For small objects it dominates, and there is a size below which the cheapest class is more expensive than the standard one.

The arithmetic is direct. If the per-object charge is a fraction of a cent per month and the storage rate difference between two classes is a fraction of a cent per gigabyte per month, then the crossover size is the per-object charge divided by the rate difference. An object smaller than that crossover pays more in metadata than it saves in storage. A bucket of millions of small objects moved wholesale to an archival class can therefore cost more than leaving it in place, and the effect is invisible in any estimate computed from total gigabytes.

This is the reason object-storage cost work begins with a size distribution rather than a total. The relevant statistics are the count of objects below the crossover size, the total bytes they represent, and the request rate against them. A dataset with a mean object size in the megabytes has a different optimal class from one with a mean in the kilobytes, even when the two have identical totals.

Minimum durations turn deletion into a fee

Archival classes impose a minimum storage duration, on the order of a month to three months, during which an object is billed as if it were still present even if it has been deleted or transitioned away. The mechanism is not punitive bookkeeping; it reflects the physical commitment the class makes. Moving an object to cold media involves a write to a medium that is not designed for rapid rewrite, and the provider’s cost of that write is recovered over the expected residency. An object deleted after a day leaves that cost unrecovered, so the fee recovers it.

The interaction with lifecycle rules is where the money is lost. A common rule set transitions objects to an archival class after thirty days and deletes them after ninety. If the archival class has a ninety-day minimum, the deletion at day ninety is exactly at the boundary and incurs no fee. If the rule is changed so that transition happens at sixty days and deletion at ninety, the object spends thirty days in the class and is charged for sixty days of unused minimum. The fee is proportional to the object’s size and to the shortfall, so a rule change intended to save storage cost can add a deletion charge to every object in the bucket.

The general rule is that a lifecycle policy has a constraint the rule editor does not enforce: the gap between transition and expiration must be at least the minimum duration of the target class. Expressing that as a check over the policy is straightforward, and it is worth doing before a policy is applied to a large bucket:

def validate(transitions, expiration_day, min_days):
    """transitions: [(class_name, day)] in order; min_days: {class_name: days}"""
    errors = []
    for i, (cls, day) in enumerate(transitions):
        end = transitions[i + 1][1] if i + 1 < len(transitions) else expiration_day
        if end - day < min_days[cls]:
            errors.append(f"{cls}: {end - day}d residency < {min_days[cls]}d minimum")
    return errors

Transitions are themselves billable events

Each transition is a write to the destination class and a delete from the source, and both are charged as requests. A lifecycle rule that transitions every object in a bucket of many millions of small objects generates one put and one delete per object, and the request charge for that sweep can exceed the storage saving for the month in which it happens. The charge is one-time per object, so it amortizes, but it lands in a single billing period and is often mistaken for a pricing anomaly.

A second cost is the transition’s effect on retrieval latency. Objects in an archival class are not readable until a restore job completes, and the restore is charged per request and per gigabyte. A workload that reads an archived object occasionally pays both, and a workload that discovers it needs an archived object urgently pays for expedited retrieval, which is priced higher than the standard tier. Lifecycle design therefore has to separate data that is merely old from data that is genuinely unlikely to be read, because age is a poor predictor of access.

There is a further wrinkle in the interaction with versioning. In a versioned bucket, a lifecycle rule that expires an object creates a delete marker rather than removing bytes, and the previous versions remain stored and billed. A rule set that appears to delete data after ninety days may leave every version in place indefinitely, with the storage charge intact and the object count growing. The lifecycle configuration must include a rule for noncurrent versions, and that rule has its own transition and expiration semantics.

Where the estimate diverges from the invoice

An estimate built from total gigabytes and a published storage rate will be low by the per-object component and high or low by the retrieval component depending on access. It will also miss the one-time transition sweep and any early-deletion fee. On a bucket whose objects average a few kilobytes, the per-object component alone can exceed the per-gigabyte component, so the estimate is wrong by a factor rather than a percentage.

The reconciliation that works is to price the population, not the total: bucket the objects by size, multiply each bucket by its class’s per-object and per-gigabyte rates, add the request volume by operation type, and add the minimum-duration exposure for objects whose remaining residency is shorter than the class minimum. That last term is the one most often omitted, and it is the one that makes a lifecycle policy actively expensive. The same reasoning about a fixed per-unit charge dominating a small unit applies to compute, where the minimum billing increment sets a floor under short-lived instances, as described in billing units and why a cloud bill is an estimate. It also applies to instance shapes, where a bundle’s unused half is a fixed charge per instance rather than a per-byte rate, discussed in instance shape selection and the vCPU-to-memory ratio.