Alternativa solo UE a Microsoft Azure.

Microsoft Azure es la nube que más a menudo se defiende con las palabras "pero ya usamos Microsoft para todo". Esa defensa no sobrevive a un análisis Schrems II: Microsoft Corporation es una empresa estadounidense, cada subsidiaria de Azure está controlada por EE. UU., y Microsoft ha reconocido explícitamente en un tribunal (Microsoft Ireland, 2018) que cumpliría con un proceso legal estadounidense válido para datos ubicados en cualquier parte del mundo - que es precisamente lo que la CLOUD Act codificó después. Las iniciativas "Microsoft Cloud for Sovereignty" y Bleu (Microsoft × Capgemini × Orange) son interesantes, pero la tecnología está licenciada por una matriz estadounidense. Para una soberanía europea genuina, hay que salir. A continuación, el mapa.

Estados Unidos Pila de reemplazo, solo UE 14 servicios mapeados

Agendar una llamada Escanee primero su dominio

Proveedor: Microsoft Azure
Sede: Redmond, WA
Jurisdicción: Estados Unidos
Régimen legal: CLOUD Act, FISA 702, EO 12333

"Región UE" no es soberanía. Cuatro preguntas lo deciden.

La residencia de datos dice dónde están los bits. La soberanía dice qué sistema legal puede obligar al acceso. La respuesta debe sostenerse en los cuatro puntos, o la pila no es soberana.

Residencia

¿Dónde se almacenan físicamente los datos?

No "en la nube": qué centro de datos, en qué país, bajo qué jurisdicción.

Subprocesadores

¿Quién más está en su ruta de datos?

Cada proveedor que toca los datos: el CDN, el relay de correo, el rastreador de errores, el pipeline de analítica.

Jurisdicción

¿Qué leyes pueden obligar a la divulgación?

Un proveedor con sede en EE. UU. está sujeto a la FISA 702 y a la CLOUD Act, aunque los datos estén en Fráncfort.

Custodia de claves

¿Quién posee realmente las claves de cifrado?

Si el proveedor cloud posee tanto los datos como las claves, puede leerlos, con independencia de cualquier DPA.

No cumple AWS · Azure · GCP · Región de la UE

Falla en jurisdicción y custodia de claves.

Bits en la UE, matriz con sede en EE. UU., subprocesadores estadounidenses en la ruta por defecto, claves gestionadas por el proveedor.

Cumple Stack gestionado por Binadit

Pasa en los cuatro.

Alojado en la UE sobre infraestructura con sede europea. Cero subprocesadores estadounidenses en la ruta por defecto. Claves del cliente o de un KMS europeo. Nombrados en su DPA del Artículo 28.

Por qué los equipos están saliendo Microsoft Azure

Las salidas de Azure suelen originarse por uno de tres factores: una licitación del sector público que excluye explícitamente a los procesadores bajo jurisdicción de EE. UU., una auditoría de servicios sanitarios o financieros que señaló Microsoft 365 + Azure como un riesgo de concentración único bajo DORA, o un CISO que calculó que los costes de true-up de licencias y los créditos "gratuitos" de Azure se traducen en realidad en un vendor lock-in de seis cifras. El ecosistema de Azure tiene un acoplamiento más estrecho que AWS - Active Directory, Office 365, Defender, Sentinel suelen estar todos involucrados - lo que hace que la migración sea más invasiva que su equivalente en AWS. Sigue siendo factible; lo hemos hecho.

Microsoft Azure servicios y sus equivalentes solo en la UE

Una migración no es "cambiar una caja por otra". El mapeo a continuación es lo que ejecutamos para los clientes que dejan Microsoft Azure por motivos de Schrems II: jurisdicción europea completa, sin matriz estadounidense en la ruta de datos.

