Alternative UE-uniquement à AWS.

Amazon Web Services est le cloud public original - et le problème Schrems II original. Les mêmes régions UE qui rendent AWS techniquement utilisable pour les charges de travail européennes ne changent pas la juridiction de la maison mère : AWS Inc. est une société du Delaware, AWS EMEA SARL est une filiale luxembourgeoise entièrement contrôlée par elle, et le CLOUD Act s'applique aux deux. Pour les charges de travail auditées, les secteurs réglementés et toute entreprise à qui un client a déjà demandé « votre fournisseur est-il assujetti à une citation à comparaître américaine ? », la réponse honnête pour AWS est oui. Voici la feuille de route au niveau ingénierie pour en sortir.

États-Unis Stack de remplacement, UE uniquement 14 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: AWS
Siège: Seattle, WA
Juridiction: États-Unis
Régime juridique: CLOUD Act, FISA 702, EO 12333

Une "région UE" n'est pas la souveraineté. Quatre questions tranchent.

La résidence des données indique où se trouvent les bits. La souveraineté indique quel système juridique peut en imposer l'accès. La réponse doit tenir sur les quatre points, sinon la stack n'est pas souveraine.

Résidence

Où les données sont-elles physiquement stockées ?

Pas "dans le cloud" : quel centre de données, dans quel pays, sous quelle juridiction.

Sous-traitants

Qui d'autre est dans votre chemin de données ?

Chaque fournisseur qui touche les données : le CDN, le relais e-mail, le tracker d'erreurs, le pipeline analytics.

Juridiction

Quelles lois peuvent contraindre à la divulgation ?

Un fournisseur dont le siège est aux États-Unis relève de la FISA 702 et du CLOUD Act, même si les données se trouvent à Francfort.

Garde des clés

Qui détient réellement les clés de chiffrement ?

Si le fournisseur cloud détient à la fois les données et les clés, il peut les lire, quel que soit le DPA.

Échoue AWS · Azure · GCP · Région UE

Échoue sur la juridiction et la garde des clés.

Bits en UE, maison mère américaine, sous-traitants américains dans le chemin par défaut, clés gérées par le fournisseur.

Réussit Stack géré par Binadit

Réussit sur les quatre.

Hébergé en UE sur une infrastructure au siège européen. Zéro sous-traitant américain dans le chemin par défaut. Clés détenues par le client ou par un KMS européen. Nommés dans votre DPA Article 28.

Pourquoi les équipes partent AWS

Les facteurs que nous entendons lors des appels de cadrage sont cohérents : une exigence d'approvisionnement qui impose désormais « aucun sous-traitant de données d'un pays tiers » (NIS2, DORA, secteur public), un audit client (généralement B2B entreprise ou santé) qui a signalé la relation avec AWS, des coûts d'egress et de bande passante qui s'aggravent chaque trimestre, ou une préoccupation au niveau de la direction après la vague d'incertitude 2024-2025 sur les mécanismes de transfert UE-US. L'effort technique pour quitter AWS est rarement le blocage qu'il semble être. La véritable difficulté est la chorégraphie : migrations de bases de données sans interruption, bascule DNS, continuité de l'observabilité. C'est là qu'un partenaire d'infrastructure managée fait gagner des mois.

AWS services et leurs équivalents UE-uniquement

Une migration n'est pas "échanger une boîte contre une autre". La cartographie ci-dessous est ce que nous exécutons pour les clients qui quittent AWS au titre de Schrems II : juridiction UE complète, aucune maison mère américaine dans le chemin des données.

