Ein Stromtransfer in São Paulo testet, was Cloudflares lateinamerikanische Anycast-Karte nicht versprechen kann

Zusammenfassung

• Cloudflare weist einen umfangreichen lateinamerikanischen Städte-Fußabdruck und 500 Tbps globale externe Interkonnektivität aus, veröffentlicht jedoch nicht die Serveranzahl, die vertraglich gesicherte Stromversorgung, die aktuellen Port-Reserven oder die physisch diversen Routen an jedem lateinamerikanischen Standort.
• Öffentliche Aufzeichnungen belegen ein costa-ricanisches Unternehmen, costa-ricanische Adressressourcen und ein San-José-Deployment in Verbindung mit NIC.CR, belegen jedoch nicht, dass das costa-ricanische Unternehmen jedes regionale Rack, jede Leitung oder jede Kundenbeziehung unter dem Namen Cloudflare besitzt oder vertraglich kontrolliert.
• Anycast kann die Erreichbarkeit von einem ausgefallenen Standort wegbewegen, aber eine erfolgreiche Wiederherstellung hängt dennoch von freier Rechen- und Netzwerkkapazität, unabhängiger Gebäudestromversorgung, intakten Metro-Glasfasern, funktionierenden Cross-Connects und befugtem Personal ab, um die betroffene Ausrüstung wiederherzustellen.

Der Umschalter, wo die Karte endet

Stellen Sie sich eine carrier-neutrale Einrichtung im Großraum São Paulo während einer geplanten elektrischen Umschaltung vor. Die Netzversorgung wird abgeschaltet, die unterbrechungsfreie Stromversorgung trägt die Last für den Zeitraum zwischen den Einspeisungen, und Generatoren oder ein zweiter Netzpfad sollen die Versorgung übernehmen. Ein Techniker überwacht die Rack-Stromverteilung und die optischen Cross-Connects, während Netzwerktechniker die Routen überwachen. Dies ist ein Belastungstest, kein Bericht über einen bestimmten Cloudflare-Unfall. Er ist nützlich, weil er die visuelle Leichtigkeit einer globalen Edge-Karte beseitigt.

Im Moment der Umschaltung sind die relevanten Fragen konkret: Welche Schränke blieben unter Spannung, welche Router behielten Licht, welche Peers blieben erreichbar und wie viel Arbeit könnte anderswo übernommen werden?

Cloudflares eigene Betriebshinweise zeigen die beabsichtigte Netzwerkantwort. Während geplanter Arbeiten am Standort GRU am 3. Juli 2026 warnte das Unternehmen, dass Datenverkehr umgeleitet werden könnte, Endnutzer einen leichten Anstieg der Latenz sehen könnten und private oder Kunden-Interconnect-Schnittstellen in diesem Rechenzentrum vorübergehend nicht verfügbar sein könnten. Der Hinweis vermerkte später den Abschluss der Arbeiten. Diese Sequenz ist imGRU-Wartungsprotokollsichtbar. Es handelt sich um einen eng begrenzten Beleg: Er zeigt ein angekündigtes Wartungsfenster und das erwartete Verhalten der Schnittstellen, nicht die Identität eines Gebäudes, den Grund der Arbeiten, eine gemessene Verkehrsverschiebung oder die Menge der anderweitig genutzten Reservekapazitäten.

Dieöffentliche Statusseitetrennt lateinamerikanische Standorte wie San José und São Paulo in benannte Komponenten und gibt jeder einen aktuellen Status. Das ist eine wertvolle operative Transparenz, aber eine grüne Komponente ist eine Momentaufnahme. Sie offenbart nicht, ob die Komponente einen oder mehrere Räume repräsentiert, ob zwei Räume eine gemeinsame Umspannstation haben, oder ob ein nominell verfügbarer Nachbar eine plötzliche regionale Last aufnehmen könnte. Sie identifiziert auch nicht, welches juristische Unternehmen den Strom kaufte, das Rack mietete oder die Cross-Connect-Bestellung unterzeichnete.

Die normale Intuition ist, dass Anycast das Standortproblem löst. CloudflaresErklärung von Anycastbesagt, dass dieselbe Adresse von mehreren Standorten aus bedient werden kann und dass das Ausschalten eines Rechenzentrums dazu führen kann, dass Datenverkehr zu einem nahe gelegenen Standort fließt. Das beschreibt die Erreichbarkeit. Es erzeugt keine Watt, Serverzyklen oder unausgelastete Ports am empfangenden Standort. Wenn São Paulo Routen zurückzieht, können Benutzer je nach den von ihren Zugangsanbietern ausgewählten Routen in Rio de Janeiro, Curitiba, Porto Alegre, Buenos Aires, Santiago, Bogotá, Miami oder einem anderen verfügbaren Standort landen. Jede Alternative bringt ihre eigenen Einrichtungs-, Carrier- und Kapazitätsbedingungen mit sich.

Die Stromübertragung testet daher zwei Systeme gleichzeitig. Erstens lokal: Netzversorgung, Schaltanlagen, Batterien, Generatoren, Kühlung, Rack-Verteilung, Router und Cross-Connects müssen innerhalb der Toleranzen bleiben. Zweitens regional: Routenänderungen müssen sauber propagieren und die Ziele, die Datenverkehr aufnehmen, müssen nutzbare Reserven haben. Eine Städtekarte repräsentiert keines der beiden Systeme in dieser Auflösung. Sie zeigt die Geografie des Dienstes, nicht die elektrischen und kommerziellen Abhängigkeiten, die darüber entscheiden, ob ein Failover reibungslos verläuft.

Die Lücke ist wichtig, weil Kunden das Ergebnis als einen Dienst erleben, selbst wenn die physische Verantwortung auf Cloudflare, Betreiber, Carrier, Börsen und Auftragnehmer vor Ort verteilt ist.

Ein Städtepunkt ist keine Ausfall-Domain

Cloudflaresaktuelle Netzwerkseitezeigt einen großen lateinamerikanischen Fußabdruck mit Dutzenden von Städten in ganz Brasilien und Standorten von San José bis Bogotá, Lima, Santiago, Buenos Aires und darüber hinaus. Die Seite sagt auch, dass jeder Dienst in jedem Rechenzentrum läuft. Diese Aussagen belegen die beabsichtigte Breite des Edge und das gemeinsame Servicedesign. Sie belegen nicht, dass jede Stadt die gleiche Anzahl oder Generation von Servern, die gleiche Anzahl von Upstreams, die gleiche Fähigkeit, Datenverkehr von einer anderen Stadt aufzunehmen, oder den gleichen Schutz vor einem lokalen Stromausfall bietet.

Cloudflare hat selbst erklärt, warum die Stadt eine zu grobe Einheit ist. In einem Bericht von 2019 über denAusbau seines globalen Netzwerkssagte das Unternehmen, dass eine Stadt bis zu fünf verschiedene Deployments enthalten könne. Es beschrieb auch die Kapazitätsplanung nach Adresse, nicht nur nach Stadt, und die Verwendung von Lieferanten und Remote-Hands vor Ort, um Server zu installieren und zu verkabeln. Die Offenlegung war historisch und global; sie ist keine aktuelle Bestandsaufnahme Lateinamerikas. Ihr anhaltender analytischer Wert liegt in der Unterscheidung: Ein Metro-Label kann mehrere physische Adressen verbergen, während ein Deployment in einer Kleinstadt in einem Internetdienstanbieter und nicht auf einem großen neutralen Campus untergebracht sein kann.

