From AWS to Scaleway: what becomes of RDS, S3 and Route 53

Anyone moving from AWS to Scaleway usually has a good reason: a European provider, a bill you can understand, less dependence on a single hyperscaler. The move itself looks bigger than it is. Almost every service a typical SaaS uses on AWS has a direct counterpart at Scaleway. The work lies in the transitions: switching data over without losing anything, and switching DNS without anyone noticing.

Which AWS service becomes which Scaleway service?

EKS to Kapsule

Kubernetes is Kubernetes. Deployments, Services, Ingresses and Helm charts run on Kapsule without changes. Two things still stand out.

There are no IAM roles for service accounts. On EKS, a pod gets an AWS role via IRSA and reads S3 without keys. On Kapsule, the application gets an API key that ends up in the pod as a Secret. That is less elegant, but easy to keep track of: one key per application, with exactly the rights it needs, and rotatable.

The load balancer comes from the Service. The AWS Load Balancer Controller and its annotations go away. On Kapsule, the cloud controller creates a Scaleway Load Balancer for every Service of type LoadBalancer. For a SaaS, that means one ingress controller per cluster, one load balancer, all hosts behind it.

Rebuild instead of migrating: a Kapsule cluster is up in a few minutes. More important than the speed is that it is built right from the start – with a private network, nodes without public IPs and an API server that is only reachable from known addresses. Cluster provisioning shows what that looks like.

RDS to Managed Database

Postgres stays Postgres, MySQL stays MySQL. The move is a dump and an import, and this is where the most important decision of the entire project lies: what happens to the writes between the dump and the cutover?

As long as the old application keeps running on AWS, it writes to RDS. Anything written after the dump is missing from the new database. There are three answers:

1. Maintenance window. Stop the application on AWS or set it to read-only, import, cut over. For databases of up to a few gigabytes, that takes minutes. The right choice for most SaaS vendors.
2. Dry run, then window. Import once to learn the duration and the errors, then a second time in the window for the real state.
3. Replication. The new database follows along via replication until both are identical, then you cut over. Check beforehand that both sides grant the necessary rights for this. It saves the window but costs setup and testing. It only pays off for large databases or strict availability commitments.

Check beforehand: does the application use extensions such as PostGIS or pg_trgm? Do the major versions match? Is the RDS instance reachable for the import, for example via a public address with an allowlist just for the duration of the move? How the import into a Managed Database works is described under Managed databases.

S3 to Object Storage

Object Storage at Scaleway speaks S3. SDKs, upload libraries and signed URLs keep working once the endpoint, region and keys are right. Three differences still cost time:

• Endpoints. Instead of s3.eu-central-1.amazonaws.com, it’s s3.fr-par.scw.cloud, s3.nl-ams.scw.cloud or s3.pl-waw.scw.cloud. If the region is hard-coded, you’ll be hunting for it.
• Permissions. Scaleway combines project-level IAM permissions with bucket policies. A key that is only listed in the bucket policy gets a 403. A key with project permissions reaches every bucket that has no policy of its own. If you want to separate applications, you need both.
• Egress. AWS charges for outbound data transfer. A bucket with a few hundred gigabytes costs noticeable money when copied to Scaleway. Copy once, then only the changes.

The copy itself is harmless: copy and overwrite, never delete, repeatable as often as you like. Shortly before the cutover, one last run that only picks up the new objects. More on buckets with their own key under Object Storage.

ECR, secrets and the rest

Images move to the Container Registry of the Scaleway project the cluster runs in. That is not a formality: without additional credentials, a Kapsule node only pulls from the registry of its own project. If you have two projects, you need two registry namespaces or pull secrets.

Secrets from AWS Secrets Manager are not copied but created anew – ideally rotated right away. A move is the best opportunity to replace keys nobody has touched in years, and to get them out of Git and Helm values in the process. Why that matters is explained in Kubernetes Secrets: why Base64 is not encryption.

Why does DNS come last, host by host?

The move has only happened once DNS has been switched. And that is where the advantage over one big moving weekend lies: every host can be switched individually.

1. Lower the TTL. One day before, set the TTL of the affected records to five minutes.
2. Run in parallel. The application runs on Scaleway, with a certificate, tested via a separate hostname.
3. Switch. Point the record at the load balancer at Scaleway. If there are problems, switch back – the old environment is still running.
4. Clean up. Only tear down the old environment once nothing has reached AWS for a week.

Route 53 doesn’t have to move for this. But if you move the zone to Cloudflare, you can have records set automatically and get a proxy in front. DNS & certificates describes how hosts, records and certificates work together.

How long does the move realistically take?

For a typical SaaS with a web application, an API, a database and two buckets, an unhurried move looks like this:

1. Week 1: Create the cluster, database instance and registry at Scaleway. Build and push images, roll out applications via a test hostname.
2. Week 2: Trial import of the database, first bucket copy. Test the application on Scaleway against the imported data, measure how long the import takes.
3. Week 3: Lower the TTL, announce the maintenance window. In the window: stop writes on AWS, final import, last bucket copy, switch DNS.
4. Weeks 4 to 5: Monitor, keep the old environment running, then tear it down and check the AWS bill.

If you have several applications, move them one after another. The first takes the longest because every question is new; from the second one on, it’s routine.

How Clusterward supports the move

Clusterward manages only the Scaleway side: the cluster, secure by default; the Managed Database with import from RDS (the applications at the target are paused in the meantime); the bucket copy from S3 with a progress display; the registry per cluster; and the hosts with record and certificate. AWS is only read, and only when you import data. The overview of the whole journey is under Moving from AWS, Azure or Google Cloud.

Conclusion

Moving from AWS to Scaleway is not a Kubernetes project but a data project. The clusters are built quickly, and the applications run unchanged. Plan the database cutover with a maintenance window, copy buckets early and once, and switch DNS host by host. Then the move is a series of small, reversible steps instead of a weekend with an uncertain outcome.

Want to talk through your move from AWS? Send us the list of your AWS services. We’ll tell you how each of them runs on Scaleway and where the snags are. Discuss your move →

Sources and further reading

• AWS: IAM roles for service accounts (IRSA) in EKS
• Scaleway: Load Balancers for Kubernetes Kapsule
• Scaleway: Object Storage concepts (endpoints, bucket policies)
• AWS: Amazon S3 pricing (data transfer)