Microsoft Azure servicio	Lo que usamos en su lugar	Nota de ingeniería
Azure Virtual Machines	Binadit Managed Cloud Platform. Máquinas virtuales KVM sobre Debian o Ubuntu, aprovisionadas con Terraform y configuradas con Ansible.	La migración de IaaS es sencilla; el capítulo de licenciamiento de Windows requiere más consideración (BYOL o migrar a Linux donde sea posible).
Azure Blob Storage	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatible con S3.	El almacenamiento compatible con S3 en la UE es el destino de migración; los cambios en el SDK son mínimos.
Azure SQL Database	Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni para failover y pgBackRest para recuperación point-in-time.	La migración del esquema desde Azure SQL (variante T-SQL) es la tarea individual más larga; herramientas como AWS SCT o pgloader ayudan. Suele ser un buen momento para revisar las opciones de ORM.
Azure Front Door / CDN	Implementamos y operamos una CDN en la UE para ti: Bunny.net o KeyCDN, con caching de Nginx y Varnish en tu origin.	Un CDN es una de las pocas capas que no operamos nosotros mismos. Elegimos el proveedor de la UE, configuramos las cabeceras de caché, la estrategia de purga y el origin shielding, y lo operamos como parte del servicio gestionado.
Azure DNS	Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativo, firmado con DNSSEC.	Las zonas se exportan e importan como archivos de zona estándar, por lo que suele ser la parte menos problemática de una migración. Reduce los TTL una semana antes.
AKS (managed Kubernetes)	Binadit Managed Cloud Platform. Kubernetes sobre Debian o Talos, con networking Cilium y cert-manager para certificados.	Los Helm charts y YAML se transfieren sin problemas; los addons específicos de Azure (Application Gateway Ingress, Azure CNI) necesitan reemplazarse con equivalentes estándar.
Azure Functions	Binadit Managed Cloud Platform. Knative u OpenFaaS en tu clúster de Kubernetes.	La mayoría de las cargas de trabajo de Azure Functions encajan en un pequeño clúster de Kubernetes de la UE ejecutando Knative.
Azure Active Directory / Entra ID	Binadit Managed Cloud Platform. Keycloak o Authentik como proveedor de identidad, con OIDC y SAML.	La migración individual más difícil. Planifica una ventana de ejecución paralela de 3 meses. Las integraciones SSO entre SaaS necesitan remapearse.
Azure Service Bus / Event Grid	Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, según las garantías de entrega.	Las opciones de colas gestionadas en el espacio soberano de la UE son limitadas; el modelo autogestionado es el estándar.
Azure Monitor / Application Insights	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki y Tempo, integrados con OpenTelemetry.	La instrumentación con OpenTelemetry hace que el cambio sea mecánico para el código de la aplicación.
Azure Cosmos DB	Binadit Managed Cloud Platform. Replica sets de MongoDB, o PostgreSQL con JSONB donde el modelo de documentos es más simple de lo que parece.	No existe un reemplazo 1:1 para el patrón activo-activo multirregión global; si su carga de trabajo realmente necesita ese patrón, la conversación es diferente.
Defender / Sentinel (security)	Binadit Managed Cloud Platform. Coraza o ModSecurity con el OWASP Core Rule Set, más CrowdSec para el bloqueo por comportamiento.	CrowdSec tiene su sede en Francia y es cada vez más competitiva en el espacio SIEM/IDS.
Key Vault	Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, autoalojado, con rotación automática de leases.	Vault es la respuesta soberana de calidad producción; la operamos para nuestros clientes.
Microsoft 365 (email, Teams, OneDrive)	Binadit Managed Cloud Platform. Postfix con DKIM, SPF y DMARC, y Rspamd para filtrado.	A menudo es la conversación política más difícil, más que la migración de infraestructura en sí. Con frecuencia se mantiene en M365 con exposición documentada en lugar de migrarse.

Azure Virtual Machines

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Máquinas virtuales KVM sobre Debian o Ubuntu, aprovisionadas con Terraform y configuradas con Ansible.
Nota de ingeniería: La migración de IaaS es sencilla; el capítulo de licenciamiento de Windows requiere más consideración (BYOL o migrar a Linux donde sea posible).

Azure Blob Storage

Lo que usamos en su lugar: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatible con S3.
Nota de ingeniería: El almacenamiento compatible con S3 en la UE es el destino de migración; los cambios en el SDK son mínimos.

Azure SQL Database

