Alternativa solo UE a Cloudflare.

Cloudflare è il vendor più esposto agli USA nella maggior parte degli stack "EU" perché si trova davanti all'utente - ogni visitatore si connette a un edge server di Cloudflare prima di raggiungere la tua origin. Le regioni EU di Cloudflare sono edge localizzati in EU, ma la società madre è una corporation del Delaware con key material controllato dagli USA e log del traffico controllati dagli USA. Per finalità Schrems II, Cloudflare davanti al traffico di dati personali è uno dei problemi più facilmente difendibili da rimuovere per primo, perché le alternative - Bunny.net (SI) e KeyCDN (CH) - hanno set di funzionalità comparabili e storie legali drammaticamente più semplici.

Stati Uniti Stack sostitutivo, solo UE 11 servizi mappati

Prenota una chiamata Scansiona prima il tuo dominio

Fornitore: Cloudflare
Sede: San Francisco, CA
Giurisdizione: Stati Uniti
Regime giuridico: CLOUD Act, FISA 702, EO 12333

"Regione UE" non è sovranità. Quattro domande decidono.

La residenza dei dati dice dove si trovano i bit. La sovranità dice quale sistema giuridico può imporne l'accesso. La risposta deve reggere su tutti e quattro i punti, altrimenti lo stack non è sovrano.

Residenza

Dove sono fisicamente archiviati i dati?

Non "nel cloud": quale datacenter, in quale paese, sotto quale giurisdizione.

Sub-responsabili

Chi altro è nel suo percorso dei dati?

Ogni fornitore che tocca i dati: il CDN, il relay e-mail, il tracker degli errori, la pipeline di analytics.

Giurisdizione

Quali leggi possono imporre la divulgazione?

Un fornitore con sede negli Stati Uniti ricade sotto FISA 702 e CLOUD Act, anche se i bit si trovano a Francoforte.

Custodia delle chiavi

Chi detiene effettivamente le chiavi di cifratura?

Se il provider cloud detiene sia i dati sia le chiavi, può leggerli, indipendentemente da qualsiasi DPA.

Non supera AWS · Azure · GCP · Regione UE

Fallisce su giurisdizione e custodia delle chiavi.

Bit nell'UE, casa madre statunitense, sub-responsabili americani nel percorso predefinito, chiavi gestite dal fornitore.

Supera Stack gestito da Binadit

Passa su tutte e quattro.

Ospitato in UE su infrastruttura con sede europea. Zero sub-responsabili statunitensi nel percorso predefinito. Chiavi del cliente o di KMS europeo. Elencati per nome nel suo DPA Articolo 28.

Perché i team se ne vanno Cloudflare

Lo schema che osserviamo: una review privacy o del DPO identifica Cloudflare come subprocessor statunitense che elabora ogni richiesta dei visitatori, inclusi indirizzi IP, fingerprint del browser (tramite Bot Management) e cookie. Secondo Schrems II, questo è un trasferimento che richiede misure supplementari - tipicamente una crittografia che Cloudflare non può leggere, il che vanifica le funzionalità WAF e Bot Management che erano il motivo dell'utilizzo di Cloudflare. La soluzione più semplice è passare a un provider di giurisdizione UE, dove l'analisi legale si riduce a "nessun trasferimento". Bunny.net è la scelta standard e la migrazione richiede realmente solo poche ore di lavoro su DNS e configurazione.

Cloudflare servizi e i loro equivalenti solo UE

Una migrazione non è "scambiare una scatola con un'altra". La mappatura sottostante è ciò che eseguiamo per i clienti che lasciano Cloudflare in base a Schrems II: piena giurisdizione UE, nessuna capogruppo statunitense nel percorso dei dati.