Die neueste jährliche Offenlegung des Unternehmens liefert die andere Hälfte der Abgrenzung. CloudflaresForm-10-K von 2025sagt, dass sein Netzwerk in Colocation- und Internetdienstanbieter-Partnereinrichtungen in mehr als 330 Städten und mehr als 125 Ländern am Ende des Jahres 2025 gehostet wurde. Es sagt, dass Cloudflare elektronischen und in geringerem Maße physischen Zugang zu von Dritten gehosteten Geräten hat, aber den Betrieb dieser Einrichtungen nicht kontrolliert. Dieselbe Einreichung identifiziert Stromausfälle, Carrier-Entscheidungen, Standortschließungen, menschliches Versagen und Bandbreitenbegrenzungen als Risiken. Dies sind nicht nur theoretische Verzierungen um einen Punkt; sie sind die Betriebsgrenze des Punktes.

Die Breite tritt auch in verschiedenen physischen Formen auf. Ein Expansionsbericht von 2023 sagte, dass Cloudflare mehr als 300 Städte erreicht habe und beschrieb einen neuen Standort in Campos dos Goytacazes, Brasilien, der mit einem regionalen Anbieter verbunden ist, der mehr als 100 lokale Internetdienstanbieter versorgt. Das Unternehmen berichtete, dass sich die Latenzmessungen nach der Eröffnung des Standorts wesentlich verbessert haben. DieserStädte-Expansionsberichtbelegt die Präsenz eines partnergeführten Edge in der Nähe der Benutzer. Er gibt keine Auskunft über Rack-Strom, Serveranzahl, Port-Auslastung oder die Route, die die Last tragen würde, wenn der Partnerstandort ausfällt.

Eine nützliche Ausfall-Domain muss um gemeinsame Abhängigkeiten herum gezogen werden. Zwei Deployments an verschiedenen Straßenadressen können dennoch von derselben Umspannstation, Carrier-Rohrleitung, Exchange-Fabric, Fernverkehrsausfahrt oder lokalen Support-Dienstleister abhängen. Umgekehrt können zwei Schränke auf einem großen Campus sinnvoll getrennte Stromkreise und diverse Glasfasereingänge haben. Öffentliche Städtelisten lösen keinen der beiden Fälle. Selbst eine benannte Einrichtung beweist nicht, dass die beiden Stromkreise eines bestimmten Kunden auf verschiedenen Geräten enden oder dass hinter jedem Kapazität reserviert ist.

Deshalb ist eine Zählung von Städten keine Zählung von unabhängigen Wiederherstellungsoptionen. Es ist ein Maß für die geografische Reichweite. Um daraus eine Belastbarkeitsaussage zu machen, müsste ein Leser die Anzahl der aktiven Standorte pro Metro, ihre Strom- und Faserkorrelation, die an jedem Standort aktivierten Workloads, die normale und Notfallauslastung jedes Ports sowie die Richtlinie für das Zurückziehen oder Wiederherstellen von Routen kennen. Keines dieser Elemente kann einfach daraus abgeleitet werden, dass São Paulo, San José und Bogotá auf derselben Karte erscheinen.

Das costa-ricanische Unternehmen ist eine Grenze, keine regionale Asset-Bezeichnung

CloudFlare Latin America S.R.L ist eine reale costa-ricanische juristische Präsenz, kein geografischer Spitzname. Das offizielle Amtsblatt Costa Ricas verzeichnete eine Unternehmenshandlung von „Cloudflare Latin America S.R.L“ vom Januar 2026 und gab die juristische Personennummer 3-102-651761 an. Die Mitteilung betraf ihre offizielle elektronische Adresse und Vertretung, nicht Netzwerkassets, aber derAmtsblatteintragist ein aktueller öffentlicher Beleg dafür, dass das Unternehmen im costa-ricanischen Unternehmenssystem existiert.

Internet-Nummernressourcen liefern eine separate Verbindung. LACNICsöffentliche Registrierung für 190.93.240.0/20nennt CloudFlare Latin America S.R.L als Registrant und gibt eine Adresse im Großraum San José an, während Betriebskontakte auf den Cloudflare-Netzwerkbetrieb in San Francisco verweisen. Dies belegt eine Beziehung zwischen dem costa-ricanischen Unternehmen und Adressressourcen, die im Rahmen des größeren Cloudflare-Betriebs genutzt werden. Es beweist nicht, dass jede Adresse nur in Costa Rica bedient wird. Anycast ermöglicht bewusst die Ankündigung derselben Dienstadressen von mehreren Orten aus, und eine Adressregistrierung ist kein Rack-Inventar oder Eigentumsdokument.

Die Kundenschnittstelle weist in eine andere Richtung. Cloudflares Standard-Enterprise-Abonnementvereinbarungbesagt, dass die öffentliche Vereinbarung zwischen dem Kunden und Cloudflare, Inc., einem Unternehmen aus Delaware, geschlossen wird. Sie erlaubt auch verbundene Unternehmen und separate Bestellformulare. Die richtige Schlussfolgerung ist begrenzt: Die öffentlichen Standardbedingungen weisen gewöhnliche Enterprise-Abonnements nicht dem costa-ricanischen Unternehmen zu. Sie schließen ein anderes Bestellformular, eine lokale Steuervereinbarung, einen Mietvertrag, einen Arbeitsvertrag, eine Carrier-Vereinbarung oder eine Transaktion eines verbundenen Unternehmens nicht aus. Diese Dokumente sind in dem hier geprüften Material nicht öffentlich.

Die gleiche Vorsicht gilt für ganz Lateinamerika. Ein mit Cloudflare gebrandetes Rack in Brasilien könnte Cloudflare, Inc., einem anderen verbundenen Unternehmen, einem Servicepartner oder einem Hosting-Gegenpartei unter nicht öffentlich einsehbaren Bedingungen gehören. Das costa-ricanische Unternehmen kann bestimmte Nummernressourcen oder lokale Verpflichtungen halten, ohne der Vertragspartei für einen Raum in São Paulo zu sein. Umgekehrt würde das Fehlen seines Namens auf einer Standortseite nicht zeigen, dass es keine finanzielle oder operative Rolle spielt.

Öffentliche Einrichtungs- und Routing-Aufzeichnungen identifizieren normalerweise das Netzwerk oder die Marke, nicht die interne Zuteilung von Rechten zwischen verbundenen Unternehmen.

Diese Grenze ist bei Ausfällen wichtig. Die Partei, die einen Carrier bitten kann, Lichtpegel zu testen, einen Remote-Hands-Besuch zu autorisieren, Notfallausgaben zu genehmigen oder eine Serviceverpflichtung durchzusetzen, ist möglicherweise nicht dieselbe Partei, die in einem öffentlichen IP-Eintrag genannt wird. Regulatorische Anforderungen können auch an das lokale Unternehmen anknüpfen, selbst wenn operative Entscheidungen woanders getroffen werden.

