Der Dienst, den du brauchst, gibt es in Zürich nicht

Über Datenresidenz habe ich hier schon zweimal geschrieben: darüber, was “Daten in der Schweiz” technisch abdeckt, und darüber, was die Zürcher Region gegenüber Frankfurt kostet.

Beide Beiträge setzen etwas voraus, das ich damals für selbstverständlich gehalten habe: dass die Dienste, die du brauchst, in Zürich überhaupt existieren.

Was mir passiert ist

Für ein eigenes Projekt musste ich Geräte im Feld anbinden. MQTT über TLS, Geräteidentität über Zertifikate, ein Zustandsabbild pro Gerät. Auf AWS ist das IoT Core.

Die Region stand längst fest, eu-central-2, aus dem Grund, den alle nennen: Schweizer Kunden, Schweizer Daten.

IoT Core gibt es dort nicht.

Keine Vorschauversion, keine Warteliste. Der Dienst ist in eu-central-2 schlicht nicht verfügbar. Die Geräteanbindung läuft heute in eu-central-1, also Frankfurt, und das steht so in der Dokumentation des Projekts.

Gemerkt habe ich es beim Schreiben der ersten Infrastrukturzeile. Das war früh genug. Zwei Monate später wäre es teuer geworden.

Eine Region ist ein Katalog

Das Wort “Region” erzeugt ein falsches Bild. Es klingt nach einem Rechenzentrum, in dem alles steht, was AWS anbietet, nur eben in Zürich statt in Frankfurt.

Tatsächlich ist eine Region ein Katalog, und Kataloge haben Lücken. Dienste kommen dazu, wenn genug Nachfrage da ist, und die Schweiz ist ein kleiner Markt.

Zürich ging im November 2022 mit 58 Diensten an den Start. AWS gibt den Stand inzwischen mit rund 173 an. Das ist eine gute Entwicklung, und genau diese Zahl erzeugt den Eindruck von Vollständigkeit. Frankfurt liegt trotzdem deutlich darüber.

Bei IoT Core ist die Lage eindeutig. Der Dienst läuft im August 2026 in 25 von 37 Regionen. In Europa sind das unter anderem Frankfurt, Irland, London, Paris, Stockholm, Mailand und Spanien.

Das ist kein Vorwurf an AWS. Der Fehler entsteht auf unserer Seite, wenn wir aus dem Wort “Region” auf Vollständigkeit schliessen und den Satz über Schweizer Datenhaltung in ein Angebot schreiben, bevor jemand die Liste durchgegangen ist.

Die Prüfung, zehn Minuten

1. Konkrete Dienste auflisten, keine Kategorien. “Datenbank” ist keine Antwort, “DynamoDB” ist eine. Geh die geplante Architektur durch und schreib die Dienstnamen auf. Die unsichtbaren gehören dazu: die Warteschlange, die Schlüsselverwaltung, der Zeitplaner, die Ablage für Protokolldaten, der Mailversand.
2. Jeden Dienst einzeln nachschlagen. Die offizielle Übersicht heisst “AWS Services by Region” und steht auf aws.amazon.com. Verlass dich nicht auf das Gedächtnis, auch nicht auf das eigene. Die Tabelle ändert sich laufend, und das ist ja der Sinn der Sache.
3. Auf die regionslosen Dienste achten. Manche Dienste haben gar keine Region im üblichen Sinn. IAM ist global. CloudFront ist ein weltweites Netz, konfiguriert in us-east-1. Route 53 ebenso. Das ist meist unproblematisch, gehört aber ins Protokoll, weil sonst ein Prüfer selbst darüber stolpert und dann du erklären musst.
4. Das Ergebnis mit Datum festhalten. Eine Tabelle mit Dienst, Region, geprüft am. Dieses Dokument ist später der Unterschied zwischen “wir haben das bedacht” und “das ist uns durchgerutscht”.

Der vierte Schritt ist der, den alle weglassen, und er ist der einzige, der Monate später noch etwas wert ist.

Vier Wege, wenn ein Dienst fehlt

Ein fehlender Dienst kippt kein Projekt. Er verlangt eine Entscheidung, und die trifft man besser vorher als nachher.

Den Dienst in einer anderen Region betreiben und das offenlegen. Diesen Weg habe ich gewählt. Entscheidend ist die Frage, welche Daten dort tatsächlich verarbeitet werden. Bei meiner Geräteanbindung sind das Telemetriewerte und Zertifikatskennungen. Personendaten liegen dort keine. Diese Unterscheidung gehört ins Angebot, weil sie die eigentliche Antwort auf die Frage des Kunden ist.

Den Dienst ersetzen. Manchmal gibt es einen anderen, der in Zürich verfügbar ist und dasselbe Problem löst, mit etwas mehr Arbeit auf deiner Seite.

Die Funktion selbst betreiben. Ein verwalteter Broker lässt sich durch eine eigene Installation auf Containern ersetzen. Dann trägst du Betrieb, Aktualisierung und Bereitschaft selbst. Das ist eine ehrliche Rechnung und für manche Projekte die richtige.

Die Anforderung klären. Das ist der Weg, den die wenigsten gehen, und meistens der beste.

