Intramedial befindet sich in der eingeschränkten Beta. Bei der Registrierung oder Anmeldung müssen Sie das erhaltene Beta-Tester-Passwort angeben oder unter preview@intramedial.com eines anfordern. Vielen Dank.
Wird geladen…
Datenregionen
Datenort
Ihre Belege liegen, wo Sie sie ablegen.
Jeder Workspace hat einen Datenstandort, der beim Anlegen gewählt wird: einen der angebotenen Standorte (die sieben Produktregionen plus weitere AWS-Standorte). Dort werden Ihre Daten gespeichert. Belege, geplante Prüfungen, Kontingentzähler und Relay-Anfragen werden in der Produktregion verarbeitet und mit deren eigenem Schlüssel signiert, die den Standort bedient; ein Standort außerhalb der sieben nutzt die nächstgelegene. Diese Seite sagt genau, was regional ist, was nicht und was eine Region zusagt und was nicht.
Agenten handeln, wenn die Ebene Ja sagt – und das Protokoll sagt, warum.
Leiten Sie Agent-Aktionen, Inhalts-Hashes, API-Checks, DNS-Abfragen, Webhooks, LLM-Aufrufe und Git-Commits über Intramedial – für einen signierten Beleg, den jeder prüft, ohne uns zu vertrauen.
Jede Region ist ein eigener Dienst mit eigener Datenbank und eigenem Signatur-Key. Die Pins zeigen, wo der Key jeder Region im AWS Key Management Service liegt. Sie sagen nichts darüber, in welchem Gebäude die Datenbank steht.
Region
Code
Signatur-Key in AWS KMS
Key-Jurisdiktion
Speicher
USA WestFree-Tarif-Region
wnam
Oregon
WNAM
Standorthinweis
USA Ost
enam
N. Virginia
ENAM
Standorthinweis
Die Codes sind die Werte von region im Workspace-Status und, in Großbuchstaben, die Jurisdiktion jedes Keys im publizierten Schlüsselsatz. In den drei EU-Regionen hält Cloudflare die Daten in der EU und wählt das Rechenzentrum, daher nennen wir keine Stadt. Bei den anderen vier entsteht die Datenbank mit Standorthinweis, also einer Bitte zur Platzierung, keiner Garantie.
Cloudflares eigene Beschreibung von D1-Jurisdiktionen und Standorthinweisen, Stand Oktober 2026: Cloudflare D1: Datenstandort ↗
02
Datenumfang
Was in der Region bleibt, und was nicht.
Nur die Datenebene ist regional. Die Kontoebene läuft in den USA (US West), egal welche Region Sie wählen. Ein Aufruf wird gegen Kontodaten in den USA authentifiziert, dann an Ihre Region übergeben, dort verarbeitet, signiert und gespeichert.
Regional: in der gewählten Region
Belege und gespeicherte Inhalte, sofern aufbewahrt
Geplante Watches, ihre Prüfergebnisse und ihre Belege
Kontingentzähler des Monats
Verarbeitung von Relay-Anfragen: agent.call, webhook.deliver, monitor.http, dns.watch
03
Routing
Wie ein Aufruf Ihre Region findet.
Die Eingangstür kennt die Datenregion des Workspace Ihres Zugangs und leitet jeden Aufruf an den Dienst dieser Region, der nur die Datenbank dieser Region liest und schreibt.
1Ihr AufruferEine App, ein CI-Job oder Agent, mit API-Key.
2
04
Schlüssel
Jede Region signiert mit eigenem Key.
Jede Region signiert mit eigenem Ed25519-Key in einem AWS-KMS-Hardware-Sicherheitsmodul in der AWS-Region der Karte. Der private Key verlässt das Modul nie: Der Regionaldienst sendet die Bytes und erhält eine Signatur.
Publiziert, samt Jurisdiktion
Der öffentliche Teil jedes regionalen Keys liegt in einem Schlüsselsatz, jeder Eintrag nennt seine Jurisdiktion. Ein Beleg nennt den signierenden Key in signatureKeyId.
Geteilt von allen Workspaces der Region
Es gibt sieben Keys, einen je Jurisdiktion. Belege aller Workspaces einer Jurisdiktion werden mit deren Key signiert.
05
Über Grenzen
Was Regionen quert.
Vier Arten von Daten verlassen eine Region, jede steht hier. Nichts geht von einer Region in eine andere.
Zwischen Regionen
Nichts
Der Dienst einer Region hat keinen Zugriff auf Belege einer anderen. Jeder liest nur seine Datenbank.
In die USA
Konto und Messung
Die Metadaten, die die Eingangstür zur Authentifizierung und Tarifmessung braucht, und alles aus den USA.
06
Zuordnung
Wie ein Workspace zur Region kommt.
Sie wählen die Region beim Anlegen des Workspace. Ein Konto kann Workspaces in mehreren Regionen haben.
Beim Signup
Das Formular wählt die nächste der sieben nach Ihrem Standort vor; Sie können sie ändern.
Jeder weitere Workspace
Das Formular für neue Workspaces hat dieselbe Auswahl, so trennt ein Team EU- und US-Arbeit.
07
Leistung
Latenz
Gearbeitet wird nah an den Daten, doch jeder Aufruf passiert zuerst die Eingangstür. Latenzwerte der Regionen haben wir nicht publiziert und nennen hier keine.
Der Weg eines Aufrufs
Aufrufer
Nächster Cloudflare-Standort
Eingangstür
Regionaldienst
08
Nachweise
Die Dokumente hinter der Region
Diese Seite erklärt. Diese Dokumente binden. Braucht eine Aufsicht oder ein Kunde eine vertragliche Aussage zum Datenort, sind sie zu lesen.
Kontoebene und Eingangstür: Dashboard, Anmeldung, Abrechnung, API-Eingangstür
Schematische Karte. Küsten vereinfacht; die Pins folgen den AWS-Regionen, die die Keys halten.
Europa Mitte
weur-1
eu.Frankfurt
WEUR-1
EU-Jurisdiktion, erzwungen
Europa West
weur-2
eu.Irland
WEUR-2
EU-Jurisdiktion, erzwungen
Europa Nord
neur
eu.Stockholm
NEUR
EU-Jurisdiktion, erzwungen
Asia-Pacific
apac
asia.Singapur
APAC
Standorthinweis
Oceania
oc
oc.Sydney
OC
Standorthinweis
Belegsignatur mit dem eigenen Key der Region
Aufbewahrung, Auto-Löschung, Schwärzung für Ihre Daten
Aus den USA bedient (US West)
Das Dashboard und die Website
Anmeldung, Sessions und Kontodaten: Name, E-Mail, Mitgliedschaften
Abrechnung, über Avonao Billing und Avonao Billing
Prüfung von API-Keys und Tokens sowie Rate-Limits an der Eingangstür
Die Steuerungsebene und das Konto-Auditlog
Öffentliche Statusseite
Was eine Region verspricht und was nicht
Eine Region sagt, wo Daten gespeichert und verarbeitet werden. Sie sagt nicht, dass Verkehr nie einen Netzrand verlässt: Cloudflare nimmt eine Verbindung am Standort nächst dem Aufrufer an, der überall sein kann, und der Inhalt einer Anfrage passiert die Eingangstür, die sie empfängt. Dashboard und Kontodaten liegen in jedem Fall in den USA. Für eine vertragliche Aussage lesen Sie AVV und Datenschutzerklärung oder fragen Sie uns.
3Eingangstür, US WestPrüft den Key, drosselt, misst den Tarif und findet die Region des Workspace.
4Dienst Ihrer RegionVerarbeitet den Aufruf, signiert und speichert den Beleg.Signiert vom Key der Region in AWS KMSGespeichert in der Regions-DB
Vier Regeln ohne Ausnahme
01
Kein stiller Fallback
Ist der Dienst Ihrer Region nicht erreichbar, scheitert der Aufruf. Nie antwortet eine andere Region, denn so lägen Ihre Daten, wo Sie es nicht wählten. Verarbeitet wurde nichts.
02
Nur bekannte Regionen
Ein Regionswert außerhalb der sieben wird abgelehnt, bevor Arbeit beginnt.
03
Kein Key-Verleih
Eine Region ohne konfigurierten Key signiert nicht. Nie signiert sie mit dem Key einer anderen.
04
Prüfen braucht keine Region
Einen Beleg prüfen ist Public-Key-Kryptografie über den Beleg, den Sie halten. Ohne Konto, ohne Region, ohne Aufruf bei uns.
Was Ihr Client sieht
503
federation_unavailableDie Region des Workspace ist nicht verfügbar; nichts verarbeitet. Später neu.
421
Misdirected RequestDer Regionswert des Workspace ist keiner der sieben.
503
Service UnavailableDie Region hat keinen Signatur-Key; kein Beleg wurde ausgestellt.
Geplante Arbeit ist auch regional
Jede Region betreibt ihren eigenen Minuten-Scheduler über ihre Datenbank, also wird ein Watch aus der Region seines Workspace geprüft und seine Belege dort gespeichert. Ausnahme sind die öffentlichen Statussonden: Sie laufen von einem US-Standort, die Statusseite zeigt also, was dieser sieht.
Ein Rotationsplan oder Schlüsselablauf ist nicht dokumentiert, daher wird hier keiner versprochen. Ein Bundle nennt weiterhin den Schlüssel, der es signiert hat, sodass Sie diesen Schlüssel festschreiben können.
Ein Eintrag im publizierten Key-Satz/.well-known/ledger-bundles-keys.json
rehoming.plan nennt eine Quell- und eine Zielregion und liefert, was verschoben würde und ob das Ziel EU-gebunden ist. Execute erfasst einen Snapshot; das Ziel wendet ihn bei seiner nächsten Anfrage an.
Was er beweist
Plan nennt die festgelegten Durable-Object-Klassen und ob der Umzug EU-gebunden ist. Execute kopiert Leases, Zeilen und Objektzustand.
Was er nicht beweist
Es ist kein atomarer Umzug und löscht an der Quelle nichts. Der Snapshot ist nicht signiert, und der Umzug wird nicht in das Ledger geschrieben, das ledger.blame liest. Es gibt keine Wiederherstellungsaktion.
Je Beleg gehen die kanonischen Beleg-Bytes an AWS KMS in der AWS-Region der Region. KMS speichert sie nicht.
An Ihre Zielsysteme
Ihre Relays
Eine Relay-Anfrage geht an den genannten Host, wo immer er ist, und verlässt Cloudflares Netz aus der verarbeitenden Region. Wo dieser Host Daten speichert, liegt nicht bei uns.
Dann steht sie fest
Umziehen geht nicht. Für eine andere Region legen Sie dort einen Workspace an und stellen dort neue Belege aus. Ihre Belege bleiben prüfbar, wo immer sie entstanden.
Über die API gegenprüfen
Ihr Workspace-Status meldet region und euResidency, das für die drei EU-Regionen true ist.
EU-Residenz nötig?
Wählen Sie Europe Central, Europe West oder Europe North. Alle drei speichern unter Cloudflares EU-Jurisdiktion. Sie unterscheiden sich im Dienst, der Ihre Aufrufe bearbeitet, und im Ort Ihres Signatur-Keys: Frankfurt, Irland oder Stockholm.
Vorgewählte Region nach Standort
Nur eine Vorgabe im Anmeldeformular, aus dem Standort der Anfrage. Sie können stets anders wählen.
Bei Anmeldung aus
Vorgewählt
Mittel- und Osteuropa, der Balkan, das östliche Mittelmeer, der Nahe Osten und Afrika
Europa Mitteweur-1
Britische Inseln, Frankreich, Benelux, Iberien, Italien und Island
Europa Westweur-2
Nordische und baltische Länder
Europa Nordneur
Westliche US-Staaten und kanadische Provinzen, Mexiko, USA oder Kanada ohne bekannten Staat
USA Westwnam
Asien
Asia-Pacificapac
Australien, Neuseeland und die Pazifikinseln
Oceaniaoc
Ist der Standort gar nicht lesbar, wählt das Formular US West vor.
Regionale Datenbank
Messen Sie aus Ihrem Netz mit Ihrem Client. Brauchen Sie Nachweise, was ein Standort sieht, halten signierte Monitor-Belege es fest. Guide: Uptime-Nachweise →
Datenort
