Alternativa apenas UE a Microsoft Azure.

Microsoft Azure is the cloud most often defended with the words "but we already use Microsoft for everything." That defence does not survive a Schrems II analysis: Microsoft Corporation is a US company, every Azure subsidiary is US-controlled, and Microsoft has explicitly acknowledged in court (Microsoft Ireland, 2018) that it would comply with valid US legal process for data anywhere globally - which is precisely what the CLOUD Act later codified. The "Microsoft Cloud for Sovereignty" and Bleu (Microsoft × Capgemini × Orange) initiatives are interesting but technology-licensed from a US parent. For genuine EU sovereignty, you exit. Below is the map.

United States Stack de substituição, apenas UE 14 serviços mapeados
Fornecedor
Microsoft Azure
Sede
Redmond, WA
Jurisdição
United States
Regime jurídico
CLOUD Act, FISA 702, EO 12333

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Microsoft Azure

Azure exits typically come from one of three triggers: a public-sector tender that explicitly excludes US-jurisdiction processors, a healthcare or financial services audit that flagged Microsoft 365 + Azure as a single concentration risk under DORA, or a CISO who calculated that the licence true-up costs and "free" Azure credits actually translate to vendor lock-in worth six figures. The Azure ecosystem has tighter coupling than AWS - Active Directory, Office 365, Defender, Sentinel are typically all in the mix - which makes the migration more invasive than its AWS equivalent. It is still doable; we have done it.

Microsoft Azure serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Microsoft Azure com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Azure Virtual Machines

O que usamos no lugar
Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.
Nota de engenharia
A migração de IaaS é direta; o capítulo do licenciamento Windows requer mais reflexão (BYOL ou mudança para Linux sempre que possível).

Azure Blob Storage

O que usamos no lugar
Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia
O storage europeu compatível com S3 é o destino da migração; as alterações no SDK são mínimas.

Azure SQL Database

O que usamos no lugar
Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.
Nota de engenharia
A portabilidade do schema a partir do Azure SQL (variante T-SQL) é a tarefa isolada mais demorada; ferramentas como AWS SCT ou pgloader ajudam. Costuma ser um bom momento para reconsiderar as escolhas de ORM.

Azure Front Door / CDN

O que usamos no lugar
Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
Nota de engenharia
A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.

Azure DNS

O que usamos no lugar
Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia
As zones são exportadas e importadas como ficheiros de zone standard, pelo que esta é geralmente a parte menos problemática de uma migração. Reduza os TTLs uma semana antes.

AKS (managed Kubernetes)

O que usamos no lugar
Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.
Nota de engenharia
Os Helm charts e YAML transferem-se sem problemas; addons específicos do Azure (Application Gateway Ingress, Azure CNI) precisam de ser substituídos por equivalentes standard.

Azure Functions

O que usamos no lugar
Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia
A maioria das cargas de trabalho de Azure Functions cabe num pequeno cluster Kubernetes da UE a correr Knative.

Azure Active Directory / Entra ID

O que usamos no lugar
Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.
Nota de engenharia
A migração individual mais difícil. Planeie uma janela de execução paralela de 3 meses. As integrações SSO entre SaaS precisam de ser remapeadas.

Azure Service Bus / Event Grid

O que usamos no lugar
Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.
Nota de engenharia
As opções de queueing geridas no espaço soberano da UE são limitadas; self-managed é o padrão.

Azure Monitor / Application Insights

O que usamos no lugar
Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.
Nota de engenharia
A instrumentação com OpenTelemetry torna a troca mecânica para o código da aplicação.

Azure Cosmos DB

O que usamos no lugar
Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.
Nota de engenharia
Não existe substituto 1:1 para active-active multi-região global; se a sua carga de trabalho realmente precisar desse padrão, a conversa é diferente.

Defender / Sentinel (security)

O que usamos no lugar
Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.
Nota de engenharia
A CrowdSec tem sede em França e está cada vez mais competitiva no espaço SIEM/IDS.

Key Vault

O que usamos no lugar
Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.
Nota de engenharia
O Vault é a resposta soberana de nível de produção; nós operamo-lo para os clientes.

Microsoft 365 (email, Teams, OneDrive)

O que usamos no lugar
Binadit Managed Cloud Platform. Postfix com DKIM, SPF e DMARC, e Rspamd para filtragem.
Nota de engenharia
Frequentemente é a conversa política mais difícil do que a migração de infraestrutura. É comum manter-se no M365 com exposição documentada em vez de migrar.

Como migramos de Microsoft Azure

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

  1. Weeks 1-3

    Audit & ID-mapping

    Inventory Azure services, Entra ID dependencies, SSO integrations and licensing. The identity layer is the longest tail. Output: phased plan with the SSO migration scoped separately.

  2. Weeks 3-6

    Edge, monitoring, soft dependencies

    Replace Front Door, Azure DNS, App Insights and Blob Storage. Pre-stage EU compute and replicate database. Move CI/CD off Azure DevOps if applicable.

  3. Weeks 6-18

    Compute, DB, identity cutover

    AKS workloads to managed EU K8s. SQL Database to PostgreSQL with logical replication for live cutover. Identity migration with parallel-run; cut SSO over per application.

5-year TCO on Azure exits we have run: typically 25-45% cheaper, with the largest savings coming from licence true-up avoidance and bandwidth/egress. Bear in mind: if your team uses Microsoft 365 and is staying on it, the identity-layer migration only partially decouples - that decision belongs at board level.

Does Microsoft Cloud for Sovereignty solve the Schrems II problem?
It improves the documentation story but does not change the underlying jurisdiction: Microsoft Corporation remains the parent. For workloads where the analysis turns on parent-jurisdiction (i.e. most regulated workloads after Schrems II), it is not sufficient on its own.
What about Bleu?
Licensed sovereign offerings, where an EU entity operates US technology under licence, are pseudo-sovereign - operated by EU-headquartered entities under licence from a US technology partner. They can satisfy specific regulatory requirements (notably the French SecNumCloud certification for Bleu) but inherit a stack they cannot independently maintain. For most buyers, a clean EU-native stack is the architecturally simpler answer.
Can we leave Azure but keep Microsoft 365?
Yes, and many of our clients run that hybrid. The trade-off is that personal data flowing through M365 (email content, OneDrive files, Teams chat) remains under Microsoft processing. Document it in your DPA, apply supplementary measures (encryption at rest with EU-held keys for sensitive folders), and keep customer-data infrastructure on the sovereign stack.
How does this affect our Microsoft Enterprise Agreement?
Existing EAs typically have annual or multi-year terms; the migration target is to stop the next renewal or right-size it, not to break the current contract. Your account manager will offer concessions when they hear "we are evaluating sovereign alternatives." Use that.
Is Active Directory replaceable in practice?
Replaceable in stages. Keycloak handles OIDC/SAML/SCIM well; for Windows-domain authentication on physical desktops, Samba 4 with FreeIPA is the established open-source path. The transition typically runs alongside a "modern workplace" simplification - fewer per-app SSOs, more standard OIDC.
How long does an Azure exit take?
For a mid-size workload (50-200 VMs, 1-2 SQL DBs, AKS, Entra ID): 16-24 weeks elapsed time. With a managed-infrastructure partner driving the choreography: 10-16 weeks. The identity layer is the schedule risk, not the compute.

Planeie a sua saída de Microsoft Azure.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.