Un transfert d'électricité à São Paulo met à l'épreuve ce que la carte anycast latino-américaine de Cloudflare ne peut promettre

Résumé

• Cloudflare divulgue une vaste empreinte de villes latino-américaines et 500 Tbps d'interconnexion externe mondiale, mais ne publie pas le nombre de serveurs, la puissance sous contrat, la capacité de port disponible ni les routes physiquement diversifiées disponibles sur chaque site latino-américain.
• Les registres publics établissent une société costaricaine, des ressources d'adresse costaricaines et un déploiement à San José associé au NIC.CR, mais ils n'établissent pas que la société costaricaine possède ou contracte chaque rack régional, circuit ou relation client portant le nom Cloudflare.
• Anycast peut déplacer l'accessibilité loin d'un site défaillant, mais une récupération réussie dépend toujours de la capacité de calcul et réseau de rechange, de l'alimentation électrique indépendante des installations, de la fibre métropolitaine survivante, des interconnexions fonctionnelles et des personnes autorisées à restaurer l'équipement affecté.

Le commutateur de transfert est là où la carte s'arrête

Considérez une installation neutre pour opérateurs dans la région métropolitaine de São Paulo lors d'un transfert électrique planifié. L'alimentation du réseau est retirée du service, l'alimentation sans interruption prend le relais pendant l'intervalle entre les alimentations, et des générateurs ou une deuxième voie de réseau sont censés prendre le relais. Un technicien surveille la distribution électrique des racks et les interconnexions optiques tandis que les ingénieurs réseau surveillent les routes. C'est un cas de stress, pas un rapport d'un accident particulier de Cloudflare.

Il est utile car il dépouille la facilité visuelle d'une carte de bordure mondiale. Au moment du transfert, les questions pertinentes sont concrètes: quelles armoires sont restées alimentées, quels routeurs ont conservé la lumière, quels pairs sont restés joignables, et combien de travail peut être accepté ailleurs?

Les propres avis opérationnels de Cloudflare révèlent la réponse réseau prévue. Lors de travaux programmés dans son site GRU le 3 juillet 2026, la société a averti que le trafic pourrait être redirigé, que les utilisateurs finaux pourraient constater une légère augmentation de la latence et que les interfaces d'interconnexion privées ou clients dans ce centre de données pourraient devenir temporairement indisponibles. L'avis a ensuite marqué les travaux comme terminés. Cette séquence est visible dans leregistre de maintenance GRU. C'est une preuve étroite: elle montre une fenêtre de maintenance annoncée et le comportement attendu des interfaces, pas l'identité d'un bâtiment, la raison du travail, un changement de trafic mesuré ou la quantité de capacité de réserve utilisée ailleurs.

Lapage de statut publicplus large sépare les sites latino-américains comme San José et São Paulo en composants nommés et donne à chacun une condition actuelle. C'est une visibilité opérationnelle précieuse, mais un composant vert est un instantané. Il ne divulgue pas si le composant représente une ou plusieurs salles, si deux salles partagent une sous-station, ou si un voisin nominalement disponible pourrait accepter une charge régionale soudaine. Il n'identifie pas non plus quelle société légale a acheté l'électricité, loué le rack ou signé la commande d'interconnexion.

L'intuition normale est que l'anycast résout le problème de localisation. L'explication d'anycastde Cloudflare dit que la même adresse peut être servie depuis plusieurs sites et que la mise hors ligne d'un centre de données peut faire fluctuer le trafic vers un site voisin. Cela décrit l'accessibilité. Cela ne fabrique pas de watts, de cycles serveur ou de ports non congestionnés sur le site récepteur. Si São Paulo retire les routes, les utilisateurs peuvent atterrir à Rio de Janeiro, Curitiba, Porto Alegre, Buenos Aires, Santiago, Bogotá, Miami ou un autre site disponible selon les routes que leurs fournisseurs d'accès sélectionnent. Chaque alternative ajoute ses propres conditions d'installation, d'opérateur et de capacité.

Le transfert de puissance teste donc deux systèmes à la fois. Le premier est local: les alimentations réseau, les appareillages, les batteries, les générateurs, le refroidissement, la distribution des racks, les routeurs et les interconnexions doivent rester dans les tolérances. Le second est régional: les changements de route doivent se propager proprement et les destinations qui gagnent du trafic doivent avoir une capacité de réserve utilisable. Une carte urbaine ne représente aucun des deux systèmes à cette résolution.

Elle montre la géographie du service, pas les dépendances électriques et commerciales qui déterminent si le basculement est gracieux. L'écart compte parce que les clients vivent le résultat comme un seul service même lorsque la responsabilité physique est partagée entre Cloudflare, les opérateurs d'installation, les opérateurs télécoms, les échanges et les prestataires sur site.

Un point de ville n'est pas un domaine de défaillance

Lapage réseau actuellede Cloudflare présente une vaste empreinte latino-américaine, avec des dizaines de villes au Brésil et des sites de San José à Bogotá, Lima, Santiago, Buenos Aires et au-delà. La page indique également que tous les services fonctionnent dans chaque centre de données. Ces déclarations établissent l'étendue prévue de la périphérie et la conception commune des services. Elles n'établissent pas que chaque ville contient le même nombre ou la même génération de serveurs, le même nombre de fournisseurs en amont, la même capacité à accepter le trafic d'une autre ville, ou la même protection contre un événement électrique local.

Cloudflare a lui-même expliqué pourquoi la ville est une unité trop grossière. Dans un récit de 2019 sur lamise à l'échelle de son réseau mondial, la société a déclaré qu'une ville pouvait contenir jusqu'à cinq déploiements distincts. Elle a également décrit la planification de la capacité par adresse, et non seulement par ville, et l'utilisation de fournisseurs et de techniciens sur site pour installer et câbler les serveurs. La divulgation était historique et mondiale; ce n'est pas un recensement actuel de l'Amérique latine. Sa valeur analytique continue est la distinction qu'elle établit: une étiquette de métropole peut cacher plusieurs adresses physiques, tandis qu'un déploiement dans une petite ville peut être intégré dans un fournisseur de services Internet plutôt que dans un grand campus neutre.