Die Frage, die das Gespräch besser macht

“Wollen Sie Schweizer Datenhaltung?” ist keine nützliche Frage. Die Antwort ist immer ja.

Nützlich ist: welche Daten genau müssen in der Schweiz bleiben, und woher kommt diese Vorgabe?

Kommt sie aus einem Vertrag, aus einer Ausschreibung, aus einem Berufsgeheimnis, aus einer internen Richtlinie? Das revidierte Schweizer Datenschutzgesetz verlangt keine Speicherung im Inland, wie ich an anderer Stelle ausgeführt habe. Es verlangt, dass eine Bekanntgabe ins Ausland nur in Länder mit angemessenem Schutz erfolgt oder mit geeigneten Garantien abgesichert wird. Der Bundesrat führt dazu eine Länderliste, und die EU-Staaten stehen darauf. Eine Bearbeitung in Frankfurt ist damit in vielen Fällen rechtlich unproblematisch, und dieser Satz nimmt dem Gespräch meistens den ersten Schrecken. Das ist keine Rechtsberatung, es ist die Grundlage, auf der eine juristische Prüfung überhaupt sinnvoll stattfinden kann.

Der Druck kommt in der Praxis fast immer aus einer Vereinbarung, und eine Vereinbarung ist genauso bindend wie ein Gesetz, sobald sie unterschrieben ist.

Die Antwort fällt in der Praxis oft enger aus als der pauschale Satz vermuten lässt. Kundenstammdaten ja, Messwerte über Systemauslastung nicht. Sobald das geklärt ist, wird aus einem harten Hindernis eine Architekturentscheidung mit mehreren gangbaren Varianten. Und der Aufschlag von rund zehn Prozent, den die Zürcher Region kostet, trifft dann nur noch die Teile, für die er auch gerechtfertigt ist.

Was ich mir angewöhnt habe

Ich prüfe die Regionsverfügbarkeit vor dem ersten Entwurf, nicht während der Umsetzung. Der Aufwand ist lächerlich klein im Vergleich zu einem nachträglichen Umbau.

Und ich schreibe in kein Angebot mehr einen Satz über Datenhaltung, ohne die geprüfte Dienstliste daneben zu legen.

Eine Region ist der Rahmen. Die Entscheidung fällt pro Dienst.

Häufige Fragen

Sind in AWS eu-central-2 (Zürich) alle AWS-Dienste verfügbar?

Nein. Eine AWS-Region führt einen Teil des Gesamtangebots, und Zürich ist eine der kleineren Regionen. AWS selbst gibt für Zürich rund 173 Dienste an, gewachsen von 58 beim Start im November 2022. Frankfurt liegt deutlich darüber. AWS IoT Core zum Beispiel ist im August 2026 in 25 von 37 Regionen verfügbar, in Europa unter anderem in Frankfurt, Irland, London, Paris, Stockholm, Mailand und Spanien. Zürich gehört nicht dazu.

Wie prüfe ich, ob ein AWS-Dienst in einer Region verfügbar ist?

Über die offizielle Übersicht “AWS Services by Region” auf aws.amazon.com. Wichtig ist, die konkreten Dienstnamen zu prüfen und nicht die Kategorien: “Datenbank” ist keine Antwort, “DynamoDB” ist eine. Die unsichtbaren Bausteine gehören dazu, also Warteschlangen, Schlüsselverwaltung, Zeitplaner und die Ablage für Protokolldaten. Das Ergebnis gehört mit Datum ins Angebot, weil sich die Tabelle laufend ändert.

Was tue ich, wenn ein benötigter Dienst in Zürich fehlt?

Vier Wege sind gangbar. Den Dienst in einer anderen Region betreiben und offenlegen, welche Daten dort verarbeitet werden. Den Dienst durch einen ersetzen, den es in Zürich gibt. Die Funktion selbst betreiben, etwa auf Containern. Oder die Anforderung klären, weil sie oft enger ist als der pauschale Satz über Schweizer Datenhaltung. Was in keinem Fall funktioniert, ist die Zusage vor der Prüfung.

Zum Nachschlagen

Verfügbarkeit von Hand: die Übersicht “AWS Services by Region” auf aws.amazon.com. Stand der hier genannten Zahlen ist August 2026.

Verfügbarkeit im Skript: AWS veröffentlicht die Zuordnung von Dienst zu Region als öffentliche Parameter im Systems Manager Parameter Store.

aws ssm get-parameters-by-path \
  --region us-east-1 \
  --path /aws/service/global-infrastructure/services/<dienst>/regions/eu-central-2 \
  --output text

Eine leere Antwort heisst: in dieser Region nicht verfügbar. Die gültigen Dienstnamen listet derselbe Aufruf mit dem Pfad /aws/service/global-infrastructure/services. Der Pfad ist nur aus wenigen Regionen abfragbar, deshalb steht --region us-east-1 im Aufruf, unabhängig davon, wo dein Konto sonst arbeitet.

Ein verbreiteter Irrtum am Rand: aws account list-regions beantwortet eine andere Frage, nämlich welche Regionen für dein Konto aktiviert sind. Das ist wissenswert und sagt nichts über einen einzelnen Dienst.