Cloudflare corrects its cache traffic diversion in public clouds

Cloudflare has updated Smart Tiered Cache to address a common issue when the origin server is located on AWS, Google Cloud, Microsoft Azure, or Oracle Cloud. The platform now allows specifying the actual region where the application is hosted, even when the IP address of the service is anycast and appears to be present in multiple locations simultaneously.

This new feature prevents a request from unnecessarily traversing continents before reaching the origin. Until now, Cloudflare could detect that an IP responded with low latency from various locations, but it couldn’t always determine the true location of the final backend. In the face of this ambiguity, it used several higher-level caches—a safe decision that reduced request concentration and, consequently, system efficiency.

Smart Tiered Cache for Public Clouds: Key Points in 20 Seconds

• Cloudflare allows you to inform about the cloud region where the origin is located.
• The feature initially supports AWS, Google Cloud, Azure, and Oracle Cloud.
• Available at no additional cost for Free, Pro, Business, and Enterprise plans.
• Smart Tiered Cache selects a nearby main higher-level cache close to the specified region.
• It also assigns an alternative location at another PoP (Point of Presence).
• The goal is to avoid routes like Asia–U.S.–Asia to reach an Asian origin.
• Configuration can be done via dashboard, API, or Terraform.
• Cloudflare maintains updated IP ranges of cloud providers.
• The basis for choosing higher levels is recalculated with latency measurements.
• The regional hint does not move data or change the contracted region with the provider.

Tiered Cache organizes Cloudflare data centers into a hierarchy. When a nearby node doesn’t have a resource cached, it first consults a higher-level node. Only this level can request content from the origin server if it also lacks a copy.

This hierarchy prevents dozens of data centers from establishing independent connections to the same infrastructure. The expected result is a higher cache hit ratio, less traffic to the origin, and fewer open connections the server must handle.

The Challenge of Finding Cloud Origins via Latency

Launched in 2021, Smart Tiered Cache was based on a simple idea: measure latency from Cloudflare network to the origin and select the best-connected data center as the top level.

It works well when the IP belongs to a server in an identifiable location. If an origin is in Madrid, probes from different data centers should show a clear trend to select a nearby location.

The situation complicates with public cloud services. Load balancers, regional gateways, and other components may use anycast or regional architectures where a single IP responds from multiple points in the provider’s network.

Measurement may no longer reach the server where the application runs. Instead, it might end at the nearest cloud provider’s entry point, which then forwards the request via its private network to the backend server.

Consequently, an IP associated with an app deployed in Singapore may seem very close from Chicago. While it quickly reaches the cloud edge in the US, it doesn’t mean the content is stored there.

If Cloudflare chooses Chicago as the top level, an Asian user request might follow this path:

1. The user connects to a nearby Cloudflare node in Asia.
2. The node reports a cache miss to the higher-level cache located in Chicago.
3. Chicago requests the content from the cloud service.
4. The provider’s network transports the request to the backend in Singapore.
5. The response travels back along the same path.

This process, known as hairpinning, introduces a transcontinental journey that doesn’t add value. It can add hundreds of milliseconds and increase inter-region traffic.

Previously, when Smart Tiered Cache detected an ambiguous IP, it avoided fixing it to a single top level. Instead, it used multiple, reducing the risk of choosing an incorrect location. Cache still functioned, but content was more dispersed, increasing the chances that different nodes would query the origin.

Cloudflare’s documentation confirms that origins on AWS, Google Cloud, Azure, and Oracle can now include a regional hint so that Smart Tiered Cache can select a nearby main data center and an alternative in a different location.

A Regional Hint to Improve Cloudflare’s Routing Decisions

This involves providing an explicit hint, like aws:us-east-1 or gcp:europe-west1. Cloudflare no longer needs to deduce location solely based on anycast behavior: it knows which provider and region to reference.

From the dashboard, this option is found under Caching > Tiered Cache > Origin Configuration. The administrator locates the IP or origin hostname, selects Set Region Hint, and chooses the provider and region.

