Alternativa solo UE a Cloudflare.

Cloudflare is the most US-exposed vendor in most "EU" stacks because it sits in front of the user - every visitor connects to a Cloudflare edge server before reaching your origin. The EU regions of Cloudflare are EU-located edges, but the parent company is a Delaware corporation with US-controlled key material and US-controlled traffic logs. For Schrems II purposes, Cloudflare in front of personal-data traffic is one of the most defensible problems to remove first, because the alternatives - Bunny.net (SI) and KeyCDN (CH) - have comparable feature sets and dramatically simpler legal stories.

United States Pila de reemplazo, solo UE 11 servicios mapeados
Proveedor
Cloudflare
Sede
San Francisco, CA
Jurisdicción
United States
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

The pattern we see: a privacy or DPO review identifies Cloudflare as a US subprocessor that processes every visitor request including IP addresses, browser fingerprints (via Bot Management) and cookies. Under Schrems II that is a transfer that needs supplementary measures - typically encryption that Cloudflare cannot read, which defeats the WAF and Bot Management features that were the reason for using Cloudflare. The simpler answer is to swap to an EU-jurisdictional provider where the legal analysis collapses to "no transfer." Bunny.net is the standard target and the migration is genuinely a few hours of DNS and configuration work.

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. Days 1-3

    Inventory & risk-rank

    List every Cloudflare product in use: CDN, DNS, WAF rules, Workers, Pages, R2, Tunnel, Access. Map each to a personal-data exposure (does it touch PII?) and migration complexity. Output: priority list, usually CDN/DNS first.

  2. Days 4-10

    Soft swap (CDN, DNS, R2)

    Provision Bunny pull zones for the same hostnames. Test with a staging hostname. Cut DNS over with low TTL pre-stage. R2 → Bunny Storage migration via parallel-write. WAF rules ported manually to Bunny WAF.

  3. Weeks 2-6

    Hard pieces (Workers, Tunnel, Access)

    Worker code reviewed and either ported to Bunny Edge Scripting, rewritten as origin-side middleware, or self-hosted on Knative. Tunnel replaced with Netbird or self-managed Wireguard. Access replaced with Pomerium or Authelia. Pages workloads moved to GitLab Pages or self-hosted.

Cloudflare-to-Bunny migrations almost always reduce monthly spend by 40-70% at typical mid-market volumes. The exceptions are Workers-heavy stacks (where the equivalent self-hosted infrastructure has higher fixed cost) and high-traffic Pages stacks (where Cloudflare's aggressive free tier is hard to match).

Cloudflare has EU-only data plans now - does that solve it?
Cloudflare's "Data Localization Suite" can keep EU traffic on EU edges and EU keys, which addresses residency. It does not address jurisdiction: Cloudflare Inc. remains a US corporation subject to the CLOUD Act. For most Schrems II analyses, the data-localization product is an improvement but not full sovereignty.
Will switching CDN affect performance for European visitors?
For European users specifically, Bunny.net often performs equal or better than Cloudflare because their EU POP density is higher per-traffic. Real-world tests on e-commerce migrations have shown TTFB improvements of 10-30ms for EU-specific traffic. For global users (US, APAC), Cloudflare's POP count is larger.
How do we handle Cloudflare Workers replacement?
Three patterns depending on the Worker: (1) trivial request rewrites move to Bunny Edge Scripting unchanged, (2) Workers that talk to KV / Durable Objects need a re-architect - typically the logic moves to the origin and uses Redis or Postgres, (3) Workers acting as API endpoints become small Knative services on EU infrastructure.
Is Bunny.net a real Schrems II-safe alternative?
Bunny.net is BunnyWay d.o.o., headquartered in Ljubljana, Slovenia (EU member). The legal entity is fully under EU jurisdiction. Their published subprocessor list is short and EU-focused. For Schrems II, the analysis collapses to "no third-country transfer" which is materially easier than Cloudflare's data-localization story.
What about Fastly or Akamai?
Both US-headquartered. Fastly is San Francisco; Akamai is Cambridge, MA. Same CLOUD Act analysis as Cloudflare. They are not Schrems II-easier than Cloudflare; they are different US providers with different feature sets.
How long does a Cloudflare migration take?
For a typical workload (CDN, DNS, basic WAF, no Workers): 1-2 weeks elapsed. For a Workers-heavy or Tunnel-dependent setup: 4-8 weeks. We can run the whole thing as a managed migration if you want it done without burning your team's capacity.

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.