Alternative UE-uniquement à AWS.

Amazon Web Services is the original public cloud - and the original Schrems II problem. The same EU regions that make AWS technically usable for European workloads do not change the parent jurisdiction: AWS Inc. is a Delaware corporation, AWS EMEA SARL is a Luxembourg subsidiary fully controlled by it, and the CLOUD Act applies to both. For audited workloads, regulated industries and any business that has had a customer ask "is your provider US-subpoenable?", the honest answer on AWS is yes. Below is the engineering-grade map for getting off it.

United States Stack de remplacement, UE uniquement 14 services cartographiés

Planifier un appel Scannez d'abord votre domaine

Fournisseur: AWS
Siège: Seattle, WA
Juridiction: United States
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

The drivers we hear in scoping calls are consistent: a procurement gate that now demands "no third-country data processor" (NIS2, DORA, public sector), a customer audit (typically B2B enterprise or healthcare) that flagged the AWS relationship, escalating egress and bandwidth costs that look worse every quarter, or a leadership-level concern after the 2024-2025 round of EU-US transfer mechanism uncertainty. The technical lift to leave AWS is rarely the blocker it appears to be. The real friction is choreography: zero-downtime database migrations, DNS cutover, observability continuity. That is where a managed-infrastructure partner saves months.

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.

Weeks 1-2

Audit & dependency map

Inventory every AWS service in use, every IAM role, every Lambda, every cross-service call. Tag personal data flows. Output: a remediation plan with risk-ranked findings and an effort estimate per service.
Weeks 3-6

Soft dependencies & egress prep

Replace CloudFront, Route 53, SES and CloudWatch first - zero application code changes for most. Move S3 buckets behind S3-compatible EU storage with dual-write during cutover. Pre-stage replicas of RDS in EU.
Weeks 6-14

Core compute & DB cutover

Blue-green compute migration with DNS-level traffic shift. Streaming-replication database cutover during a low-traffic window. EKS workloads moved to managed EU K8s or self-managed Talos. Decommission AWS account once verified.

5-year TCO modelling on workloads we have actually migrated: typically 30-55% cheaper on EU sovereign infrastructure for predictable workloads, neutral to slightly higher for highly bursty workloads that benefit from sub-second autoscaling. Egress savings alone are often the difference between a positive and negative ROI.

Questions fréquemment posées

Voir toutes les questions fréquemment posées

Does using an AWS EU region (Frankfurt, Ireland, Stockholm) solve the Schrems II problem?

No. The data residency is in the EU but Amazon Web Services Inc. is the controller of the infrastructure under US law. The CLOUD Act allows US authorities to compel disclosure of data held by US-controlled entities anywhere in the world. The EDPB has explicitly flagged this as a Schrems II issue. AWS EMEA SARL is a Luxembourg subsidiary fully owned by AWS Inc.; that ownership chain is what the analysis turns on.

How long does an AWS exit take in practice?

For a mid-market application (10-50 EC2 instances, a couple of RDS databases, S3, CloudFront, SES) with a 6-10 person engineering team and competent operational support: 10-16 weeks elapsed time. With a managed-infrastructure partner driving the choreography (which is most of the actual work), 6-10 weeks.

What about AWS GovCloud or AWS Sovereign Cloud Europe?

AWS GovCloud is for US federal workloads and is not relevant to EU buyers. AWS European Sovereign Cloud (announced 2023, in build-out) is operated by EU-headquartered AWS staff in EU regions, but the parent legal entity remains Amazon Web Services Inc. Whether it is "sovereign enough" depends on your specific compliance regime; for many Schrems II analyses it is not sufficient because the parent jurisdiction is unchanged.

Will we lose features by leaving AWS?

Specific managed services (DynamoDB single-digit-ms, Aurora Serverless v2, Bedrock model access, SageMaker training on H100s) have no clean EU sovereign equivalents. For 90% of mid-market workloads - web applications, APIs, e-commerce, B2B SaaS, analytics on warehouses - the EU sovereign stack covers it. We tell you upfront if your workload sits in the 10% category.

Can we keep some AWS services and migrate the rest?

Yes - a hybrid is sometimes the right answer. The discipline is to keep AWS only for clearly non-personal workloads, and document the boundary in your DPA. We have run hybrids where AWS handles ML training (no personal data, batch-only) and the EU sovereign stack handles all customer-facing infrastructure.

What does a managed exit cost?

Project-based pricing, scoped after the audit. Typical mid-market AWS exit: €25-80k for the project, plus the ongoing managed-infrastructure retainer for the new EU stack. The first-year savings on AWS spend usually exceed the project cost.

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