Cloudflare ha actualizado Smart Tiered Cache para resolver un problema frecuente cuando el servidor de origen se encuentra en AWS, Google Cloud, Microsoft Azure u Oracle Cloud. La plataforma permitirá indicar en qué región está alojada realmente la aplicación, incluso cuando la dirección IP del servicio sea anycast y parezca estar presente en varios lugares a la vez.

La nueva función evita que una petición recorra continentes innecesariamente antes de llegar al origen. Hasta ahora, Cloudflare podía detectar que una IP respondía con baja latencia desde varias ubicaciones, pero no siempre podía averiguar dónde se encontraba el backend final. Ante esa ambigüedad, utilizaba varios niveles superiores de caché, una decisión segura que reducía la concentración de peticiones y, con ella, parte de la eficiencia del sistema.

Smart Tiered Cache para nubes públicas: las claves en 20 segundos

• Cloudflare permite informar de la región cloud donde se encuentra el origen.
• La función admite inicialmente AWS, Google Cloud, Azure y Oracle Cloud.
• Está disponible para los planes Free, Pro, Business y Enterprise sin coste adicional.
• Smart Tiered Cache selecciona un nivel superior principal cercano a la región indicada.
• También asigna una ubicación alternativa en otro punto de presencia.
• El cambio busca evitar rutas como Asia-Estados Unidos-Asia para llegar a un origen asiático.
• La configuración puede realizarse desde el panel, la API o Terraform.
• Cloudflare mantiene actualizados los rangos de direcciones de los proveedores cloud.
• La base utilizada para elegir los niveles superiores se recalcula con mediciones de latencia.
• La indicación regional no mueve los datos ni modifica la región contratada al proveedor.

Tiered Cache organiza los centros de datos de Cloudflare en una jerarquía. Cuando un nodo próximo al usuario no tiene un recurso almacenado, consulta primero a otro nodo superior. Solo este nivel puede solicitar el contenido al servidor de origen si tampoco dispone de una copia.

Esta concentración evita que decenas de centros de datos abran conexiones independientes contra la misma infraestructura. El resultado esperado es una mayor proporción de aciertos de caché, menos tráfico hacia el origen y un número menor de conexiones que el servidor debe mantener abiertas.

El problema de buscar un origen cloud mediante latencia

Smart Tiered Cache se lanzó en 2021 con una idea relativamente sencilla: medir la latencia desde la red de Cloudflare hasta el origen y escoger como nivel superior el centro de datos mejor conectado.

El sistema funciona bien cuando la IP pertenece a un servidor ubicado en un lugar identificable. Si un origen está en Madrid, los sondeos realizados desde distintos centros de datos deberían mostrar una tendencia suficientemente clara para elegir una ubicación próxima.

La situación cambia con los servicios públicos de nube. Los balanceadores, puertas de entrada regionales y otros componentes pueden utilizar anycast o arquitecturas regionales en las que una misma dirección IP responde desde diferentes puntos de la red del proveedor.

La medición ya no alcanza necesariamente el servidor donde se ejecuta la aplicación. Puede terminar en el punto de entrada más cercano de AWS, Azure, Google Cloud u Oracle, que después transportará la solicitud por su red privada hasta el backend.

Así, una IP asociada a una aplicación desplegada en Singapur puede parecer muy cercana desde Chicago. El centro de datos estadounidense llega rápidamente al borde del proveedor cloud, pero eso no significa que el contenido esté allí.

Si Cloudflare eligiera Chicago como nivel superior, una petición iniciada por un usuario asiático podría seguir este recorrido:

1. El usuario conecta con un nodo cercano de Cloudflare en Asia.
2. El nodo envía el fallo de caché al nivel superior situado en Chicago.
3. Chicago solicita el contenido al servicio cloud.
4. La red del proveedor transporta la petición hasta el backend en Singapur.
5. La respuesta recorre el trayecto inverso.

Este efecto, conocido como hairpinning, introduce un viaje transcontinental que no aporta valor. En determinadas rutas puede añadir cientos de milisegundos y aumentar el tráfico entre regiones.

Cuando Smart Tiered Cache detectaba una IP ambigua, evitaba fijarla a un único nivel superior. En su lugar utilizaba varios, reduciendo el riesgo de escoger una ubicación equivocada. La caché seguía funcionando, pero el contenido quedaba más repartido y aumentaba la posibilidad de que diferentes nodos terminasen consultando al origen.

Tipo de origen	Decisión habitual
IP unicast con ubicación clara	Un nivel superior próximo al origen
IP anycast sin información regional	Varios niveles superiores
Nube pública con región declarada	Nivel principal cercano y alternativa separada
Topología personalizada	Prevalece la configuración definida por el cliente

La documentación de Cloudflare confirma que los orígenes de AWS, Google Cloud, Azure y Oracle pueden usar ahora una indicación regional para que Smart Tiered Cache seleccione un centro de datos principal próximo y otro alternativo en una ubicación distinta.

Una pista regional para que Cloudflare elija mejor la ruta

La solución consiste en proporcionar una pista explícita, como aws:us-east-1 o gcp:europe-west1. Cloudflare ya no necesita deducir toda la ubicación a partir del comportamiento de una IP anycast: sabe qué proveedor y qué región debe tomar como referencia.

Desde el panel, la opción se encuentra en Caching > Tiered Cache > Origin Configuration. El administrador localiza la IP o el nombre del origen, selecciona Set Region Hint y escoge el proveedor y la región.