AWS service	Ce que nous utilisons à la place	Note d'ingénierie
EC2 (compute)	Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.	Nous dimensionnons les instances selon votre profil de charge réel plutôt que selon un tier de catalogue, si bien que la plupart des migrations aboutissent à moins de machines, mais mieux utilisées.
S3 (object storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.	Les APIs compatibles S3 sont universelles ; la majorité du code applicatif ne nécessite qu'un changement d'endpoint. Pas de frais d'egress chez la plupart des fournisseurs européens.
RDS / Aurora (managed DB)	Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.	La réplication en streaming permet une bascule sans interruption. Les tarifs PostgreSQL managé EU sont généralement 30 à 50 % inférieurs à un RDS équivalent.
CloudFront (CDN)	Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.	Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.
Route 53 (DNS)	Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.	Les zones sont exportées et importées sous forme de fichiers de zone standards, ce qui en fait généralement la partie la moins mouvementée d'une migration. Abaissez les TTL une semaine à l'avance.
Lambda (serverless)	Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.	Pour des déploiements souverains, Knative auto-hébergé sur du compute dans l'UE est la solution la plus propre. La plupart des charges de travail Lambda tiennent dans un petit cluster Kubernetes.
SES (email)	Binadit Managed Cloud Platform. Postfix avec DKIM, SPF et DMARC, et Rspamd pour le filtrage.	Pour un volume transactionnel inférieur à 1M/mois, un relais Postfix correctement configuré est opérationnellement plus simple et moins coûteux que SES.
SQS / SNS	Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, selon les garanties de livraison.	Les brokers de messages managés sont rares dans l'espace souverain UE. Le self-managed est le pattern standard ; nous l'opérons pour nos clients.
EKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.	Le K8s managé chez les fournisseurs UE offre une parité fonctionnelle pour 95 % des workloads.
CloudWatch / X-Ray	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.	Le standard OpenTelemetry rend la migration triviale ; le gain opérationnel réside dans des dashboards consolidés et l'absence de tarification par métrique.
IAM	Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.	Pas d'équivalent 1:1 ; l'identité cross-platform est reconstruite avec Vault, des fournisseurs OIDC (Keycloak), et des rôles par outil.
WAF / Shield	Binadit Managed Cloud Platform. Coraza ou ModSecurity avec l'OWASP Core Rule Set, complété par CrowdSec pour le blocage comportemental.	Les règles sont ajustées en fonction de votre trafic plutôt que fournies comme un ensemble par défaut, ce qui empêche un WAF de bloquer silencieusement de vrais clients.
KMS	Binadit Private Infrastructure. Vault Transit pour la gestion des clés, avec des clés adossées à un HSM lorsque le régime de conformité l'exige.	Pour les scénarios HYOK, un HSM on-premises combiné à un BYOK côté cloud constitue le schéma souverain standard.
Secrets Manager / SSM Parameter Store	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.	Vault sur infrastructure EU est la solution de niveau production. Nous le déployons et l'exploitons.

EC2 (compute)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Machines virtuelles KVM sur Debian ou Ubuntu, provisionnées avec Terraform et configurées avec Ansible.
Note d'ingénierie: Nous dimensionnons les instances selon votre profil de charge réel plutôt que selon un tier de catalogue, si bien que la plupart des migrations aboutissent à moins de machines, mais mieux utilisées.

S3 (object storage)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatible S3.
Note d'ingénierie: Les APIs compatibles S3 sont universelles ; la majorité du code applicatif ne nécessite qu'un changement d'endpoint. Pas de frais d'egress chez la plupart des fournisseurs européens.

RDS / Aurora (managed DB)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PostgreSQL ou MySQL avec Patroni pour le failover et pgBackRest pour la restauration point-in-time.
Note d'ingénierie: La réplication en streaming permet une bascule sans interruption. Les tarifs PostgreSQL managé EU sont généralement 30 à 50 % inférieurs à un RDS équivalent.

CloudFront (CDN)

Ce que nous utilisons à la place: Nous mettons en place et exploitons un CDN européen pour vous : Bunny.net ou KeyCDN, avec du caching Nginx et Varnish à votre origine.
Note d'ingénierie: Un CDN est l'une des rares couches que nous n'exploitons pas nous-mêmes. Nous choisissons le fournisseur européen, configurons les en-têtes de cache, la stratégie de purge et l'origin shielding, et l'exploitons dans le cadre du service managé.

Route 53 (DNS)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. PowerDNS ou Knot, en autorité, signés DNSSEC.
Note d'ingénierie: Les zones sont exportées et importées sous forme de fichiers de zone standards, ce qui en fait généralement la partie la moins mouvementée d'une migration. Abaissez les TTL une semaine à l'avance.

Lambda (serverless)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Knative ou OpenFaaS sur votre cluster Kubernetes.
Note d'ingénierie: Pour des déploiements souverains, Knative auto-hébergé sur du compute dans l'UE est la solution la plus propre. La plupart des charges de travail Lambda tiennent dans un petit cluster Kubernetes.

SES (email)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Postfix avec DKIM, SPF et DMARC, et Rspamd pour le filtrage.
Note d'ingénierie: Pour un volume transactionnel inférieur à 1M/mois, un relais Postfix correctement configuré est opérationnellement plus simple et moins coûteux que SES.

SQS / SNS

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, selon les garanties de livraison.
Note d'ingénierie: Les brokers de messages managés sont rares dans l'espace souverain UE. Le self-managed est le pattern standard ; nous l'opérons pour nos clients.

EKS (managed Kubernetes)

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Kubernetes sur Debian ou Talos, avec réseau Cilium et cert-manager pour les certificats.
Note d'ingénierie: Le K8s managé chez les fournisseurs UE offre une parité fonctionnelle pour 95 % des workloads.

CloudWatch / X-Ray

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki et Tempo, connectés avec OpenTelemetry.
Note d'ingénierie: Le standard OpenTelemetry rend la migration triviale ; le gain opérationnel réside dans des dashboards consolidés et l'absence de tarification par métrique.

IAM

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Keycloak ou Authentik comme fournisseur d'identité, avec OIDC et SAML.
Note d'ingénierie: Pas d'équivalent 1:1 ; l'identité cross-platform est reconstruite avec Vault, des fournisseurs OIDC (Keycloak), et des rôles par outil.

WAF / Shield

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. Coraza ou ModSecurity avec l'OWASP Core Rule Set, complété par CrowdSec pour le blocage comportemental.
Note d'ingénierie: Les règles sont ajustées en fonction de votre trafic plutôt que fournies comme un ensemble par défaut, ce qui empêche un WAF de bloquer silencieusement de vrais clients.

KMS

Ce que nous utilisons à la place: Binadit Private Infrastructure. Vault Transit pour la gestion des clés, avec des clés adossées à un HSM lorsque le régime de conformité l'exige.
Note d'ingénierie: Pour les scénarios HYOK, un HSM on-premises combiné à un BYOK côté cloud constitue le schéma souverain standard.

Secrets Manager / SSM Parameter Store

Ce que nous utilisons à la place: Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, avec rotation automatique des leases.
Note d'ingénierie: Vault sur infrastructure EU est la solution de niveau production. Nous le déployons et l'exploitons.

Comment nous migrons depuis AWS

Une migration typique de mid-market se déroule en trois phases. Les chiffres ci-dessous supposent une équipe d'ingénierie de 6 à 10 personnes et une stack applicative modérément complexe.

Semaines 1-2

Audit et cartographie des dépendances

Inventoriez chaque service AWS utilisé, chaque rôle IAM, chaque Lambda, chaque appel inter-services. Étiquetez les flux de données personnelles. Résultat : un plan de remédiation avec des constats classés par risque et une estimation d'effort par service.
Semaines 3-6

Préparation des dépendances légères et de l'egress

Remplacer d'abord CloudFront, Route 53, SES et CloudWatch - aucun changement de code applicatif pour la plupart des cas. Déplacer les buckets S3 derrière un stockage compatible S3 situé dans l'UE avec double écriture pendant la bascule. Pré-configurer des répliques de RDS dans l'UE.
Semaines 6-14

Bascule Compute & DB principale

Migration blue-green du compute avec bascule du trafic au niveau DNS. Cutover de la base de données par réplication en streaming pendant une fenêtre de faible trafic. Workloads EKS déplacés vers un K8s UE managé ou un Talos self-managed. Décommissionnement du compte AWS une fois la vérification effectuée.

Modélisation du TCO sur 5 ans sur des workloads que nous avons réellement migrés : généralement 30-55% moins cher sur une infrastructure souveraine européenne pour les workloads prévisibles, neutre à légèrement plus élevé pour les workloads très volatils qui bénéficient de l'autoscaling en moins d'une seconde. Les économies sur l'egress à elles seules font souvent la différence entre un ROI positif et négatif.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

L'utilisation d'une région AWS UE (Francfort, Irlande, Stockholm) résout-elle le problème Schrems II ?

Non. La résidence des données est dans l'UE mais Amazon Web Services Inc. est le responsable de l'infrastructure sous le droit américain. Le CLOUD Act permet aux autorités américaines de contraindre la divulgation de données détenues par des entités contrôlées par les États-Unis, partout dans le monde. L'EDPB a explicitement signalé cela comme un problème Schrems II. AWS EMEA SARL est une filiale luxembourgeoise entièrement détenue par AWS Inc. ; c'est cette chaîne de propriété qui est déterminante dans l'analyse.

Combien de temps dure une sortie d'AWS en pratique ?

Pour une application mid-market (10 à 50 instances EC2, quelques bases de données RDS, S3, CloudFront, SES) avec une équipe d'ingénierie de 6 à 10 personnes et un support opérationnel compétent : 10 à 16 semaines de délai. Avec un partenaire d'infrastructure managée pilotant la chorégraphie (qui représente l'essentiel du travail réel) : 6 à 10 semaines.

Qu'en est-il d'AWS GovCloud ou d'AWS Sovereign Cloud Europe ?

AWS GovCloud est destiné aux charges de travail fédérales américaines et n'est pas pertinent pour les acheteurs européens. AWS European Sovereign Cloud (annoncé en 2023, en cours de déploiement) est opéré par du personnel AWS basé dans l'UE au sein de régions européennes, mais l'entité juridique mère reste Amazon Web Services Inc. Le fait qu'il soit « suffisamment souverain » dépend de votre régime de conformité spécifique ; pour de nombreuses analyses Schrems II, ce n'est pas suffisant car la juridiction de la maison mère reste inchangée.

Allons-nous perdre des fonctionnalités en quittant AWS ?

Certains services managés spécifiques (DynamoDB en quelques millisecondes, Aurora Serverless v2, accès aux modèles Bedrock, entraînement SageMaker sur H100) n'ont pas d'équivalent souverain UE propre. Pour 90 % des charges de travail du marché intermédiaire - applications web, API, e-commerce, SaaS B2B, analytique sur entrepôts de données - la pile souveraine UE couvre le besoin. Nous vous informons dès le départ si votre charge de travail relève de la catégorie des 10 %.

Pouvons-nous conserver certains services AWS et migrer le reste ?

Oui - une approche hybride est parfois la bonne réponse. La discipline consiste à ne conserver AWS que pour des workloads clairement non personnels, et à documenter cette frontière dans votre DPA. Nous avons mis en place des configurations hybrides où AWS gère l'entraînement de modèles ML (aucune donnée personnelle, en mode batch uniquement) tandis que la pile souveraine UE gère toute l'infrastructure orientée client.

Combien coûte une sortie managée ?

Tarification au projet, définie après l'audit. Sortie AWS typique pour le mid-market : 25-80k€ pour le projet, plus l'abonnement d'infrastructure managée continue pour la nouvelle stack européenne. Les économies réalisées sur les dépenses AWS la première année dépassent généralement le coût du projet.

Planifiez votre sortie de AWS.

Appel de cadrage de 30 minutes. Nous cartographions votre stack par rapport aux alternatives UE-uniquement, estimons l'effort de migration et vous disons si c'est le bon choix.

Planifier un appel Comparer un autre fournisseur