Storage Tiering: S3, Cloud Storage and Azure Blob Classes
Colder classes cost less to store and more to read. Tiering pays off only when the data really goes cold and stays there.
Storage tiering is placing each object in the storage class whose price matches how often it is read. Object stores charge less per GB-month for colder classes and recover the difference through retrieval fees, minimum storage durations, and higher request prices. Tiering is a trade between those charges: the right class is the one with the lowest total cost for the actual access pattern, not the lowest storage price.
Tiering applies to object storage. It is not a change of instance type, and object stores such as S3 are not stopped or scheduled; the only levers are which class the data sits in and how long it is kept.
The classes side by side
| Access pattern | Amazon S3 | Google Cloud Storage | Azure Blob |
|---|---|---|---|
| Frequent | Standard (no minimum) | Standard (no minimum) | Hot |
| About monthly | Standard-IA, One Zone-IA (30-day minimum, 128 KB minimum billable size) | Nearline (30-day minimum) | Cool (30 days) |
| About quarterly | Glacier Instant Retrieval (90 days, 128 KB minimum billable size) | Coldline (90 days) | Cold (90 days) |
| Rarely, hours to retrieve | Glacier Flexible Retrieval (90 days), Glacier Deep Archive (180 days) | Archive (365 days) | Archive (180 days, offline) |
All the colder classes charge per-GB retrieval fees. Minimum durations behave the same way everywhere: delete, overwrite, or move an object early and you pay for the rest of the minimum. Microsoft’s own example: deleting an archived blob after 120 days means it is charged for the full 180. Azure Archive is offline: a blob must be rehydrated to an online tier before it can be read, which can take up to 15 hours.
Small objects change the maths
On S3, objects under 128 KB are billed as 128 KB in Standard-IA and One Zone-IA, lifecycle rules do not transition objects smaller than 128 KB by default, and Intelligent-Tiering does not monitor them. Google Cloud’s Autoclass likewise keeps objects under 128 KiB in Standard. A bucket full of small files may cost more after tiering, not less.
Rules versus automatic tiering
Lifecycle rules move objects after a fixed age, which suits data whose access declines predictably, such as logs read for a few weeks and then kept for audit. Each lifecycle transition is also billed as a request per object, which is why AWS does not recommend transitioning objects under 128 KB, and an object moved out of Standard-IA before 30 days is charged for the remainder of the 30.
Automatic tiering watches access instead of age. S3 Intelligent-Tiering moves an object to its Infrequent Access tier after 30 consecutive days without access and to Archive Instant Access after 90, for a per-object monitoring charge and no retrieval fees. Cloud Storage Autoclass transitions objects to colder classes when they are not read and back to Standard when they are, with a management fee and no retrieval fees outside enablement charges; its default terminal class is Nearline, configurable to Archive. Azure has a smart tier that moves data between hot, cool, and cold.
A practical order of work
- Measure access per bucket or prefix before choosing a class.
- Put predictable, age-driven data under lifecycle rules.
- Use automatic tiering for large, unpredictable datasets of larger objects.
- Leave hot or small-object buckets alone.
- Expire what no longer needs keeping; the cheapest tier is deletion.
How ZopNight helps
ZopNight enriches S3 and Cloud Storage buckets with size and object count. Its S3 tiering recommendations fire only on buckets that are measured as cold from request metrics, are mostly in Standard, and have no lifecycle policy already managing transitions, and they price the saving from the actual Standard-to-IA rate difference or abstain. A lifecycle policy can be applied through the remediation workflow’s set-lifecycle-policy step.
Related: data transfer costs, resource lifecycle, and the S3 resource page at S3 in ZopNight.