Cloudflare servizio	Cosa usiamo al suo posto	Nota di ingegneria
Cloudflare CDN	Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.	Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.
Cloudflare WAF	Binadit Managed Cloud Platform. Coraza o ModSecurity con l'OWASP Core Rule Set, più CrowdSec per il blocco comportamentale.	Le regole vengono calibrate sul vostro traffico reale invece di essere fornite come set predefinito, ed è proprio questo a impedire che un WAF blocchi silenziosamente clienti reali.
Cloudflare DDoS protection	Binadit Private Infrastructure. Filtraggio volumetrico a monte, con rate limiting e CrowdSec all'edge applicativo.	Gli attacchi volumetrici vengono assorbiti a monte dei tuoi server. L'abuso a livello applicativo viene gestito dove può effettivamente essere compreso, vicino al tuo traffico.
Cloudflare DNS	Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.	Le zone vengono esportate e importate come file di zona standard, quindi questa è di solito la parte meno critica di una migrazione. Abbassa i TTL con una settimana di anticipo.
Cloudflare R2 (storage)	Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.	Il vantaggio zero-egress di R2 è unico; sui provider EU, l'egress è tipicamente gratuito o molto basso, quindi l'argomento economico si trasferisce.
Cloudflare Workers	Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.	La maggior parte delle funzioni che migriamo si rivelano essere piccoli HTTP handler che funzionano bene come normali container, spesso a costi inferiori e senza cold start.
Cloudflare Pages	Binadit Managed Cloud Platform. Nginx che serve gli asset compilati, distribuiti da GitLab CI.	Il valore principale di Pages è la build pipeline; quel componente si sposta sul vostro provider CI.
Cloudflare Tunnel (Argo)	Binadit Managed Cloud Platform. Tunnel WireGuard, oppure un reverse proxy Nginx nella tua DMZ.	Netbird ha sede in Germania e offre il pattern "no-public-IP" con giurisdizione UE. Wireguard autogestito è la risposta sovrana standard.
Cloudflare Access (zero trust)	Binadit Managed Cloud Platform. WireGuard con Keycloak o Authentik davanti ai servizi interni.	Per applicazioni solo interne, un reverse proxy protetto da OIDC su infrastruttura UE è funzionalmente equivalente.
Cloudflare Stream (video)	Transcoding con FFmpeg su infrastruttura Binadit, distribuito tramite una CDN EU come Bunny.net.	Il transcoding è un workload batch che gira sulla capacità che già possiedi. La distribuzione avviene tramite normale HTTP su una CDN che configuriamo per te.
Cloudflare Bot Management	Binadit Managed Cloud Platform. CrowdSec per il rilevamento comportamentale, con rate limiting e challenge page all'edge.	CrowdSec ha sede in Francia ed è sempre più capace. Per e-commerce ad alto traffico, DataDome (anch'essa francese) è l'alternativa enterprise.

Cloudflare CDN

Cosa usiamo al suo posto: Implementiamo e gestiamo per te una CDN EU: Bunny.net o KeyCDN, con caching Nginx e Varnish sulla tua origine.
Nota di ingegneria: Il CDN è uno dei pochi livelli che non gestiamo direttamente. Scegliamo il provider EU, configuriamo cache headers, strategia di purge e origin shielding, e lo operiamo come parte del servizio gestito.

Cloudflare WAF

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Coraza o ModSecurity con l'OWASP Core Rule Set, più CrowdSec per il blocco comportamentale.
Nota di ingegneria: Le regole vengono calibrate sul vostro traffico reale invece di essere fornite come set predefinito, ed è proprio questo a impedire che un WAF blocchi silenziosamente clienti reali.

Cloudflare DDoS protection

Cosa usiamo al suo posto: Binadit Private Infrastructure. Filtraggio volumetrico a monte, con rate limiting e CrowdSec all'edge applicativo.
Nota di ingegneria: Gli attacchi volumetrici vengono assorbiti a monte dei tuoi server. L'abuso a livello applicativo viene gestito dove può effettivamente essere compreso, vicino al tuo traffico.

Cloudflare DNS

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. PowerDNS o Knot, autoritativi, firmati con DNSSEC.
Nota di ingegneria: Le zone vengono esportate e importate come file di zona standard, quindi questa è di solito la parte meno critica di una migrazione. Abbassa i TTL con una settimana di anticipo.

Cloudflare R2 (storage)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. MinIO o Ceph RGW, compatibili S3.
Nota di ingegneria: Il vantaggio zero-egress di R2 è unico; sui provider EU, l'egress è tipicamente gratuito o molto basso, quindi l'argomento economico si trasferisce.

Cloudflare Workers

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Knative o OpenFaaS sul tuo cluster Kubernetes.
Nota di ingegneria: La maggior parte delle funzioni che migriamo si rivelano essere piccoli HTTP handler che funzionano bene come normali container, spesso a costi inferiori e senza cold start.

Cloudflare Pages

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Nginx che serve gli asset compilati, distribuiti da GitLab CI.
Nota di ingegneria: Il valore principale di Pages è la build pipeline; quel componente si sposta sul vostro provider CI.

Cloudflare Tunnel (Argo)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. Tunnel WireGuard, oppure un reverse proxy Nginx nella tua DMZ.
Nota di ingegneria: Netbird ha sede in Germania e offre il pattern "no-public-IP" con giurisdizione UE. Wireguard autogestito è la risposta sovrana standard.

Cloudflare Access (zero trust)

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. WireGuard con Keycloak o Authentik davanti ai servizi interni.
Nota di ingegneria: Per applicazioni solo interne, un reverse proxy protetto da OIDC su infrastruttura UE è funzionalmente equivalente.

Cloudflare Stream (video)

Cosa usiamo al suo posto: Transcoding con FFmpeg su infrastruttura Binadit, distribuito tramite una CDN EU come Bunny.net.
Nota di ingegneria: Il transcoding è un workload batch che gira sulla capacità che già possiedi. La distribuzione avviene tramite normale HTTP su una CDN che configuriamo per te.

Cloudflare Bot Management

