Alternativa solo UE a 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 sostitutivo, solo UE 14 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: AWS
Sede: Seattle, WA
Giurisdizione: United States
Regime giuridico: CLOUD Act, FISA 702, EO 12333

"Regione UE" non è sovranità. Quattro domande decidono.

La residenza dei dati dice dove si trovano i bit. La sovranità dice quale sistema giuridico può imporne l'accesso. La risposta deve reggere su tutti e quattro i punti, altrimenti lo stack non è sovrano.

Residenza

Dove sono fisicamente archiviati i dati?

Non "nel cloud": quale datacenter, in quale paese, sotto quale giurisdizione.

Sub-responsabili

Chi altro è nel suo percorso dei dati?

Ogni fornitore che tocca i dati: il CDN, il relay e-mail, il tracker degli errori, la pipeline di analytics.

Giurisdizione

Quali leggi possono imporre la divulgazione?

Un fornitore con sede negli Stati Uniti ricade sotto FISA 702 e CLOUD Act, anche se i bit si trovano a Francoforte.

Custodia delle chiavi

Chi detiene effettivamente le chiavi di cifratura?

Se il provider cloud detiene sia i dati sia le chiavi, può leggerli, indipendentemente da qualsiasi DPA.

Non supera AWS · Azure · GCP · Regione UE

Fallisce su giurisdizione e custodia delle chiavi.

Bit nell'UE, casa madre statunitense, sub-responsabili americani nel percorso predefinito, chiavi gestite dal fornitore.

Supera Stack gestito da Binadit

Passa su tutte e quattro.

Ospitato in UE su infrastruttura con sede europea. Zero sub-responsabili statunitensi nel percorso predefinito. Chiavi del cliente o di KMS europeo. Elencati per nome nel suo DPA Articolo 28.

Perché i team se ne vanno 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 servizi e i loro equivalenti solo UE

Una migrazione non è "scambiare una scatola con un'altra". La mappatura sottostante è ciò che eseguiamo per i clienti che lasciano AWS in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

AWS servizio	Cosa usiamo al suo posto	Nota di ingegneria
EC2 (compute)	Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.	Dimensioniamo le istanze in base al tuo effettivo profilo di carico e non a un livello di catalogo, così la maggior parte delle migrazioni si conclude con meno macchine, meglio utilizzate.
S3 (object storage)	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.	Le API compatibili S3 sono universali; nella maggior parte dei casi il codice applicativo richiede solo la modifica di un endpoint. Nessun costo di egress sulla maggior parte dei provider EU.
RDS / Aurora (managed DB)	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.	La replica in streaming consente un cutover a downtime zero. Il prezzo di PostgreSQL gestito EU è tipicamente del 30-50% inferiore rispetto a un RDS equivalente.
CloudFront (CDN)	Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.	Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.
Route 53 (DNS)	Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.	Le zone vengono esportate e importate come file di zona standard, quindi questa è di solito la parte meno critica di una migrazione. Abbassa i TTL con una settimana di anticipo.
Lambda (serverless)	Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.	Per i deployment sovrani, Knative self-hosted su compute UE è la soluzione più pulita. La maggior parte dei workload Lambda si adatta a un piccolo cluster Kubernetes.
SES (email)	Binadit Managed Cloud Platform. Postfix con DKIM, SPF e DMARC, e Rspamd per il filtraggio.	Per volumi transazionali sotto 1M/mese, un relay Postfix configurato correttamente è operativamente più semplice ed economico rispetto a SES.
SQS / SNS	Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, a seconda delle garanzie di consegna richieste.	I message broker gestiti sono rari nello spazio sovrano UE. L'autogestione è il pattern standard; lo gestiamo noi per conto dei clienti.
EKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes su Debian o Talos, con networking Cilium e cert-manager per i certificati.	Il K8s gestito su provider UE ha parità di funzionalità per il 95% dei workload.
CloudWatch / X-Ray	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.	Lo standard OpenTelemetry rende la migrazione banale; il vantaggio operativo sono dashboard consolidate e nessun costo per metrica.
IAM	Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.	Non esiste un sostituto 1:1; l'identità cross-platform viene ricostruita con Vault, provider OIDC (Keycloak) e ruoli per singolo tool.
WAF / Shield	Binadit Managed Cloud Platform. Coraza o ModSecurity con l'OWASP Core Rule Set, più CrowdSec per il blocco comportamentale.	Le regole vengono calibrate sul vostro traffico reale invece di essere fornite come set predefinito, ed è proprio questo a impedire che un WAF blocchi silenziosamente clienti reali.
KMS	Binadit Private Infrastructure. Vault Transit per la gestione delle chiavi, con chiavi supportate da HSM dove il regime di conformità lo richiede.	Per scenari HYOK, HSM on-premises con BYOK lato cloud è il pattern sovrano standard.
Secrets Manager / SSM Parameter Store	Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.	Vault su infrastruttura EU è la risposta di livello produttivo. Ce ne occupiamo noi, dal deployment alla gestione.