La misma configuración está disponible mediante API, lo que permite incorporarla a procesos automatizados. Cloudflare también contempla su administración con Terraform para que la correspondencia entre origen y región forme parte de la infraestructura como código.

La pista no fuerza el uso de un centro de datos concreto. Cloudflare continúa tomando la decisión final a partir de sus mediciones y de la situación de su red. El cliente aporta el contexto que no puede extraerse con fiabilidad de la IP.

Para construir esa correspondencia, la compañía descarga cada pocas horas los archivos públicos con los rangos de direcciones de los proveedores compatibles. Esos ficheros reflejan qué prefijos están asociados con cada región y recogen los cambios cuando una nube añade, elimina o reasigna subredes.

Después cruza esos rangos con una base de niveles superiores construida mediante sondeos continuos. Según la explicación técnica de Cloudflare, los datos de latencia utilizados para esa selección se actualizan cada 15 minutos.

Cada subred asociada con una región aporta un voto ponderado. La ubicación con la señal más sólida se convierte en el nivel superior principal. La alternativa se elige en otro punto de presencia para evitar que una incidencia local afecte a ambas rutas.

Cuando todavía no existen suficientes mediciones, el sistema recurre a la geografía y elige inicialmente uno de sus centros principales próximos. A medida que llegan datos reales, puede sustituir esa estimación por una selección basada en el rendimiento observado.

Cómo detecta Cloudflare que una IP es anycast

Antes de permitir la configuración regional desde el panel, Cloudflare intenta determinar si la IP responde desde varios lugares. Para ello utiliza una limitación que no puede manipularse mediante enrutamiento: la velocidad de la luz.

La compañía mide la latencia desde varios centros de datos de referencia. Si la suma de dos trayectos resulta menor que el tiempo físicamente necesario para viajar entre esos lugares por fibra, la respuesta no puede proceder de un único servidor.

Supongamos que dos puntos separados por miles de kilómetros reciben una respuesta extremadamente rápida desde la misma IP. Un origen ubicado en un único lugar no podría estar tan cerca de ambos al mismo tiempo. La explicación probable es que la dirección está anunciada desde múltiples ubicaciones.

Este método permite distinguir un origen unicast de una entrada anycast sin depender únicamente de bases geográficas de IP, que pueden estar desactualizadas o describir la sede administrativa del propietario en lugar de la ubicación real del servicio.

En el panel, las pistas regionales se muestran para los orígenes que Cloudflare ha identificado como anycast. Mediante la API se puede consultar el catálogo de proveedores y regiones compatibles. La documentación señala además que una topología personalizada tiene prioridad, por lo que una pista regional no sobrescribirá una configuración específica acordada para un cliente Enterprise.

Qué mejoras puede esperar una aplicación

El efecto dependerá de la arquitectura, el tráfico y la proporción de contenido que pueda almacenarse en caché. No todas las webs experimentarán una reducción visible de latencia.

La mejora será más clara cuando concurran varias condiciones:

• el origen está detrás de una IP anycast o regional ambigua;
• la ubicación elegida anteriormente quedaba lejos del backend;
• existe una cantidad relevante de contenido cacheable;
• el servicio recibe tráfico desde múltiples regiones;
• el origen soporta muchas peticiones repetidas por fallos de caché.

Concentrar las consultas en un nivel superior aumenta la probabilidad de encontrar allí una copia. También reduce las conexiones y las transferencias solicitadas al proveedor cloud, algo que puede influir tanto en la carga del backend como en los costes de salida de datos.

La función no corrige una política de caché deficiente. Si las respuestas se marcan como privadas, utilizan tiempos de vida muy cortos o cambian constantemente por usuario, el nivel superior tendrá pocas oportunidades de reutilizar el contenido.

Tampoco sustituye a una arquitectura multirregional. La pista informa de dónde se encuentra un origen, pero no replica una aplicación ni desplaza automáticamente el tráfico entre varias regiones cloud. Los clientes con diferentes backends deberán mantener correctamente sus pools, balanceadores y políticas de caché.

Los cambios en la IP o en los registros DNS también pueden provocar que Smart Tiered Cache seleccione otro nivel superior. Durante el traslado aumentarán temporalmente los MISS mientras la nueva caché se llena. Cloudflare recomienda comprobar en los registros el campo CacheTieredFill para verificar si Tiered Cache intervino en una petición.

La novedad es pequeña desde el punto de vista de configuración: basta con declarar una región. Su efecto técnico puede ser considerable porque proporciona al sistema un dato que el enrutamiento anycast ocultaba.

Cloudflare convierte así una ubicación conocida por el administrador en una señal operativa para su CDN. La red continúa tomando decisiones dinámicas, pero deja de confundir la cercanía al borde de una nube con la proximidad real al servidor donde reside la aplicación.

Preguntas frecuentes

¿Qué es Smart Tiered Cache?
Es una topología de caché de Cloudflare que concentra los accesos al origen en un nivel superior seleccionado automáticamente, en lugar de permitir que todos los centros de datos lo consulten directamente.

¿Para qué sirve la indicación de región cloud?
Permite informar de la ubicación real de un backend que se encuentra detrás de una dirección anycast o de una entrada regional difícil de localizar mediante latencia.

¿Qué proveedores están admitidos?
La primera versión es compatible con AWS, Google Cloud, Microsoft Azure y Oracle Cloud.

¿Tiene un coste adicional?
Cloudflare indica que Smart Tiered Cache y las pistas de región están disponibles sin coste adicional en los planes Free, Pro, Business y Enterprise.