AWS to Scaleway: A Service-by-Service Migration Overview

Originally published on moveinfra.eu.

Migrating from AWS to Scaleway means moving from a sprawling catalog of over 200 proprietary services to a focused, European-owned cloud built on open standards. For most small and mid-sized engineering teams, Scaleway covers the core infrastructure stack directly: virtual machines, managed Kubernetes, managed PostgreSQL and MySQL, Redis-compatible caching, S3-compatible object storage, and even SQS/SNS-compatible messaging. The transition is straightforward for standard web applications and containerized workloads, while architectures heavily tied to AWS-specific services like DynamoDB or Redshift require either refactoring or a phased migration.

Key takeaways

• Direct mappings for core workloads: Compute (EC2 to Instances), containers (EKS to Kapsule), relational databases (RDS to Managed Databases), and storage (S3 to Object Storage) have direct equivalents on Scaleway.
• Built-in protocol compatibility: Scaleway supports the S3 API for storage and implements the AWS SQS and SNS protocols for queuing and messaging, reducing the need to rewrite application code.
• European jurisdiction: Scaleway is a French company (part of the Iliad Group) operating data centers in Paris, Amsterdam, Warsaw, and Milan under EU law.
• Predictable cost structure: Scaleway uses flat, resource-based pricing with free private network traffic, removing the complex per-gigabyte internal routing charges common on AWS.
• Clear boundaries on proprietary tools: AWS-specific services like DynamoDB, Cognito, and Redshift do not have drop-in managed equivalents on Scaleway and require open-source alternatives.

Why European teams move from AWS to Scaleway

For companies of 10 to 300 people, AWS often provides more complexity than the business actually uses. Teams end up paying a premium—both in monthly bills and engineering time—to configure VPC peering, NAT gateways, IAM policy chains, and granular billing alarms.

Scaleway offers a middle ground between bare-bones server hosts and US hyperscalers. Founded in 1999 and headquartered in Paris as a subsidiary of the Iliad Group, Scaleway operates Multi-AZ regions in the European Union, including Paris (fr-par), Amsterdam (nl-ams), and Warsaw (pl-waw). Because it is EU-owned and operated, customer data stays within European jurisdiction without exposure to the US CLOUD Act. In contrast, even the AWS European Sovereign Cloud remains owned by Amazon, a US corporation.

Regulatory requirements also drive the move. The Digital Operational Resilience Act (DORA), which applies from January 17, 2025, requires financial entities and their critical ICT providers to maintain practical exit strategies and avoid concentration risk. Furthermore, under Article 29 of the EU Data Act, cloud switching charges—including data egress fees when moving to another provider—are capped at cost until January 12, 2027, and banned entirely from that date onward.

Service-by-service comparison: AWS to Scaleway

Before moving any workload, you need an accurate map of how your current AWS resources translate to Scaleway products.

Deep dive into key infrastructure areas

Compute and containers

If you run virtual machines on EC2, Scaleway splits its Instances into Development (shared resources for staging and testing) and Production ranges (General Purpose POP2, Compute Optimized COP, and Memory Optimized MOP with dedicated vCPUs). Like AWS, Scaleway separates compute from network-attached Block Storage, allowing you to resize volumes independently.

For teams on Amazon EKS, Scaleway's Kubernetes Kapsule is often the easiest part of the migration. EKS relies heavily on AWS-specific IAM roles for service accounts (IRSA), custom VPC CNI plugins, and ALB Ingress Controllers. Kapsule runs certified, upstream Kubernetes with a free managed control plane. When migrating, you replace AWS-specific annotations on your Ingress and StorageClass manifests with Scaleway's CSI (Container Storage Interface) and Load Balancer annotations, then apply the same deployments.

Relational databases and caching

Scaleway offers Managed Databases for PostgreSQL and MySQL with standalone or High Availability (HA) configurations. An HA cluster provisions a standby node in a separate Availability Zone with synchronous replication.

Moving from RDS or Aurora PostgreSQL/MySQL does not require changing your database schema, provided you are not using proprietary Aurora extensions. The safest migration method is logical replication. You provision the target database on Scaleway, take an initial snapshot of your AWS database, and stream ongoing changes (Write-Ahead Logs in PostgreSQL or binlogs in MySQL) over an encrypted connection until the Scaleway database is in sync.

For caching, AWS ElastiCache maps to Scaleway's Managed Database for Redis. Because cache data is normally transient, most teams simply deploy a new Redis cluster in Scaleway's Private Network and let the application populate the cache after cutover.

Object storage and CDN

