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.
- 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.
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.
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.
-
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.
-
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.
-
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).
Preguntas frecuentes
Cloudflare ya tiene planes de datos exclusivos para la UE - ¿eso resuelve el problema?
¿Afectará el cambio de CDN al rendimiento para los visitantes europeos?
¿Cómo manejamos el reemplazo de Cloudflare Workers?
¿Es Bunny.net una alternativa realmente segura frente a Schrems II?
¿Qué pasa con Fastly o Akamai?
¿Cuánto tiempo toma una migración de Cloudflare?
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.