Cloudflare vient de mettre à jour Smart Tiered Cache pour régler un problème récurrent dès que le serveur d’origine tourne sur AWS, Google Cloud, Microsoft Azure ou Oracle Cloud. La plateforme permet désormais d’indiquer la région où l’application est vraiment hébergée, même quand l’adresse IP en anycast semble présente partout à la fois.

La nouvelle option évite qu’une requête traverse des continents entiers avant d’atteindre l’origine. Jusqu’ici, Cloudflare pouvait repérer qu’une IP répondait avec une faible latence depuis plusieurs points du globe, sans pouvoir dire où se trouvait réellement le backend. Face à ce doute, le système multipliait les niveaux supérieurs de cache, une solution prudente mais qui dispersait les requêtes et rognait l’efficacité du cache.

Ce qu’il faut retenir en 20 secondes

• Cloudflare permet désormais d’indiquer la région cloud où se trouve l’origine.
• La fonction couvre pour l’instant AWS, Google Cloud, Azure et Oracle Cloud.
• Disponible sur les plans Free, Pro, Business et Enterprise, sans surcoût.
• Smart Tiered Cache choisit un niveau supérieur principal proche de la région indiquée, plus une alternative.
• L’objectif : éviter des trajets absurdes comme Asie-États-Unis-Asie pour joindre une origine asiatique.
• Configuration possible via le panneau, l’API ou Terraform.
• L’indication régionale ne déplace aucune donnée et ne change rien au contrat passé avec le fournisseur cloud.

Comment fonctionne Tiered Cache

Tiered Cache organise les centres de données de Cloudflare en hiérarchie. Quand un nœud proche de l’utilisateur n’a pas la ressource demandée, il interroge d’abord un nœud supérieur. Seul ce niveau va, si besoin, chercher le contenu directement auprès du serveur d’origine. Ce regroupement évite que des dizaines de centres de données ouvrent chacun leur propre connexion vers la même infrastructure, ce qui fait grimper le taux de cache hit et fait baisser le trafic vers l’origine ainsi que le nombre de connexions à maintenir côté serveur.

Le problème : localiser une origine cloud grâce à la seule latence

Lancé en 2021, Smart Tiered Cache repose sur une idée simple : mesurer la latence entre le réseau Cloudflare et l’origine, puis retenir comme niveau supérieur le centre de données le mieux connecté. Ça fonctionne très bien quand l’IP appartient à un serveur situé dans un endroit identifiable : une origine à Madrid affichera une tendance nette vers un site proche.

Les services cloud publics changent la donne. Équilibreurs de charge, points d’entrée régionaux et autres composants s’appuient souvent sur l’anycast ou des architectures régionales où une même IP répond depuis plusieurs points du réseau du fournisseur. La mesure de latence n’aboutit alors plus forcément au serveur qui exécute réellement l’application : elle peut s’arrêter au point d’entrée le plus proche chez AWS, Azure, Google Cloud ou Oracle, qui relaie ensuite la requête par son réseau privé jusqu’au backend.

Une IP liée à une application déployée à Singapour peut ainsi paraître très proche depuis Chicago, simplement parce que le centre de données américain atteint vite la frontière du fournisseur cloud. Rien ne dit pour autant que le contenu s’y trouve. Si Cloudflare retenait Chicago comme niveau supérieur, une requête d’un utilisateur asiatique suivrait un parcours absurde : nœud proche en Asie, erreur de cache vers Chicago, appel de Chicago au service cloud, transport par le réseau du fournisseur jusqu’à Singapour, puis retour en sens inverse.

Cet effet, appelé hairpinning, ajoute un aller-retour transcontinental sans aucune valeur. Selon les routes, cela peut coûter des centaines de millisecondes et gonfler le trafic entre régions. Pour limiter la casse, Smart Tiered Cache évitait de figer une IP ambiguë sur un seul niveau supérieur et en utilisait plusieurs à la fois. Le cache continuait de fonctionner, mais le contenu se retrouvait plus dispersé, ce qui augmentait les chances que différents nœuds interrogent l’origine directement.

La piste régionale, une correction simple pour le routage

La solution tient en une indication explicite du type aws:us-east-1 ou gcp:europe-west1. Cloudflare n’a plus besoin de deviner la localisation à partir du comportement d’une IP anycast, il connaît directement le fournisseur et la région de référence. Depuis le panneau d’administration, l’option se configure dans Caching puis Tiered Cache puis Origin Configuration : l’administrateur localise l’IP ou le nom de l’origine, sélectionne Set Region Hint et choisit fournisseur et région. La même configuration passe aussi par l’API, ce qui facilite son intégration dans des pipelines automatisés, et Cloudflare prévoit de la gérer via Terraform.

