The access curve nobody prices
Ask a working photographer when a gallery gets viewed and you get a very confident answer: the week it lands. Recital and event galleries are the extreme case, since the audience is a fixed roster of families who all get the link on the same day, but portrait galleries behave the same way with a longer tail. Access is hot for roughly 60 to 90 days after delivery, then near-dead, with occasional reopenings years later when someone wants a print or a slideshow for a graduation.
That is a predictable, event-driven decay curve, and it is the single most useful fact about the workload. Nothing in the category's pricing reflects it.
So the back catalog becomes the tax. It is the part of a photographer's storage that grows every year, gets accessed the least, and costs the most in aggregate. It is also the part they are least willing to delete, because deleting it means telling a family that the 2019 recital is gone.
Three ways the category handles it, none of which is pricing
When I surveyed the delivery platforms in July 2026, the responses to the back-catalog problem sorted into three buckets:
- Eat the cost. Keep everything at active rates and fund it out of the subscription tier ladder, which means the growing catalog eventually pushes the photographer up a tier.
- Push the cost back onto the user. Archive old galleries so they stop consuming the quota, sometimes with a notification the photographer does not connect to the customer emailing them a week later about a dead link.
- Monetize the anxiety. Sell retention or backup as its own recurring add-on, so keeping your own work becomes a line item.
What none of them do is pass archive-tier economics through to the customer, and the reason is structural rather than technical. Their storage ladder is the revenue model. A tier that made old galleries nearly free would cannibalize the upsell that pays for the company. This is the rare case where a competitor can see exactly what you are doing, agree that it is better, and still not follow.
The mechanism: explicit lifecycle rules, not Intelligent-Tiering
The AWS rates that make this work, us-east-1, verified against the pricing page on 11 August 2026:
| Class | Per GB-month | Access | Minimums |
|---|---|---|---|
| S3 Standard | $0.023 | milliseconds | none |
| Glacier Instant Retrieval | $0.004 | milliseconds, $0.03/GB retrieval | 90 days, 128 KB |
| Glacier Deep Archive | $0.00099 | restore, hours | 180 days, 40 KB overhead |
Glacier Instant Retrieval is the interesting one, and it is routinely misread as an archive tier you have to thaw. You do not. It serves objects in milliseconds, exactly like Standard, at a bit under a fifth of the price, and charges you three cents a gigabyte when you actually read them. For data that is browsed rarely but must appear instantly when it is, that trade is close to perfect.
The obvious-looking alternative is Intelligent-Tiering: let AWS watch the access pattern and move objects for you. For this workload it is the wrong tool, for three reasons.
- It reacts, and we already know the answer. Intelligent-Tiering moves an object to Infrequent Access after 30 consecutive days without access, and to Archive Instant Access after 90. A delivered gallery is in its expensive tier for exactly the window when it is being hammered, which is the window we are trying to pay full price for anyway, and then waits out the clock again to get cheap. An explicit rule keyed to the delivery date does the same thing on the calendar we already control.
- It charges per object to monitor. A gallery is not one object. It is an original, a download rendition, a web rendition and a thumbnail for every frame, so a season can be hundreds of thousands of objects carrying a monitoring fee each.
- It refuses the small ones. Objects under 128 KB are not monitored and stay in the frequent access tier permanently, which is most of your thumbnails.
So the rule is written by hand, per prefix, against the calendar:
Standard
→ Glacier Instant Retrieval at day 90 (season is over)
→ Glacier Deep Archive at day 730 (the forever archive)
Two more things the transition has to respect. The minimums are real: an object moved to Glacier IR and deleted at day 30 still bills for the full 90 days, so a lifecycle rule that races a retention policy costs more than doing nothing. And transitions are billed per object request, which means tiering a million thumbnails has a real one-time cost against a saving measured in cents.
Which is why the small files stay hot
Glacier IR bills any object under 128 KB as though it were 128 KB. A 20 KB thumbnail therefore does not get 5.75x cheaper when you archive it. It gets billed at 6.4x its own size in a tier that is 5.75x cheaper, which is a rounding error of a saving, and now the grid view that renders 400 of them pays a retrieval fee every time somebody scrolls.
The rule that falls out of this is worth stating plainly, because it is the opposite of the intuition that cold storage is for everything old: tier by object size and role, not just by age. Originals and full-size downloads are big, rarely fetched, and belong in the cold tier. Thumbnails and web renditions are small, fetched in bulk the moment anyone opens the page at all, and belong in Standard forever. The archive saves money on the bytes that constitute the archive, and the browsing experience of a ten-year-old gallery is indistinguishable from a new one.
The honest math, including where it loses
Here is the part that most storage-economics posts skip. Cold tiering is not free money, and for a photographer with a small active catalog it is not even a saving.
My own numbers: I pay $99.99 a year for 2 TB of Google One, which is about $4.17 per terabyte-month at full utilization. Glacier IR is $4.10. Migrating my current catalog to a cold tier saves me somewhere between nothing and three dollars a month, and S3 Standard is roughly 4.7x the price of Drive, so any bytes that stay hot make it actively worse.
Consumer cloud storage is genuinely cheap. What it is not is linear. The case for lifecycle pricing does not activate on rate, it activates on the shape of the curve:
- At the plan cliff. Going from 2 TB to 5 TB on a consumer plan is a step function of roughly $150 a year. On S3 the next terabyte costs the same as the last one, and if it is a cold terabyte it costs about a dollar a month.
- On a blended catalog. A growing archive is mostly old bytes by definition. Five terabytes with one hot season lands around $10 to $20 a month, against $24.99 for a 5 TB consumer plan holding the same thing at one flat rate.
- Against a platform ladder rather than raw storage. This is the real comparison, because the photographer is not choosing between S3 and Drive. They are choosing between S3 economics passed through and a gallery platform's storage tier.
The discipline this imposed on the product: the mechanism goes on the marketing page, the price does not. Our price corridor is still unverified, so quoting it would be inventing a number that a photographer could hold us to. Argue the mechanism, and let the number arrive when it has been tested.
Restore as an event, not a punishment
Deep Archive's cost comes with a latency of hours, which sounds like the thing that kills the design. It is not, as long as the delay is expected. The same wait is a great experience or an outage depending entirely on whether the person knew it was coming.
A surprise archive is: family clicks a link from 2019, gets an error or a dead gallery, emails the photographer, photographer discovers their platform archived it. A requested restore is: family clicks a link from 2019, sees a page that says these photographs are in the long-term archive, asks for them back, and gets an email when they are ready. Same latency. Opposite feeling.
The genuinely interesting part is what the request is. Somebody just raised their hand and said they want their 2019 photographs, and attached their contact details to the request. That is a print sale or a rebooking lead landing in the studio's inbox. One competitor has built the restore-request flow and, when we checked in July 2026, its owner notification does not even pass the requester's contact information through. The email is collected only to notify the requester when the restore finishes. The lead exists in their system and nobody surfaces it.
That is the pattern I keep finding in this category. The expensive infrastructure work is done; the product thinking around it is not.
What is actually built
Being precise, because a design post is easy to mistake for a shipping announcement. Kept is in preview with real galleries and real families on it. The lifecycle argument is the lead story on its pitch, and the storage architecture is built to accommodate the tiering described here. Age-based pricing is deliberately out of the MVP, and no price appears anywhere on the site.
What I will not do is ship the pricing model before the restore experience is good, since the entire promise depends on the cold tier being invisible when someone wants their photographs back. Cheap storage that makes the 2019 recital feel gone is worse than expensive storage that keeps it one click away.
The takeaway
If your product stores media that people stop looking at:
- Find the decay curve and check whether your pricing knows about it
- Use explicit lifecycle rules when access is predictable; reserve Intelligent-Tiering for patterns you genuinely cannot forecast
- Tier by size and role, not only age. Small objects and the ones that render the page stay hot
- Price the retrieval, the minimums, and the per-object transitions, not just the headline per-gigabyte rate
- Make the wait an event the user chose, and read the request as the demand signal it is
Storage rates change and mine were verified the day this was published. The decay curve will not change, and neither will the fact that almost nobody is billing for it.