Ohne Verträge, Vorstandsprotokolle oder explizite Offenlegungen von verbundenen Unternehmen würde eine Zuschreibung regionaler Kontrolle an CloudFlare Latin America S.R.L über die Beweise hinausgehen.

Die am besten zu vertretende Beschreibung ist daher geschichtet. Cloudflare, Inc. berichtet das konsolidierte globale Netzwerk und seine Abhängigkeiten von Drittanbietereinrichtungen. AS13335 ist die globale Routing-Identität. CloudFlare Latin America S.R.L ist ein costa-ricanisches Unternehmen, das mit LACNIC-Ressourcen und einem aktuellen costa-ricanischen rechtlichen Eintrag verbunden ist. NIC.CR wurde als Partner für das erste San-José-Deployment genannt. Diese Schichten beziehen sich eindeutig auf einen Dienst, sind aber nicht austauschbar.

Eine regionale Edge-Geschichte, die sie zu „das costa-ricanische Unternehmen betreibt Lateinamerika“ zusammenfasst, würde Assoziation in Eigentum und Eigentum in Kontrolle ohne öffentlichen Beweis verwandeln.

San José beweist Präsenz, nicht Kontrolle

Cloudflare kündigte sein erstes costa-ricanisches Deployment im Juni 2021 an. SeinBericht zur Expansion in San Josésagte, der Standort sei mit NIC.CR, betrieben von der Academia Nacional de Ciencias, eingerichtet worden. Dies ist ein direkter Unternehmensbeleg für eine bereitgestellte Präsenz und einen benannten lokalen Partner zu diesem Zeitpunkt. Die aktuelle Netzwerkkarte und der Statuskomponente weisen darauf hin, dass San José weiterhin im Live-Fußabdruck vertreten ist. Keine der Offenlegungen nennt das Gebäude, die Serveranzahl, die Stromzuteilung, die Carrier-Liste, den Ersatzteilbestand oder den vertraglichen Eigentümer der Ausrüstung.

NIC Costa Rica beschreibt CRIX als einen neutralen Internet-Knoten, der es lokalen Netzwerken ermöglicht, Datenverkehr an einem gemeinsamen Punkt im Land auszutauschen, anstatt sich auf internationale Verbindungen zu verlassen. DieseNIC.CR-Infrastrukturbeschreibungzeigt, warum ein Edge in San José wichtig sein kann: Lokales Peering kann einen Teil des costa-ricanischen Datenverkehrs lokal halten, die Abhängigkeit von internationalem Transit für diesen Austausch verringern und die Distanz zu gecachten oder verarbeiteten Inhalten verkürzen. Sie belegt nicht die aktuelle Port-Größe von Cloudflare oder ob jeder costa-ricanische Zugangsanbieter Cloudflare über CRIX erreicht.

Cloudflares aktueller selbstberichteterPeeringDB-Netzwerkeintragidentifiziert AS13335 als globales Anycast-Netzwerk und listet seine öffentlichen Peering- und Einrichtungsbeziehungen auf. Der Eintrag enthält eine aktive CRIX-Verbindung und meldet zum Untersuchungszeitpunkt einen Exchange-Port von 200 Gbps für diesen Eintrag. PeeringDB ist ein wichtiger operativer Beleg, da Cloudflare angibt, den Dienst für die Peering-Bereitstellung zu nutzen. Dennoch bleiben seine Werte selbstberichtet und veränderlich. Eine aufgeführte Port-Geschwindigkeit ist die nominale Schnittstellenrate, nicht der beobachtete Verkehr, der garantierte Durchsatz, die freie Kapazität oder der Nachweis eines zweiten physisch diversen Ports.

Dies ergibt ein präzises, aber bescheidenes Bild von San José. Es gibt eine mit NIC.CR angekündigte Stadtpräsenz, einen aktuellen Statuskomponenten, eine öffentliche Exchange-Verbindung und beim costa-ricanischen Unternehmen registrierte Adressressourcen. Es gibt keine öffentliche Einrichtungsadresse in diesen Quellen. Es gibt keine veröffentlichte Anzahl unabhängiger Deployments innerhalb des Metros. Es gibt keine einpolige Stromzeichnung, keine an Cloudflares Schränke gebundene Generator-Autonomiezahl und keine Routendiversitätsaussage, die separate Fasereingänge oder Upstream-Pfade zeigt.

Die Unterscheidung zwischen Lokalität und Kontrolle ist hier besonders wichtig. CRIX kann Datenverkehr zwischen verbundenen Netzwerken lokalisieren, aber die Exchange-Fabric selbst wird zu einem Element des Dienstpfades. Eine Cross-Connect-Verbindung von Cloudflares Router zum Exchange kann ausfallen, während die Server weiterhin mit Strom versorgt werden. Der Edge kann auch über Transit erreichbar bleiben, während eine lokale Peering-Sitzung ausfällt, allerdings auf Kosten eines längeren Pfades. Eine Einrichtung kann betriebsbereit bleiben, während ein Carrier unter einem Metro-Ausfall leidet.

Ein Stadtkomponente kann daher auf mehrere Arten beeinträchtigt sein, die ein binärer Städtepunkt nicht beschreiben kann.

San José kann auch nicht für das regionale Netzwerk stehen. Selbst wenn sein lokaler Datenverkehr klein genug für einen Exchange-Port und ein Deployment ist, sagt dies nichts über die Fähigkeit aus, Datenverkehr aus Guatemala, Panama, dem nördlichen Südamerika oder Brasilien aufzunehmen. Das Fehlen einer veröffentlichten Server- und Auslastungsreihe verhindert einen Vergleich zwischen installierter Hardware und Notfallreserven.

Die sichtbare 200-Gbps-Exchange-Schnittstelle sollte nicht zu globalen Kapazitätszahlen addiert werden, als wäre sie eine unabhängig nutzbare Reserve; sie ist eine Schnittstelle in einer größeren Menge von Transit-, privaten und öffentlichen Verbindungen, und ihre Live-Nachfrage wird nicht offengelegt.

Was San José beweist, ist signifikant: Cloudflare hat den Dienst näher an costa-ricanische Benutzer gebracht und eine lokale Interkonnektionsbeziehung aufgebaut. Was unbeantwortet bleibt, ist die Frage im Titel dieses Artikels. Wenn eine größere lateinamerikanische Metro die Stromversorgung verliert oder Routen zurückzieht, zeigt der öffentliche Bericht nicht, wie viel Datenverkehr San José aufnehmen könnte, welche Anwendungen es unter den Lokalitätseinstellungen der Kunden verarbeiten könnte oder welches Unternehmen die physische Wiederherstellung leiten würde.

São Paulo besteht aus mehreren Räumen, Ports und kommerziellen Abhängigkeiten

São Paulo ist die stärkste öffentliche Veranschaulichung dafür, warum ein Städteetikett mehrere unterschiedliche Betriebsoberflächen verbergen kann. Cloudflares PeeringDB-Eintrag listet das Netzwerk in Equinix SP2 und SP4 in Barueri, in Ascenty SPO02 und SPO03 in Osasco und in Elea SPO1 in São Paulo. Dies ist nicht unbedingt ein vollständiges Live-Inventar, und eine Einrichtungsauflistung zeigt nicht, wie viel Ausrüstung dort aktiv ist. Es zeigt jedoch, dass die Metro nicht verantwortungsvoll als ein einziger Raum behandelt werden kann.