La dernière divulgation annuelle de l'entreprise fournit l'autre moitié de la frontière. LeFormulaire 10-K 2025de Cloudflare indique que son réseau était hébergé dans des installations de colocation et de partenaires fournisseurs de services Internet dans plus de 330 villes et plus de 125 pays à la fin 2025. Il indique que Cloudflare a un accès électronique et, dans une moindre mesure, physique aux équipements hébergés par des tiers, mais ne contrôle pas le fonctionnement de ces installations. Le même dépôt identifie la perte de puissance, les décisions des opérateurs, les fermetures d'installations, l'erreur humaine et les limites de bande passante comme des risques. Ce ne sont pas des décorations théoriques autour d'un point; c'est la frontière opérationnelle du point.

L'étendue se présente également sous différentes formes physiques. Un récit d'expansion de 2023 indiquait que Cloudflare avait atteint plus de 300 villes et décrivait un nouveau site à Campos dos Goytacazes, au Brésil, interconnecté avec un fournisseur régional desservant plus de 100 fournisseurs de services Internet locaux. La société a rapporté que les mesures de latence se sont sensiblement améliorées après l'ouverture du site. Cerécit d'expansion de villesoutient la présence d'une périphérie dirigée par un partenaire proche des utilisateurs. Il ne divulgue pas la puissance du rack, la quantité de serveurs, l'utilisation des ports ou la route qui transporterait la charge si le site partenaire tombait en panne.

Un domaine de défaillance utile doit être dessiné autour des dépendances partagées. Deux déploiements à des adresses différentes peuvent toujours dépendre de la même sous-station électrique, du même conduit d'opérateur, du même tissu d'échange, de la même sortie longue distance ou du même fournisseur de support local. Inversement, deux armoires dans un grand campus peuvent avoir des chaînes électriques significativement séparées et des entrées de fibre diverses. Les listes de villes publiques ne résolvent aucun des deux cas.

Même une installation nommée ne prouve pas que deux circuits d'un client particulier aboutissent sur des dispositifs séparés ou qu'une capacité de réserve existe derrière chacun.

C'est pourquoi un nombre de villes n'est pas un nombre de choix de récupération indépendants. C'est une mesure de portée géographique. Pour le convertir en une affirmation de résilience, un lecteur aurait besoin du nombre de sites actifs par métropole, de leur corrélation de puissance et de fibre, des charges de travail activées sur chacun, de l'utilisation normale et d'urgence de chaque port, et de la politique de retrait ou de restauration des routes. Aucun de ces éléments ne peut être déduit simplement parce que São Paulo, San José et Bogotá apparaissent sur la même carte.

La société costaricaine est une frontière, pas une étiquette d'actif régional

CloudFlare Latin America S.R.L est une véritable présence juridique costaricaine, pas un surnom géographique. La gazette officielle du Costa Rica a enregistré une action corporative de « Cloudflare Latin America S.R.L. » en janvier 2026 et a donné le numéro de personne légale 3-102-651761. L'avis concernait son adresse électronique officielle et sa représentation résidente, pas les actifs réseau, mais l'entrée de la gazetteest une preuve publique récente que la société existe dans le système corporatif costaricain.

Les registres de numéros Internet fournissent un lien séparé. L'enregistrement public du bloc 190.93.240.0/20de LACNIC nomme CloudFlare Latin America S.R.L comme titulaire et donne une adresse dans la région de San José, tandis que les contacts opérationnels pointent vers les opérations réseau de Cloudflare à San Francisco. Cela soutient une relation entre la société costaricaine et les ressources d'adresse utilisées sous l'opération plus large de Cloudflare. Cela ne prouve pas que chaque adresse est servie uniquement au Costa Rica. Anycast permet délibérément que les mêmes adresses de service soient annoncées depuis plusieurs endroits, et un enregistrement d'adresse n'est pas un inventaire de rack ou un document de titre.

La surface contractuelle client pointe dans une direction différente. Lecontrat d'abonnement d'entreprise standardde Cloudflare stipule que l'accord public est entre le client et Cloudflare, Inc., une société du Delaware. Il permet également l'utilisation par des affiliés et des formulaires de commande d'affiliés séparés. La conclusion correcte est limitée: les conditions standard publiques n'attribuent pas les abonnements d'entreprise ordinaires à la société costaricaine. Elles n'excluent pas un formulaire de commande différent, un arrangement fiscal local, un bail immobilier, un contrat de travail, un accord d'opérateur ou une transaction d'affilié. Ces documents ne sont pas publics dans les documents examinés ici.

La même prudence s'applique dans toute l'Amérique latine. Un rack marqué Cloudflare au Brésil pourrait être possédé par Cloudflare, Inc., un autre affilié, un partenaire de service ou une contrepartie d'hébergement dans des termes non visibles de l'extérieur. La société costaricaine peut détenir des ressources de numéros particulières ou des obligations locales sans être la partie contractante pour une salle à São Paulo. Inversement, l'absence de son nom d'une page d'installation ne montrerait pas qu'elle n'a aucun rôle financier ou opérationnel.

Les registres publics d'installations et de routage identifient généralement le réseau ou la marque, pas l'allocation interne des droits entre affiliés.

Cette frontière compte lors des pannes. La partie qui peut demander à un opérateur de tester les niveaux de lumière, autoriser une visite de technicien à distance, approuver une dépense d'urgence ou faire respecter un engagement de service peut ne pas être la même partie nommée dans un enregistrement IP public. Les exigences réglementaires peuvent également s'attacher à la société locale même lorsque les décisions opérationnelles sont prises ailleurs. Sans contrats, registres de conseil d'administration ou divulgations explicites d'affiliés, attribuer un contrôle régional à CloudFlare Latin America S.R.L irait au-delà des preuves.