Ce pense-bête ne force rien : Cloudflare garde la décision finale, basée sur ses mesures et l’état de son réseau. La contribution du client se limite à fournir un contexte que l’IP seule ne peut généralement pas révéler. Pour construire cette correspondance, Cloudflare télécharge toutes les quelques heures les plages d’adresses IP publiques des fournisseurs concernés, avec leurs préfixes par région, et intègre les changements dès qu’un cloud ajoute, retire ou réattribue des sous-réseaux. Ces plages sont ensuite croisées avec une base de niveaux supérieurs alimentée par des mesures de latence actualisées toutes les 15 minutes.

Chaque sous-réseau associé à une région reçoit une pondération. La localisation la mieux notée devient le niveau supérieur principal, une autre est choisie dans un point de présence différent pour qu’un incident local n’affecte pas les deux routes en même temps. Quand les données manquent, le système privilégie d’abord une proximité géographique, puis affine sa décision au fil des mesures.

Repérer une IP anycast avec la vitesse de la lumière

Avant d’autoriser la configuration régionale, Cloudflare vérifie si une IP répond depuis plusieurs sites. La méthode s’appuie sur une limite physique impossible à contourner par le routage : la vitesse de la lumière. Le système mesure la latence depuis plusieurs centres de référence, et si la somme de deux trajets tombe sous le temps minimal nécessaire en fibre optique pour parcourir la distance entre ces points, la réponse ne peut tout simplement pas venir d’un seul serveur. Deux points séparés de milliers de kilomètres qui reçoivent tous les deux une réponse très rapide depuis la même IP, ça trahit une annonce anycast depuis plusieurs sites à la fois.

Cette approche évite de dépendre de bases IP géographiques souvent périmées, qui indiquent parfois le siège administratif d’une entreprise plutôt que la localisation réelle du serveur. Dans le panneau, les pistes régionales n’apparaissent que pour les origines déjà identifiées comme anycast. Une topologie personnalisée reste prioritaire : l’indication régionale ne remplace pas une configuration spécifique déjà fixée pour un client Enterprise.

Ce que ça change concrètement pour une application

L’impact varie selon l’architecture, le volume de trafic et la capacité de cache du site. Il se fera surtout sentir quand plusieurs conditions se cumulent : origine derrière une IP anycast ambiguë, ancienne localisation trop éloignée du backend, contenu cacheable conséquent, trafic venant de plusieurs régions, et beaucoup de requêtes répétées à cause d’échecs de cache. Concentrer les requêtes sur un seul niveau supérieur augmente les chances d’y trouver une copie, réduit le nombre de connexions et le volume transféré vers le fournisseur cloud, ce qui allège la charge du backend et les coûts de sortie de données.

Cette fonction ne corrige pas une politique de cache mal réglée. Si les réponses sont marquées privées, ont une durée de vie courte ou changent selon l’utilisateur, le niveau supérieur aura peu de chances de réutiliser quoi que ce soit. Elle ne remplace pas non plus une vraie architecture multirégionale, comme celle décrite dans notre analyse sur la latence et la géographie de l’hébergement : la piste indique où se trouve une origine, elle ne duplique pas l’application ni ne déplace le trafic entre régions cloud. Les équipes qui gèrent plusieurs backends doivent continuer à maintenir leurs pools, leurs équilibrages et leurs politiques de cache.

Un changement d’IP ou d’enregistrement DNS peut entraîner la sélection d’un autre niveau supérieur. Pendant la transition, le nombre d’échecs de cache (MISS) grimpe temporairement, le temps que le nouveau cache se remplisse. Cloudflare recommande de surveiller le champ CacheTieredFill dans les logs pour vérifier si Tiered Cache est bien intervenu sur une requête donnée.

Perspectives

Déclarer une région reste une manipulation simple, mais son effet peut être net puisqu’elle donne au système une information que l’anycast ne pouvait jusque-là pas révéler. Cloudflare transforme ainsi une localisation connue en paramètre opérationnel pour son CDN, à l’heure où la plateforme multiplie les briques edge, du filtrage de bots avec Precursor à l’analyse continue du comportement des visiteurs. Le réseau garde ses décisions dynamiques, mais évite désormais de confondre proximité du bord avec proximité réelle du serveur d’application. Une distinction que d’autres acteurs européens du edge, comme Aire Cloud avec son offre CDN et WAF intégrée, devront eux aussi soigner à mesure que leurs clients multiplient les déploiements multicloud.

Questions fréquentes

Qu’est-ce que Smart Tiered Cache ?

Une hiérarchie de cache Cloudflare qui concentre l’accès à l’origine sur un niveau supérieur choisi automatiquement, plutôt que de laisser chaque centre de données interroger directement le serveur.

À quoi sert l’indication de région cloud ?

À signaler explicitement la localisation réelle d’un backend situé derrière une adresse anycast ou difficile à localiser par simple mesure de latence.

Quels fournisseurs sont supportés aujourd’hui ?

La première version couvre AWS, Google Cloud, Microsoft Azure et Oracle Cloud.

Cette fonction entraîne-t-elle un coût supplémentaire ?

Non, Cloudflare la propose gratuitement sur les plans Free, Pro, Business et Enterprise.