EU-owned equivalents of AWS services: S3, RDS, EKS, Lambda and more

Originally published on moveinfra.eu.

European cloud providers offer direct, open-standard equivalents for the core AWS services that most applications actually run on: virtual machines (EC2), managed relational databases (RDS), S3-compatible object storage, load balancers, private networks (VPC), managed Kubernetes (EKS), and in-memory caches (ElastiCache). On UpCloud, Scaleway, and OVHcloud, you can replace these core building blocks with managed services that work with the same open protocols and Terraform workflows. Hetzner covers compute, networks, load balancers, and object storage, while databases and Kubernetes must be run on cloud servers. The real gaps appear when an architecture relies on AWS-specific services: serverless functions (Lambda) and queues (SQS/SNS) require some adjustments on most European providers, and proprietary data services like DynamoDB and Redshift have no direct managed equivalent on these four EU clouds.

Key takeaways

• Core infrastructure maps one-to-one: EC2, S3, VPC, and Elastic Load Balancing have direct equivalents across UpCloud, Scaleway, Hetzner, and OVHcloud.
• Managed databases and Kubernetes are widely available: UpCloud, Scaleway, and OVHcloud offer managed PostgreSQL, MySQL, Redis/Valkey, and CNCF-certified Kubernetes. Hetzner does not offer managed databases or managed Kubernetes, so teams run them on virtual machines.
• S3 compatibility is standard: All four EU providers support the S3 API for object storage, meaning existing application code and SDKs usually only need a new endpoint URL and credentials.
• Serverless and messaging need a closer look: Scaleway is the only provider in this group with native serverless functions and SQS/SNS-compatible queues. On the others, workloads typically move to containers or self-hosted message brokers like NATS or RabbitMQ.
• Proprietary AWS databases have no drop-in replacement: DynamoDB and Redshift do not have direct equivalents on these providers and require re-platforming to open-source engines like PostgreSQL or ClickHouse before or during a move.

AWS to EU cloud service mapping

For a complete, interactive directory that also includes Google Cloud, Azure, and DigitalOcean, see our free EU Cloud Service Map. The table below covers the twelve most common AWS infrastructure categories across UpCloud, Scaleway, Hetzner, and OVHcloud.

Core infrastructure: compute, networks, and storage

For standard web applications, SaaS backends, and APIs, the foundation of an AWS account is EC2, VPC, Elastic Load Balancing, and S3. This layer is the easiest to move because the underlying concepts are identical across clouds.

Virtual machines (EC2) and networking (VPC)

AWS EC2 instances map directly to Cloud Servers on UpCloud and Hetzner, Instances on Scaleway, and Public Cloud Instances on OVHcloud. All four providers offer both shared-CPU plans for general workloads and dedicated-CPU plans for production databases and compute-heavy services, backed by local NVMe or network block storage.

Networking follows the same isolation model as an AWS VPC, though with fewer moving parts. On AWS, setting up a private network requires configuring VPCs, public and private subnets, route tables, internet gateways, and often costly NAT Gateways. On UpCloud (SDN private networks), Scaleway (VPC and Private Networks), Hetzner (Networks), and OVHcloud (vRack private networks), private L2/L3 networks connect your servers across the project with far simpler routing. Stateful firewalls and security groups attach directly to servers or network interfaces to restrict traffic by IP, port, and protocol, matching the behavior of AWS security groups.

Load balancers (ALB and NLB)

Elastic Load Balancing (Application Load Balancers and Network Load Balancers) maps to managed load balancers on every provider in this list. They handle TLS termination, HTTP/HTTPS routing, TCP forwarding, and health checks. If you run Kubernetes, installing an ingress controller like Envoy, NGINX, or Traefik inside the cluster automatically provisions and configures the provider's native load balancer via their Cloud Controller Manager, just as the AWS Load Balancer Controller does on EKS.

Object storage (S3)

Amazon S3 is both an AWS product and the de facto industry standard API for object storage. UpCloud Managed Object Storage, Scaleway Object Storage, Hetzner Object Storage, and OVHcloud Object Storage all implement the S3 API.

For most engineering teams, this means you do not have to rewrite your storage code. You continue using boto3 in Python, @aws-sdk/client-s3 in Node.js, or the AWS SDK for Go, and you change the endpoint URL and region in the client configuration. Standard features like bucket policies, pre-signed URLs, multipart uploads, and lifecycle expiration rules are supported across the board.

The differences show up only if you use AWS-specific S3 extensions. If your application triggers Lambda functions directly from S3 object-creation events, uses S3 Object Lambda, or relies on AWS KMS keys tied to IAM roles for server-side encryption, you will need to move that logic into your application layer instead of relying on the storage bucket to trigger it.

