Cache Reserve goes GA: enhanced control to minimize egress costs

Cache Reserve hits GA with new controls and analytics

Cloudflare’s Cache Reserve is now generally available. The product has graduated from beta with two new features aimed at giving customers granular control over which assets get cached and clearer insight into the savings it provides.

Cache Reserve, which combines Cloudflare's tiered cache with R2 storage, is designed to prevent cache eviction for infrequently accessed content. In a conventional CDN setup, assets that aren't requested often may be evicted from edge caches to make room for more popular content, even when those assets have a long time-to-live (TTL). When those files are requested again, the origin must serve them, incurring egress fees. Cache Reserve extends retention for eligible content up to 30 days by default, and refreshes that window each time the content is requested, acting as a backstop that keeps customers from having to go back to their origin.

Why cache misses are a cost problem

Cache effectiveness is usually measured by the hit/miss ratio: content served from a CDN’s cache is a hit, content fetched from the origin is a miss. Even with a well-configured cache, misses happen for reasons beyond the customer's control. When cache storage becomes constrained, Cloudflare uses a least-recently-used (LRU) eviction policy, meaning content that is not requested frequently may get dropped before its specified TTL expires. Additionally, cache revalidation requires checking with the origin to determine whether a stored version is still fresh.

For customers with large but low-traffic content libraries where assets may be evicted on a regular basis, those origin requests come with a real economic impact in the form of egress fees. Cache Reserve addresses that by providing a layer of storage that does not use LRU eviction and remains available through the default 30-day window or until TTL dictates otherwise.

Cache Rules integration

During the beta, one of the most requested capabilities was finer control over which assets would be written into Cache Reserve. Previously, enabling Cache Reserve meant all eligible assets from a zone, including rapidly-changing files, would be admitted. The new Cache Rules integration lets customers define explicit eligibility criteria based on the typical Cache Rules fields — hostnames, paths, URLs — plus new configuration options such as a minimum resource size. For example, a rule could specify that only objects 100KB or larger are written into the Reserve. This provides a way to keep dynamic or rapidly-changing content out, while maintaining edge cache usage and reducing potential origin egress.

New Cache Reserve-specific analytics

Earlier analytics for Cache Reserve provided storage usage and operation counts for a given time period. Those views have been expanded to present storage and operations as a custom time series, similar in structure to other cache analytics dashboards. In addition, the updated analytics include an estimate of egress savings attributable to Cache Reserve. Cloudflare says that in coming months it will add visibility into the largest and most-requested items being served from Cache Reserve.

A safe way to clear Cache Reserve

Previously, customers who wanted to stop using Cache Reserve entirely were dependent on cache purging. Purge, however, operates across all of Cloudflare’s cache layers — Cache Reserve and the traditional edge cache — which could invalidate edge cached content, resulting in additional origin requests and egress fees.

The new changes introduce a dedicated delete action for the entire content of a zone's Cache Reserve storage, leaving the edge cache intact. This is useful for customers dropping the product, and also for those who simply need to clear Reserve data without impacting content still being served off the edge. After the zone’s Reserve storage is deleted, customers will need to wait for the deletion process to finish before they can re-enable Cache Reserve — completion generally takes around 24 hours, though it depends on how much data is stored.

Cache Reserve remains a product capable of shifting cache ratios meaningfully. Docker reported via Cloudflare’s case study that a 2% cache hit ratio improvement from Cache Reserve eliminated roughly two-thirds of its S3 egress, and that the reduction in egress charges was "almost an order of magnitude larger than the price we paid for Cache Reserve."

Users can enable the service from the Cache Reserve section of the Cloudflare dashboard, following standard asset eligibility guidelines. Full configuration details are available in the documentation.