La description la plus défendable est donc en couches. Cloudflare, Inc. rapporte le réseau mondial consolidé et ses dépendances d'installations tierces. AS13335 est l'identité de routage mondiale. CloudFlare Latin America S.R.L est une société costaricaine associée aux ressources LACNIC et à un registre légal costaricain actuel. NIC.CR a été nommé comme partenaire pour le premier déploiement à San José. Ces couches sont clairement liées à un seul service, mais elles ne sont pas interchangeables.

Un récit de périphérie régionale qui les réduit à « l'entreprise costaricaine opère en Amérique latine » transformerait l'association en propriété et la propriété en contrôle sans preuve publique.

San José prouve la présence, pas le contrôle

Cloudflare a annoncé son premier déploiement costaricain en juin 2021. Sonrécit d'expansion à San Joséindiquait que le site avait été établi avec NIC.CR, géré par l'Academia Nacional de Ciencias. C'est une preuve directe de l'entreprise pour une présence déployée et un partenaire local nommé à ce moment-là. La carte réseau actuelle et le composant de statut indiquent que San José reste représenté dans l'empreinte en direct. Aucune des divulgations ne nomme le bâtiment, le nombre de serveurs, l'allocation électrique, la liste d'opérateurs, le stock de pièces de rechange ou le propriétaire contractuel de l'équipement.

NIC Costa Rica décrit CRIX comme un point d'échange Internet neutre qui permet aux réseaux locaux d'échanger du trafic à un point commun à l'intérieur du pays plutôt que de dépendre de liaisons internationales. Cettedescription d'infrastructure NIC.CRétablit pourquoi une périphérie à San José peut être importante: le peering local peut garder une partie du trafic costaricain local, réduire la dépendance au transit international pour cet échange et réduire la distance au contenu mis en cache ou traité. Elle n'établit pas la taille actuelle du port de Cloudflare ni si tous les fournisseurs d'accès costaricains atteignent Cloudflare via CRIX.

L'enregistrement réseau PeeringDBactuel auto-déclaré de Cloudflare identifie AS13335 comme un réseau anycast mondial et liste ses relations de peering public et de facility. L'enregistrement inclut une connexion CRIX opérationnelle et rapporte un port d'échange de 200 Gbps pour cette entrée au moment examiné. PeeringDB est une preuve opérationnelle importante car Cloudflare déclare utiliser le service pour le provisionnement de peering. Pourtant, ses valeurs restent auto-déclarées et modifiables. Une vitesse de port listée est le taux d'interface nominal, pas le trafic observé, le débit engagé, la capacité de réserve ou la preuve d'un second port physiquement diversifié.

Cela produit une image précise mais modeste de San José. Il y a une présence en ville annoncée avec NIC.CR, un composant de statut actuel, une connexion d'échange public et des ressources d'adresse enregistrées auprès de la société costaricaine. Il n'y a pas d'adresse d'installation publique dans ces sources. Il n'y a pas de nombre divulgué de déploiements indépendants dans la métropole. Il n'y a pas de schéma unifilaire électrique, pas de chiffre d'autonomie de générateur lié aux armoires de Cloudflare, et pas de déclaration de diversité de route montrant des entrées de fibre séparées ou des chemins en amont.

La distinction entre localité et contrôle est particulièrement importante ici. CRIX peut localiser le trafic entre réseaux connectés, mais le tissu d'échange lui-même devient un élément du chemin de service. Une interconnexion du routeur de Cloudflare à l'échange peut tomber en panne pendant que les serveurs restent alimentés. La périphérie peut également rester joignable via le transit pendant qu'une session de peering locale est coupée, au prix d'un chemin plus long. Une installation peut rester opérationnelle pendant qu'un opérateur subit une coupure métropolitaine.

Un composant de ville peut donc être dégradé de plusieurs façons qu'un point de ville binaire ne peut pas décrire.

San José ne peut pas non plus représenter le réseau régional. Même si son trafic local est suffisamment faible pour un port d'échange et un déploiement, cela ne dit rien sur la capacité à absorber le trafic du Guatemala, du Panama, du nord de l'Amérique du Sud ou du Brésil. L'absence de séries publiées de serveurs et d'utilisation empêche de comparer le matériel installé et la capacité de réserve d'urgence.

L'interface d'échange visible de 200 Gbps ne doit pas être ajoutée aux chiffres de capacité mondiale comme s'il s'agissait d'une réserve utilisable indépendamment; c'est une interface dans un ensemble plus large de connexions de transit, privées et publiques, et sa demande en direct n'est pas divulguée.

Ce que San José prouve est significatif: Cloudflare a rapproché le service des utilisateurs costaricains et a établi une relation d'interconnexion locale. Ce qui reste sans réponse est la question dans le titre de cet article. Lorsqu'une plus grande métropole latino-américaine perd de l'énergie ou retire des routes, le registre public ne montre pas combien de trafic San José pourrait accepter, quelles applications il pourrait traiter selon les paramètres de localité des clients, ou quelle entreprise dirigerait la récupération physique.

São Paulo est plusieurs salles, ports et dépendances commerciales

São Paulo est la plus forte illustration publique de pourquoi une étiquette de ville peut cacher plusieurs surfaces opérationnelles distinctes. L'enregistrement PeeringDB de Cloudflare liste le réseau chez Equinix SP2 et SP4 à Barueri, chez Ascenty SPO02 et SPO03 à Osasco, et chez Elea SPO1 à São Paulo. Ce n'est pas nécessairement un inventaire en direct complet, et une liste d'installations ne révèle pas la quantité d'équipement actif sur place. Cela montre que la métropole ne peut pas être traitée de manière responsable comme une seule salle.

