Alternativa solo UE a Microsoft Azure.

Microsoft Azure è il cloud più spesso difeso con le parole "ma usiamo già Microsoft per tutto". Questa difesa non regge a un'analisi Schrems II: Microsoft Corporation è un'azienda US, ogni filiale Azure è controllata dagli USA, e Microsoft ha esplicitamente riconosciuto in tribunale (Microsoft Ireland, 2018) che si sarebbe conformata a un valido processo legale US per i dati ovunque nel mondo - esattamente ciò che il CLOUD Act ha poi codificato. Le iniziative "Microsoft Cloud for Sovereignty" e Bleu (Microsoft × Capgemini × Orange) sono interessanti ma la tecnologia è concessa in licenza da una parent company US. Per una reale sovranità EU, si esce. Di seguito la mappa.

Stati Uniti Stack sostitutivo, solo UE 14 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: Microsoft Azure
Sede: Redmond, 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 Microsoft Azure

Le uscite da Azure derivano tipicamente da uno di tre fattori scatenanti: una gara d'appalto nel settore pubblico che esclude esplicitamente i processori sotto giurisdizione statunitense, un audit in ambito sanitario o finanziario che ha segnalato Microsoft 365 + Azure come un unico rischio di concentrazione ai sensi del DORA, oppure un CISO che ha calcolato che i costi di true-up delle licenze e i crediti Azure "gratuiti" si traducono in realtà in un vendor lock-in dal valore a sei cifre. L'ecosistema Azure presenta un accoppiamento più stretto rispetto ad AWS - Active Directory, Office 365, Defender, Sentinel sono tipicamente tutti coinvolti - il che rende la migrazione più invasiva rispetto all'equivalente AWS. È comunque fattibile; lo abbiamo già fatto.

Microsoft Azure 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 Microsoft Azure in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

Microsoft Azure servizio	Cosa usiamo al suo posto	Nota di ingegneria
Azure Virtual Machines	Binadit Managed Cloud Platform. Macchine virtuali KVM su Debian o Ubuntu, provisionate con Terraform e configurate con Ansible.	La migrazione IaaS è semplice; il capitolo del licensing Windows richiede maggiore attenzione (BYOL o passaggio a Linux dove possibile).
Azure Blob Storage	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.	Lo storage EU compatibile S3 è la destinazione della migrazione; le modifiche all'SDK sono minime.
Azure SQL Database	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni per il failover e pgBackRest per il point-in-time recovery.	Il porting dello schema da Azure SQL (variante T-SQL) è il compito più lungo; strumenti come AWS SCT o pgloader aiutano. Spesso è un buon momento per rivedere le scelte relative all'ORM.
Azure Front Door / 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.
Azure 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.
AKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes su Debian o Talos, con networking Cilium e cert-manager per i certificati.	I chart Helm e i file YAML si trasferiscono senza problemi; gli addon specifici di Azure (Application Gateway Ingress, Azure CNI) devono essere sostituiti con equivalenti standard.
Azure Functions	Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.	La maggior parte dei workload Azure Functions si adatta a un piccolo cluster Kubernetes UE che esegue Knative.
Azure Active Directory / Entra ID	Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.	La singola migrazione più difficile. Pianifica una finestra di esecuzione parallela di 3 mesi. Le integrazioni SSO tra i vari SaaS richiedono una rimappatura.
Azure Service Bus / Event Grid	Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, a seconda delle garanzie di consegna richieste.	Le opzioni di queueing gestito nello spazio sovrano UE sono limitate; l'autogestione è lo standard.
Azure Monitor / Application Insights	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.	L'instrumentazione OpenTelemetry rende meccanico lo swap per il codice applicativo.
Azure Cosmos DB	Binadit Managed Cloud Platform. Replica set MongoDB, o PostgreSQL con JSONB dove il modello a documenti è più leggero di quanto sembri.	Non esiste un sostituto 1:1 per il multi-region active-active globale; se il tuo workload richiede davvero questo pattern, la conversazione è diversa.
Defender / Sentinel (security)	Binadit Managed Cloud Platform. Coraza o ModSecurity con l'OWASP Core Rule Set, più CrowdSec per il blocco comportamentale.	CrowdSec ha sede in Francia ed è sempre più competitiva nello spazio SIEM/IDS.
Key Vault	Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.	Vault è la risposta sovrana di livello produttivo; la gestiamo noi per conto dei clienti.
Microsoft 365 (email, Teams, OneDrive)	Binadit Managed Cloud Platform. Postfix con DKIM, SPF e DMARC, e Rspamd per il filtraggio.	Spesso è la conversazione politica più difficile rispetto alla migrazione dell'infrastruttura. Frequentemente resta su M365 con esposizione documentata invece di essere migrata.

Azure Virtual Machines

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: La migrazione IaaS è semplice; il capitolo del licensing Windows richiede maggiore attenzione (BYOL o passaggio a Linux dove possibile).

Azure Blob Storage

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.
Nota di ingegneria: Lo storage EU compatibile S3 è la destinazione della migrazione; le modifiche all'SDK sono minime.

Azure SQL Database

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: Il porting dello schema da Azure SQL (variante T-SQL) è il compito più lungo; strumenti come AWS SCT o pgloader aiutano. Spesso è un buon momento per rivedere le scelte relative all'ORM.

Azure Front Door / 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.

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