Lo que usamos en su lugar: Binadit Managed Cloud Platform. PostgreSQL o MySQL con Patroni para failover y pgBackRest para recuperación point-in-time.
Nota de ingeniería: La migración del esquema desde Azure SQL (variante T-SQL) es la tarea individual más larga; herramientas como AWS SCT o pgloader ayudan. Suele ser un buen momento para revisar las opciones de ORM.

Azure Front Door / CDN

Lo que usamos en su lugar: Implementamos y operamos una CDN en la UE para ti: Bunny.net o KeyCDN, con caching de Nginx y Varnish en tu origin.
Nota de ingeniería: Un CDN es una de las pocas capas que no operamos nosotros mismos. Elegimos el proveedor de la UE, configuramos las cabeceras de caché, la estrategia de purga y el origin shielding, y lo operamos como parte del servicio gestionado.

Azure DNS

Lo que usamos en su lugar: Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativo, firmado con DNSSEC.
Nota de ingeniería: Las zonas se exportan e importan como archivos de zona estándar, por lo que suele ser la parte menos problemática de una migración. Reduce los TTL una semana antes.

AKS (managed Kubernetes)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Kubernetes sobre Debian o Talos, con networking Cilium y cert-manager para certificados.
Nota de ingeniería: Los Helm charts y YAML se transfieren sin problemas; los addons específicos de Azure (Application Gateway Ingress, Azure CNI) necesitan reemplazarse con equivalentes estándar.

Azure Functions

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Knative u OpenFaaS en tu clúster de Kubernetes.
Nota de ingeniería: La mayoría de las cargas de trabajo de Azure Functions encajan en un pequeño clúster de Kubernetes de la UE ejecutando Knative.

Azure Active Directory / Entra ID

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Keycloak o Authentik como proveedor de identidad, con OIDC y SAML.
Nota de ingeniería: La migración individual más difícil. Planifica una ventana de ejecución paralela de 3 meses. Las integraciones SSO entre SaaS necesitan remapearse.

Azure Service Bus / Event Grid

Lo que usamos en su lugar: Binadit Managed Cloud Platform. RabbitMQ, NATS o Redis Streams, según las garantías de entrega.
Nota de ingeniería: Las opciones de colas gestionadas en el espacio soberano de la UE son limitadas; el modelo autogestionado es el estándar.

Azure Monitor / Application Insights

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki y Tempo, integrados con OpenTelemetry.
Nota de ingeniería: La instrumentación con OpenTelemetry hace que el cambio sea mecánico para el código de la aplicación.

Azure Cosmos DB

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Replica sets de MongoDB, o PostgreSQL con JSONB donde el modelo de documentos es más simple de lo que parece.
Nota de ingeniería: No existe un reemplazo 1:1 para el patrón activo-activo multirregión global; si su carga de trabajo realmente necesita ese patrón, la conversación es diferente.

Defender / Sentinel (security)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Coraza o ModSecurity con el OWASP Core Rule Set, más CrowdSec para el bloqueo por comportamiento.
Nota de ingeniería: CrowdSec tiene su sede en Francia y es cada vez más competitiva en el espacio SIEM/IDS.

Key Vault

Lo que usamos en su lugar: Binadit Managed Cloud Platform. HashiCorp Vault o Infisical, autoalojado, con rotación automática de leases.
Nota de ingeniería: Vault es la respuesta soberana de calidad producción; la operamos para nuestros clientes.

Microsoft 365 (email, Teams, OneDrive)

Lo que usamos en su lugar: Binadit Managed Cloud Platform. Postfix con DKIM, SPF y DMARC, y Rspamd para filtrado.
Nota de ingeniería: A menudo es la conversación política más difícil, más que la migración de infraestructura en sí. Con frecuencia se mantiene en M365 con exposición documentada en lugar de migrarse.

Cómo migramos desde Microsoft Azure

Una migración típica de mid-market se desarrolla en tres fases. Los números a continuación asumen un equipo de ingeniería de 6 a 10 personas y un stack de aplicación moderadamente complejo.

Semanas 1-3

Auditoría y mapeo de IDs