Databases, caches, and Kubernetes

Moving stateful workloads and container orchestration requires deciding whether you want a fully managed control plane or prefer to run the software yourself on cheaper compute.

Managed PostgreSQL and MySQL (RDS and Aurora)

If you run PostgreSQL or MySQL on Amazon RDS, or if you use provisioned Amazon Aurora with PostgreSQL or MySQL compatibility, you have direct managed equivalents on UpCloud, Scaleway, and OVHcloud. These managed database services handle automated daily backups, point-in-time recovery, minor version patching, and high-availability failover across multiple nodes. Because the underlying database engine is standard open-source PostgreSQL or MySQL, data can be kept in live sync from RDS to the European cloud using native logical replication during a migration.

Hetzner is the exception here. Hetzner does not offer a managed database service. Teams moving to Hetzner run PostgreSQL or MySQL directly on Cloud Servers, typically using automation tools like Ansible or Terraform, alongside open-source backup tools such as pgBackRest or Wal-G writing to object storage.

Redis-compatible caches (ElastiCache)

Following Redis's licensing changes in 2024, several European providers adopted Valkey, the Linux Foundation's open-source fork of Redis that remains drop-in compatible with existing Redis clients. UpCloud offers Managed Valkey, Scaleway offers Managed Redis, and OVHcloud offers Managed Databases for Caching. Hetzner users deploy Valkey or Redis directly on Cloud Servers. Because caches normally hold ephemeral session data or temporary query results, replacing ElastiCache is usually a matter of pointing your application's connection string to the new cluster.

Kubernetes (EKS)

Amazon EKS is notoriously complex because of how deeply it ties Kubernetes into AWS IAM, VPC CNI networking, and EC2 auto-scaling groups. By contrast, UpCloud Managed Kubernetes, Scaleway Kubernetes Kapsule, and OVHcloud Managed Kubernetes Service (MKS) provide standard, CNCF-certified Kubernetes clusters that feel much closer to upstream Kubernetes. You get a managed control plane, automated node pool upgrades, CSI drivers for persistent block volumes, and load balancer integration.

If your workloads are already packaged as Helm charts or standard Kubernetes manifests, moving from EKS to UpCloud, Scaleway, or OVHcloud mainly involves replacing AWS-specific annotations (such as IAM Roles for Service Accounts or ALB ingress annotations) with standard Kubernetes equivalents like cert-manager and a standard ingress controller. Once again, Hetzner does not offer a managed Kubernetes service, so teams using Hetzner run self-managed distributions like k3s or Talos Linux on Hetzner Cloud Servers.

Where you need to adapt: queues, serverless, and DNS

Not every AWS service has a one-to-one clone on every European provider. When you move beyond VMs, databases, and Kubernetes, you occasionally have to adjust how a component is deployed.

Queues and messaging (SQS and SNS)

Amazon SQS and SNS are simple, serverless message queues and pub/sub topics. If you want an exact API replacement, Scaleway offers Queues and Topics, which implements the SQS and SNS protocols directly.

UpCloud, Hetzner, and OVHcloud do not have an SQS-compatible API service. On OVHcloud, you can use Managed Kafka for high-throughput event streaming, or run RabbitMQ on servers. On UpCloud and Hetzner, teams typically replace SQS and SNS by running lightweight, open-source message brokers like NATS (with JetStream) or RabbitMQ on virtual machines or inside their Kubernetes cluster, or by moving background jobs to a Redis/Valkey-backed queue such as BullMQ, Sidekiq, or Celery.

Serverless functions (Lambda)

AWS Lambda encourages building applications as dozens of small, event-driven functions wired together with API Gateway and IAM. Among the four providers covered here, only Scaleway offers native Serverless Functions and Serverless Containers (built on Knative) that scale down to zero.

On UpCloud, Hetzner, and OVHcloud, there is no native Function-as-a-Service product. In practice, teams migrating off Lambda package their function code into lightweight HTTP containers and run them as deployments on Managed Kubernetes (UpCloud, OVHcloud) or as containers on cloud servers (Hetzner). For scheduled cron jobs that used to run on EventBridge and Lambda, Kubernetes CronJobs or systemd timers on a VM replace them cleanly.

DNS (Route 53)

Standard DNS hosting is available via Scaleway Domains and DNS, Hetzner DNS, and OVHcloud DNS. UpCloud does not operate its own public authoritative DNS service, so UpCloud customers use an external European DNS provider (or keep DNS on a dedicated DNS host). If you rely on Route 53 for standard A, AAAA, CNAME, and TXT records, migrating is a straightforward zone file export and import. If you rely on Route 53 latency-based routing or health-check failover, make sure your chosen DNS provider supports traffic steering before moving the zone.