Cloudflares Liste derCustomer-Interconnect-Standortevom Mai 2026 macht die Vielfalt noch deutlicher. Sie nennt mehrere Einrichtungen in São Paulo für Kundeninterkonnektion, darunter Equinix SP2 und SP4, Ascenty SPO02 und SPO03 und Elea SPO1. Das Dokument ist eine Service-Standortliste, keine Karte des internen Edge oder Backbones des Unternehmens. Sie zeigt, wo eine Kundenverbindung enden kann; sie zeigt nicht, dass jeder aufgeführte Standort identische Edge-Compute hat, dass Verbindungen in zwei Gebäuden getrennte Carrier-Routen verwenden oder dass jeder Standort jeden anderen ersetzen kann.

Einrichtungsoffenlegungen fügen physischen Kontext hinzu, ohne die Cloudflare-spezifische Lücke zu schließen. Equinix sagt, dassSP4N+1-USV- und Generator-Redundanz, mindestens 30 Stunden Generator-Autonomie bei Volllast, N+1-Kühlung und Smart-Hands-Dienste bietet. Dies sind Betreiberspezifikationen für das Gebäude. Sie zeigen nicht, welcher Stromkreis Cloudflare versorgt, die Last seiner Schränke, den Wartungszustand einer bestimmten Komponente, die Menge des an einem bestimmten Tag vorhandenen Kraftstoffs oder ob ein Cloudflare-Schaltkreis einen gemeinsamen Punkt vor dem Eintritt in die Einrichtung überquert.

Der GRU-Wartungshinweis liefert einen lebenden betrieblichen Hinweis. Er behandelte den Standort São Paulo als eine Komponente, von der Datenverkehr und private Schnittstellen ausweichen konnten. Er identifizierte nicht, welches der mehreren Gebäude beteiligt war. „GRU“ kann eine betriebliche Gruppierung darstellen, die größer ist als eine Einrichtung, oder der Hinweis kann die Details der Einrichtung absichtlich abstrahieren. In jedem Fall sollte die Komponentenbezeichnung nicht als physische Adresse gelesen werden.

Metro-Vielfalt hilft nur, wenn die Abhängigkeiten wirklich unabhängig sind. SP2 und SP4 können separate Einrichtungen sein, aber die entscheidenden Pfade umfassen die Netzversorgung, Generator- und USV-Kreise, Meet-Me-Räume, Leitungswege, Carrier-Ringe, Exchange-Fabrics und die Backbone-Ausgänge, die die Metro mit anderen Städten verbinden. Zwei Kunden-Interconnects, die in zwei Gebäuden bestellt werden, können dennoch auf einer Carrier-Route zusammenlaufen. Zwei Cloudflare-Deployments können dennoch sich eine Änderungsbefugnis oder eine regionale Kontrollabhängigkeit teilen. Keine der öffentlichen Quellen kartiert diese Korrelationen.

Kommerzielle Konzentration fügt eine weitere Ebene hinzu. Der 10-K besagt, dass eine signifikante Anzahl wichtiger Colocation-Verträge mit einem ungenannten Unternehmen bestehen. Equinix ist in der öffentlichen Liste der Einrichtungen in São Paulo sichtbar, aber die Einreichung identifiziert den konzentrierten Anbieter nicht, und es wäre unbelegt, den Namen anzunehmen. Der relevante Punkt ist, dass physische Verteilung über Städte oder Räume hinweg nicht automatisch vertragliche Konzentration beseitigt.

Ein Anbieterstreit, Supportausfall oder eine ungünstige Preisänderung können Expansions- und Wiederherstellungsoptionen beeinflussen, selbst wenn das Netzwerk technisch routingfähig bleibt.

São Paulo ist daher am besten als eine Metro mit mehreren öffentlich sichtbaren Interkonnektions- und Einrichtungsoptionen zu beschreiben, nicht als ein quantifizierter Pool austauschbarer Kapazität. Die Beweise stützen mehr als einen Punkt, aber weniger als ein Resilienzdiagramm. Sie zeigen Räume und Dienste, die an der Diversität teilnehmen könnten; sie beweisen nicht die Unabhängigkeit, Zuteilung oder Notfallkapazität, die dafür erforderlich wäre.

Peering lokalisiert Datenverkehr, kann aber die Metro konzentrieren

CloudflaresPeering-Richtlinievom Dezember 2025 besagt, dass AS13335 mehr als 335 Städte umfasst, bittet Peers, Sitzungen an allen gemeinsam genutzten Standorten einzurichten, und unterstützt private Interkonnektionen in Vielfachen von 100 Gbps für Netzwerke oberhalb einer Verkehrsschwelle. Sie empfiehlt auch, alle verfügbaren Adressen zu verwenden, wenn mehr als eine an einer Exchange vorhanden ist. Diese Praktiken können die Pfaddiversität verbessern und es erleichtern, Datenverkehr zwischen Ports zu verschieben. Sie bleiben Bedingungen der Richtlinie, kein Beweis dafür, dass ein bestimmter lateinamerikanischer Peer diverse Cross-Connects bestellt oder ausreichend freie Kapazität vorgehalten hat.

Der historische Aufbau zeigt, wie unterschiedlich die lokalen Vereinbarungen sein können. In Medellín sagte Cloudflare, dass sein Start im Jahr 2014 auf Internexa angewiesen war und dass lokale Dienste über das terrestrische Netzwerk des Partners übertragen wurden. DieMedellín-Ankündigungbeschrieb einen wichtigen Reichweitenvorteil, macht aber auch die Abhängigkeit sichtbar: Die Verkehrslokalität war an das Backbone eines Partners gebunden. Das heutige Netzwerk mag breiter sein; der alte Bericht kann nicht als aktuelle Topologie behandelt werden.

In Quito sagte das Unternehmen, dass sein Standort von 2017 durch den NAP.EC-Exchange ermöglicht wurde und dass zusätzliche lokale Peers Datenverkehr verschieben konnten, der zuvor von Miami aus bedient wurde. DerQuito-Berichtzeigt den Wert eines lokalen Exchanges und die vorherige Abhängigkeit von einem Übersee-Hub. Auch hier zeigt er nicht die heutigen Racks, Ports oder Ausweichziele. Er veranschaulicht auch, dass „lokal“ relational ist: Ein Deployment ist nur für Netzwerke lokal, die es über akzeptable Routen erreichen können.

Bogotá begann mit einer anderen offengelegten physischen Anordnung. CloudflaresBogotá-Bericht von 2018sagte, dass das Deployment in einer Tier-III-Einrichtung in der Freihandelszone der Stadt lag. Aktuelle öffentliche Aufzeichnungen listen Cloudflare in Equinix BG2, aber die historische Beschreibung nennt diesen Standort nicht, sodass die beiden Aufzeichnungen ohne weitere Beweise nicht zu einer ununterbrochenen Einrichtungsgeschichte zusammengefügt werden können. Was gesagt werden kann, ist, dass Bogotá eine offengelegte physische Präsenz hatte und jetzt einen aktuellen Einrichtungseintrag hat.