EC2 (compute)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.
Nota di ingegneria: Dimensioniamo le istanze in base al tuo effettivo profilo di carico e non a un livello di catalogo, così la maggior parte delle migrazioni si conclude con meno macchine, meglio utilizzate.

S3 (object storage)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.
Nota di ingegneria: Le API compatibili S3 sono universali; nella maggior parte dei casi il codice applicativo richiede solo la modifica di un endpoint. Nessun costo di egress sulla maggior parte dei provider EU.

RDS / Aurora (managed DB)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.
Nota di ingegneria: La replica in streaming consente un cutover a downtime zero. Il prezzo di PostgreSQL gestito EU è tipicamente del 30-50% inferiore rispetto a un RDS equivalente.

CloudFront (CDN)

Cosa usiamo al suo posto: Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.
Nota di ingegneria: Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.

Route 53 (DNS)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.
Nota di ingegneria: Le zone vengono esportate e importate come file di zona standard, quindi questa è di solito la parte meno critica di una migrazione. Abbassa i TTL con una settimana di anticipo.

Lambda (serverless)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.
Nota di ingegneria: Per i deployment sovrani, Knative self-hosted su compute UE è la soluzione più pulita. La maggior parte dei workload Lambda si adatta a un piccolo cluster Kubernetes.

SES (email)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Postfix con DKIM, SPF e DMARC, e Rspamd per il filtraggio.
Nota di ingegneria: Per volumi transazionali sotto 1M/mese, un relay Postfix configurato correttamente è operativamente più semplice ed economico rispetto a SES.

SQS / SNS

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, a seconda delle garanzie di consegna richieste.
Nota di ingegneria: I message broker gestiti sono rari nello spazio sovrano UE. L'autogestione è il pattern standard; lo gestiamo noi per conto dei clienti.

EKS (managed Kubernetes)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Kubernetes su Debian o Talos, con networking Cilium e cert-manager per i certificati.
Nota di ingegneria: Il K8s gestito su provider UE ha parità di funzionalità per il 95% dei workload.

CloudWatch / X-Ray

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.
Nota di ingegneria: Lo standard OpenTelemetry rende la migrazione banale; il vantaggio operativo sono dashboard consolidate e nessun costo per metrica.

IAM

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.
Nota di ingegneria: Non esiste un sostituto 1:1; l'identità cross-platform viene ricostruita con Vault, provider OIDC (Keycloak) e ruoli per singolo tool.

WAF / Shield

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Coraza o ModSecurity con l'OWASP Core Rule Set, più CrowdSec per il blocco comportamentale.
Nota di ingegneria: Le regole vengono calibrate sul vostro traffico reale invece di essere fornite come set predefinito, ed è proprio questo a impedire che un WAF blocchi silenziosamente clienti reali.

KMS

Cosa usiamo al suo posto: Binadit Private Infrastructure. Vault Transit per la gestione delle chiavi, con chiavi supportate da HSM dove il regime di conformità lo richiede.
Nota di ingegneria: Per scenari HYOK, HSM on-premises con BYOK lato cloud è il pattern sovrano standard.

Secrets Manager / SSM Parameter Store

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.
Nota di ingegneria: Vault su infrastruttura EU è la risposta di livello produttivo. Ce ne occupiamo noi, dal deployment alla gestione.

Come migriamo da AWS

Una tipica migrazione di mid-market si svolge in tre fasi. I numeri qui sotto assumono un team di ingegneria di 6-10 persone e uno stack applicativo moderatamente complesso.

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.

Domande frequenti

Visualizza tutte le domande frequenti

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.

Pianifica la tua uscita da AWS.

Chiamata di scoping di 30 minuti. Mappiamo il tuo stack rispetto alle alternative solo UE, stimiamo lo sforzo di migrazione e ti diciamo se è la scelta giusta.

Prenota una chiamata Confronta un altro provider