The hard gaps: DynamoDB and Redshift

It is important to be upfront about where European cloud catalogs stop. Neither UpCloud, Scaleway, Hetzner, nor OVHcloud offers a direct managed equivalent to Amazon DynamoDB or Amazon Redshift.

If your application is built heavily on DynamoDB's single-table design, DynamoDB Streams, or IAM-scoped item permissions, you cannot simply lift and shift that database to an EU cloud. Most teams with modest DynamoDB workloads (under a few hundred gigabytes and predictable query patterns) migrate that data into PostgreSQL using jsonb columns and indexed keys. Teams with massive, high-throughput key-value needs either look at self-hosting ScyllaDB or Cassandra on NVMe instances, or keep that specific component separate until they can refactor the data layer.

Similarly, if you run analytical workloads on Amazon Redshift, there is no drop-in managed Redshift service on these providers. Teams typically replace Redshift by deploying an open-source analytical database like ClickHouse on dedicated cloud servers, or by using PostgreSQL with columnar extensions if the dataset fits on a single large node.

If you want to know exactly which AWS services your codebase and Terraform state depend on before planning a move, you can run our free, open-source cloud lock-in scanner from our free cloud migration tools page, or upload a billing export to the Cloud Bill Analyzer to compare your current AWS spend against EU cloud list prices.

Checklist: auditing your AWS architecture for an EU move

Use this five-step checklist to see how cleanly your current AWS environment maps to an EU cloud:

1. List your stateful stores: Check whether your data lives in RDS (PostgreSQL/MySQL), ElastiCache, and S3, or if you have dependencies on DynamoDB, Aurora Serverless, or Redshift.
2. Check how you use S3: Verify that your app talks to S3 via standard SDK methods (GetObject, PutObject, pre-signed URLs) rather than triggering AWS Lambda functions directly from bucket events.
3. Inspect your compute layer: Determine whether your apps run on EC2, ECS, or EKS (which map cleanly to VMs and Kubernetes) or if your core API is built entirely out of Lambda functions and API Gateway.
4. Decide between managed services and raw compute: If you want managed PostgreSQL and managed Kubernetes, shortlist UpCloud, Scaleway, or OVHcloud. If your team prefers managing its own databases and Kubernetes clusters on bare VMs for lower raw compute prices, include Hetzner.
5. Review IAM coupled into application code: Look for places where your application uses AWS STS or IAM roles to authenticate between internal services, and plan to replace them with standard service accounts, mTLS, or environment credentials.

Frequently asked questions

Can I keep using my existing S3 code when moving to an EU cloud?

Yes, in most cases. UpCloud, Scaleway, Hetzner, and OVHcloud all provide S3-compatible object storage APIs. You can keep using the official AWS SDKs (such as boto3 or the AWS SDK for JavaScript) by changing the configured endpoint URL, region name, and access keys. You only need to change code if you rely on AWS-only features like S3 event notifications tied to Lambda or IAM-based bucket access.

What about the AWS European Sovereign Cloud?

The AWS European Sovereign Cloud keeps data residency and day-to-day operations inside the European Union, which helps with physical location requirements. However, it is still owned by Amazon, a US corporation, and runs the same proprietary AWS services and pricing structure. If your goal is to avoid US legal jurisdiction (such as the US CLOUD Act), reduce cloud bills, or move onto open-standard infrastructure, an EU-owned provider is a different category of choice.

How do I replace AWS IAM on a European cloud?

European clouds do not attempt to replicate the thousands of granular resource permissions in AWS IAM. Instead, they offer project-level access control and API tokens for managing infrastructure, while application-level authentication is handled using standard protocols: database usernames and passwords, dedicated S3 access keys per bucket, Kubernetes RBAC, and OpenID Connect (OIDC).

Do I have to pay AWS data egress fees when I move my S3 buckets and RDS databases?

Under the EU Data Act (Regulation (EU) 2023/2854), cloud switching charges, including data egress fees when moving to another provider, cannot exceed the provider's direct cost and are banned entirely from 12 January 2027. In addition, AWS already offers a waiver for data transfer out when you move all your data off AWS or off a specific AWS service after contacting AWS Support, as well as switching terms under the AWS EU Data Act Addendum. Always check the current AWS documentation before starting a large data transfer.

Sources

• Regulation (EU) 2023/2854 (EU Data Act) on EUR-Lex
• UpCloud Documentation: Products and Guides
• Scaleway Documentation
• Hetzner Documentation
• OVHcloud Documentation

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.