Der Fernstreckenpfad zwischen diesen Metros ist gleichermaßen wichtig. Cloudflare sagt, dass sein Backbone eigene Dark Fibre oder geleaste dichte Wellenlängendienste innerhalb und zwischen Städten nutzt, die von globalen Carrier-Partnern bezogen werden. DieBackbone-Beschreibungdes Unternehmens bezeichnet ihre illustrierte Karte ausdrücklich als eine Vereinfachung, die nicht jeden Pfad zeigt. Diese Vorsicht sollte jede Lektüre von Linien zwischen lateinamerikanischen Punkten bestimmen. Eine gezeichnete Linie identifiziert keinen Carrier, keine Landestation, keine Leitung, keine Wellenlänge, keinen Schutzpfad oder keine verfügbare Bandbreite.

Peering kann Transitkosten senken und es vermeiden, lokalen Datenverkehr nach Miami zu schicken, aber es kann auch Datenverkehr in den Einrichtungen konzentrieren, in denen der Exchange verfügbar ist. Wenn der lokale Internet-Knoten eines Landes und ein großes Edge-Deployment ein Gebäude oder einen Metro-Leitungsweg teilen, verbessert sich die lokale Leistung während des Normalbetriebs, während korreliertes physisches Risiko bestehen bleiben kann. Mehrere bilaterale Sitzungen auf einer Switch-Fabric schützen nicht vor einem Fabric-weiten oder Gebäude-weiten Ereignis. Mehrere Carrier in einem Meet-Me-Raum beweisen keine diversen Eingänge.

Die gewünschten Beweise sind pfadspezifisch. Für jede große Metro würde eine Resilienzbewertung die Exchange-Ports, privaten Interconnects und Transitverbindungen identifizieren; ob ihre Cross-Connects auf verschiedenen Routern landen; ob die Carrier durch separate Leitungswege austreten; und welche regionalen Standorte berechtigt sind, die betroffenen Routen nach einem Rückzug anzukündigen. Öffentliche Aufzeichnungen zeigen Teile dieses Bildes. Sie zeigen nicht die vollständige Kette, daher bleiben Behauptungen eines nahtlosen regionalen Failovers bedingt.

Anycast leitet Erreichbarkeit um, nicht Strom oder freie Reserven

Anycast ist leistungsfähig, weil es eine Dienstadresse von einem physischen Ziel trennt. Wenn ein Standort aufhört, eine Route anzukündigen, können Upstream-Netzwerke eine andere Ankündigung auswählen. Aber das ausgewählte Ziel ist der beste Pfad gemäß der Routing-Richtlinie, nicht unbedingt die geografisch nächste Stadt oder der Standort mit dem größten ungenutzten Serverpool. CloudflaresLeitfaden für geografisches Routingerkennt an, dass Anfragen möglicherweise nicht das nächstgelegene physische Rechenzentrum erreichen, und sagt, dass Zuverlässigkeit Vorrang vor Lokalität haben kann.

Es gibt drei verschiedene Wiederherstellungsschritte. Erstens muss der beeinträchtigte Standort aus dem eingehenden Pfad entfernt werden, entweder durch Routenrückzug, Traffic Engineering oder Upstream-Änderung. Zweitens muss das Internet auf alternative Ankündigungen konvergieren. Drittens müssen die empfangenden Standorte die zusätzlichen Verbindungen akzeptieren, ohne Rechen-, Speicher-, Cache-, Router-, Cross-Connect- oder Transitressourcen zu erschöpfen. Die ersten beiden sind Routing-Aktionen. Die dritte ist eine Kapazitätsbedingung.

Innerhalb eines überlebenden Standorts verwendet Cloudflare eine weitere Verteilungsebene. Sein Bericht überUnimogerklärt, wie Verbindungen auf Server verteilt werden, wie nicht gesunde Server entfernt werden und warum die Last für Maschinen unterschiedlicher Leistung angepasst werden muss. Dies kann um einen ausgefallenen Server oder einen überlasteten Host innerhalb eines Rechenzentrums herumleiten. Es hilft nicht, wenn der gesamte Raum die Stromversorgung verliert, der Edge-Router ausfällt oder alle externen Pfade unterbrochen sind. In diesem Fall muss die regionale Anycast-Ebene die Wiederherstellung tragen.

Private-Interconnect-Kunden haben eine zusätzliche Abhängigkeit. Cloudflares aktuelleoperative Anleitung für Interconnectsbesagt, dass ein Kundendeployment den ungeplanten Ausfall eines einzelnen Stromkreises tolerieren muss und dass das Failover zwischen redundanten Stromkreisen automatisch erfolgen sollte. Sie weist auch darauf hin, dass Wartungsarbeiten nicht zwischen verschiedenen Standorten koordiniert werden. Dies weist einen Teil der Resilienz dem Kundendesign zu: Ein Kunde mit einem physischen Interconnect in GRU kann diesen direkten Pfad verlieren, selbst wenn Cloudflares öffentlicher Edge an anderer Stelle verfügbar bleibt.

Der Unterschied ist für betroffene Dienste wichtig. Eine öffentliche Website-Verbindung kann oft einer anderen Anycast-Route folgen, ohne dass der Kunde eingreifen muss, obwohl sich Latenz und Cache-Verhalten ändern können. Ein privater Netzwerk-Interconnect kann einen zweiten Stromkreis, eine geeignete Route-Richtlinie und ausreichende Kapazität an seinem alternativen Endpunkt erfordern. Eine langlebige Verbindung kann unterbrochen werden, selbst wenn eine neue Verbindung woanders erfolgreich ist. Eine regionalisierte Anwendung kann auf eine Teilmenge von Standorten beschränkt sein.

Der Ursprungspfad eines Kunden kann auch nach dem Umzug des Edge beeinträchtigt bleiben, insbesondere wenn der Ursprung über dieselbe Metro verbunden ist.

Anycast-Wiederherstellung ist daher eine Übertragung der Nachfrage, nicht das Verschwinden der Nachfrage. Wenn GRU normalerweise ein großes Volumen verarbeitet und sich zurückzieht, muss eine Kombination anderer Standorte dies verarbeiten. Der öffentliche Bericht offenbart nicht die normale GRU-Last, den Anteil, der aus dem Cache bedient werden kann, die Produktmischung, die Zielverteilung oder die Auslastung der empfangenden Standorte. Der Satz „Datenverkehr könnte umgeleitet werden“ ist korrekt, aber unvollständig; er beschreibt die Bewegung, ohne die Landung zu quantifizieren.

Die glaubwürdige Belastbarkeitsbehauptung ist bedingt: Erreichbarkeit kann sich bewegen, wenn Routen sauber zurückgezogen werden, und der Dienst kann fortgesetzt werden, wenn alternative Pfade und Standorte die notwendigen Ressourcen haben und berechtigt sind, die Arbeit zu übernehmen. Strom bleibt lokal. Freie Reserven bleiben endlich. Eine Internet-Route kann auf ein dunkles Gebäude zeigen, aber sie kann das alternative Gebäude nicht bereit machen.

Installierte Kapazität ist nicht nutzbare Failover-Kapazität