Laliste des sites d'interconnexion clientde Cloudflare de mai 2026 rend la multiplicité encore plus explicite. Elle nomme plusieurs installations à São Paulo pour l'interconnexion client, y compris Equinix SP2 et SP4, Ascenty SPO02 et SPO03, et Elea SPO1. Le document est une liste de sites de service, pas une carte de la périphérie interne ou du backbone de l'entreprise. Il montre où une connexion client peut aboutir; il ne montre pas que chaque site listé a une puissance de calcul périphérique identique, que les connexions dans deux bâtiments utilisent des routes d'opérateur séparées, ou que chaque site peut se substituer à l'autre.

Les divulgations d'installations ajoutent un contexte physique sans combler l'écart spécifique à Cloudflare. Equinix indique queSP4a une redondance UPS et générateur N+1, au moins 30 heures d'autonomie du générateur à pleine charge, un refroidissement N+1 et des services de technicien sur site. Ce sont des spécifications de l'opérateur pour le bâtiment. Elles ne révèlent pas quelle chaîne électrique alimente Cloudflare, la charge de ses armoires, l'état de maintenance d'un composant particulier, la quantité de carburant présente un jour donné ou si un circuit de Cloudflare traverse un point partagé avant d'entrer dans l'installation.

L'avis de maintenance GRU fournit un indice comportemental en direct. Il a traité le site de São Paulo comme un composant à partir duquel le trafic et les interfaces privées pouvaient basculer. Il n'a pas identifié lequel des plusieurs bâtiments était impliqué. « GRU » peut représenter un groupe opérationnel plus grand qu'une seule installation, ou l'avis peut délibérément masquer les détails de l'installation. Dans les deux cas, l'étiquette de composant ne doit pas être lue comme une adresse physique.

La diversité métropolitaine n'aide que lorsque les dépendances sont vraiment indépendantes. SP2 et SP4 peuvent être des installations séparées, mais les chemins décisifs incluent l'alimentation électrique, les chaînes UPS et générateur, les salles de rencontre, les conduits, les anneaux d'opérateurs, les tissus d'échange et les sorties de backbone reliant la métropole à d'autres villes. Deux interconnexions client commandées dans deux bâtiments peuvent encore converger sur une seule route d'opérateur. Deux déploiements Cloudflare peuvent encore partager une autorité de changement ou une dépendance de contrôle régionale.

Aucune des sources publiques ne cartographie ces corrélations.

La concentration commerciale ajoute une autre couche. Le 10-K indique qu'un nombre significatif de contrats de colocation importants sont avec une seule entreprise non nommée. Equinix est visible dans la liste publique des installations de São Paulo, mais le dépôt n'identifie pas le fournisseur concentré, et il serait non fondé de supposer le nom. Le point pertinent est que la distribution physique entre villes ou salles ne supprime pas automatiquement la concentration contractuelle.

Un litige avec un fournisseur, une défaillance du support ou un changement de prix défavorable peut affecter les choix d'expansion et de restauration même lorsque le réseau reste techniquement routable.

São Paulo est donc mieux décrite comme une métropole avec plusieurs options d'interconnexion et d'installations publiquement visibles, pas comme un pool quantifié de capacité interchangeable. Les preuves soutiennent plus qu'un point mais moins qu'un diagramme de résilience. Elles montrent des salles et des services qui pourraient participer à la diversité; elles ne prouvent pas l'indépendance, l'allocation ou la capacité d'urgence requises pour qu'ils le fassent.

Le peering localise le trafic mais peut concentrer la métropole

Lapolitique de peeringde Cloudflare de décembre 2025 indique qu'AS13335 couvre plus de 335 villes, demande aux pairs d'établir des sessions dans tous les sites mutuels et soutient les interconnexions privées par multiples de 100 Gbps pour les réseaux au-dessus d'un seuil de trafic. Elle recommande également d'utiliser toutes les adresses disponibles lorsqu'il y en a plus d'une à un échange. Ces pratiques peuvent améliorer la diversité des chemins et faciliter le déplacement du trafic entre les ports. Elles restent des conditions de politique, pas la preuve qu'un pair latino-américain donné a commandé des interconnexions diversifiées ou a gardé une capacité suffisante inutilisée.

Le déploiement historique montre à quel point les arrangements locaux peuvent être différents. À Medellín, Cloudflare a déclaré que son lancement en 2014 reposait sur Internexa et que le service local était transporté sur le réseau terrestre du partenaire. L'annonce de Medellíndécrivait un avantage de portée important, mais rend également la dépendance visible: la localité du trafic était connectée au backbone d'un seul partenaire. Le réseau actuel peut être plus large; l'ancien récit ne peut pas être traité comme une topologie actuelle.

À Quito, l'entreprise a déclaré que son site de 2017 avait été rendu possible grâce à l'échange NAP.EC et que des pairs locaux supplémentaires pouvaient déplacer le trafic qui était auparavant servi depuis Miami. Lerécit de Quitodémontre la valeur d'un échange local et la dépendance antérieure à un hub outre-mer. Encore une fois, il ne montre pas les racks, ports ou destinations de repli d'aujourd'hui. Il illustre également que « local » est relationnel: un déploiement est local uniquement pour les réseaux qui peuvent l'atteindre par des routes acceptables.

Bogotá a commencé avec un autre arrangement physique divulgué. Lerécit de Bogotá de 2018de Cloudflare indiquait que le déploiement était dans une installation Tier III dans la zone de libre-échange de la ville. Les registres publics actuels listent Cloudflare chez Equinix BG2, mais la description historique ne nomme pas ce site, donc les deux registres ne peuvent pas être joints en un historique d'installation ininterrompu sans plus de preuves. Ce que l'on peut dire, c'est que Bogotá a eu une présence physique divulguée et a maintenant une liste d'installation actuelle.

