Alternatives européennes à AWS.

Une équipe achats allemande qui rédige une analyse d'impact Schrems II, un acheteur public français exigeant SecNumCloud, ou une entreprise SaaS qui cartographie ses dépendances avant le Tech Sovereignty Package de l'UE : toutes finissent par se poser la même question sur AWS, à savoir qui contrôle réellement l'infrastructure. Amazon Web Services, Inc. est une filiale de la société américaine Amazon.com, Inc. (NASDAQ : AMZN), et malgré plusieurs datacenters en région UE et l'European Sovereign Cloud annoncé, cette structure de propriété maintient la juridiction du CLOUD Act. L'appel d'offres cloud souverain UE d'avril 2026 (180 M€, attribués à Scaleway, Clever Cloud, OVH et STACKIT, AWS exclu) est le signal institutionnel le plus net que les acheteurs européens répondent déjà à cette question par des alternatives.

Cette page confronte douze alternatives européennes d'hébergement cloud à AWS sur quatre questions concrètes : à qui appartient juridiquement l'entreprise, où se trouvent physiquement les données, quels sous-traitants touchent la couche opérationnelle, et si la plateforme détient un cadre de conformité européen reconnu comme ISO 27001, BSI C5, EUCS ou SecNumCloud. Chaque ligne remonte au DPA public du fournisseur.

Trois noms à retenir d'emblée : Scaleway (France, Paris ; catalogue de services managés le plus large, lauréat d'une partie de l'appel d'offres cloud souverain UE), Hetzner (Allemagne, Gunzenhausen ; meilleur rapport prix-performance pour les charges compute-intensives), et OVHcloud (France, Roubaix ; le plus grand cloud européen, avec des paliers qualifiés SecNumCloud pour les acheteurs publics français). Les trois sont de propriété européenne et hébergés en UE.

Vos briques de compute, de stockage et de réseau survivent au déménagement à peu près intactes :

• Primitives IaaS (VM, stockage bloc, stockage objet, networking VPC, équilibrage de charge, bases de données managées) ; chaque alternative a des équivalents directs.
• Kubernetes (Scaleway, OVH, IONOS, STACKIT, Exoscale, UpCloud proposent tous du K8s managé).
• Stockage objet compatible S3 avec compatibilité SDK standard.
• Images VM Linux et Windows standard avec support cloud-init.
• Support Terraform / OpenTofu et Pulumi sur tous les principaux clouds européens.
• IPv6, protection DDoS sur la plupart des paliers, options CDN basiques.

Là où la parité s'arrête, c'est sur l'étendue, pas sur les briques de base :

• L'étendue de services managés d'AWS à l'échelle d'AWS : ~250 services AWS, ~50 à 80 services sur les plus grands clouds européens. L'étendue se réduit sur les clouds européens à moindre coût (Hetzner est notoirement minimal côté services managés : compute, stockage, réseau et c'est tout, par choix).
• Produits spécifiques AWS : DynamoDB (utilisez un Postgres managé ou Scaleway Document Database), le catalogue complet de runtimes Lambda (utilisez Scaleway Functions, OVH Functions ou OpenFaaS auto-hébergé), SageMaker (Scaleway et OVH ont des équivalents de plateforme ML mais plus petits).
• Certaines intégrations avec des DevTools de teinte américaine (CodePipeline spécifique AWS, CloudFormation StackSets à l'échelle extrême). La plupart des équipes utilisent Terraform / OpenTofu à la place, qui fonctionne de manière identique sur tous les clouds européens.
• Le catalogue logiciel tiers de l'AWS Marketplace. Les clouds européens ont des marketplaces plus petits ; pour des logiciels d'entreprise de niche, vous pourriez avoir besoin de relations directes avec les fournisseurs plutôt que d'un pull-in via marketplace.

Les migrations AWS vers un cloud européen suivent presque toujours le même schéma en sept étapes, quel que soit le fournisseur choisi.

1. Inventoriez votre usage des services AWS. Utilisez AWS Cost Explorer pour identifier quels services consomment réellement du budget : la plupart des charges SaaS utilisent 5 à 10 services pour 90 % du coût (EC2, S3, RDS, ELB, CloudFront, Route 53). Le long tail correspond généralement aux logs CloudWatch et aux ressources de test oubliées. Migrez l'ensemble à coût élevé ; archivez ou terminez le long tail avant le déménagement.
2. Mappez les services AWS sur les équivalents européens. Construisez le tableau de mapping explicitement : EC2 → Scaleway Instances / Hetzner Cloud / IONOS Compute, S3 → Scaleway Object Storage / OVH Object Storage, RDS → Scaleway Managed PostgreSQL / OVH Managed Databases, CloudFront → Scaleway Edge ou BunnyCDN. Pour chaque service AWS de votre inventaire, choisissez la cible européenne.
3. Recréez votre topologie VPC sur le nouveau cloud. Scaleway, OVH, Hetzner Cloud, IONOS et STACKIT prennent tous en charge des réseaux privés avec routage de sous-réseau équivalent aux VPC AWS. Répliquez votre disposition de sous-réseaux, security groups et règles de routage en code (Terraform/OpenTofu) avant de déplacer la moindre donnée.
4. Mettez en place la réplication des données dans les deux sens pendant la bascule. Pour les bases de données, utilisez la réplication logique (Postgres Logical Decoding, réplication MySQL basée sur GTID) pour streamer les données depuis AWS RDS vers la nouvelle base européenne managée. Pour le stockage objet, utilisez rclone en mode s3-to-s3 pour synchroniser les buckets S3 vers le service compatible S3 européen. Faites tourner les deux en parallèle pendant 2 à 4 semaines pour vérifier la cohérence avant de basculer la couche applicative.
5. Basculez le trafic applicatif via DNS, pas en changeant la configuration applicative. Utilisez des enregistrements DNS pondérés (Route 53 ou l'équivalent de votre fournisseur DNS) pour déplacer le trafic du point de terminaison AWS vers le point de terminaison européen sur une fenêtre de 7 à 14 jours. Cela vous permet de revenir en arrière rapidement si quelque chose casse. La plupart des équipes trouvent une ou deux réponses mises en cache par CloudFront ou des health checks Route 53 à ajuster pendant cette fenêtre.
6. Migrez les fonctions Lambda en services containerisés. Les fonctions Lambda ne peuvent pas être déplacées vers Scaleway Functions ou OVH Functions sans retravail (modèles de cold-start différents, liaisons de sources d'événements différentes). La voie pragmatique : containerisez chaque Lambda en petite image Docker, déployez dans votre nouveau cluster Kubernetes ou vers Scaleway Serverless Containers, et routez via API gateway. La plupart du code Lambda se transfère avec des modifications de wrapper mineures.
7. Gardez AWS actif 90 jours après le dernier service migré. Les migrations AWS ont un long tail de ressources oubliées : un groupe de logs CloudWatch inutilisé mais toujours écrit, une Lambda déclenchée par un topic SNS dont vous aviez oublié l'existence, un bucket S3 avec un ancien export de données. Mettez le compte AWS en pause à dépense zéro, faites tourner AWS Cost Anomaly Detection sur le résiduel, et ne fermez le compte qu'après 90 jours de rapports propres.