AWS exitEU jurisdictionCLOUD Act

Migrating from AWS to a Dutch sovereign cloud

Running your application on AWS and want to bring your data and systems under European jurisdiction? We translate your AWS environment into open alternatives with Dutch sovereign providers: S3 becomes S3-compatible object storage, RDS becomes managed PostgreSQL or MySQL, and Lambda becomes containers. Appfront handles the application adaptation and migration; for the infrastructure, we work with specialist Dutch partners.

Book an advisory call View the process

What is migrating from AWS to a sovereign cloud?

Migrating from AWS to a sovereign cloud means moving your applications, data and infrastructure from Amazon Web Services to a provider that falls entirely under European jurisdiction. The core of the problem: as a US company, AWS is subject to the US CLOUD Act, including in the EU regions of Frankfurt, Amsterdam and Paris, and also within the announced AWS European Sovereign Cloud. Jurisdiction follows the parent company, not the location of the servers. If you want to demonstrably fall under EU law, you need to change provider, not just region.

That requirement is becoming more concrete. The revised Dutch government cloud policy of 3 July 2026 requires storage and processing within the EEA, mandates a risk assessment for each cloud service and an annually tested exit plan, and advises against email and document management in public cloud. In addition, NIS2, DORA and the GDPR set requirements for controlling your digital supply chain. This page focuses specifically on the AWS translation; the general approach is covered on our page on migrating applications to a sovereign cloud.

How we approach this

AWS inventory

We map out your AWS environment: which services you use (S3, RDS, Lambda, SQS, CloudFront), which data flows and IAM policies exist, and which dependencies are embedded in the code.

Service-by-service translation

For each AWS service, we determine the target alternative with a Dutch provider, and we are honest about where no exact equivalent exists and what that means for the application.

Adapting and migrating

We adapt the application, migrate data and configuration, and where possible run in parallel so we can switch over in a controlled way and fall back if needed.

Landing and management

Your environment lands with a Dutch sovereign provider. We then take care of monitoring, maintenance and ongoing development of the application.

What we build and manage

S3 to object storage

S3 buckets move to S3-compatible object storage with an EU provider. The API is largely the same, so code changes remain limited to endpoints, credentials and bucket policies.

RDS to managed Postgres or MySQL

RDS databases migrate to managed PostgreSQL or MySQL, including data migration, user management, replication and backup policy.

Lambda to containers

We rebuild serverless functions as containers on Kubernetes: as a service, a scheduled job or a queue worker. The business logic stays, and the platform becomes open.

SQS and SNS to RabbitMQ or NATS

We translate queues and pub/sub patterns into open alternatives such as RabbitMQ or NATS, with attention to delivery guarantees and retry behaviour.

Rebuilding IAM and networking

IAM roles, VPCs, security groups and secrets do not translate automatically. We redesign the identity and network model according to least privilege.

CloudFront to EU CDN

Static assets and caching move from CloudFront to a European CDN solution, including TLS certificates and cache rules.

What can and cannot be replaced one-to-one

An honest picture up front prevents surprises during the migration. A large part of a typical AWS environment has a mature European or open-source alternative. But some managed services are so specific to AWS that no exact equivalent exists. That functionality does not disappear: we rebuild it in the application layer, using open components that you control yourself.

Easy to replace

Object storage: the S3 API is a de facto standard, which EU providers support
Relational databases: RDS Postgres and MySQL migrate to managed variants
Compute: translating EC2 and ECS/EKS to VMs and Kubernetes
Messaging: SQS/SNS patterns map onto RabbitMQ or NATS
CDN and DNS: European alternatives are available

No exact equivalent

Services such as DynamoDB, Step Functions, Cognito and EventBridge are tightly woven into the AWS platform. For these, we choose a solution in the application layer on a case-by-case basis: DynamoDB patterns, for example, move to PostgreSQL with jsonb, authentication moves to an open identity provider such as Keycloak, and orchestration is rebuilt using open workflow components or explicit application code.