Cloudflare kündigte im April 2026 an, dass es 500 Tbps externe Interkonnektion überschritten habe. Entscheidend ist, dass das Unternehmen die Zahl definierte. Sein500-Tbps-Berichtsagt, dass die Zahl die Summe der bereitgestellten Ports zu Transit-Anbietern, privaten Peers, Internet-Knoten und Kunden-Interconnects in mehr als 330 Städten ist. Er sagt auch, dass die Zahl nicht der Spitzenverkehr ist und dass die Differenz die Absorption von Denial-of-Service-Angriffen unterstützt.

Das ist ein bedeutendes globales Skalenmaß. Es ist keine lateinamerikanische Kapazitätstabelle. Die Summierung der Portraten zählt installierte Schnittstellen, wo immer sie sich befinden, auch wenn einige Ports andere nicht ersetzen können. Ein Kunden-Interconnect in Bogotá kann nicht automatisch öffentlichen Cache-Verkehr aufnehmen, der von São Paulo verdrängt wurde. Ein Port, der mit einem Peer verbunden ist, erreicht den Verkehr dieses Peers, nicht jeden Benutzer. Zwei 100-Gbps-Links auf demselben Router oder derselben Faserroute sind weniger unabhängig als zwei Links in separaten Einrichtungen.

Portkapazität sagt auch nichts direkt über Serverzyklen, Speicher, Cache-Wärme oder elektrische Leistung hinter den Routern aus.

Cloudflares Peering-Richtlinie verstärkt das Einheitenproblem. Sie unterstützt Nx100G private Verbindungen und setzt Verkehrsschwellen für die Anforderung, veröffentlicht aber keine aktuelle Auslastung. PeeringDB markiert das Gesamtverkehrsniveau des Netzwerks als nicht offengelegt. Die daraus resultierenden öffentlichen Beweise können zeigen, dass große Schnittstellen existieren und einige Standorte nennen; sie können nicht zeigen, wie viele Gigabit während eines regionalen Ereignisses sicher nutzbar bleiben.

Die finanzielle Offenlegung ist ebenfalls aggregiert. Der 10-K weist zum Ende des Jahres 2025 nicht kündbare Bandbreiten- und andere Colocation-Verpflichtungen in Höhe von 179,357 Millionen US-Dollar aus, verteilt auf zukünftige Perioden. Dies beweist, dass das Unternehmen langfristige Netzwerkkapazität und -raum in signifikantem Umfang einkauft. Es kann nicht aus der Einreichung auf Lateinamerika zugeteilt werden, und Ausgaben sind nicht der Durchsatz.

Ein Vertrag kann Raum reservieren, der noch nicht in Betrieb ist, eine feste Laufzeit abdecken und keine Notfallreserve darstellen, oder Produkte enthalten, deren Kapazität nicht austauschbar ist.

Einrichtungszahlen müssen in ihrer eigenen Kategorie bleiben. Die N+1-Stromversorgung und die angegebene Generator-Autonomie von SP4 beschreiben das Gebäude. Equinix sagt, dassBogotá BG2N+1-USV- und Generator-Redundanz, 72 Stunden Generator-Autonomie und 24-Stunden-Support hat. CirionsLima LIM1-Spezifikationbeschreibt 2N-Strom, N+1-Kühlung und mehr als 2.200 Quadratmeter Colocation-Raum auf Doppelboden. Aktuelle öffentliche Aufzeichnungen verbinden Cloudflare mit diesen Einrichtungen oder Kunden-Interconnect-Standorten, aber die Einrichtungsbewertungen sind keine Cloudflare-Zuteilungen. Sie geben an, was der Betreiber entworfen hat, nicht wie viel Strom oder Raum Cloudflare gekauft hat.

Nutzbare Failover-Kapazität ist enger als jede dieser installierten Maße. Es ist der Anteil der alternativen Rechen-, Strom- und Netzwerkressourcen, der gesund, erreichbar, vertraglich verfügbar, mit dem betroffenen Dienst kompatibel und im Moment des Ausfalls nicht verbraucht ist. Sie muss Verkehrswachstum während der Konvergenz, Cache-Fehlschläge, Angriffslast und die Möglichkeit berücksichtigen, dass eine zweite Abhängigkeit beeinträchtigt ist. Eine vorsichtige Reserve ist daher nicht einfach „ungenutzte Portrate“.

Keine der hier geprüften öffentlichen Quellen gibt diese Zahl nach lateinamerikanischer Metro an. Dieses Fehlen verhindert eine quantitative Behauptung, dass der Datenverkehr von São Paulo vollständig innerhalb der Region absorbiert werden könnte. Die globale Zahl von 500 Tbps macht eine solche Absorption für viele gewöhnliche Ereignisse plausibel, aber Plausibilität ist keine Messung. Bis standortspezifische Auslastung, Dienstberechtigung und korrelierte Ausfallgrenzen veröffentlicht werden, ist die richtige Schlussfolgerung, dass der installierte Umfang stark ist, während die regionale nutzbare Reserve nicht offengelegt bleibt.

Die Wiederherstellung erfolgt über Remote-Hands, Carrier und Änderungsbefugnis

Wenn ein Raum die Stromversorgung verliert, ist der Routenrückzug erst der Anfang. Jemand muss feststellen, ob die Netzversorgung, Schaltanlagen, USV, Generatoren, Kühlung und Rack-Verteilung stabil sind. Jemand muss die Router- und Server-Stromversorgung überprüfen, optisches Licht verifizieren, ausgefallene Komponenten ersetzen, Stromkreise wiederherstellen und die Ausrüstung sequentiell wieder in Betrieb nehmen. In einer Einrichtung eines Drittanbieters überschreiten diese Aufgaben organisatorische Grenzen.

Cloudflares Bericht über denStromausfall in Oregonvom November 2023 liegt außerhalb Lateinamerikas und betraf Kerndienste, nicht einen lateinamerikanischen Edge-Standort. Er ist dennoch ein wertvolles offengelegtes Beispiel für die physische Wiederherstellungskette. Die Einrichtung verlor die Netz- und Generatorstromversorgung nach einem Erdschluss; Batterien entluden sich; Zugang und Personal erschwerten den Generator-Neustart; Cloudflare erfuhr von den Problemen, als Router offline gingen; Sicherungsautomaten mussten ersetzt werden; und Server wurden in einer kontrollierten Sequenz wieder in Betrieb genommen. Das Unternehmen trennte klar bestätigte Fakten von fundierten Spekulationen, wo der Einrichtungsbetreiber keine Antworten geliefert hatte.

Dieselbe Einrichtung fiel im März 2024 erneut aus. Cloudflareszweiter Stromausfallberichtsagte, dass frühere Änderungen die Reaktion verbessert und die Auswirkungen reduziert hätten. Der Vergleich zeigt, dass die Wiederherstellungsqualität von Vorbereitung, getesteten Abhängigkeiten und klaren Aktivierungskriterien abhängt, nicht nur von redundanter Ausrüstung auf einem Einrichtungsdatenblatt.