Le chemin longue distance entre ces métropoles est tout aussi important. Cloudflare déclare que son backbone utilise de la fibre noire possédée ou des services à longueur d'onde dense loués à l'intérieur et entre les villes, achetés auprès de partenaires opérateurs mondiaux. Ladescription du backbonede l'entreprise appelle explicitement sa carte illustrée une simplification qui ne montre pas tous les chemins. Cette prudence devrait gouverner toute lecture des lignes entre les points latino-américains. Une ligne tracée n'identifie pas un opérateur, une station d'atterrissage, un conduit, une longueur d'onde, une route de protection ou une bande passante disponible.

Le peering peut réduire le coût de transit et éviter d'envoyer le trafic local vers Miami, mais il peut aussi concentrer le trafic dans les installations où l'échange est disponible. Si le point d'échange Internet local d'un pays et un déploiement majeur de périphérie partagent un bâtiment ou un conduit métropolitain, les performances locales s'améliorent en fonctionnement normal tandis que le risque physique corrélé peut persister. Plusieurs sessions bilatérales sur un seul tissu de commutateur ne protègent pas contre un événement à l'échelle du tissu ou du bâtiment.

Plusieurs opérateurs dans une même salle de rencontre ne prouvent pas des entrées diversifiées.

La preuve souhaitée est spécifique au chemin. Pour chaque grande métropole, une évaluation de résilience identifierait les ports d'échange, les interconnexions privées et les liaisons de transit; si leurs interconnexions aboutissent sur des routeurs séparés; si les opérateurs sortent par des conduits séparés; et quels sites régionaux sont autorisés à annoncer les routes affectées après le retrait. Les registres publics révèlent des pièces de cette image. Ils ne révèlent pas la chaîne complète, donc les affirmations de basculement régional transparent restent conditionnelles.

Anycast redirige l'accessibilité, pas l'électricité ni la capacité de réserve

Anycast est puissant car il sépare une adresse de service d'une destination physique unique. Lorsqu'un site cesse d'annoncer une route, les réseaux en amont peuvent sélectionner une autre annonce. Mais la destination sélectionnée est le meilleur chemin selon la politique de routage, pas nécessairement la ville la plus proche géographiquement ou le site avec le plus grand pool de serveurs inutilisé. Lesdirectives de routage géographiquede Cloudflare reconnaissent que les requêtes peuvent ne pas atteindre le centre de données physique le plus proche et que la fiabilité peut primer sur la localité.

Il y a trois étapes de récupération distinctes. Premièrement, le site défaillant doit être retiré du chemin entrant, soit par retrait de route, ingénierie du trafic ou changement en amont. Deuxièmement, l'Internet doit converger vers des annonces alternatives. Troisièmement, les sites récepteurs doivent accepter les connexions ajoutées sans épuiser les ressources de calcul, mémoire, cache, routeur, interconnexion ou transit. Les deux premières sont des actions de routage. La troisième est une condition de capacité.

Au sein d'un site survivant, Cloudflare utilise une autre couche de distribution. Son récit d'Unimogexplique comment les connexions sont réparties entre les serveurs, comment les serveurs défaillants sont retirés et pourquoi la charge doit être ajustée pour les machines de performances différentes. Cela peut contourner un serveur défaillant ou un hôte surchargé à l'intérieur d'un centre de données. Cela ne peut pas aider si la salle entière perd de l'énergie, le routeur de périphérie s'éteint ou tous les chemins externes sont coupés. Dans ce cas, la couche anycast régionale doit porter la récupération.

Les clients d'interconnexion privée ont une dépendance supplémentaire. Lesdirectives opérationnelles d'interconnexionactuelles de Cloudflare indiquent qu'un déploiement client doit tolérer la perte imprévue de tout circuit unique et que le basculement entre circuits redondants doit être automatique. Elles notent également que la maintenance n'est pas coordonnée entre différents sites. Cela assigne une partie de la résilience à la conception du client: un client avec une seule interconnexion physique à GRU peut perdre ce chemin direct même si la périphérie publique de Cloudflare reste disponible ailleurs.

La différence compte pour les services affectés. Une connexion de site Web public peut souvent suivre un autre chemin anycast sans action du client, bien que la latence et le comportement du cache puissent changer. Une interconnexion réseau privée peut nécessiter un deuxième circuit, une politique de routage adaptée et une capacité suffisante à sa terminaison alternative. Une connexion de longue durée peut se rompre même si une nouvelle connexion réussit ailleurs. Une application régionalisée peut être limitée à un sous-ensemble de sites.

Le chemin d'origine d'un client peut également rester défaillant après le déplacement de la périphérie, particulièrement si l'origine est connectée via la même métropole.

La récupération Anycast est donc un transfert de demande, pas la disparition de la demande. Si GRU traite normalement un volume important et se retire, une combinaison d'autres sites doit le traiter. Le registre public ne divulgue pas la charge normale de GRU, la part qui peut être servie depuis le cache, la composition des produits, la distribution des destinations ou l'utilisation des sites récepteurs. L'expression « le trafic pourrait être redirigé » est précise mais incomplète; elle décrit le mouvement sans quantifier l'atterrissage.

L'affirmation de résilience crédible est conditionnelle: l'accessibilité peut se déplacer si les routes se retirent proprement, et le service peut continuer si les chemins et sites alternatifs ont les ressources nécessaires et sont autorisés à effectuer le travail. L'électricité reste locale. La capacité de réserve reste finie. Une route Internet peut contourner un bâtiment sombre, mais elle ne peut pas rendre le bâtiment alternatif prêt.

La capacité installée n'est pas la capacité de basculement utilisable

Cloudflare a annoncé en avril 2026 avoir dépassé 500 Tbps d'interconnexion externe. De manière cruciale, l'entreprise a défini le nombre. Sonrécit des 500 Tbpsindique que le chiffre est la somme des ports provisionnés faisant face aux fournisseurs de transit, aux pairs privés, aux échanges Internet et aux interconnexions client dans plus de 330 villes. Il indique également que le nombre n'est pas le trafic de pointe et que la différence soutient l'absorption des attaques par déni de service.

