Alternativa apenas UE a Microsoft Azure.

O Microsoft Azure é a cloud mais frequentemente defendida com as palavras "mas já usamos Microsoft para tudo". Essa defesa não sobrevive a uma análise Schrems II: a Microsoft Corporation é uma empresa dos EUA, todas as subsidiárias Azure são controladas pelos EUA, e a Microsoft reconheceu explicitamente em tribunal (Microsoft Ireland, 2018) que cumpriria processos legais válidos dos EUA relativamente a dados em qualquer parte do mundo - exatamente o que o CLOUD Act codificou mais tarde. As iniciativas "Microsoft Cloud for Sovereignty" e Bleu (Microsoft × Capgemini × Orange) são interessantes, mas a tecnologia é licenciada por uma empresa-mãe dos EUA. Para uma soberania europeia genuína, a saída é a solução. Abaixo está o mapa.

Estados Unidos Stack de substituição, apenas UE 14 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Microsoft Azure
Sede: Redmond, WA
Jurisdição: Estados Unidos
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

As saídas do Azure normalmente resultam de um de três fatores: um concurso público que exclui explicitamente processadores sob jurisdição dos EUA, uma auditoria de saúde ou de serviços financeiros que identificou o Microsoft 365 + Azure como um risco de concentração único sob o DORA, ou um CISO que calculou que os custos de true-up de licenças e os créditos "gratuitos" do Azure representam, na prática, um vendor lock-in de seis dígitos. O ecossistema Azure tem um acoplamento mais forte do que o AWS - Active Directory, Office 365, Defender, Sentinel normalmente estão todos envolvidos - o que torna a migração mais invasiva do que o equivalente na AWS. Ainda assim, é viável; já o fizemos.

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.

Microsoft Azure serviço	O que usamos no lugar	Nota de engenharia
Azure Virtual Machines	Binadit Managed Cloud Platform. Máquinas virtuais KVM em Debian ou Ubuntu, provisionadas com Terraform e configuradas com Ansible.	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	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	O storage europeu compatível com S3 é o destino da migração; as alterações no SDK são mínimas.
Azure SQL Database	Binadit Managed Cloud Platform. PostgreSQL ou MySQL com Patroni para failover e pgBackRest para recuperação point-in-time.	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	Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.	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	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	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)	Binadit Managed Cloud Platform. Kubernetes em Debian ou Talos, com networking Cilium e cert-manager para certificados.	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	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	A maioria das cargas de trabalho de Azure Functions cabe num pequeno cluster Kubernetes da UE a correr Knative.
Azure Active Directory / Entra ID	Binadit Managed Cloud Platform. Keycloak ou Authentik como identity provider, com OIDC e SAML.	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	Binadit Managed Cloud Platform. RabbitMQ, NATS, ou Redis Streams, dependendo das garantias de entrega.	As opções de queueing geridas no espaço soberano da UE são limitadas; self-managed é o padrão.
Azure Monitor / Application Insights	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki e Tempo, integrados com OpenTelemetry.	A instrumentação com OpenTelemetry torna a troca mecânica para o código da aplicação.
Azure Cosmos DB	Binadit Managed Cloud Platform. Replica sets MongoDB, ou PostgreSQL com JSONB onde o modelo de documentos é mais simples do que parece.	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)	Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.	A CrowdSec tem sede em França e está cada vez mais competitiva no espaço SIEM/IDS.
Key Vault	Binadit Managed Cloud Platform. HashiCorp Vault ou Infisical, self-hosted, com rotação automática de leases.	O Vault é a resposta soberana de nível de produção; nós operamo-lo para os clientes.
Microsoft 365 (email, Teams, OneDrive)	Binadit Managed Cloud Platform. Postfix com DKIM, SPF e DMARC, e Rspamd para filtragem.	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.

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.

Semanas 1-3

Auditoria e mapeamento de IDs

Inventariar os serviços Azure, dependências do Entra ID, integrações SSO e licenciamento. A camada de identidade é a mais demorada. Resultado: plano faseado com a migração do SSO dimensionada separadamente.
Semanas 3-6

Edge, monitorização, dependências leves

Substituir o Front Door, Azure DNS, App Insights e Blob Storage. Pré-preparar computação na UE e replicar a base de dados. Mover o CI/CD para fora do Azure DevOps, se aplicável.
Semanas 6-18

Cutover de Compute, DB e identidade

Workloads AKS para K8s managed na UE. SQL Database para PostgreSQL com replicação lógica para cutover em produção. Migração de identidade com parallel-run; corte do SSO aplicação a aplicação.

TCO a 5 anos em saídas da Azure que já realizámos: normalmente 25-45% mais barato, com as maiores poupanças a vir da eliminação de licence true-up e de bandwidth/egress. Tenha em conta: se a sua equipa usa Microsoft 365 e vai continuar a usá-lo, a migração da camada de identidade só desacopla parcialmente - essa decisão pertence ao nível da direção.

Perguntas frequentes

Ver todas as perguntas frequentes

O Microsoft Cloud for Sovereignty resolve o problema do Schrems II?

Melhora a documentação, mas não altera a jurisdição subjacente: a Microsoft Corporation continua a ser a empresa-mãe. Para workloads em que a análise depende da jurisdição da empresa-mãe (ou seja, a maioria dos workloads regulados após o Schrems II), isto não é suficiente por si só.

E quanto ao Bleu?

As ofertas soberanas licenciadas, em que uma entidade da UE opera tecnologia americana sob licença, são pseudo-soberanas - operadas por entidades sediadas na UE sob licença de um parceiro tecnológico dos EUA. Podem satisfazer requisitos regulatórios específicos (nomeadamente a certificação francesa SecNumCloud para a Bleu), mas herdam uma stack que não conseguem manter de forma independente. Para a maioria dos compradores, uma stack nativa da UE é a resposta arquitetonicamente mais simples.

Podemos abandonar o Azure mas manter o Microsoft 365?

Sim, e muitos dos nossos clientes utilizam esse modelo híbrido. O compromisso é que os dados pessoais que passam pelo M365 (conteúdo de e-mail, ficheiros do OneDrive, chat do Teams) permanecem sob processamento da Microsoft. Documente isso no seu DPA, aplique medidas suplementares (encriptação em repouso com chaves detidas na UE para pastas sensíveis) e mantenha a infraestrutura de dados de clientes na stack soberana.

Como é que isto afeta o nosso Microsoft Enterprise Agreement?

Os EAs existentes têm normalmente termos anuais ou multi-anuais; o objetivo da migração é interromper a próxima renovação ou ajustá-la ao tamanho certo, não quebrar o contrato atual. O seu gestor de conta oferecerá concessões quando ouvir "estamos a avaliar alternativas soberanas". Use isso a seu favor.

O Active Directory é substituível na prática?

Substituível por etapas. O Keycloak lida bem com OIDC/SAML/SCIM; para autenticação em domínio Windows em desktops físicos, o Samba 4 com FreeIPA é o caminho open-source estabelecido. A transição normalmente ocorre em paralelo com uma simplificação de "local de trabalho moderno" - menos SSOs por aplicação, mais OIDC padrão.

Quanto tempo demora uma saída do Azure?

Para um workload de médio porte (50-200 VMs, 1-2 bases de dados SQL, AKS, Entra ID): 16-24 semanas de tempo decorrido. Com um parceiro de infraestrutura managed a coordenar a coreografia: 10-16 semanas. A camada de identidade é o risco de calendário, não a computação.

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.

Agendar uma chamada Comparar outro fornecedor