AKS (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: I chart Helm e i file YAML si trasferiscono senza problemi; gli addon specifici di Azure (Application Gateway Ingress, Azure CNI) devono essere sostituiti con equivalenti standard.

Azure Functions

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.
Nota di ingegneria: La maggior parte dei workload Azure Functions si adatta a un piccolo cluster Kubernetes UE che esegue Knative.

Azure Active Directory / Entra ID

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Keycloak o Authentik come identity provider, con OIDC e SAML.
Nota di ingegneria: La singola migrazione più difficile. Pianifica una finestra di esecuzione parallela di 3 mesi. Le integrazioni SSO tra i vari SaaS richiedono una rimappatura.

Azure Service Bus / Event Grid

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, a seconda delle garanzie di consegna richieste.
Nota di ingegneria: Le opzioni di queueing gestito nello spazio sovrano UE sono limitate; l'autogestione è lo standard.

Azure Monitor / Application Insights

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrati con OpenTelemetry.
Nota di ingegneria: L'instrumentazione OpenTelemetry rende meccanico lo swap per il codice applicativo.

Azure Cosmos DB

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Replica set MongoDB, o PostgreSQL con JSONB dove il modello a documenti è più leggero di quanto sembri.
Nota di ingegneria: Non esiste un sostituto 1:1 per il multi-region active-active globale; se il tuo workload richiede davvero questo pattern, la conversazione è diversa.

Defender / Sentinel (security)

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: CrowdSec ha sede in Francia ed è sempre più competitiva nello spazio SIEM/IDS.

Key Vault

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, self-hosted, con rotazione automatica dei lease.
Nota di ingegneria: Vault è la risposta sovrana di livello produttivo; la gestiamo noi per conto dei clienti.

Microsoft 365 (email, Teams, OneDrive)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Postfix con DKIM, SPF e DMARC, e Rspamd per il filtraggio.
Nota di ingegneria: Spesso è la conversazione politica più difficile rispetto alla migrazione dell'infrastruttura. Frequentemente resta su M365 con esposizione documentata invece di essere migrata.

Come migriamo da Microsoft Azure

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-3

Audit e mappatura degli ID

Inventario dei servizi Azure, dipendenze da Entra ID, integrazioni SSO e licenze. Il livello identità è quello con la coda più lunga. Output: piano graduale con la migrazione SSO pianificata separatamente.
Settimane 3-6

Edge, monitoring, dipendenze soft

Sostituire Front Door, Azure DNS, App Insights e Blob Storage. Pre-staging del compute UE e replica del database. Spostare CI/CD fuori da Azure DevOps, se applicabile.
Settimane 6-18

Cutover Compute, DB, identità

Workload AKS verso K8s UE gestiti. SQL Database verso PostgreSQL con replica logica per il cutover live. Migrazione dell'identità con esecuzione parallela; cutover del SSO per applicazione.

TCO a 5 anni sulle uscite da Azure che abbiamo gestito: tipicamente il 25-45% più economico, con i risparmi maggiori derivanti dall'evitare il true-up delle licenze e dalla banda/egress. Da tenere presente: se il vostro team utilizza Microsoft 365 e intende continuare a farlo, la migrazione del livello identità si disaccoppia solo parzialmente: questa decisione spetta al livello di board.

Domande frequenti

Visualizza tutte le domande frequenti

Microsoft Cloud for Sovereignty risolve il problema Schrems II?

Migliora la documentazione ma non cambia la giurisdizione sottostante: Microsoft Corporation resta la casa madre. Per i workload in cui l'analisi dipende dalla giurisdizione della casa madre (cioè la maggior parte dei workload regolamentati dopo Schrems II), non è sufficiente da sola.

E per quanto riguarda Bleu?

Le offerte sovrane su licenza, in cui un'entità UE gestisce tecnologia statunitense su licenza, sono pseudo-sovrane - operate da entità con sede nell'UE su licenza di un partner tecnologico statunitense. Possono soddisfare requisiti normativi specifici (in particolare la certificazione francese SecNumCloud per Bleu) ma ereditano uno stack che non possono mantenere in autonomia. Per la maggior parte degli acquirenti, uno stack nativo UE pulito è la risposta architetturalmente più semplice.

Possiamo lasciare Azure ma mantenere Microsoft 365?

Sì, e molti nostri clienti gestiscono questo approccio ibrido. Il compromesso è che i dati personali che transitano attraverso M365 (contenuto delle email, file OneDrive, chat Teams) restano sotto il processing di Microsoft. Documentatelo nel DPA, applicate misure supplementari (cifratura at rest con chiavi detenute in EU per le cartelle sensibili) e mantenete l'infrastruttura dei dati clienti sullo stack sovrano.

Come influisce questo sul nostro Microsoft Enterprise Agreement?

Gli EA esistenti hanno tipicamente durata annuale o pluriennale; l'obiettivo della migrazione è fermare il prossimo rinnovo o ridimensionarlo, non rescindere il contratto attuale. Il tuo account manager offrirà concessioni quando sentirà "stiamo valutando alternative sovrane". Usalo a tuo vantaggio.

Active Directory è sostituibile nella pratica?

Sostituibile per fasi. Keycloak gestisce bene OIDC/SAML/SCIM; per l'autenticazione Windows-domain su desktop fisici, Samba 4 con FreeIPA è il percorso open-source consolidato. La transizione avviene tipicamente insieme a una semplificazione "modern workplace" - meno SSO per singola app, più OIDC standard.

Quanto tempo richiede un'uscita da Azure?

Per un workload di dimensioni medie (50-200 VM, 1-2 DB SQL, AKS, Entra ID): 16-24 settimane di tempo trascorso. Con un partner di infrastruttura gestita che guida la coreografia: 10-16 settimane. Il livello di identità è il rischio per la pianificazione, non il compute.

Pianifica la tua uscita da Microsoft Azure.

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