Alternatives européennes à AWS.

AWS est la plateforme d'hébergement cloud dominante à l'échelle mondiale et le choix par défaut d'une génération d'entreprises SaaS — et c'est aussi un produit constitué aux États-Unis (Amazon Web Services, Inc., filiale d'Amazon.com, Inc., NASDAQ : AMZN), et malgré plusieurs datacenters en région UE et l'European Sovereign Cloud annoncé, la structure de propriété signifie que la juridiction du CLOUD Act s'applique. Pour une équipe achats allemande qui rédige une analyse d'impact Schrems II, un acheteur public français exigeant SecNumCloud, ou tout SaaS européen planifiant pour les implications du Tech Sovereignty Package de mai 2026, le profil de propriété est ce qui pousse les acheteurs à évaluer des alternatives. L'appel d'offres cloud souverain UE d'avril 2026 (180 M€ attribués à Scaleway, Clever Cloud, OVH et STACKIT, avec AWS délibérément exclu) est le signal institutionnel auquel les équipes achats européennes répondent.

Cette page cartographie les douze alternatives européennes d'hébergement cloud que nous avons vérifiées face à AWS sur les critères qui comptent réellement pour un acheteur : à qui appartient juridiquement l'entreprise, où se trouvent physiquement les données, quels sous-traitants traitent la couche opérationnelle, et si la plateforme détient un cadre de conformité européen reconnu (ISO 27001, BSI C5, EUCS, SecNumCloud). Le score de conformité est éditorial, jamais payé, et chaque ligne est sourcée au DPA public du fournisseur. Nous re-vérifions chaque trimestre.

Si vous n'avez que dix minutes : Scaleway est la meilleure adéquation pour les charges SaaS modernes avec le catalogue de services managés le plus large (France, Paris, 5/5, lauréat de l'appel d'offres cloud souverain UE), Hetzner est le choix prix-performance le plus solide pour les charges compute-intensives (Allemagne, Gunzenhausen, 5/5), et OVHcloud est le plus grand cloud européen avec des paliers qualifiés SecNumCloud pour les acheteurs publics français (France, Roubaix, 5/5).

Ce que vous gardez en passant d'AWS à un cloud européen :

• 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.

Ce que vous lâchez :

• 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.

Un plan de migration pratique en sept étapes que la plupart des clouds européens accepteront.

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.