Alternativa solo UE a Cloudflare.

Cloudflare es el proveedor más expuesto a EE. UU. en la mayoría de los stacks "UE" porque se sitúa delante del usuario - cada visitante se conecta a un servidor edge de Cloudflare antes de llegar a tu origin. Las regiones UE de Cloudflare son edges ubicados en la UE, pero la empresa matriz es una corporación de Delaware con material criptográfico controlado por EE. UU. y logs de tráfico controlados por EE. UU. A efectos de Schrems II, Cloudflare delante del tráfico de datos personales es uno de los problemas más defendibles de eliminar primero, porque las alternativas - Bunny.net (SI) y KeyCDN (CH) - tienen conjuntos de funciones comparables y historias legales mucho más simples.

Estados Unidos Pila de reemplazo, solo UE 11 servicios mapeados
Proveedor
Cloudflare
Sede
San Francisco, CA
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 Cloudflare

El patrón que vemos: una revisión de privacidad o del DPO identifica a Cloudflare como subprocesador estadounidense que procesa cada solicitud de visitante, incluyendo direcciones IP, huellas de navegador (via Bot Management) y cookies. Bajo Schrems II eso es una transferencia que necesita medidas suplementarias, típicamente cifrado que Cloudflare no pueda leer, lo cual anula las funciones de WAF y Bot Management que eran la razón para usar Cloudflare. La respuesta más simple es cambiar a un proveedor de jurisdicción de la UE donde el análisis legal se reduce a "no hay transferencia". Bunny.net es el destino estándar y la migración es, en la práctica, unas pocas horas de trabajo de DNS y configuración.

Cloudflare 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 Cloudflare por motivos de Schrems II: jurisdicción europea completa, sin matriz estadounidense en la ruta de datos.

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

Cloudflare WAF

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
Las reglas se ajustan según tu tráfico en lugar de venir como un conjunto predeterminado, que es lo que evita que un WAF bloquee silenciosamente a clientes reales.

Cloudflare DDoS protection

Lo que usamos en su lugar
Binadit Private Infrastructure. Filtrado volumétrico upstream, con rate limiting y CrowdSec en el edge de la aplicación.
Nota de ingeniería
Los ataques volumétricos se absorben antes de llegar a tus servidores. El abuso en la capa de aplicación se gestiona donde realmente puede entenderse, junto a tu tráfico.

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

Cloudflare R2 (storage)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatible con S3.
Nota de ingeniería
La propuesta de egress cero de R2 es única; en proveedores de la UE, el egress también suele ser gratuito o muy bajo, por lo que el argumento de costo se traslada igual.

Cloudflare Workers

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 funciones que migramos resultan ser pequeños manejadores HTTP que funcionan perfectamente como contenedores ordinarios, a menudo más económicos y sin cold start.

Cloudflare Pages

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Nginx sirviendo assets compilados, desplegado desde GitLab CI.
Nota de ingeniería
El valor principal de Pages es el pipeline de build; esa pieza se traslada a su proveedor de CI.

Cloudflare Tunnel (Argo)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. Túneles WireGuard, o un reverse proxy Nginx en tu propia DMZ.
Nota de ingeniería
Netbird tiene su sede en Alemania y ofrece el patrón "sin IP pública" con jurisdicción de la UE. Wireguard autogestionado es la respuesta soberana estándar.

Cloudflare Access (zero trust)

Lo que usamos en su lugar
Binadit Managed Cloud Platform. WireGuard con Keycloak o Authentik delante de los servicios internos.
Nota de ingeniería
Para aplicaciones de uso interno exclusivo, un proxy inverso protegido con OIDC en infraestructura de la UE es funcionalmente equivalente.

Cloudflare Stream (video)

Lo que usamos en su lugar
Transcodificación con FFmpeg en infraestructura de Binadit, entregada a través de un CDN de la UE como Bunny.net.
Nota de ingeniería
La transcodificación es una carga de trabajo por lotes que se ejecuta sobre capacidad que ya tienes. La entrega es HTTP ordinario a través de un CDN que configuramos para ti.

Cloudflare Bot Management

Lo que usamos en su lugar
Binadit Managed Cloud Platform. CrowdSec para detección de comportamiento, con rate limiting y páginas de desafío en el edge.
Nota de ingeniería
CrowdSec tiene su sede en Francia y es cada vez más capaz. Para e-commerce de alto tráfico, DataDome (también francesa) es la alternativa empresarial.