The same configuration is available via API, enabling automated processes. Cloudflare also supports managing these hints with Terraform, integrating the origin-region correspondence into Infrastructure as Code.

The hint does not force a specific data center. Cloudflare maintains its final decision based on measurements and network conditions. The customer provides the context that can’t reliably be inferred from the IP alone.

To build this mapping, Cloudflare downloads publicly available IP range files from providers every few hours. These files show which prefixes are associated with each region and are updated whenever a cloud provider adds, removes, or reassigns subnets.

They then cross-reference these ranges with a database of higher levels built from continuous latency probes. As explained by Cloudflare, latency data used for this selection updates every 15 minutes.

Each subnet linked to a region contributes a weighted vote. The location with the strongest signal becomes the main higher level. Alternatives are chosen at other PoPs to prevent local issues from affecting both routes.

When insufficient data exists, the system defaults to geographic proximity, initially selecting a nearby main data center. As real measurements come in, it can replace this estimate with a performance-based choice.

How Cloudflare Detects If an IP Is Anycast

Before enabling regional hints in the dashboard, Cloudflare attempts to determine if the IP responds from multiple locations. It does this by measuring propagation speed—beyond routing, it leverages a fundamental constant: the speed of light.

The company measures latency from several reference data centers. If the combined trips to and from two locations are less than the physical minimum time to travel between those points via fiber, the response can’t originate from a single server.

For example, if two points separated by thousands of kilometers receive a response from the same IP with extremely low latency, an origin in a single place can’t be nearby both simultaneously. It’s likely the IP is announced from multiple locations.

This method helps distinguish unicast origins from anycast entries, relying not solely on outdated IP geolocation databases but on real-time latency measurements.

In the dashboard, regional hints are shown for origins identified as anycast. Via the API, you can explore the catalog of supported providers and regions. Moreover, Cloudflare states that custom topologies take precedence, so a regional hint won’t override a specific configuration for an Enterprise customer.

Potential Benefits for Applications

The impact depends on architecture, traffic, and cacheable content proportion. Not all websites will experience noticeable latency improvements.

Conditions that favor significant gains include:

• The origin is behind an anycast or ambiguous regional IP;
• The previously chosen location was far from the backend;
• There is a substantial amount of cacheable content;
• The service receives traffic from multiple regions;
• The origin supports frequent repeated requests due to cache misses.

Focusing queries at a higher level increases cache hit chances, reduces connections, and lowers outbound data costs—beneficial for both backend load and expenses.

However, this feature doesn’t fix poor caching policies. If responses are marked private, have very short TTLs, or vary per user, higher levels will have fewer opportunities to reuse content.

It also doesn’t replace a multiregional architecture. The hint indicates origin location but doesn’t automatically replicate data or shift traffic among multiple cloud regions. Customers must properly maintain their pools, load balancers, and cache policies.

IP or DNS record changes can also trigger a different higher-level cache selection. During this transition, MISS responses may temporarily increase as caches fill anew. Cloudflare recommends checking the CacheTieredFill field in logs to verify if Tiered Cache handled a request.

This simple addition—declaring a region—can have a significant technical impact, as it provides a piece of data that anycast routing previously concealed.

Cloudflare turns a known location into an operational signal for its CDN. While the network still makes dynamic decisions, it no longer confuses cloud edge proximity with actual nearness to the origin server hosting the application.

Frequently Asked Questions

What is Smart Tiered Cache?
It’s a Cloudflare caching topology that funnels origin requests to an automatically selected higher level, instead of letting all data centers directly query the origin.

What is the purpose of the cloud region hint?
It allows specifying the actual location of an origin behind an anycast or regional IP that’s hard to determine via latency alone.

Which providers are supported?
The initial release supports AWS, Google Cloud, Microsoft Azure, and Oracle Cloud.

Is there an additional cost?
Cloudflare states that Smart Tiered Cache and region hints are included at no extra charge for Free, Pro, Business, and Enterprise plans.