Von AWS zu Scaleway: Was aus RDS, S3 und Route 53 wird

Wer von AWS zu Scaleway wechselt, hat meist einen guten Grund: ein europäischer Anbieter, eine verständliche Rechnung, weniger Abhängigkeit von einem einzigen Hyperscaler. Der Umzug selbst wirkt größer, als er ist. Fast jeder Dienst, den eine typische SaaS auf AWS nutzt, hat bei Scaleway ein direktes Gegenstück. Die Arbeit steckt in den Übergängen: Daten umschalten, ohne etwas zu verlieren, und DNS umstellen, ohne dass jemand es merkt.

Welcher AWS-Dienst wird zu welchem Scaleway-Dienst?

EKS zu Kapsule

Kubernetes ist Kubernetes. Deployments, Services, Ingresses und Helm-Charts laufen auf Kapsule ohne Änderung. Zwei Dinge fallen trotzdem auf.

IAM-Rollen für Service Accounts gibt es nicht. Auf EKS bekommt ein Pod über IRSA eine AWS-Rolle und liest S3 ohne Schlüssel. Auf Kapsule bekommt die Anwendung einen API-Schlüssel, der als Secret im Pod landet. Das ist weniger elegant, aber übersichtlich: ein Schlüssel pro Anwendung, mit genau den Rechten, die sie braucht, und rotierbar.

Der Load Balancer entsteht aus dem Service. Der AWS Load Balancer Controller mit seinen Annotationen fällt weg. Auf Kapsule legt der Cloud-Controller für jeden Service vom Typ LoadBalancer einen Scaleway Load Balancer an. Für eine SaaS heißt das: ein Ingress-Controller pro Cluster, ein Load Balancer, alle Hosts dahinter.

Neu aufsetzen statt migrieren: Ein Kapsule-Cluster ist in wenigen Minuten da. Wichtiger als die Geschwindigkeit ist, dass er von Anfang an richtig gebaut ist, mit privatem Netz, Nodes ohne öffentliche IP und einem API-Server, der nur aus bekannten Adressen erreichbar ist. Wie das aussieht, zeigt Cluster-Provisioning.

RDS zu Managed Database

Postgres bleibt Postgres, MySQL bleibt MySQL. Der Umzug ist ein Dump und ein Import, und genau hier liegt die wichtigste Entscheidung des ganzen Projekts: Was passiert mit den Schreibzugriffen zwischen Dump und Umschalten?

Solange die alte Anwendung auf AWS weiterläuft, schreibt sie in RDS. Alles, was nach dem Dump geschrieben wird, fehlt in der neuen Datenbank. Es gibt drei Antworten:

1. Wartungsfenster. Anwendung auf AWS anhalten oder auf nur lesen stellen, importieren, umschalten. Bei Datenbanken bis zu einigen Gigabyte ist das eine Sache von Minuten. Für die meisten SaaS-Anbieter die richtige Wahl.
2. Probelauf, dann Fenster. Einmal importieren, um Dauer und Fehler zu kennen, dann im Fenster ein zweites Mal für den echten Stand.
3. Replikation. Die neue Datenbank läuft per Replikation mit, bis beide gleich sind, dann wird umgeschaltet. Vorher prüfen, ob beide Seiten die nötigen Rechte dafür erlauben. Das spart das Fenster, kostet aber Einrichtung und Tests. Es lohnt sich erst bei großen Datenbanken oder harten Verfügbarkeitszusagen.

Vorher prüfen: Nutzt die Anwendung Erweiterungen wie PostGIS oder pg_trgm? Stimmen die Hauptversionen? Ist die RDS-Instanz für den Import erreichbar, etwa über eine öffentliche Adresse mit Allowlist nur für die Zeit des Umzugs? Wie der Import in eine Managed Database abläuft, steht unter Managed Datenbanken.

S3 zu Object Storage

Object Storage bei Scaleway spricht S3. SDKs, Upload-Bibliotheken und signierte URLs funktionieren weiter, sobald Endpunkt, Region und Schlüssel stimmen. Drei Unterschiede kosten trotzdem Zeit:

• Endpunkte. Statt s3.eu-central-1.amazonaws.com heißt es s3.fr-par.scw.cloud, s3.nl-ams.scw.cloud oder s3.pl-waw.scw.cloud. Wer die Region fest im Code hat, sucht danach.
• Rechte. Scaleway kombiniert IAM-Rechte auf Projektebene mit Bucket-Policies. Ein Schlüssel, der nur in der Bucket-Policy steht, bekommt einen 403. Ein Schlüssel mit Projektrechten erreicht jeden Bucket ohne eigene Policy. Wer Anwendungen trennen will, braucht beides.
• Egress. AWS berechnet ausgehenden Datenverkehr. Ein Bucket mit einigen hundert Gigabyte kostet beim Kopieren nach Scaleway spürbar Geld. Einmal kopieren, dann nur noch die Änderungen.