Cosa usiamo al suo posto: Binadit Managed Cloud Platform. CrowdSec per il rilevamento comportamentale, con rate limiting e challenge page all'edge.
Nota di ingegneria: CrowdSec ha sede in Francia ed è sempre più capace. Per e-commerce ad alto traffico, DataDome (anch'essa francese) è l'alternativa enterprise.

Come migriamo da Cloudflare

Una tipica migrazione di mid-market si svolge in tre fasi. I numeri qui sotto assumono un team di ingegneria di 6-10 persone e uno stack applicativo moderatamente complesso.

Giorni 1-3

Inventario e classificazione del rischio

Elenca ogni prodotto Cloudflare in uso: CDN, DNS, regole WAF, Workers, Pages, R2, Tunnel, Access. Mappa ciascuno a un'esposizione di dati personali (tocca PII?) e alla complessità di migrazione. Output: lista di priorità, di solito CDN/DNS per primi.
Giorni 4-10

Swap soft (CDN, DNS, R2)

Provisioning delle pull zone Bunny per gli stessi hostname. Test con un hostname di staging. Cutover DNS con pre-staging del TTL basso. Migrazione R2 → Bunny Storage tramite parallel-write. Regole WAF portate manualmente su Bunny WAF.
Settimane 2-6

Componenti complessi (Workers, Tunnel, Access)

Il codice worker è stato revisionato e portato su Bunny Edge Scripting, riscritto come middleware lato origine, oppure self-hosted su Knative. Tunnel sostituito con Netbird o Wireguard self-managed. Access sostituito con Pomerium o Authelia. I workload di Pages spostati su GitLab Pages o self-hosted.

Le migrazioni da Cloudflare a Bunny riducono quasi sempre la spesa mensile del 40-70% ai volumi tipici del mid-market. Le eccezioni sono gli stack ad alto uso di Workers (dove l'infrastruttura self-hosted equivalente ha un costo fisso più alto) e gli stack Pages ad alto traffico (dove il tier gratuito aggressivo di Cloudflare è difficile da eguagliare).

Domande frequenti

Visualizza tutte le domande frequenti

Cloudflare ora ha piani dati solo EU - questo risolve il problema?

La "Data Localization Suite" di Cloudflare può mantenere il traffico EU su edge EU e chiavi EU, il che affronta la residenza dei dati. Non affronta la giurisdizione: Cloudflare Inc. rimane una corporation statunitense soggetta al CLOUD Act. Per la maggior parte delle analisi Schrems II, il prodotto di data-localization è un miglioramento ma non piena sovranità.

Il cambio di CDN influirà sulle prestazioni per i visitatori europei?

Per gli utenti europei in particolare, Bunny.net spesso offre prestazioni pari o superiori a Cloudflare perché la densità di POP EU è maggiore in rapporto al traffico. Test reali su migrazioni e-commerce hanno mostrato miglioramenti del TTFB di 10-30ms per il traffico specifico EU. Per gli utenti globali (USA, APAC), il numero di POP di Cloudflare è maggiore.

Come gestiamo la sostituzione di Cloudflare Workers?

Tre schemi a seconda del Worker: (1) le riscritture di richieste banali migrano su Bunny Edge Scripting senza modifiche, (2) i Worker che comunicano con KV / Durable Objects richiedono una riprogettazione - tipicamente la logica si sposta sull'origin e utilizza Redis o Postgres, (3) i Worker che fungono da endpoint API diventano piccoli servizi Knative su infrastruttura UE.

Bunny.net è una reale alternativa sicura rispetto a Schrems II?

Bunny.net è BunnyWay d.o.o., con sede a Lubiana, Slovenia (Stato membro UE). L'entità legale è interamente sotto giurisdizione UE. Il loro elenco di subprocessor pubblicato è breve e focalizzato sull'UE. Ai fini Schrems II, l'analisi si riduce a "nessun trasferimento verso paesi terzi", il che è nettamente più semplice rispetto allo scenario di localizzazione dei dati di Cloudflare.

E per quanto riguarda Fastly o Akamai?

Entrambe con sede negli Stati Uniti. Fastly è a San Francisco; Akamai è a Cambridge, MA. Stessa analisi CLOUD Act di Cloudflare. Non sono "più semplici" rispetto a Cloudflare dal punto di vista Schrems II; sono semplicemente provider statunitensi diversi con set di funzionalità diversi.

Quanto tempo richiede una migrazione da Cloudflare?

Per un workload tipico (CDN, DNS, WAF di base, senza Workers): 1-2 settimane di tempo trascorso. Per una configurazione con uso intensivo di Workers o dipendente da Tunnel: 4-8 settimane. Possiamo gestire l'intera operazione come migrazione gestita se preferisci che venga eseguita senza consumare la capacità del tuo team.

Pianifica la tua uscita da Cloudflare.

Chiamata di scoping di 30 minuti. Mappiamo il tuo stack rispetto alle alternative solo UE, stimiamo lo sforzo di migrazione e ti diciamo se è la scelta giusta.

Prenota una chiamata Confronta un altro provider