Introducción
En entornos de cloud público, los orígenes rara vez tienen una ubicación fija. Proveedores como AWS, Azure o GCP suelen exponer sus balanceadores de carga o puntos de entrada mediante IPs anycast o unicast regionales, lo que dificulta que Cloudflare determine con precisión la mejor ruta para el tráfico. Hasta ahora, el sistema Smart Tiered Cache de Cloudflare intentaba seleccionar un único upper tier (data center de borde) como punto de concentración para las misses de caché, pero en estos casos terminaba derivando el tráfico a nodos subóptimos, generando hairpinning: rutas que cruzan continentes innecesariamente.
Por ejemplo, si un origen está alojado en Singapur pero su IP anycast es alcanzable desde múltiples data centers de Cloudflare, el sistema podría elegir Chicago como upper tier para una solicitud desde Asia. El resultado: el tráfico viaja de Asia a Chicago, luego vuelve a Singapur para obtener el recurso, sumando cientos de milisegundos de latencia adicional. Esto no solo degrada la experiencia del usuario, sino que incrementa la carga en el origen y reduce la eficiencia de la caché.
Qué ocurrió
Cloudflare resolvió este problema con la incorporación de Smart Tiered Cache para regiones de nube pública, que permite a los equipos definir hints regionales (ej: aws:us-east-1, gcp:europe-west1) para sus orígenes alojados en proveedores soportados. La solución automatiza la selección del upper tier más cercano al origen real, incluso cuando la IP es anycast, evitando el hairpinning.
El lanzamiento incluye soporte nativo para AWS, GCP, Azure y Oracle Cloud, con integración directa en Terraform y APIs. Desde noviembre de 2024, Cloudflare ya había mejorado el sistema para manejar orígenes en R2 (su almacenamiento objeto) y, en enero de 2025, para pools de balanceo de carga (Load Balancing). Estas iteraciones anteriores demostraron que el enfoque de entender la infraestructura del cliente y automatizar las decisiones es clave para optimizar el rendimiento.
Impacto para DevOps, Infraestructura, Cloud y Seguridad
DevOps y SRE
Para equipos que operan orígenes en múltiples regiones, la mejora reduce la necesidad de ajustes manuales en la configuración de caché. El hint regional se propaga automáticamente a través del sistema de Cloudflare, que:
- Asigna el upper tier óptimo: Elige el data center más cercano al origen real, no al frontend anycast.
- Minimiza el tráfico cruzado: Elimina rutas como «Asia → Chicago → Singapur», reduciendo la latencia en hasta un 70% en casos extremos (según mediciones de Cloudflare con orígenes en Singapur y Chicago).
- Mantiene alta disponibilidad: El sistema prioriza upper tiers en PoPs distintos para evitar dependencia de un único punto de falla.
Para equipos que usan Infrastructure as Code, la configuración via Terraform o API acelera la adopción. Un ejemplo con Terraform:
resource "cloudflare_zone_settings_override" "smart_tiered_cache" {
zone_id = "d41d8cd98f00b204e9800998ecf8427e"
settings {
tiered_cache_mode = "smart"
tiered_cache_origin_region_hints = {
"203.0.113.10" = "aws:ap-southeast-1"
"198.51.100.20" = "gcp:us-central1"
}
}
}Infraestructura y Cloud
Los proveedores de cloud implementan anycast por defecto en balanceadores de carga (ej: AWS Global Accelerator, Azure Front Door, GCP HTTP(S) Load Balancing). Esto genera IPs compartidas que resuelven a múltiples regiones, confundiendo los sistemas de enrutamiento tradicional. Con el hint regional, Cloudflare correlaciona:
- Subredes dinámicas: Cada 4 horas, Cloudflare descarga los rangos de IPs de los proveedores soportados (AWS, GCP, Azure, Oracle) y los mapea a regiones.
- Votación ponderada: Para cada subred, asigna un upper tier basado en mediciones de latencia actualizadas cada 15 minutos. Si una región no tiene suficientes datos (ej: un nuevo availability zone), el sistema usa un fallback geográfico a un PoP Tier 1 cercano.
Seguridad
Aunque el hint no modifica la superficie de ataque, reduce la exposición a:
- Ataques de origen: Menos tráfico cruzado significa menos puntos de entrada indirectos para abusadores que aprovechan rutas subóptimas.
- Fugas de datos: Con rutas más directas, se minimiza el riesgo de exposición en tránsito en redes compartidas.
Detalles técnicos
Detección de anycast
Cloudflare identifica orígenes anycast mediante una restricción física: la velocidad de la luz. Si las latencias desde dos data centers distintos (ej: Tokio y Frankfurt) a una misma IP son menores que el tiempo mínimo que tardaría la luz en viajar entre ambas ubicaciones fibra óptica, el sistema deduce que la IP responde desde múltiples ubicaciones.
Algoritmo simplificado:
- Medir latencia desde N PoPs de Cloudflare a la IP del origen.
- Calcular la distancia física mínima entre cada par de PoPs (usando coordenadas geográficas).
- Comparar: si
latencia(Tokio→IP) + latencia(Frankfurt→IP) < distancia(Tokio→Frankfurt) / velocidad_luz, entonces la IP es anycast.
Este enfoque evita falsos positivos en casos de anycast legítimo (como los de CDNs).
Mapeo dinámico de regiones
Cloudflare mantiene una base de datos de upper tiers actualizada cada 15 minutos, donde cada región de cloud tiene asociado:
- Primary upper tier: El PoP con mejor latencia medida.
- Backup upper tier: Un PoP alternativo en otra zona geográfica (para evitar single point of failure).
- Fallback geográfico: Si no hay datos suficientes, usa el PoP Tier 1 más cercano a la región indicada en el hint.
Ejemplo de cómo Cloudflare procesa los hints para una IP anycast:
- Recibe el hint
aws:ap-southeast-2para una IP. - Descarga el rango de IPs de AWS para
ap-southeast-2(ej:52.95.110.0/24). - Busca coincidencias entre la IP del origen y los rangos de subredes de la región.
- Asigna el upper tier basado en la votación ponderada de latencia.
Integración con Terraform y APIs
La configuración via API sigue el patrón REST de Cloudflare. Ejemplo en Python para actualizar hints regionales:
import requests
headers = {
"Authorization": "Bearer <API_TOKEN>",
"Content-Type": "application/json"
}
payload = {
"tiered_cache_origin_region_hints": {
"203.0.113.10": "azure:eastus",
"198.51.100.20": "gcp:asia-northeast1"
}
}
response = requests.patch(
"https://api.cloudflare.com/client/v4/zones/<ZONE_ID>/settings/tiered_cache",
headers=headers,
json=payload
)En Terraform, el campo tiered_cache_origin_region_hints acepta un mapa de IPs a strings de región (ej: "aws:us-east-1").
Proveedores soportados y versiones
- AWS: Desde us-east-1 hasta ap-southeast-4 (regiones soportadas en junio 2025).
- GCP: Desde us-central1 hasta southamerica-east1.
- Azure: Desde eastus hasta brazilsouth.
- Oracle Cloud: Desde us-phoenix-1 hasta ap-tokyo-1.
Cloudflare actualiza automáticamente los rangos de IPs cada 4 horas, por lo que no requiere intervención manual al agregar o mover recursos en la nube.
Qué deberían hacer los administradores y equipos técnicos
1. Identificar orígenes anycast
No todos los orígenes anycast necesitan un hint. Cloudflare lo recomienda cuando:
- El origen usa un balanceador de carga anycast (AWS ALB, GCP Global Load Balancer, etc.).
- Las mediciones de latencia muestran rutas subóptimas (ej: tráfico de Europa a un upper tier en EE.UU.).
Para verificar, revisa en el dashboard de Cloudflare:
- Caching > Tiered Cache > Origin Configuration.
- Busca el campo «Anycast detected» en la tabla de orígenes.
Si el origen tiene cualquiercast detectado, aparecerá la opción para agregar un hint.
2. Configurar el hint regional
Puedes hacerlo de tres formas:
a) Dashboard de Cloudflare
- Ve a Caching > Tiered Cache > Origin Configuration.
- Haz clic en el ícono de edición junto al origen anycast.
- Selecciona el proveedor y región (ej:
aws:us-west-2). - Guarda los cambios.
b) API de Cloudflare
Usa el endpoint PATCH /zones/{zone_id}/settings/tiered_cache con el payload:
{
"tiered_cache_origin_region_hints": {
"203.0.113.10": "azure:northeurope"
}
}c) Terraform
Agrega el bloque tiered_cache_origin_region_hints al recurso cloudflare_zone_settings_override:
settings {
tiered_cache_mode = "smart"
tiered_cache_origin_region_hints = {
"203.0.113.10" = "gcp:europe-west4"
"198.51.100.20" = "oracle:sa-saopaulo-1"
}
}3. Validar la configuración
Tras aplicar el hint, verifica:
- Latencia: Usa herramientas como
pingomtrdesde una VM en la región del origen para confirmar que el tráfico ya no cruza continentes. - Tasas de acierto en caché: En Analytics > Caching, monitorea el hit ratio del upper tier asignado. Un aumento del 10-15% es esperable en orígenes con tráfico anycast.
- Tráfico origin-to-edge: Reduce la métrica «Origin Requests» en Analytics > Traffic para la zona afectada.
4. Automatizar con CI/CD
Si gestionas múltiples zonas, integra la configuración en tu pipeline:
# .github/workflows/update-tiered-cache.yml
- name: Update Tiered Cache hints
run: |
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/settings/tiered_cache" \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"tiered_cache_origin_region_hints": {"203.0.113.10": "aws:ap-southeast-1"}}'5. Monitorear cambios en rangos de IPs
Dado que los proveedores actualizan sus rangos cada pocas semanas, revisa:
- AWS IP Ranges: https://ip-ranges.amazonaws.com/ip-ranges.json
- GCP IP Ranges: https://www.gstatic.com/ipranges/cloud.json
Si Cloudflare no actualiza automáticamente un rango modificado, contacta al soporte con el hint afectado.
Conclusión
La mejora de Smart Tiered Cache para regiones de nube pública resuelve un problema crítico en entornos cloud modernos: la ambigüedad de las IPs anycast. Al permitir que los equipos definan hints regionales, Cloudflare automatiza la selección del upper tier óptimo, eliminando el hairpinning y mejorando la latencia en un 30-70% para orígenes con tráfico anycast.
Para equipos de DevOps y SRE, la integración nativa con Terraform y APIs simplifica la adopción, mientras que la detección automática de anycast reduce la carga operativa. La solución es gratuita para todos los planes de Cloudflare, pero su verdadero valor radica en la capacidad de entender la infraestructura del cliente y actuar en consecuencia.
En un mundo donde el 64% de las aplicaciones empresariales corren en la nube pública (según Flexera 2025), herramientas como esta marcan la diferencia entre una arquitectura eficiente y una con latencias ocultas.