C'est une mesure d'échelle mondiale significative. Ce n'est pas un tableau de capacité latino-américain. Additionner les taux de ports compte les interfaces installées où qu'elles soient, même si certains ports ne peuvent pas se substituer à d'autres. Une interconnexion client à Bogotá ne peut pas transporter automatiquement le trafic de cache public déplacé de São Paulo. Un port connecté à un pair atteint le trafic de ce pair, pas chaque utilisateur. Deux liaisons 100 Gbps sur le même routeur ou route de fibre sont moins indépendantes que deux liaisons dans des installations séparées.

La capacité de port ne dit rien directement sur les cycles serveur, le stockage, la chaleur du cache ou la puissance électrique derrière les routeurs.

La politique de peering de Cloudflare renforce le problème d'unité. Elle soutient les connexions privées Nx100G et fixe des seuils de trafic pour les demander, mais ne publie pas l'utilisation actuelle. PeeringDB marque le niveau de trafic global du réseau comme non divulgué. La preuve publique résultante peut montrer que de grandes interfaces existent et nommer certains sites; elle ne peut pas montrer combien de gigabits restent utilisables en toute sécurité lors d'un événement régional.

La divulgation financière est également agrégée. Le 10-K rapporte 179,357 millions de dollars d'engagements non annulables en bande passante et autres colocations à la fin 2025, répartis sur des périodes futures. Cela prouve que l'entreprise achète de la capacité réseau et de l'espace à long terme à une échelle significative. Cela ne peut pas être alloué à l'Amérique latine à partir du dépôt, et la dépense n'est pas le débit. Un contrat peut réserver de l'espace qui n'est pas encore en service, couvrir une durée fixe plutôt qu'une réserve d'urgence, ou inclure des produits dont la capacité n'est pas interchangeable.

Les chiffres d'installation doivent être gardés dans leur propre catégorie. La disposition électrique N+1 de SP4 et l'autonomie déclarée du générateur décrivent le bâtiment. Equinix indique queBogotá BG2a une redondance UPS et générateur N+1, 72 heures d'autonomie du générateur et un support 24h/24. Laspécification de Lima LIM1de Cirion décrit une alimentation 2N, un refroidissement N+1 et plus de 2 200 mètres carrés de colocation sur dalle surélevée. Les registres publics actuels associent Cloudflare à ces installations ou à des sites d'interconnexion client, mais les évaluations d'installation ne sont pas des allocations de Cloudflare. Elles disent ce que l'opérateur a conçu, pas combien d'énergie ou d'espace de plancher Cloudflare a acheté.

La capacité de basculement utilisable est plus étroite que chacune de ces mesures installées. C'est la part des ressources de calcul, d'alimentation et de réseau alternatives qui sont saines, joignables, contractuellement disponibles, compatibles avec le service affecté et non consommées au moment de la défaillance. Elle doit permettre la croissance du trafic pendant la convergence, les échecs de cache, la charge d'attaque et la possibilité qu'une deuxième dépendance soit dégradée. Une réserve prudente n'est donc pas simplement un « taux de port inutilisé ».

Aucune source publique examinée ici ne donne ce chiffre par métropole latino-américaine. Cette absence empêche une affirmation quantitative que le trafic de São Paulo pourrait être entièrement absorbé dans la région. Le chiffre mondial de 500 Tbps rend une telle absorption plausible pour de nombreux événements ordinaires, mais la plausibilité n'est pas une mesure. Tant que l'utilisation par site, l'éligibilité au service et les limites de défaillance corrélées ne sont pas publiées, la conclusion correcte est que l'échelle installée est forte tandis que la capacité de réserve régionale utilisable reste non divulguée.

La récupération passe par des techniciens à distance, des opérateurs et l'autorité de changement

Lorsqu'une salle perd de l'énergie, le retrait de route n'est que le début. Quelqu'un doit déterminer si les alimentations réseau, les appareillages, les UPS, les générateurs, le refroidissement et la distribution des racks sont stables. Quelqu'un doit inspecter l'alimentation des routeurs et serveurs, vérifier la lumière optique, remplacer les pièces défectueuses, restaurer les circuits et remettre l'équipement en service de manière séquentielle. Dans une installation tierce, ces tâches traversent des frontières organisationnelles.

Lerécit de panne électrique en Oregonde Cloudflare de novembre 2023 est en dehors de l'Amérique latine et concerne les services centraux plutôt qu'un site de périphérie latino-américain. C'est toujours un exemple divulgué précieux de la chaîne de récupération physique. L'installation a perdu l'alimentation électrique et du générateur après un défaut à la terre; les batteries se sont épuisées; l'accès et le personnel ont compliqué le redémarrage du générateur; Cloudflare a appris le problème lorsque les routeurs sont devenus hors ligne; les disjoncteurs ont ensuite dû être remplacés; et les serveurs ont été ramenés dans une séquence contrôlée. L'entreprise a clairement séparé les faits confirmés des spéculations éclairées lorsque l'opérateur de l'installation n'avait pas fourni de réponses.

La même installation a de nouveau échoué en mars 2024. Ledeuxième récit d'événement électriquede Cloudflare indique que des changements antérieurs ont amélioré la réponse et réduit l'impact. La comparaison montre que la qualité de la récupération dépend de la préparation, des dépendances testées et des critères d'activation clairs, pas seulement de l'équipement redondant sur une fiche technique d'installation.