Für lateinamerikanische Edge-Standorte sagt der 10-K, dass Drittanbieter-Auftragnehmer Hardware im Ausland installieren und warten können und dass Cloudflare den Betrieb von Drittanbietereinrichtungen nicht kontrolliert. Öffentliche Support-Informationen zu Einrichtungen helfen, eine menschliche Abhängigkeit zu identifizieren. EquinixsVerfügbarkeit des Colocation-Supportslistet rund um die Uhr Vor-Ort-Betriebsabdeckung für Bogotá BG2, während die Abdeckung an anderen Standorten variiert. Dies offenbart nicht Cloudflares Serviceberechtigung, Reaktionsziel, Ersatzteillager oder ob ein Techniker autorisiert ist, ein bestimmtes Gerät zu berühren. Es zeigt, warum Personal zur physischen Bewertung gehört.

Die Carrier-Wiederherstellung hat ihre eigene Kette. Ein Cross-Connect-Ausfall erfordert Koordination zwischen Cloudflare, der Einrichtung und dem Peer oder Carrier. Niedriges optisches Licht kann durch einen verschmutzten Stecker, beschädigte Faser, defektes Optikmodul oder ein Problem auf einem längeren Pfad verursacht werden. Die Wiederherstellung einer Seite, ohne die andere zu bestätigen, kann die Sitzung unterbrochen lassen. Bei einem Kunden-Interconnect muss der Kunde auch automatisches Failover und ausreichende alternative Kapazität haben.

Bei einem Exchange-Ausfall müssen Sitzungen möglicherweise zu privaten oder Transit-Pfaden wechseln.

Die Änderungsbefugnis kann zur langsamsten Abhängigkeit werden. Die Person, die ein Routing-Problem sieht, kann möglicherweise keinen Zugang zur Einrichtung genehmigen. Die lokale Einrichtung kann einen Autorisierungsbrief verlangen, bevor ein Cross-Connect bewegt wird. Ein Auftragnehmer benötigt möglicherweise eine Einsatzzentrale. Ein Carrier kann auf Tests an einem Demarkationspunkt bestehen, bevor er eskaliert. Ein verbundenes Unternehmen kann den Vertrag halten, während ein globales Betriebsteam die Reparatur leitet. Keiner dieser Schritte ist in einer Statusfarbe sichtbar.

Der sichere Wiederherstellungspfad ist auch langsamer als das bloße Einschalten. Eine Einrichtung, die nach einem instabilen Ereignis zurückkehrt, muss Stromkreise möglicherweise stufenweise aktivieren, um Einschaltströme zu vermeiden. Netzwerkgeräte sollten überprüft werden, bevor Server Datenverkehr anziehen. Der Zustand und die Kapazität müssen bestätigt werden, bevor Routen zurückkehren, sonst kann die Nachfrage zwischen Standorten oszillieren oder einen teilweise wiederhergestellten Raum überlasten. Cache- und langlebige Verbindungsverhalten können zusätzliche Zeit zur Normalisierung benötigen.

Öffentliche Beweise belegen Cloudflares Fähigkeit, aus schwerwiegenden Stromereignissen zu lernen und eine globale Reaktion zu betreiben. Sie offenbaren nicht lateinamerikanische Standort-Runbooks, lokale Ersatzteile, Wiederherstellungszeitziele oder Befugnisdiagramme. Diese Auslassungen beweisen keine Schwäche. Sie bedeuten, dass der menschliche und vertragliche Teil der Resilienz nicht unabhängig aus dem Städte-Fußabdruck verifiziert werden kann.

Wer spürt den Ausfall zuerst

Die zuerst betroffene Bevölkerung hängt davon ab, welche Ebene ausfällt. Wenn ein Server ausfällt, aber der Router und der Raum gesund bleiben, kann die lokale Lastverteilung ihn mit geringer sichtbarer Wirkung entfernen. Wenn ein Exchange-Port ausfällt, können Benutzer von Peers, die auf diesen Port angewiesen waren, längere Pfade nehmen, während Benutzer, die über andere Carrier kommen, lokal bleiben. Wenn ein gesamter Standort sich zurückzieht, können sich viele Zugangsnetzwerke gemeinsam verschieben. Wenn eine Metro mehrere korrelierte Pfade verliert, kann eine viel größere Region zu entfernteren Städten geschickt werden.

Endbenutzer bemerken Latenz, Verbindungsabbrüche, geringeren Durchsatz oder Fehler. Das Muster wird innerhalb eines Landes nicht einheitlich sein. Ein Internetdienstanbieter mit einer direkten Sitzung in San José kann einem anderen Pfad folgen als einer, der Transit im Upstream kauft. Mobile und feste Netzwerke können unterschiedliche Routing-Entscheidungen treffen. Ein Cache-Treffer kann lokal abgeschlossen werden, während eine ungecachte Anfrage weiterhin von einem Ursprung in der ausgefallenen Metro abhängt. Der Status von „San José“ oder „São Paulo“ übersetzt sich daher nicht in ein einheitliches nationales Erlebnis.

Cloudflare-Kunden, die private Interconnects nutzen, stehen vor einer expliziteren Grenze. Die GRU-Mitteilung teilte ihnen mit, dass Schnittstellen nicht verfügbar werden und sie ein Failover an anderer Stelle arrangieren sollten. Wenn ihr alternativer Stromkreis in derselben Metro liegt oder denselben Carrier-Pfad nutzt, kann die nominelle Redundanz nicht helfen. Wenn er in einer anderen Stadt endet, muss er für die übertragene Nachfrage dimensioniert sein und sein Routing muss ohne manuelle Verzögerung aktiviert werden. Die Kontinuität des öffentlichen Edge stellt von sich aus keinen privaten Pfad wieder her.

Die Wahl der Datenlokalität verkleinert die empfangende Menge. CloudflaresBeschreibung der Regional Servicessagt, dass verschlüsselte Verbindungen global akzeptiert werden können, während HTTPS-Entschlüsselung und Anwendungsverarbeitung nur in der ausgewählten Region erfolgen. Das bedeutet, dass ein Standort außerhalb der ausgewählten Menge die Netzwerkverbindung aufnehmen, aber nicht unbedingt die gesamte Arbeit erledigen kann. Die Failover-Kapazität muss innerhalb der erlaubten Verarbeitungsregion gezählt werden, nicht über jeden Punkt auf der Weltkarte.

Die aktuelleRegion-Support-Tabellelistet Brasilien als verwaltete Region für Regional Services. Sie listet keine einzige verwaltete Region für ganz Lateinamerika auf, obwohl kundenspezifische Konfigurationen für einige Optionen verfügbar sein können. Eine brasilianische Lokalitätsverpflichtung kann daher die Anzahl und Verteilung gesunder brasilianischer Standorte besonders wichtig machen. Kapazität in Miami, Bogotá oder San José kann physisch erreichbar, aber für die Entschlüsselung unter dieser Einstellung nicht berechtigt sein. Die Produktkonfiguration jedes Kunden ist wichtig.

Öffentliche Dienste, Banken, Einzelhändler, Gesundheitsdienstleister, Medien, softwaredienstleistungen und kleine Websites können alle hinter demselben Edge sitzen, aber ihre Ausfallkosten unterscheiden sich. Eine kurze Verzögerung auf einer statischen Seite ist nicht dasselbe wie der Verlust einer Zahlungsverbindung, eines Mitarbeiterzugangspfades oder eines öffentlichen Informationsdienstes. Kunden mit einem zweiten Anbieter oder einer Umgehungsroute können sich unabhängig erholen; Kunden, die ausschließlich von Cloudflare abhängen, benötigen sowohl Cloudflares Edge als auch ihre eigenen Ursprünge, um verbunden zu bleiben.

