AWS to OVHcloud: planning the move

Moving from AWS to OVHcloud is a practical route for European companies that want to bring their cloud infrastructure under EU jurisdiction while keeping managed services like Kubernetes, relational databases, and S3-compatible object storage. A successful migration requires mapping your AWS resources to OVHcloud Public Cloud equivalents, rebuilding your network and compute layer using Infrastructure as Code, syncing data continuously via logical replication, and switching DNS traffic during a brief, planned write pause. Most standard web applications, container clusters, and relational databases map directly between the two platforms, though proprietary AWS services like DynamoDB or SQS must be replaced with open-source alternatives during the transition.

Key takeaways

Direct service mapping for core workloads: OVHcloud Public Cloud provides direct equivalents for EC2, RDS (PostgreSQL and MySQL), S3, EKS, and ElastiCache (via managed Valkey/Redis).
Open standards under the hood: OVHcloud builds its Public Cloud on OpenStack and CNCF-certified vanilla Kubernetes, which makes it straightforward to manage via Terraform and standard APIs.
More predictable bandwidth costs: Unlike AWS, which charges per gigabyte for internet egress, OVHcloud includes incoming and outgoing public network traffic in the base price of its Public Cloud instances and Managed Kubernetes worker nodes.
Switching fees are regulated: Under Article 29 of the EU Data Act, AWS can charge no more than its direct cost for data egress when you switch providers until 12 January 2027, after which switching fees are banned entirely.
Proprietary services require refactoring: If your architecture relies heavily on AWS Lambda, DynamoDB, or CloudFormation, you will need to adapt those components to open standards before or during the move.

Why European companies move from AWS to OVHcloud

For companies with 10 to 300 employees, the decision to leave AWS for a European provider usually comes down to two factors: legal jurisdiction and cost predictability.

Jurisdiction and compliance

AWS operates several data center regions inside the European Union, as well as the AWS European Sovereign Cloud. While these options keep data and day-to-day operations inside the EU, Amazon remains a US parent company subject to extraterritorial US laws, such as the CLOUD Act.

OVHcloud is headquartered in Roubaix, France, and is subject to European and French law. For companies in regulated industries, or those dealing with public-sector procurement and strict enterprise vendor assessments, hosting on an EU-owned cloud simplifies compliance. Furthermore, for financial entities subject to the Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554), which has applied since 17 January 2025, having a tested exit strategy away from dominant ICT providers is a regulatory requirement.

Cost structure and egress

AWS pricing is highly granular. While base compute and storage prices are clear, monthly bills often grow unpredictable due to charges for NAT Gateways, cross-Availability Zone (AZ) data transfer, and public internet egress.

OVHcloud structures its pricing around bundled resources. On OVHcloud Public Cloud, standard public bandwidth (both ingress and egress) and private network traffic over vRack are included in the monthly or hourly price of compute instances. Similarly, the OVHcloud Managed Kubernetes Service (MKS) Free plan provides the cluster control plane at no charge, meaning you only pay for the underlying worker node instances, block storage, and load balancers. (OVHcloud also offers a paid MKS Standard plan with higher SLA guarantees and 3-AZ deployment options; check the official OVHcloud pricing page for current 2026 rates.)

Mapping AWS services to OVHcloud equivalents

Before moving any workloads, you need an accurate inventory of what you run on AWS and how each component translates to OVHcloud. Most infrastructure falls into OVHcloud’s “Public Cloud” product line, rather than their traditional bare-metal dedicated servers or VPS offerings.

AWS Service	OVHcloud Public Cloud Equivalent	Migration Notes
EC2	Public Cloud Instances	General purpose (`b3`), CPU-optimized (`c3`), and RAM-optimized (`r3`) flavors available.
VPC & Private Subnets	vRack & Private Networks	vRack connects Public Cloud instances, Kubernetes, and bare metal over private VLANs.
Security Groups	OpenStack Security Groups	Stateful firewall rules managed via the OVHcloud API or OpenStack CLI/Terraform.
EBS (Elastic Block Store)	Block Storage (Cinder)	High-speed and classic volume types attached to instances or mounted as Kubernetes Persistent Volumes.
S3	Object Storage	S3-compatible API supporting standard tools like `rclone`, AWS CLI, and standard SDKs.
RDS (PostgreSQL / MySQL)	Public Cloud Databases	Managed databases with automated backups and high-availability node options.
ElastiCache (Redis/Valkey)	Public Cloud Databases for Valkey	Managed in-memory caching compatible with Redis clients.
EKS	Managed Kubernetes Service (MKS)	CNCF-certified vanilla Kubernetes; uses Octavia Load Balancers and Cinder CSI storage.
ALB / NLB	Public Cloud Load Balancer	Managed OpenStack Octavia load balancers supporting HTTP/HTTPS and TCP traffic.
SQS / SNS	Managed Kafka or self-hosted RabbitMQ	OVHcloud offers managed Kafka, or you can run RabbitMQ/NATS on Kubernetes or VMs.
DynamoDB	Managed MongoDB or PostgreSQL	Requires data model migration; no direct drop-in replacement for DynamoDB’s proprietary API.