Cómo migramos desde Cloudflare

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.

  1. Días 1-3

    Inventario y clasificación de riesgo

    Listar cada producto de Cloudflare en uso: CDN, DNS, reglas WAF, Workers, Pages, R2, Tunnel, Access. Mapear cada uno con una exposición de datos personales (¿toca PII?) y complejidad de migración. Resultado: lista de prioridades, generalmente CDN/DNS primero.

  2. Días 4-10

    Cambio suave (CDN, DNS, R2)

    Aprovisionar pull zones de Bunny para los mismos hostnames. Probar con un hostname de staging. Realizar el corte de DNS con TTL bajo preconfigurado. Migración de R2 a Bunny Storage mediante escritura en paralelo. Reglas de WAF trasladadas manualmente a Bunny WAF.

  3. Semanas 2-6

    Piezas difíciles (Workers, Tunnel, Access)

    Código de worker revisado y migrado a Bunny Edge Scripting, reescrito como middleware del lado del origen, o autoalojado en Knative. Tunnel sustituido por Netbird o Wireguard autogestionado. Access sustituido por Pomerium o Authelia. Las cargas de trabajo de Pages se trasladan a GitLab Pages o a alojamiento propio.

Las migraciones de Cloudflare a Bunny casi siempre reducen el gasto mensual entre un 40% y un 70% en volúmenes típicos de mid-market. Las excepciones son los stacks intensivos en Workers (donde la infraestructura self-hosted equivalente tiene un coste fijo más alto) y los stacks de Pages con tráfico alto (donde el generoso plan gratuito de Cloudflare es difícil de igualar).

Cloudflare ya tiene planes de datos exclusivos para la UE - ¿eso resuelve el problema?
La "Data Localization Suite" de Cloudflare puede mantener el tráfico UE en edges UE y claves UE, lo que aborda la residencia de datos. No aborda la jurisdicción: Cloudflare Inc. sigue siendo una corporación estadounidense sujeta a la CLOUD Act. Para la mayoría de los análisis Schrems II, el producto de localización de datos es una mejora, pero no una soberanía completa.
¿Afectará el cambio de CDN al rendimiento para los visitantes europeos?
Para usuarios europeos específicamente, Bunny.net a menudo rinde igual o mejor que Cloudflare porque su densidad de POPs en la UE es mayor por tráfico. Pruebas reales en migraciones de e-commerce han mostrado mejoras de TTFB de 10-30 ms para tráfico específico de la UE. Para usuarios globales (EE. UU., APAC), el número de POPs de Cloudflare es mayor.
¿Cómo manejamos el reemplazo de Cloudflare Workers?
Tres patrones según el Worker: (1) las reescrituras de solicitudes triviales se mueven a Bunny Edge Scripting sin cambios, (2) los Workers que hablan con KV / Durable Objects necesitan una re-arquitectura, típicamente la lógica se mueve al origen y usa Redis o Postgres, (3) los Workers que actúan como endpoints de API se convierten en pequeños servicios Knative sobre infraestructura de la UE.
¿Es Bunny.net una alternativa realmente segura frente a Schrems II?
Bunny.net es BunnyWay d.o.o., con sede en Liubliana, Eslovenia (estado miembro de la UE). La entidad legal está completamente bajo jurisdicción de la UE. Su lista publicada de subprocesadores es corta y centrada en la UE. Para Schrems II, el análisis se reduce a "sin transferencia a un tercer país", lo cual es considerablemente más sencillo que el planteamiento de localización de datos de Cloudflare.
¿Qué pasa con Fastly o Akamai?
Ambas con sede en EE. UU. Fastly está en San Francisco; Akamai en Cambridge, MA. Mismo análisis de la CLOUD Act que Cloudflare. No son más sencillas frente a Schrems II que Cloudflare; son proveedores de EE. UU. distintos con conjuntos de funciones diferentes.
¿Cuánto tiempo toma una migración de Cloudflare?
Para una carga de trabajo típica (CDN, DNS, WAF básico, sin Workers): 1-2 semanas transcurridas. Para una configuración con uso intensivo de Workers o dependiente de Tunnel: 4-8 semanas. Podemos ejecutar todo el proceso como una migración gestionada si prefieres que se realice sin consumir la capacidad de tu equipo.

Planifique su salida de Cloudflare.

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.