Cloudflares 10-K erkennt an, dass Kunden den Zugang zu ihren Netzwerken oder dem Internet verlieren können, bis der Dienst zurückkehrt oder sie einen Umgehungsweg aktivieren.

Die ersten Benutzer, die einen Ausfall spüren, sind daher nicht unbedingt diejenigen, die dem dunklen Raum am nächsten sind. Es sind die Benutzer, deren Zugangsanbieter, Produkt, Lokalitätsregel, privater Stromkreis und Ursprungspfad die wenigsten Alternativen lassen. Diese Verteilung kann nicht allein aus der Geografie abgeleitet werden. Sie erfordert Verkehrs- und Kundenkonfigurationsdaten, die nicht öffentlich sind.

Die Beweise, die für eine glaubwürdige Belastbarkeitsbehauptung noch fehlen

Die öffentlichen Beweise reichen aus, um eine substanzielle lateinamerikanische Betriebsoberfläche zu belegen. Cloudflare listet einen breiten Städte-Fußabdruck auf. Es meldet ein San-José-Deployment mit NIC.CR und einem aktiven Statuskomponenten dort. Sein PeeringDB-Eintrag zeigt aktuelle Exchange- und Einrichtungsbeziehungen. Kunden-Interconnect-Material identifiziert benannte Einrichtungen von São Paulo bis Bogotá und Lima. Einrichtungsbetreiber veröffentlichen Strom-, Kühlungs- und Support-Eigenschaften.

Cloudflare meldet globale externe Interkonnektivität mit 500 Tbps und beschreibt offen die Risiken von Drittanbietereinrichtungen, Carriern und Strom.

Es reicht nicht aus, um zu beweisen, dass die Region den Verlust einer großen Metro ohne wesentliche Auswirkungen verkraften kann. Die fehlenden Beweise beginnen mit einem datierten Inventar: aktive Einrichtungen pro Stadt, die an jedem Standort aktivierten Dienste, Servergenerationen, nutzbare Rechenleistung, vertraglich gesicherter Strom, externe Portkapazität. Der nächste Bedarf ist die Auslastung: normale und Perzentil-Last, Reservepolitik, Angriffstoleranz und die getestete maximale Übertragung von jeder großen Ausfall-Domain. Globale Gesamtzahlen können diese lokalen Fragen nicht beantworten.

Physische Unabhängigkeit muss ebenfalls nachgewiesen werden. Für jedes Paar nominell diverser Standorte würde eine nützliche Offenlegung separate Netzversorgung, USV- und Generator-Kreise, Fasereingänge, Meet-Me-Räume, Exchange-Fabrics, Carrier-Routen und Fernverkehrsausgänge identifizieren. Sie würde angeben, wo zwei „diverse“ Stromkreise zusammenlaufen. Sie würde ein separates Gebäude von einer separaten Metro und eine separate Metro von einem separaten internationalen Landepfad unterscheiden. Die aktuelle Backbone-Illustration zeigt ausdrücklich nicht alle Routen, und Einrichtungsmarketing kartiert keine kundenspezifischen Stromkreise.

Die rechtliche und kommerzielle Grenze bleibt unvollständig. Der aktuelle rechtliche Eintrag des costa-ricanischen Unternehmens und die LACNIC-Registrierung sind starke Belege für lokale Präsenz, aber es gibt keinen öffentlichen Plan, der regionale Einrichtungen, Carrier-Verträge, Ausrüstungseigentum oder Notfallbefugnisse auf Cloudflare-Verbundene aufteilt. Die Standard-Kundenvereinbarung nennt die Delaware-Muttergesellschaft.

Ein glaubwürdiger Bericht sollte daher die vertragsschließende Einheit nur dort nennen, wo ein öffentliches Dokument dies tut, und vermeiden, den costa-ricanischen Namen als pauschale regionale Betreiberbezeichnung zu behandeln.

Wiederherstellungsbelege würden den Alarmpfad von der Einrichtung zu Cloudflare, die Reaktionszusagen von Remote-Hands, den Standort von Ersatzteilen, die Carrier-Eskalation, die Schwellen für Routenrückzug, die Neustartreihenfolge und den Nachweis von vollständigen Standortübungen umfassen. Die Oregon-Vorfälle zeigen, warum diese Details wichtig sind, aber sie belegen nicht die lateinamerikanische Leistung. Die N+1- oder 2N-Bewertung einer Einrichtung ist eine Eingabe, kein Ergebnis.

Tests sollten den Verlust des gesamten Raums, den Verlust eines Metro-Carrier-Pfades und den Verlust einer erlaubten Lokalitätsregion umfassen, nicht nur einzelne Geräte.

Die Kundenauswirkung benötigt ihre eigene Messung. Öffentliche Berichterstattung könnte zeigen, ohne Kunden zu exponieren, wie viel Datenverkehr sich bewegte, wo er landete, wie sich die Latenz veränderte, ob private Interconnects failovern, ob regionalisierte Dienste in ihren erlaubten Standorten blieben und wie lange Caches und langlebige Sitzungen zur Stabilisierung brauchten. Die GRU-Wartungsmitteilung gibt die erwartete Bewegungsrichtung an, veröffentlicht aber keine dieser Ergebnisse.

Keines der fehlenden Elemente beweist, dass Cloudflare keine Resilienz hat. Geheimhaltung um genaue Standorte und Kapazitäten kann selbst Sicherheit und Verhandlungsmacht schützen. Der Punkt ist enger: Die öffentliche Karte und die globale Kapazitätszahl können allein kein quantitatives regionales Failover-Versprechen stützen. Was verteidigt werden kann, ist eine bedingte Kette.

Cloudflare hat viele Standorte und mehrere Formen der Interkonnektion; Anycast und lokale Lastverteilung können Arbeit verschieben; Einrichtungen und Carrier von Drittanbietern bieten die physische Plattform; und eine erfolgreiche Wiederherstellung hängt von unabhängiger Stromversorgung, Routen, Kapazität und menschlichem Handeln ab, die nur teilweise sichtbar sind.

Kehren wir abschließend zum Umschalter in São Paulo zurück. Wenn die zweite Einspeisung hält, Router Licht behalten und die Einrichtung kühl bleibt, werden Benutzer möglicherweise nie erfahren, dass sie bewegt wurde. Wenn der Raum dunkel wird, können Routen abwandern. Ob der Dienst reibungslos überlebt, wird in den empfangenden Räumen entschieden: ihren freien Watt, Serverzyklen, Ports, erlaubten Arbeitslasten und funktionierenden Pfaden. Das sind die Größen, die ein Städtepunkt verbirgt.

Bis sie offengelegt oder unabhängig gemessen sind, ist die ehrliche Lesart von Cloudflares lateinamerikanischem Edge nicht „die Karte heilt sich selbst“, sondern „die Karte zeigt, wo eine sorgfältig gewartete physische Kette voraussichtlich antwortet.“