Architectural differences to plan for

While the service table shows strong parity for standard stacks, the underlying mechanics of AWS and OVHcloud differ in several ways that affect your engineering team.

1. Region topology (1-AZ vs. 3-AZ)

In AWS, every region consists of at least three Availability Zones by default, and architectures are built around multi-AZ subnets from day one. OVHcloud historically built its Public Cloud regions (such as Gravelines GRA and Strasbourg SBG in France, or Limburg LIM in Germany) as single-datacenter locations, oftenwith multiple independent rooms on the same campus.

However, OVHcloud has expanded its multi-availability-zone footprint, offering 3-AZ region deployments (starting with the Paris region) for Public Cloud and Managed Kubernetes Standard. When planning your move, check which specific services and database engines are available in your chosen OVHcloud region, and decide whether your availability requirements call for a 3-AZ region or multi-region replication.

2. IAM and API credentials

AWS relies on a single, unified IAM system across every service, allowing fine-grained role assumption (such as IAM Roles for Service Accounts in EKS).

OVHcloud uses a two-layer API structure for its Public Cloud:

The OVHcloud API: Used for account management, billing, vRack creation, Managed Kubernetes cluster provisioning, and Managed Databases.
The OpenStack API: Because OVHcloud Public Cloud runs on OpenStack, low-level resources like compute instances, security groups, block storage volumes, and S3 object storage credentials can be managed directly through standard OpenStack APIs.

In Terraform, it is common practice to configure both the ovh provider and the openstack provider side by side. This also means your applications cannot rely on AWS-specific IAM instance profiles; instead, you will pass standard S3 access keys or database connection strings via environment variables or Kubernetes secrets.

3. Networking and vRack

In AWS, a VPC is a software-defined network isolated to a single region. In OVHcloud, private networking is built on vRack (Virtual Rack). vRack allows you to create isolated Layer 2/Layer 3 private networks that can span across multiple OVHcloud data centers and even bridge Public Cloud virtual instances with dedicated bare-metal servers.

When translating an AWS VPC to OVHcloud, you will attach a vRack to your Public Cloud project, define private networks (subnets) with DHCP enabled, and deploy an OpenStack Gateway instance (which acts similarly to a combined AWS Internet Gateway and NAT Gateway) so private worker nodes can reach the outside internet.

Step-by-step migration plan

To avoid extended downtime or data loss, treat the migration as a parallel build followed by a controlled cutover, rather than a manual “backup and restore” weekend project.

Step 1: Audit your bill and inventory resources

Start by pulling your last three months of AWS bills and inspecting your live environment. List every active EC2 instance, RDS cluster, S3 bucket, load balancer, and DNS zone.

Pay special attention to hidden dependencies:

Are your applications using AWS SES for transactional email? (You can keep SES while hosting compute on OVHcloud, or switch to an EU email provider.)
Are you using AWS KMS or Secrets Manager?
Are images stored in Amazon ECR?

Step 2: Rebuild the infrastructure as code

Do not click through the OVHcloud Control Panel to build production environments. Translate your existing Terraform, OpenTofu, or CloudFormation templates into Terraform modules using the ovh and openstack providers.

Provision the foundational layer first:

vRack, private subnets, and routing gateways.
Security groups mirroring your AWS ingress/egress rules.
Managed Kubernetes clusters or compute instances matching your current vCPU and RAM sizing.
Empty Managed PostgreSQL/MySQL databases and S3-compatible Object Storage buckets.

Step 3: Set up continuous data synchronization

Moving gigabytes or terabytes of data takes time. Instead of stopping your application to take a snapshot, synchronize data while the AWS environment remains live:

Object Storage: Use a tool like rclone to copy objects from AWS S3 to OVHcloud Object Storage. Run an initial bulk sync, followed by periodic incremental syncs with checksum verification enabled.
Relational Databases: Configure logical replication between AWS RDS and OVHcloud Public Cloud Databases. For PostgreSQL, use native CREATE PUBLICATION and CREATE SUBSCRIPTION after loading an initial schema and base backup. For MySQL, configure binlog replication from the AWS source to the OVHcloud replica.

Keep this replication running until replication lag drops to near zero.

Step 4: Point your CI/CD pipelines

