Alternativa solo UE a AWS.

Amazon Web Services è il public cloud originale - e il problema Schrems II originale. Le stesse region UE che rendono AWS tecnicamente utilizzabile per i workload europei non cambiano la giurisdizione della società madre: AWS Inc. è una corporation del Delaware, AWS EMEA SARL è una filiale del Lussemburgo interamente controllata da essa, e il CLOUD Act si applica a entrambe. Per i workload sottoposti ad audit, i settori regolamentati e qualsiasi azienda a cui un cliente abbia chiesto "il vostro provider è soggetto a subpoena statunitensi?", la risposta onesta su AWS è sì. Di seguito la mappa a livello ingegneristico per uscirne.

Stati Uniti Stack sostitutivo, solo UE 14 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: AWS
Sede: Seattle, WA
Giurisdizione: Stati Uniti
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

I fattori che riscontriamo nelle call di scoping sono coerenti: un requisito di procurement che ora impone "nessun data processor di paese terzo" (NIS2, DORA, settore pubblico), un audit del cliente (tipicamente enterprise B2B o sanità) che ha segnalato il rapporto con AWS, costi di egress e banda in escalation che peggiorano ogni trimestre, oppure una preoccupazione a livello di leadership dopo l'incertezza del 2024-2025 sui meccanismi di trasferimento dati UE-USA. Lo sforzo tecnico per lasciare AWS raramente è il vero ostacolo. L'attrito reale è la coreografia: migrazioni di database a zero downtime, cutover DNS, continuità dell'observability. È lì che un partner di infrastruttura gestita fa risparmiare mesi.

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.

Settimane 1-2

Audit e mappa delle dipendenze

Inventario di ogni servizio AWS in uso, ogni ruolo IAM, ogni Lambda, ogni chiamata cross-service. Tag sui flussi di dati personali. Output: un piano di remediation con risultati classificati per rischio e una stima dello sforzo per ciascun servizio.
Settimane 3-6

Dipendenze soft e preparazione egress

Sostituire prima CloudFront, Route 53, SES e CloudWatch - zero modifiche al codice applicativo per la maggior parte dei casi. Spostare i bucket S3 dietro uno storage UE compatibile con S3 con dual-write durante il cutover. Pre-staging delle repliche di RDS nell'UE.
Settimane 6-14

Cutover Core Compute & DB

Migrazione del compute blue-green con shift del traffico a livello DNS. Cutover del database con replica in streaming durante una finestra a basso traffico. I workload EKS vengono spostati su K8s EU gestito o su Talos self-managed. Dismissione dell'account AWS una volta verificato.

Modellazione TCO a 5 anni su workload che abbiamo effettivamente migrato: tipicamente il 30-55% più economica su infrastruttura sovrana UE per workload prevedibili, neutra o leggermente superiore per workload molto irregolari che beneficiano di autoscaling sub-secondo. Il solo risparmio sull'egress spesso fa la differenza tra un ROI positivo e uno negativo.

Domande frequenti

Visualizza tutte le domande frequenti

L'uso di una regione EU di AWS (Francoforte, Irlanda, Stoccolma) risolve il problema Schrems II?

No. La residenza dei dati è nell'EU ma Amazon Web Services Inc. è il controllore dell'infrastruttura secondo il diritto statunitense. Il CLOUD Act consente alle autorità statunitensi di obbligare la divulgazione dei dati detenuti da entità controllate dagli Stati Uniti ovunque nel mondo. L'EDPB ha esplicitamente segnalato questo come un problema Schrems II. AWS EMEA SARL è una controllata lussemburghese interamente posseduta da AWS Inc.; è questa catena di proprietà a determinare l'analisi.

Quanto tempo richiede in pratica un'uscita da AWS?

Per un'applicazione mid-market (10-50 istanze EC2, un paio di database RDS, S3, CloudFront, SES) con un team di ingegneria di 6-10 persone e supporto operativo competente: 10-16 settimane di tempo trascorso. Con un partner di infrastruttura gestita che guida la coreografia (che è la maggior parte del lavoro effettivo), 6-10 settimane.

E per quanto riguarda AWS GovCloud o AWS Sovereign Cloud Europe?

AWS GovCloud è destinato ai workload federali statunitensi e non è rilevante per gli acquirenti UE. AWS European Sovereign Cloud (annunciato nel 2023, in fase di costruzione) è gestito da personale AWS con sede nell'UE in region UE, ma l'entità legale controllante rimane Amazon Web Services Inc. Che sia "sufficientemente sovrano" dipende dal vostro specifico regime di conformità; per molte analisi Schrems II non è sufficiente perché la giurisdizione della società madre resta invariata.

Perderemo funzionalità lasciando AWS?

Servizi gestiti specifici (DynamoDB con latenza single-digit-ms, Aurora Serverless v2, accesso ai modelli Bedrock, training SageMaker su H100) non hanno equivalenti sovrani EU puliti. Per il 90% dei workload mid-market - applicazioni web, API, e-commerce, B2B SaaS, analytics su data warehouse - lo stack sovrano EU li copre. Ti diciamo fin da subito se il tuo workload rientra nella categoria del 10%.

Possiamo mantenere alcuni servizi AWS e migrare il resto?

Sì - a volte un approccio ibrido è la risposta giusta. La disciplina consiste nel mantenere AWS solo per workload chiaramente non personali, documentando il confine nel DPA. Abbiamo gestito configurazioni ibride in cui AWS si occupa del training ML (nessun dato personale, solo batch) mentre lo stack sovrano EU gestisce tutta l'infrastruttura rivolta ai clienti.

Quanto costa una migrazione gestita?

Prezzo su base progettuale, definito dopo l'audit. Tipica uscita da AWS per il mid-market: €25-80k per il progetto, più il canone continuativo per l'infrastruttura gestita del nuovo stack UE. I risparmi sulla spesa AWS nel primo anno di solito superano il costo del progetto.

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