Field guide

Choosing object storage for public images

Separate originals, variants, origin requests and delivery before comparing the bill.

Reviewed 2026-09-07 · Editorial analysis, not a performance test

Start with three numbers

An image library has at least three independent dimensions: the bytes you retain, the bytes visitors receive, and the number of operations that reach storage. A catalog of large originals with modest traffic can be capacity-heavy. A small collection of icons can be request-heavy. The same library can also contain generated variants that multiply both object count and retained bytes.

For an illustrative workload, retain 1,000 decimal GB all month, deliver 2,000 GB, perform 100,000 write/list operations and 10 million reads, and keep objects for at least 90 days. The static estimate below comes from the same engine as the interactive calculator. It assumes the monthly allowances have not been used elsewhere.

Monthly estimates · images · no currency conversion
Service / pricing regionStorageDeliveryWrites / readsMinimum top-upTotal / month
Amazon S3US East · N. VirginiaUSD 21.42158.640.50 / 4.000.00USD 184.56
Cloudflare R2Automatic placement / EU jurisdictionUSD 14.850.000.00 / 0.000.00USD 14.85
Backblaze B2US / EU / CanadaUSD 6.880.000.00 / 0.000.00USD 6.88
WasabiAll commercial regionsOutside modelOutside the published egress policy. Obtain provider approval; no estimate shown.
Bunny StorageOne storage region · EU/NA deliveryUSD 10.0020.000.00 / 0.000.00USD 30.00
ScalewayParis · fr-parEUR 16.0619.250.00 / 0.000.00EUR 35.31

The rows use different routes: direct internet delivery for S3, R2, B2 and Scaleway; Bunny Storage plus its EU/NA Standard CDN for Bunny. Wasabi’s egress policy does not fit this example. These totals do not establish equivalent user experience.

Count variants deliberately

Suppose an original produces a thumbnail, a medium image and a large image. That is four retained objects if you keep everything. Generating them on upload moves work toward the write path and stores predictable outputs. Generating them on demand moves work to a transformation service and can create new cache keys. Neither transformation compute nor an image service subscription is included in the storage estimate.

Create an inventory of original sizes, variant sizes and expiration policy. Keep the original if it is needed for future formats or sizes, but do not assume a generated variant is disposable unless you can reproduce it. Include the time needed to rebuild a whole library in your recovery plan.

Treat cache misses as origin work

A cache hit can avoid an origin read, while a miss may fetch bytes and make a billable operation. If you add a CDN to a direct-storage row, estimate origin traffic and CDN delivery separately. Do not simply reduce the delivered-byte input by the hit ratio: that would also erase the downstream delivery bill.

Use measured cache logs once available. Before launch, write down a conservative miss assumption and model a cold-cache event as well. Query parameters, inconsistent image URLs and frequent overwrites can all undermine a neat cache-hit projection. CDNHandbook provides the companion reference for delivery and caching.

Make the URL part of the design

For public assets, a versioned filename makes replacement behavior explicit. Keep a stable application identifier that can point to a new asset URL. For private images, check whether signed access is validated before cached content is served. Do not put storage management credentials into the browser.

Test an upload, a replacement, a missing image and a revoked private link from the intended application. Record response type and cache behavior. The S3 compatibility guide supplies an operation checklist; the calculator lets you vary this example. Provider pricing evidence is available in each linked profile.