Update your GitHub Actions, GitLab CI, or ArgoCD pipelines to deploy your application code to the new OVHcloud environment alongside AWS. Verify that container images pull cleanly, environment variables and secrets are mounted properly, and internal services can communicate over the vRack private network. Run end-to-end tests against the OVHcloud staging URL or load balancer IP before routing real user traffic.

Step 5: Execute the cutover and keep a rollback path

Twenty-four hours before your planned switch, lower the TTL (Time to Live) on your DNS records (in Route 53, Cloudflare, or your DNS provider) to 60 seconds.

At the scheduled cutover window:

Put your application into maintenance mode or pause database writes on the AWS side.
Wait until database replication lag reaches zero (typically under 5 seconds once writes stop) and run a final rclone pass on object storage.
Promote the OVHcloud database to primary (standalone writable).
Update your DNS records to point to the OVHcloud Load Balancer IPs.
Re-enable writes on the OVHcloud environment.

For critical workloads, configure reverse logical replication from OVHcloud back to AWS for the first two to four weeks. Leaving the old AWS environment running (or scaled down with synced data) gives you a reliable rollback option before you permanently delete your AWS resources.

Planning checklist: AWS to OVHcloud

Use this checklist with your engineering and operations team before scheduling a cutover date:

EU Data Act fee waiver requested: If you are transferring significant data volume out of AWS, submit an exit switching request under the AWS EU Data Act Addendum in advance to have switching egress fees reduced or waived.
Region and AZ requirements verified: Confirm whether a standard OVHcloud region (GRA, SBG, LIM, BHS) or a 3-AZ region (PAR) matches your resilience needs and supports all required managed services.
Quota limits raised: New OVHcloud Public Cloud projects have default OpenStack quotas for vCPUs, RAM, and instances. Request quota increases via OVHcloud support before running your Terraform apply.
S3 SDK compatibility tested: Ensure your application’s S3 client libraries support custom endpoint URLs and path-style or virtual-hosted-style addressing as used by OVHcloud Object Storage.
Database extensions checked: Compare installed PostgreSQL extensions or MySQL plugins on AWS RDS against the supported extensions list in OVHcloud Public Cloud Databases.
SSL/TLS certificates provisioned: If you use AWS Certificate Manager (ACM) attached to an ALB, plan to replace it with Let’s Encrypt (cert-manager on Kubernetes) or imported certificates on the OVHcloud Load Balancer, as ACM certificates cannot be exported.

Frequently asked questions

Can I keep using S3 tools and SDKs with OVHcloud Object Storage?

Yes. OVHcloud Object Storage supports the standard S3 API. You can continue using the official AWS SDKs (such as boto3 for Python or @aws-sdk/client-s3 for Node.js), the AWS CLI, and backup tools like restic or velero. You only need to change the endpoint URL, region identifier, and access credentials in your application configuration.

Does AWS charge egress fees when I migrate to OVHcloud?

Under Article 29 of the EU Data Act (Regulation (EU) 2023/2854), cloud providers may charge no more than direct costs for switching-related data egress until 12 January 2027, and must remove switching charges completely from 12 January 2027 onward. AWS provides a formal process under its EU Data Act Addendum to request reduced or waived data transfer fees when switching to another provider. Note that you must apply to AWS Support prior to migrating the data, and standard fees still apply if you keep running a permanent multi-cloud setup rather than completing a switch.

What happens to my AWS ACM SSL certificates during the move?

Public SSL/TLS certificates generated through AWS Certificate Manager (ACM) are bound to AWS services like Elastic Load Balancing and CloudFront and cannot be exported. When moving to OVHcloud, you will need to issue new certificates—typically by automating Let’s Encrypt via cert-manager on Kubernetes or ACME clients on your load balancers—prior to switching your DNS records.

How long does a typical AWS to OVHcloud migration take?

For a small to mid-sized company running standard virtual machines, a managed Kubernetes cluster, PostgreSQL/MySQL, and S3 storage, the end-to-end process typically takes two to four weeks of calendar time. Most of that time is spent writing and testing the Terraform code, verifying CI/CD deployments, and letting initial database and storage replication complete in the background. The actual cutover window usually requires only a few minutes of paused writes.

How MoveInfra can help

MoveInfra automates the infrastructure transition from AWS to EU-owned clouds, including OVHcloud. You start by uploading your cloud bill for a free inventory and fixed-price quote, after which MoveInfra rebuilds your environment on OVHcloud as clean Terraform code, syncs your databases and object storage with live replication, and helps your team point your CI/CD pipelines to the new setup. Once replication lag is under five seconds, we coordinate the DNS switch during a brief write pause and maintain 30 days of reverse replication so you always have a safe rollback option.