Scaleway Object Storage is built on the S3 API. If your application uses boto3, the AWS SDK for JavaScript, or any standard S3 client, you do not need to rewrite your storage logic. You only change the region (for example, fr-par) and the endpoint URL (https://s3.fr-par.scw.cloud) in your client configuration.

Scaleway also includes Multi-AZ redundancy as standard in its main regions and provides archival tiers (Scaleway Glacier) that respond to standard S3 restore commands. For content delivery, Scaleway Edge Services provides caching and custom TLS domains in front of buckets, replacing basic Amazon CloudFront setups.

Networking and security

Networking is where engineers notice the biggest philosophical difference between AWS and Scaleway. On AWS, designing a VPC requires calculating CIDR blocks for public and private subnets across each Availability Zone, configuring route tables, and paying hourly and per-gigabyte fees for NAT Gateways so private instances can reach the internet.

Scaleway simplifies this with VPC and Private Networks. A Private Network is a regional Layer 2/Layer 3 network that spans all Availability Zones in a region. You attach Instances, Kubernetes clusters, Managed Databases, and Load Balancers directly to the Private Network. For outbound internet access from private resources, Scaleway offers a Public Gateway (managed NAT), which is billed at a flat hourly/monthly rate without per-gigabyte processing charges.

Queues, serverless, and application services

Many European cloud providers lack application-level middleware, forcing teams to self-host RabbitMQ or Kafka when leaving AWS. Scaleway is an exception here. Its Queues and Topics and Events services are built as compatible implementations of the AWS SQS and AWS SNS protocols (alongside native support for CNCF NATS). In many cases, you can keep using the AWS SDK in your worker services by pointing the endpoint to Scaleway's messaging API, though you should check Scaleway's documentation for specific SQS parameters your app might rely on.

For serverless workloads, Scaleway provides Serverless Functions (supporting Python, Node.js, Go, PHP, and Rust) and Serverless Containers (comparable to AWS App Runner or Fargate). While the concepts are identical, event payloads and IAM bindings differ from AWS Lambda, so you will need to adapt your function entrypoints and Terraform definitions.

What does not map directly

Being realistic about what Scaleway cannot do is the most important part of migration planning. You will need to rethink your architecture if you rely on:

• Proprietary NoSQL (DynamoDB): Scaleway does not have a managed key-value/document store equivalent to DynamoDB. Teams migrating off DynamoDB typically move the data into PostgreSQL using JSONB columns, or use a managed MongoDB/Cassandra service hosted on EU regions via a third-party provider.
• Cloud Data Warehouses (Redshift): Scaleway does not offer a managed petabyte-scale data warehouse. Teams usually migrate analytical workloads to self-hosted ClickHouse on Scaleway Instances/Kubernetes, or use PostgreSQL with analytical extensions for smaller datasets.
• Complex IAM and Cognito: Scaleway IAM supports users, groups, applications, and policy rules scoped to projects and resource types, which is sufficient for infrastructure access control. However, if you use Amazon Cognito for end-user authentication, you will need to migrate to an open-source identity provider like Keycloak or an EU-hosted auth service.

Practical migration checklist

If you are planning a move from AWS to Scaleway, follow this sequence to keep risk low and rollback options open:

1. Audit your AWS bill and Terraform state: List every active service across all AWS regions. Flag any proprietary services (DynamoDB, Lambda, SQS, Cognito) that need specific compatibility checks.
2. Choose your target Scaleway region: Select Paris (fr-par), Amsterdam (nl-ams), or Warsaw (pl-waw) based on user latency and data residency needs. Verify that all required instance types exist in your chosen Availability Zones.
3. Rebuild infrastructure as code: Write new Terraform or OpenTofu configurations using the official scaleway/scaleway provider. Set up your VPC, Private Networks, Security Groups, and Public Gateways first.
4. Provision and sync stateful stores: Launch Managed PostgreSQL/MySQL and Object Storage buckets. Start continuous logical replication from RDS to Scaleway, and use rclone or a similar checksum-verified tool to sync S3 buckets.
5. Adapt CI/CD pipelines: Update your GitHub Actions or GitLab CI workflows to push container images to Scaleway Container Registry and deploy to your new Scaleway Instances or Kapsule cluster alongside AWS.
6. Test in parallel: Run synthetic traffic and integration tests against the Scaleway environment using staging domains before touching production DNS.
7. Execute the DNS cutover: Lower DNS TTLs ahead of time. During a scheduled maintenance window, pause writes on the AWS application, verify that database replication lag is near zero, promote the Scaleway database to primary, and update your DNS records.
8. Maintain a rollback window: Keep the AWS environment alive (and ideally syncing data back from Scaleway) for two to four weeks before deleting AWS resources and closing the account.

Frequently asked questions

Can I keep using the AWS SDK for S3 and SQS on Scaleway?

Yes. Scaleway Object Storage is compatible with the Amazon S3 API, and Scaleway Queues and Topics/Events implement the AWS SQS and SNS protocols. In most languages, you can continue using the official AWS SDK by overriding the endpoint_url and region parameters and supplying your Scaleway access and secret keys. Always test specific features like S3 lifecycle rules or SQS dead-letter queues in staging first.

How does Scaleway pricing compare to AWS?

Scaleway generally offers lower and more predictable pricing than AWS, particularly on bandwidth and Kubernetes management. The Kubernetes Kapsule control plane is free (you only pay for worker nodes), and egress traffic is significantly cheaper than standard AWS data transfer rates. Because prices vary by instance family and region, check the official Scaleway pricing page for current 2026 list prices.

Does Scaleway support Terraform and OpenTofu?

Yes. Scaleway maintains an official, well-documented provider in the Terraform and OpenTofu registries. You can manage almost all resources—including Instances, Kapsule clusters, Managed Databases, Object Storage buckets, and IAM policies—entirely through code.

How much downtime is required to switch from AWS to Scaleway?

For standard web applications using PostgreSQL, MySQL, and S3, the infrastructure is built and synced while AWS remains live. The actual switch only requires a brief planned write pause—typically a few minutes—to let the final database transactions replicate, run sanity checks, and flip the DNS records.

Sources

• Scaleway Product Documentation
• Scaleway Queues Overview (SQS Compatibility)
• Scaleway Pricing Overview
• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• Regulation (EU) 2022/2554 (DORA) on EUR-Lex

Drafted with AI assistance and fact-checked by the MoveInfra team. The original, kept up to date, is at moveinfra.eu. Free tools for pricing a move to an EU cloud: moveinfra.eu/tools.