For the past year a good share of our cloud work has started with the same conversation. A client's legal team reads up on the CLOUD Act, works out that eu-west-1 is still an American company's data centre, and asks us what it would take to leave. We've written about why an EU region doesn't fix the GDPR problem and about how to plan a sovereign cloud migration. At some point you have to show your own homework.
So in October we moved three of our own production platforms off AWS and onto Scaleway, the French cloud provider owned by Iliad Group. These are the systems the business runs on every day. Time, money, delivery and sales all go through them. Every AWS service they depended on now has a Scaleway counterpart, and their data, files, backups and outgoing email all stay in the Paris region under EU law.
The three platforms
Operations Hub
The Operations Hub is where the company's operational data lives: timesheets and approvals, time off and public holidays, vendor invoices and billing. It's wired into the tools people already use. It syncs work items from Jira, ClickUp and our project management system throughout the working day, feeds the accounting systems, reads a shared mailbox every five minutes to pick up incoming invoices, connects to Google and Microsoft calendars, and uses AI for the document classification work nobody wants to do by hand. It also renders PDF reports on demand. Nine scheduled jobs keep all of this moving, from the five-minute mailbox poll up to a monthly holiday calendar import.
Project management system
Our project management system is where delivery happens. Projects, workflows, tickets, comments, attachments, work logs and search, with single sign-on for staff. It has a public API with per-project tokens that our engineers' AI coding tools use to read and update tickets directly, it receives webhooks from GitHub, it talks to our knowledge base, and it publishes shareable HTML reports on their own domain. Ticket attachments and the published reports both live in object storage.
Video streaming and demo platform
The demo platform is what our sales team puts in front of prospects. It's a gated library of product walkthrough videos. Each client gets their own login, staff sign in with company SSO, and every viewing session is tracked so the account team can see who watched what, on which device and from where. Video streams in chunks over HTTP range requests, so a prospect can jump straight to the part of a long demo they care about.
The ground rules
We agreed on three rules before writing any infrastructure code.
One extra step paid for itself. Before anything went to Scaleway, we ran all three services as plain long-running processes on a temporary host. That proved they worked outside Lambda, and it gave us a staging point between the two clouds that we could fall back to.
Service by service: what replaced what
Here's the full map. Most of it was straightforward. The parts that weren't are worth reading about in the sections that follow.
Lambda to Serverless Containers
Each platform's API now runs as a container on Scaleway Serverless Containers. Our Lambda deployments had been zip bundles, so we added Scaleway's Container Registry and a build step that bundles each service with esbuild into a small Node.js image. The containers keep what we liked about Lambda. They scale with traffic, there are no servers to patch, and we pay for what runs. The two main APIs also keep a warm instance at all times, which means no cold starts for the people using them, and the same image runs on a laptop when we need to reproduce a production issue.
API Gateway to container custom domains
On AWS, API Gateway handled routing, TLS and custom domains. On Scaleway, each API container gets its own custom domain with a managed certificate and HTTPS only. The default public endpoint is switched off, so the custom domain is the only way in. In front of that sits an edge security layer covering what API Gateway throttling and a WAF did before: strict TLS to the origin, rate limits on login endpoints, and a secret header the containers check on every request. Traffic that tries to skip the edge gets refused. The containers also rate-limit their own login routes, so brute-force protection holds at two layers.
Load balancing and scaling
There's no load balancer for us to run. Serverless Containers spreads requests across instances and adds or removes them within limits we set per service. The two busiest APIs always keep one instance warm and can scale out to five. The demo platform scales up to three instances and back down to zero when nobody is watching. The operations container that runs migrations and backups only exists while it's working. When an engineer needs direct database access, we create a load-balanced endpoint for that session and delete it afterwards.
RDS to Managed PostgreSQL
The relational data for the Operations Hub and the project management system moved from RDS to Scaleway's Managed Database for PostgreSQL 16 with high availability turned on. The database has no public endpoint. It sits on a private network with the containers, and that network is the only way to reach it. Each platform connects with its own database role that owns its own schema, so one compromised service can't read its neighbour's data.
Backups run at two levels: Scaleway's automated hourly backups, plus a logical dump every fifteen minutes to a versioned, locked-down bucket. Both are kept for fourteen days. The migration itself was a parallel dump and restore, followed by a check that table and row counts matched on both sides before anything was switched.
DynamoDB
The demo platform kept its viewing analytics and client accounts in two DynamoDB tables. Both moved to Scaleway with a one-off migration that copied every record and compared counts between source and target. Session history for every client came across intact, so the sales team's reporting carried on without a gap.
S3 to Object Storage
This was the easiest part. Scaleway Object Storage speaks the S3 API, so the applications keep using the same AWS SDK they always have, pointed at a Paris endpoint. The buckets for ticket attachments, vendor invoices, the demo media library and the published reports were copied across. One thing to watch: recent AWS SDK versions add integrity checksums to every request by default, and for an S3-compatible service those need to be set to "when required".
Access is tighter than it was before. Each service has its own identity and its own key, and every bucket carries a policy that admits that one service plus the deployment pipeline. A leaked key reaches one bucket.
CloudFront to Edge Services
The web frontends for the Operations Hub and the project management system, and the public reports site, used to be S3 buckets behind CloudFront. They're now Object Storage buckets in website mode behind Scaleway Edge Services pipelines: bucket, cache, managed TLS certificate, custom domain. Two details cost us time. An Edge Services pipeline does nothing until you explicitly set its entry stage, and the error for that is easy to miss. And once a bucket has a policy, Scaleway ignores object-level ACLs, so a public bucket needs an explicit public-read statement in the policy itself.
CloudFront Functions into the service
The demo platform used a CloudFront Function to check a signed session cookie before serving any video. That check now runs inside the service itself, with the same signature scheme.
EventBridge to cron triggers
The nine scheduled jobs that ran on EventBridge rules are now cron triggers on the Operations Hub container. Each trigger calls an internal endpoint with a shared secret and the job name, and the endpoint hands the job to the same scheduled-job handler as before, in the event format it was written for. We picked up something useful on the way: any job can now be rerun by hand with parameters, which helps when a sync needs replaying for a specific day.
SES to Transactional Email
System emails used to go out through SES. They now go through Scaleway Transactional Email over SMTP, from the same sender address.
IAM, VPC and the operations container
IAM roles became Scaleway IAM applications with narrowly scoped policies, one per service. The VPC became a Private Network shared by the containers and the database. Database migrations used to run in a dedicated Lambda. They now run in a small operations container on the private network, which the deployment pipeline calls before rolling out new versions of the apps. The same container takes the fifteen-minute backups and costs nothing while idle.
The cutover
The frontends and the APIs switched separately. The frontends are static files, so a DNS change was all they needed. For the APIs we wrote one cutover script that does four things in order:
The same script has a rollback mode that restarts the old services and points DNS back, so a bad switch would have cost minutes to undo. The write freeze lasted only as long as the final copy. Once traffic was settled on Scaleway, a teardown script removed the temporary host, the cross-account access it had needed, and the old origin DNS records.
What it took
From the first container build to production traffic on Scaleway took about a week of focused engineering. It went that fast for a reason that applies to any migration: these platforms were in good shape for it. They ran on PostgreSQL, used S3 through the standard SDK, and kept their business logic apart from the Lambda plumbing. In the terms of our readiness scoring, they were ready now. A bigger estate with proprietary queues, serverless ETL and hand-built servers takes longer, and our timeline guide explains why. The method stays the same at any size: keep the code still, script everything, rehearse the data copy, and always have a rollback.
Where things stand
All three platforms now run on a cloud provider incorporated in France, in Scaleway's Paris region. Databases, files, backups, container images and outgoing email all sit inside the EU, under EU law. A few third-party services the platforms integrate with are outside that boundary, such as the identity provider our staff sign in with, and they're next on the list. We'd mention that to any client too, because it's the first thing a good auditor asks about.
If you're weighing Scaleway against the other EU options, our provider comparison covers where each one fits.
How Looming Tech can help
This is the work we do for clients: workload assessment, the service-by-service mapping, the infrastructure scripts, the cutover and the cleanup afterwards. We're a registered partner with OVHcloud, STACKIT, Scaleway and T Cloud Public, so the provider choice follows your workloads. If you're running on AWS and your clients, auditors or board have started asking where your data really lives, we're happy to walk you through what we did and what it would look like for you.
Frequently asked questions
Can AWS Lambda functions run on Scaleway without a rewrite?
In most cases, yes. We wrapped our existing Lambda handlers in a small HTTP server that converts requests into Lambda-style events and deployed them to Scaleway Serverless Containers. The business logic stayed exactly as it was.
What replaces Amazon S3 on Scaleway?
Scaleway Object Storage, which is S3-compatible. Applications keep using the AWS SDK with a Scaleway endpoint and credentials. Recent SDK versions need request checksum calculation set to "when required".
What replaces CloudFront and API Gateway on Scaleway?
Scaleway Edge Services serves cached static frontends with managed certificates. APIs run on Serverless Containers with their own custom domains and managed TLS, and the container platform handles load balancing and autoscaling.
How long does an AWS to Scaleway migration take?
Our three platforms took about a week of execution, because they already used PostgreSQL, standard S3 and portable application code. Larger estates with proprietary services and data pipelines typically take six to eighteen months.
Is Scaleway outside the reach of the US CLOUD Act?
Scaleway is a French company owned by Iliad Group, so the CLOUD Act's power to compel US-incorporated providers does not reach it. Check the third-party services in your own stack as well, since data sent to a US-owned SaaS is exposed regardless of where your cloud runs.