Cloudflare fügt benutzerdefinierte Regionen hinzu, um globalen Edge und lokale Einschränkungen zu kombinieren. Dies ist eine Antwort auf den Druck zur Einhaltung von Vorschriften, der beginnt, die Routing-Architektur zu beeinflussen.
Das Problem tritt auf, wenn das globale Edge-Modell auf Anforderungen zur Datenlokalisierung stößt. Die Architektur von Cloudflare optimiert standardmäßig die Latenz über das nächstgelegene Rechenzentrum. Sobald jedoch Anforderungen auftreten, TLS-Termination und L7-Verarbeitung in bestimmten Ländern durchzuführen, beginnt dieses Modell, mit der Compliance in Konflikt zu geraten. Vorgegebene Regionen lösen teilweise das Problem, stoßen jedoch schnell an reale Szenarien: Ausnahmen für Länder, nicht standardisierte Gruppen, regulatorische Nuancen.
Die Lösung besteht in einem Wechsel von festen Regionen zu programmierbaren Grenzen. Benutzerdefinierte Regionen ermöglichen es, eine beliebige Geografie über Regeln festzulegen. Dies ist ein Kompromiss: Der globale Ingress und der Schutz auf L3/L4-Ebene bleiben erhalten, aber es wird eine strenge Kontrolle eingeführt, wo die sensible Verarbeitung stattfindet (TLS-Termination, Layer 7). Im Gegensatz zu region-first Clouds, bei denen die Region fest mit der Infrastruktur verbunden ist, ist hier die Region eine logische Bedingung über dem globalen Netzwerk.
Die Implementierung basiert auf drei Elementen. Erstens — die Definition der Region durch Ausdrücke über Metadaten der Rechenzentren, z. B. country_code. Include- und Exclude-Regeln werden unterstützt. Zweitens — die Auswahl des Ziels innerhalb der Region: Das System überlappt die zulässigen Rechenzentren mit einer Rangfolge basierend auf dem aktuellen Netzwerkzustand (Latenz, Kapazität, Gesundheit). Drittens — Durchsetzung am Edge: Der Datenverkehr wird global akzeptiert, dann wird die Übereinstimmung mit der Region überprüft und entweder lokal verarbeitet oder in die zulässige Zone weitergeleitet. Dies fügt einen zusätzlichen Entscheidungsschritt auf dem Weg der Anfrage hinzu, ermöglicht es jedoch, die Robustheit des Edge-Netzwerks nicht zu opfern.
Das Ergebnis ist eine genauere Einhaltung der Compliance-Anforderungen, ohne das Edge-first-Modell vollständig aufzugeben. Dabei entstehen neue Trade-offs. Die Konfiguration und Kontrolle der Regeln wird komplizierter. Potenziell steigt die Latenz aufgrund der zusätzlichen Weiterleitung innerhalb der Region. Die Einflussmetriken sind nicht offengelegt, aber die Architektur selbst zeigt einen Wandel: von „global standardmäßig“ zu „global mit Einschränkungen als Code“. Dies ist eine evolutionäre Veränderung, die die Datenplatzierungspolitik zu einem Teil der Runtime-Logik macht und nicht nur zu Vereinbarungen auf regionaler Ebene.