That is more work than a lift-and-shift, but the result is an environment free of hidden dependencies on a single vendor.

For whom

Government and public sector

Organisations subject to the revised Dutch government cloud policy and the BIO that need to bring their AWS workloads within the EEA and under EU jurisdiction.

Healthcare

Institutions processing medical data under NEN 7510 and the GDPR that want to reduce their dependence on a US hyperscaler.

Financial sector

Parties subject to DORA, applicable since 17 January 2025, who need control over ICT third parties and exit scenarios.

NIS2 sectors

Organisations subject to the Cyber Security Act, which takes effect on 15 August 2026, and who want to demonstrably manage their digital supply chain.

Technology and approach

We replace AWS-specific services with open, portable technology, so that your environment does not become locked in to a single vendor again after migration. We document the entire target environment in infrastructure as code, so the build is reproducible and verifiable, including for your exit plan.

Kubernetes / containers

S3-compatible object storage

PostgreSQL / MySQL

RabbitMQ / NATS

Keycloak

Terraform / infrastructure as code

EU CDN

Encryption in transit and at rest

Why Appfront

Appfront is an independent software and app agency. We know both the AWS side and the open alternatives, and when exiting AWS, adapting the application is the real challenge: moving the infrastructure is rarely the problem, but the entanglement of your code with AWS services often is. Because we do not sell hosting ourselves, our advice on the landing platform is not coloured by a platform of our own.

Application adaptation and migration under one roof
Independent advice on Dutch sovereign providers
Honest about what can and cannot be replaced one-to-one
Open standards and infrastructure as code as the foundation

Related services

If you are not moving from AWS but from another cloud, see migrating applications to a sovereign cloud or cloud exit and repatriation. If you want to set up a new environment that is sovereign, see building a sovereign cloud. To help choose a landing zone, our overview of the best sovereign cloud providers in the Netherlands is a useful starting point.

Frequently Asked Questions

Can we replace AWS one-to-one with a Dutch cloud?

Largely, but not entirely. Core services such as object storage, managed databases, containers and message queues have mature European or open source alternatives. For some managed services, such as DynamoDB or Step Functions, no exact equivalent exists; we resolve that functionality in the application layer using open components. We identify this per service in the migration plan beforehand.

Our data is already in an EU region of AWS. Isn't that sufficient?

No, not if EU jurisdiction is the requirement. As an American company, AWS falls under the US CLOUD Act, which allows the US government to demand access to data, even if that data is physically located in Frankfurt or Amsterdam. Jurisdiction follows the parent company, not the region where your data is stored.

What happens to our S3 buckets and RDS databases?

S3 data moves to S3-compatible object storage with a European provider; because the API is largely identical, changes to your code remain limited to endpoints and credentials. We migrate RDS databases to managed PostgreSQL or MySQL, including data migration, users and backup policy.

What do you do with our Lambda functions?

We rebuild Lambda functions as containers running on Kubernetes or a comparable platform, whether as a service, a scheduled job or a queue worker. The business logic stays intact; we reconfigure the invocation and scaling mechanisms using open components.

Does Appfront provide the infrastructure itself?

No. Appfront is a software and app agency. We handle the application adaptation and the migration; for the infrastructure itself we work with specialist Dutch providers and advise independently on which party suits your requirements.

Why is an exit plan relevant to this migration?

The revised Dutch government cloud policy of 3 July 2026 requires public sector organisations to carry out a risk assessment and maintain an annually reviewed exit plan for public cloud. An AWS migration is, in effect, the execution of such an exit plan. Beyond the public sector, supervisors and NIS2 increasingly ask for demonstrable exit scenarios too.

Getting started with your AWS migration

Would you like to know what is involved in moving your AWS environment to a Dutch sovereign cloud? We are happy to review your services with you, without obligation, and give you an honest picture of the work involved.

Book an advisory call Explore building a sovereign cloud