Die Kopie selbst ist harmlos: kopieren und überschreiben, nie löschen, beliebig oft wiederholbar. Kurz vor dem Umschalten ein letzter Lauf, der nur noch die neuen Objekte mitnimmt. Mehr zu Buckets mit eigenem Schlüssel unter Object Storage.

ECR, Secrets und der Rest

Images wandern in die Container Registry des Scaleway-Projekts, in dem der Cluster läuft. Das ist keine Formalie: Ein Kapsule-Node zieht ohne weitere Zugangsdaten nur aus der Registry seines eigenen Projekts. Wer zwei Projekte hat, braucht zwei Registry-Namespaces oder Pull-Secrets.

Secrets aus AWS Secrets Manager werden nicht kopiert, sondern neu angelegt, am besten gleich rotiert. Ein Umzug ist die beste Gelegenheit, Schlüssel zu tauschen, die seit Jahren niemand angefasst hat, und sie dabei aus Git und Helm-Values herauszuholen. Warum das wichtig ist, steht in Kubernetes Secrets: Warum Base64 keine Verschlüsselung ist.

Warum kommt DNS zuletzt, Host für Host?

Der Umzug ist erst passiert, wenn DNS umgestellt ist. Und dort liegt der Vorteil gegenüber einem großen Umzugswochenende: Jeder Host lässt sich einzeln umstellen.

1. TTL senken. Einen Tag vorher die TTL der betroffenen Records auf fünf Minuten setzen.
2. Parallel betreiben. Die Anwendung läuft auf Scaleway, mit Zertifikat, getestet über einen eigenen Hostnamen.
3. Umstellen. Den Record auf den Load Balancer bei Scaleway zeigen lassen. Wer Probleme hat, stellt zurück, die alte Umgebung läuft noch.
4. Aufräumen. Erst wenn eine Woche lang nichts mehr auf AWS ankommt, die alte Umgebung abbauen.

Route 53 muss dafür nicht umziehen. Wer die Zone aber zu Cloudflare verlegt, kann Records automatisiert setzen lassen und bekommt einen Proxy davor. Wie Hosts, Records und Zertifikate zusammenspielen, beschreibt DNS & Zertifikate.

Wie lange dauert der Umzug realistisch?

Für eine typische SaaS mit einer Web-Anwendung, einer API, einer Datenbank und zwei Buckets sieht ein Umzug ohne Hektik so aus:

1. Woche 1: Cluster, Datenbank-Instanz und Registry bei Scaleway anlegen. Images bauen und pushen, Anwendungen über einen Test-Hostnamen ausrollen.
2. Woche 2: Probeimport der Datenbank, erste Bucket-Kopie. Die Anwendung auf Scaleway gegen die importierten Daten testen, Dauer des Imports messen.
3. Woche 3: TTL senken, Wartungsfenster ankündigen. Im Fenster: Schreibzugriffe auf AWS stoppen, finaler Import, letzte Bucket-Kopie, DNS umstellen.
4. Woche 4 bis 5: Beobachten, alte Umgebung laufen lassen, dann abbauen und die AWS-Rechnung prüfen.

Wer mehrere Anwendungen hat, zieht sie nacheinander um. Die erste dauert am längsten, weil jede Frage neu ist; ab der zweiten ist es Routine.

Wie Clusterward den Umzug begleitet

Clusterward verwaltet nur die Scaleway-Seite: den Cluster sicher ab Werk, die Managed Database mit Import aus RDS (die Anwendungen am Ziel pausieren währenddessen), die Bucket-Kopie aus S3 mit Fortschrittsanzeige, die Registry pro Cluster und die Hosts mit Record und Zertifikat. AWS wird nur gelesen, und nur, wenn Sie Daten importieren. Die Übersicht für den ganzen Weg steht unter Wechsel von AWS, Azure & GCP.

Fazit

Der Wechsel von AWS zu Scaleway ist kein Kubernetes-Projekt, sondern ein Datenprojekt. Die Cluster sind schnell gebaut, die Anwendungen laufen unverändert. Planen Sie die Datenbank-Umschaltung mit einem Wartungsfenster, kopieren Sie Buckets früh und einmal, und stellen Sie DNS Host für Host um. Dann ist der Umzug eine Reihe kleiner, umkehrbarer Schritte statt eines Wochenendes mit offenem Ausgang.

Ihren Umzug von AWS durchsprechen? Schicken Sie uns die Liste Ihrer AWS-Dienste. Wir sagen Ihnen, was davon auf Scaleway wie läuft und wo es hakt. Umzug besprechen →

Quellen und weiterführende Links

• AWS: IAM-Rollen für Servicekonten (IRSA) in EKS
• Scaleway: Load Balancer für Kubernetes Kapsule (englisch)
• Scaleway: Object Storage – Konzepte (Endpunkte, Bucket-Policies) (englisch)
• AWS: Amazon S3 Preise (Datenübertragung)