Pour les sites de périphérie latino-américains, le 10-K indique que des prestataires tiers peuvent installer et maintenir le matériel à l'étranger et que Cloudflare ne contrôle pas les opérations des installations tierces. Les informations publiques sur le support des installations aident à identifier une dépendance humaine. Ladisponibilité du support de colocationd'Equinix liste une couverture opérationnelle sur site 24h/24 pour Bogotá BG2, tandis que la couverture diffère sur d'autres sites. Cela ne révèle pas le droit de service de Cloudflare, l'objectif de réponse, l'inventaire de rechange ou si un technicien est autorisé à toucher un dispositif particulier. Cela montre pourquoi le personnel appartient à l'évaluation physique.

La récupération des opérateurs a sa propre chaîne. Une défaillance d'interconnexion nécessite une coordination entre Cloudflare, l'installation et le pair ou l'opérateur. Une faible lumière optique peut résulter d'un connecteur sale, d'une fibre endommagée, d'une optique défaillante ou d'un problème de chemin plus long. Restaurer un côté sans confirmer l'autre peut laisser la session hors ligne. Pour une interconnexion client, le client doit également avoir un basculement automatique et une capacité alternative suffisante. Pour une défaillance d'échange, les sessions peuvent devoir être déplacées vers des chemins privés ou de transit.

L'autorité de changement peut devenir la dépendance la plus lente. La personne qui voit un problème de route peut ne pas être en mesure d'approuver l'accès à l'installation. L'installation locale peut exiger une lettre d'autorisation avant de déplacer une interconnexion. Un prestataire peut avoir besoin d'un numéro de dispatching. Un opérateur peut insister sur des tests à un point de démarcation avant d'escalader. Un affilié peut détenir le contrat tandis qu'une équipe d'opérations mondiales dirige la réparation. Aucune de ces étapes n'est visible dans une couleur de statut.

Le chemin de restauration sûr est également plus lent que la simple mise sous tension. Une installation revenant après un événement instable peut nécessiter que les circuits soient alimentés par étapes pour éviter la charge d'appel. Les dispositifs réseau doivent être vérifiés avant que les serveurs n'attirent le trafic. La santé et la capacité doivent être confirmées avant le retour des routes, sinon la demande peut osciller entre les sites ou surcharger une salle partiellement restaurée. Le comportement du cache et des connexions de longue durée peut prendre plus de temps pour se normaliser.

Les preuves publiques soutiennent la capacité de Cloudflare à apprendre des événements de puissance graves et à opérer une réponse mondiale. Elles ne divulguent pas les runbooks des sites latino-américains, les pièces de rechange locales, les objectifs de temps de récupération ou les cartes d'autorité. Ces omissions ne prouvent pas une faiblesse. Elles signifient que la partie humaine et contractuelle de la résilience ne peut pas être vérifiée indépendamment à partir de l'empreinte urbaine.

Qui ressent la panne en premier

La première population affectée dépend de la couche qui échoue. Si un serveur tombe en panne mais que le routeur et la salle restent sains, la distribution de charge locale peut le retirer avec peu d'effet visible. Si un port d'échange tombe en panne, les utilisateurs des pairs qui comptaient sur ce port peuvent prendre des chemins plus longs tandis que les utilisateurs arrivant par d'autres opérateurs restent locaux. Si un site entier se retire, de nombreux réseaux d'accès peuvent se déplacer ensemble. Si une métropole perd plusieurs chemins corrélés, une région beaucoup plus grande peut être envoyée vers des villes plus éloignées.

Les utilisateurs finaux remarquent la latence, les réinitialisations de connexion, un débit plus faible ou des erreurs. Le motif ne sera pas uniforme dans un pays. Un fournisseur de services Internet avec une session directe à San José peut suivre un chemin différent de celui qui achète du transit en amont. Les réseaux mobiles et fixes peuvent faire des choix de routage différents. Un succès de cache peut se produire localement tandis qu'une requête non mise en cache dépend encore d'une origine dans la métropole défaillante. Le statut de « San José » ou « São Paulo » ne se traduit donc pas par une expérience nationale unique.

Les clients de Cloudflare utilisant des interconnexions privées font face à une frontière plus explicite. L'avis GRU leur a dit de s'attendre à ce que les interfaces deviennent indisponibles et de prévoir un basculement ailleurs. Si leur circuit alternatif est dans la même métropole ou utilise le même chemin d'opérateur, la redondance nominale peut ne pas aider. S'il aboutit dans une autre ville, il doit être dimensionné pour la demande transférée et son routage doit s'activer sans délai manuel. La continuité de la périphérie publique ne restaure pas automatiquement un chemin privé.

Les choix de localité des données réduisent l'ensemble des récepteurs. Ladescription des services régionauxde Cloudflare indique que les connexions cryptées peuvent être acceptées mondialement tandis que le déchiffrement HTTPS et le traitement au niveau application se produisent uniquement dans la région sélectionnée. Cela signifie qu'un site en dehors de l'ensemble sélectionné peut absorber la connexion réseau mais ne peut pas nécessairement effectuer tout le travail. La capacité de basculement doit être comptée dans la région de traitement autorisée, pas sur chaque point de la carte mondiale.

Latable de support régionaleactuelle liste le Brésil comme une région de services régionaux gérée. Elle ne liste pas une seule région gérée couvrant toute l'Amérique latine, bien que des configurations personnalisées puissent être disponibles pour certaines options. Un engagement de localité brésilienne peut donc rendre le nombre et la distribution des sites brésiliens sains particulièrement importants. La capacité à Miami, Bogotá ou San José peut être physiquement joignable mais inéligible pour le déchiffrement selon ce paramètre. La configuration produit de chaque client est importante.

Les services publics, les banques, les détaillants, les fournisseurs de soins de santé, les médias, les services logiciels et les petits sites Web peuvent tous se trouver derrière la même périphérie, mais leurs coûts de défaillance diffèrent. Un court délai sur une page statique n'est pas la même chose que la perte d'une connexion de paiement, d'un chemin d'accès employé ou d'un service d'information public.