Inventariar los servicios de Azure, las dependencias de Entra ID, las integraciones SSO y el licenciamiento. La capa de identidad es la de mayor duración. Resultado: plan por fases con la migración de SSO delimitada por separado.
Semanas 3-6

Edge, monitoreo, dependencias blandas

Reemplazar Front Door, Azure DNS, App Insights y Blob Storage. Preconfigurar cómputo en la UE y replicar la base de datos. Trasladar CI/CD fuera de Azure DevOps si corresponde.
Semanas 6-18

Transición de Compute, DB e identidad

Workloads de AKS a K8s gestionado en la UE. SQL Database a PostgreSQL con replicación lógica para un cutover en vivo. Migración de identidad con ejecución en paralelo; se traslada el SSO por aplicación.

TCO a 5 años de las salidas de Azure que hemos ejecutado: normalmente entre un 25-45% más económico, con el mayor ahorro proveniente de evitar el true-up de licencias y del ancho de banda/egress. Tenga en cuenta: si su equipo usa Microsoft 365 y va a seguir usándolo, la migración de la capa de identidad solo se desacopla parcialmente; esa decisión corresponde al nivel directivo.

Preguntas frecuentes

Ver todas las preguntas frecuentes

¿Microsoft Cloud for Sovereignty resuelve el problema de Schrems II?

Mejora la narrativa de documentación pero no cambia la jurisdicción subyacente: Microsoft Corporation sigue siendo la matriz. Para cargas de trabajo donde el análisis depende de la jurisdicción de la matriz (es decir, la mayoría de las cargas de trabajo reguladas tras Schrems II), no es suficiente por sí solo.

¿Qué pasa con Bleu?

Las ofertas soberanas con licencia, donde una entidad de la UE opera tecnología estadounidense bajo licencia, son pseudo-soberanas: operadas por entidades con sede en la UE bajo licencia de un socio tecnológico estadounidense. Pueden satisfacer requisitos regulatorios específicos (en particular la certificación francesa SecNumCloud para Bleu) pero heredan una pila que no pueden mantener de forma independiente. Para la mayoría de los compradores, una pila nativa de la UE es la respuesta arquitectónicamente más sencilla.

¿Podemos dejar Azure pero mantener Microsoft 365?

Sí, y muchos de nuestros clientes ejecutan ese modelo híbrido. La contrapartida es que los datos personales que fluyen a través de M365 (contenido de correo, archivos de OneDrive, chat de Teams) permanecen bajo el procesamiento de Microsoft. Documéntalo en tu DPA, aplica medidas complementarias (cifrado en reposo con claves gestionadas en la UE para carpetas sensibles) y mantén la infraestructura de datos de clientes en la pila soberana.

¿Cómo afecta esto a nuestro Microsoft Enterprise Agreement?

Los EA existentes suelen tener plazos anuales o multianuales; el objetivo de la migración es detener la próxima renovación o ajustarla, no romper el contrato actual. Tu gestor de cuenta ofrecerá concesiones al escuchar "estamos evaluando alternativas soberanas". Aprovecha eso.

¿Es reemplazable Active Directory en la práctica?

Reemplazable en etapas. Keycloak maneja bien OIDC/SAML/SCIM; para la autenticación de dominio Windows en escritorios físicos, Samba 4 con FreeIPA es la vía open-source establecida. La transición normalmente se realiza junto con una simplificación hacia un "lugar de trabajo moderno": menos SSO por aplicación, más OIDC estándar.

¿Cuánto tiempo toma una salida de Azure?

Para una carga de trabajo de tamaño medio (50-200 VMs, 1-2 bases de datos SQL, AKS, Entra ID): 16-24 semanas de tiempo transcurrido. Con un partner de infraestructura gestionada liderando la coordinación: 10-16 semanas. La capa de identidad es el riesgo del cronograma, no el cómputo.

Planifique su salida de Microsoft Azure.

Llamada de alcance de 30 minutos. Mapeamos su stack frente a alternativas solo UE, estimamos el esfuerzo de migración y le decimos si es la decisión correcta.

Agendar una llamada Comparar otro proveedor