Comparing storage and access costs
Standard storage provides immediate access to objects. For audit logs and rarely accessed images, its cost is worth comparing with a class suited to those uses. Read frequency needs to be measured for the dataset concerned: a file's name or age is not enough to infer it.
In the region and price grid used for our calculation, S3 Standard is roughly $0.023 per GB, versus about $0.004 per GB for S3 Glacier Instant Retrieval. These rates compare the storage component. Access fees and the constraints of the selected class still need to be checked before deciding.
Immediate access and minimum billable amounts
S3 Glacier Instant Retrieval provides millisecond access with performance comparable to S3 Standard-IA. This tier addresses the need to access rarely read data immediately. That need must be checked against the requirements of the applications using the objects.
The calculation must account for a minimum storage duration of 90 days, a minimum billable object size of 128 KB and higher retrieval and request costs. The size distribution and read frequency matter as much as total volume. Small or frequently read objects can reduce the expected storage cost advantage.
The scope and the calculation used
The analysis covers 120 TB of audit logs and rarely accessed images, with a retention period longer than 90 days. The planned duration in the storage class after transition needs to be checked, rather than relying only on the total age of the data.
The calculation shows: before migration, roughly $2,760 per month of storage; after, roughly $480 per month for storage. The gross gap is $2,760 − $480 = $2,280 per month, i.e. 2,280 × 12 = $27,360 per year, rounded to $27,000. These figures are provided as an example, based on the region and price grid used for this calculation; every context remains to be validated.
This difference concerns storage alone. Request and retrieval amounts still need to be included before claiming a net saving.
Factoring requests and retrievals into the net saving
Net savings must include the requests and retrievals actually observed. Record the request count and volume of data retrieved, then apply the price grid for the scope concerned. A steady read flow can reduce the advantage of a cheaper storage class.
A scenario comparison can test this sensitivity: use measured volumes as a baseline, then examine the effect of increased reads. A small proportion of objects being read does not guarantee savings, especially when their sizes vary considerably. Total cost must include storage, requests, retrievals and minimum billable amounts.
A decision rule by access profile
To avoid case-by-case arbitration, a simple rule can serve as a starting point:
Frequent access: S3 Standard. Less frequent access: Standard-IA.
Quarterly access with immediate response: Glacier Instant Retrieval. Long-term retention without immediate access: Flexible Retrieval or Deep Archive.
This grid is a suggested allocation, to be adjusted to the latency and retention requirements of each workload. The decision should rely on measured read frequency and the estimated total cost of each option.
A checklist before switching
Before any migration to Glacier Instant Retrieval, a few checks are in order:
Confirm that retention in the class is compatible with the 90-day minimum. Examine the size distribution, particularly objects close to or below 128 KB.
Measure requests and retrieved volumes, then recalculate net savings. Check that access performance meets application requirements.
A gradual transition on a sample is a suggested precaution for comparing costs and access before and after. It allows the estimate to be checked against observed usage before expanding the scope.
In this calculation, $27,000 per year remains a rounded gross difference. The decision depends on the balance after accounting for access fees and minimum billable amounts.
The post behind this insight
Expanded from the LinkedIn post. The links below come from the original post; listing them does not imply independent verification.
LinkedIn ↗