Les clients avec un deuxième fournisseur ou une route de contournement peuvent se rétablir indépendamment; les clients qui dépendent exclusivement de Cloudflare ont besoin que la périphérie de Cloudflare et leurs propres origines restent connectées. Le 10-K de Cloudflare reconnaît que les clients peuvent perdre l'accès à leurs réseaux ou à Internet jusqu'à ce que le service revienne ou qu'ils invoquent un contournement.

Les premiers utilisateurs à ressentir une panne ne sont donc pas nécessairement les plus proches de la salle sombre. Ce sont les utilisateurs dont le fournisseur d'accès, le produit, la règle de localité, le circuit privé et le chemin d'origine laissent le moins d'alternatives. Cette distribution ne peut pas être dérivée de la seule géographie. Elle nécessite des données de trafic et de configuration client qui ne sont pas publiques.

Les preuves manquent encore pour une affirmation de résilience crédible

Les preuves publiques sont suffisantes pour établir une surface opérationnelle latino-américaine substantielle. Cloudflare liste une vaste empreinte de villes. Il rapporte un déploiement à San José avec NIC.CR et un composant de statut actif là-bas. Son enregistrement PeeringDB montre des relations d'échange et d'installation actuelles. Les documents d'interconnexion client nomment des installations de São Paulo à Bogotá et Lima. Les opérateurs d'installations publient les caractéristiques de puissance, de refroidissement et de support.

Cloudflare rapporte une interconnexion externe mondiale à 500 Tbps et décrit ouvertement les risques liés aux installations tierces, aux opérateurs et à l'alimentation.

Ce n'est pas suffisant pour prouver que la région peut absorber la perte d'une grande métropole sans impact matériel. La preuve manquante commence par un inventaire daté: installations actives par ville, services activés sur chacune, générations de serveurs, calcul utilisable, puissance de rack sous contrat et capacité de port externe. Le besoin suivant est l'utilisation: charge normale et au percentile élevé, politique de réserve, allocation d'attaque et transfert maximum testé de chaque domaine de défaillance majeur. Les totaux mondiaux ne peuvent pas répondre à ces questions locales.

L'indépendance physique a également besoin de preuves. Pour chaque paire de sites nominalement diversifiés, une divulgation utile identifierait une alimentation électrique séparée, des chaînes UPS et générateur, des entrées de fibre, des salles de rencontre, des tissus d'échange, des routes d'opérateur et des sorties longue distance. Elle indiquerait où deux circuits « diversifiés » convergent. Elle distinguerait un bâtiment séparé d'une métropole séparée et une métropole séparée d'un chemin d'atterrissage international séparé.

L'illustration actuelle du backbone ne montre explicitement pas toutes les routes, et le marketing des installations ne cartographie pas les circuits spécifiques aux clients.

La frontière juridique et commerciale reste incomplète. Le récent registre légal de la société costaricaine et l'enregistrement LACNIC sont de fortes preuves de présence locale, mais il n'y a pas de calendrier public attribuant les installations régionales, les contrats d'opérateur, la propriété d'équipement ou l'autorité d'urgence entre les affiliés de Cloudflare. L'accord client standard nomme la société mère du Delaware. Un récit crédible devrait donc nommer l'entité contractante uniquement là où un document public le fait et éviter de traiter le nom costaricain comme une étiquette d'opérateur régional générique.

Les preuves de récupération incluraient le chemin d'alerte de l'installation à Cloudflare, les engagements de réponse des techniciens à distance, l'emplacement des pièces de rechange, l'escalade des opérateurs, les seuils de retrait de route, l'ordre de redémarrage et la preuve d'exercices à l'échelle du site. Les incidents en Oregon montrent pourquoi ces détails sont importants, mais ils n'établissent pas la performance latino-américaine. L'évaluation N+1 ou 2N d'une installation est une entrée, pas un résultat.

Les tests devraient inclure la perte de la salle entière, la perte d'un chemin d'opérateur métropolitain et la perte d'une région de localité autorisée, pas seulement des dispositifs individuels.

L'impact client a besoin de sa propre mesure. Les rapports publics pourraient montrer, sans exposer les clients, combien de trafic a été déplacé, où il a atterri, comment la latence a changé, si les interconnexions privées ont basculé, si les services régionalisés sont restés dans leurs sites autorisés et combien de temps les caches et les sessions de longue durée ont mis à se stabiliser. L'avis de maintenance GRU indique la direction attendue du trajet mais ne publie aucun de ces résultats.

Aucun des éléments manquants ne prouve que Cloudflare manque de résilience. Le secret autour des sites exacts et de la capacité peut lui-même protéger la sécurité et le pouvoir de négociation. Le point est plus étroit: la carte publique et le chiffre de capacité mondiale ne peuvent pas soutenir une promesse de basculement régional quantitative par eux-mêmes. Ce qui peut être défendu est une chaîne conditionnelle.

Cloudflare a de nombreux sites et plusieurs formes d'interconnexion; l'anycast et la distribution de charge locale peuvent déplacer le travail; les installations tierces et les opérateurs fournissent la plateforme physique; et une récupération réussie dépend d'une alimentation indépendante, de routes, de capacité et d'action humaine qui ne sont que partiellement visibles.

Revenons, enfin, au commutateur de transfert de São Paulo. Si la deuxième alimentation tient, que les routeurs conservent la lumière et que l'installation reste froide, les utilisateurs ne sauront peut-être jamais qu'elle a bougé. Si la salle s'éteint, les routes peuvent partir. La survie gracieuse du service se décide dans les salles réceptrices: leurs watts de réserve, cycles serveur, ports, charges de travail autorisées et chemins fonctionnels. Ce sont les quantités qu'un point de ville cache.

Jusqu'à ce qu'elles soient divulguées ou mesurées indépendamment, la lecture honnête de la périphérie latino-américaine de Cloudflare n'est pas « la carte se guérit elle-même », mais « la carte montre où une chaîne physique soigneusement entretenue est censée répondre. »