Alternativa apenas UE a Cloudflare.

A Cloudflare é o fornecedor mais exposto aos EUA na maioria dos stacks "UE" porque se posiciona à frente do utilizador - cada visitante liga-se a um edge server da Cloudflare antes de chegar à sua origem. As regiões UE da Cloudflare são edges localizados na UE, mas a empresa-mãe é uma corporação do Delaware com material de chaves controlado pelos EUA e logs de tráfego controlados pelos EUA. Para efeitos de Schrems II, a Cloudflare à frente de tráfego de dados pessoais é um dos problemas mais defensáveis de remover primeiro, porque as alternativas - Bunny.net (SI) e KeyCDN (CH) - têm conjuntos de funcionalidades comparáveis e histórias legais drasticamente mais simples.

Estados Unidos Stack de substituição, apenas UE 11 serviços mapeados

Agendar uma chamada Verifique primeiro o seu domínio

Fornecedor: Cloudflare
Sede: San Francisco, CA
Jurisdição: Estados Unidos
Regime jurídico: CLOUD Act, FISA 702, EO 12333

"Região UE" não é soberania. Quatro perguntas decidem.

A residência de dados diz onde estão os bits. A soberania diz que sistema legal pode obrigar ao acesso. A resposta tem de se sustentar nos quatro pontos, caso contrário a stack não é soberana.

Residência

Onde os dados estão fisicamente armazenados?

Não "na cloud": que centro de dados, em que país, sob que jurisdição.

Subprocessadores

Quem mais está no seu caminho de dados?

Cada fornecedor que toca os dados: o CDN, o relay de e-mail, o rastreador de erros, o pipeline de analytics.

Jurisdição

Quais leis podem forçar a divulgação?

Um fornecedor com sede nos EUA está sujeito à FISA 702 e à CLOUD Act, mesmo com os dados em Frankfurt.

Custódia de chaves

Quem detém realmente as chaves de cifragem?

Se o fornecedor cloud detém tanto os dados como as chaves, consegue lê-los, independentemente de qualquer DPA.

Não cumpre AWS · Azure · GCP · Região da UE

Falha em jurisdição e custódia de chaves.

Bits na UE, casa-mãe nos EUA, subprocessadores americanos no caminho predefinido, chaves geridas pelo fornecedor.

Cumpre Stack gerida pela Binadit

Passa nos quatro.

Hospedado na UE em infraestrutura com sede europeia. Zero subprocessadores americanos no caminho padrão. Chaves do cliente ou de KMS europeu. Nomeados no seu DPA Artigo 28.

Porque é que as equipas estão a sair Cloudflare

O padrão que vemos: uma revisão de privacidade ou do DPO identifica a Cloudflare como subprocessador nos EUA que processa todos os pedidos de visitantes, incluindo endereços IP, fingerprints de browser (via Bot Management) e cookies. Ao abrigo do Schrems II, isso é uma transferência que precisa de medidas suplementares - tipicamente encriptação que a Cloudflare não consegue ler, o que anula as funcionalidades de WAF e Bot Management que foram a razão para usar a Cloudflare. A resposta mais simples é mudar para um provedor de jurisdição na UE, onde a análise jurídica se resume a "nenhuma transferência". A Bunny.net é o alvo standard e a migração é genuinamente algumas horas de trabalho de DNS e configuração.

Cloudflare serviços e os seus equivalentes apenas na UE

Uma migração não é "trocar uma caixa por outra". O mapeamento abaixo é o que executamos para clientes que saem de Cloudflare com base em Schrems II: jurisdição da UE completa, sem empresa-mãe norte-americana no caminho dos dados.

Cloudflare serviço	O que usamos no lugar	Nota de engenharia
Cloudflare CDN	Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.	A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.
Cloudflare WAF	Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.	As regras são ajustadas com base no seu tráfego em vez de serem entregues como um conjunto predefinido, o que é o que impede um WAF de bloquear silenciosamente clientes reais.
Cloudflare DDoS protection	Binadit Private Infrastructure. Filtragem volumétrica upstream, com rate limiting e CrowdSec na edge da aplicação.	Ataques volumétricos são absorvidos a montante dos seus servers. Abusos na camada de aplicação são tratados onde podem efetivamente ser compreendidos, junto ao seu tráfego.
Cloudflare DNS	Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.	As zones são exportadas e importadas como ficheiros de zone standard, pelo que esta é geralmente a parte menos problemática de uma migração. Reduza os TTLs uma semana antes.
Cloudflare R2 (storage)	Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.	A proposta de egress zero do R2 é única; em provedores europeus, o egress também é tipicamente gratuito ou muito baixo, pelo que o argumento de custo se mantém.
Cloudflare Workers	Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.	A maioria das funções que migramos acaba por ser pequenos handlers HTTP que correm bem como containers normais, muitas vezes mais baratos e sem cold start.
Cloudflare Pages	Binadit Managed Cloud Platform. Nginx servindo assets compilados, implantado a partir do GitLab CI.	O valor principal do Pages é o pipeline de build; essa parte passa para o seu provedor de CI.
Cloudflare Tunnel (Argo)	Binadit Managed Cloud Platform. Túneis WireGuard, ou um reverse proxy Nginx na sua própria DMZ.	A Netbird tem sede na Alemanha e fornece o padrão "sem IP público" com jurisdição da UE. Wireguard self-managed é a resposta soberana padrão.
Cloudflare Access (zero trust)	Binadit Managed Cloud Platform. WireGuard com Keycloak ou Authentik à frente dos serviços internos.	Para aplicações apenas internas, um reverse proxy protegido por OIDC em infraestrutura da UE é funcionalmente equivalente.
Cloudflare Stream (video)	Transcodificação com FFmpeg na infraestrutura Binadit, entregue através de uma CDN europeia como a Bunny.net.	A transcodificação é uma carga de trabalho em lote que corre em capacidade que já possui. A entrega é HTTP normal através de uma CDN que configuramos para si.
Cloudflare Bot Management	Binadit Managed Cloud Platform. CrowdSec para detecção comportamental, com rate limiting e challenge pages no edge.	A CrowdSec tem sede em França e está cada vez mais capaz. Para e-commerce de alto tráfego, a DataDome (também francesa) é a alternativa enterprise.

Cloudflare CDN

O que usamos no lugar: Implementamos e operamos uma CDN na UE para si: Bunny.net ou KeyCDN, com caching em Nginx e Varnish na sua origem.
Nota de engenharia: A CDN é uma das poucas camadas que não operamos nós mesmos. Escolhemos o provedor europeu, configuramos cache headers, estratégia de purge e origin shielding, e operamos como parte do serviço gerido.

Cloudflare WAF

O que usamos no lugar: Binadit Managed Cloud Platform. Coraza ou ModSecurity com o OWASP Core Rule Set, mais CrowdSec para bloqueio comportamental.
Nota de engenharia: As regras são ajustadas com base no seu tráfego em vez de serem entregues como um conjunto predefinido, o que é o que impede um WAF de bloquear silenciosamente clientes reais.

Cloudflare DDoS protection

O que usamos no lugar: Binadit Private Infrastructure. Filtragem volumétrica upstream, com rate limiting e CrowdSec na edge da aplicação.
Nota de engenharia: Ataques volumétricos são absorvidos a montante dos seus servers. Abusos na camada de aplicação são tratados onde podem efetivamente ser compreendidos, junto ao seu tráfego.

Cloudflare DNS

O que usamos no lugar: Binadit Managed Cloud Platform. PowerDNS ou Knot, autoritativo, assinado com DNSSEC.
Nota de engenharia: As zones são exportadas e importadas como ficheiros de zone standard, pelo que esta é geralmente a parte menos problemática de uma migração. Reduza os TTLs uma semana antes.

Cloudflare R2 (storage)

O que usamos no lugar: Binadit Managed Cloud Platform. MinIO ou Ceph RGW, compatível com S3.
Nota de engenharia: A proposta de egress zero do R2 é única; em provedores europeus, o egress também é tipicamente gratuito ou muito baixo, pelo que o argumento de custo se mantém.

Cloudflare Workers

O que usamos no lugar: Binadit Managed Cloud Platform. Knative ou OpenFaaS no seu cluster Kubernetes.
Nota de engenharia: A maioria das funções que migramos acaba por ser pequenos handlers HTTP que correm bem como containers normais, muitas vezes mais baratos e sem cold start.

Cloudflare Pages

O que usamos no lugar: Binadit Managed Cloud Platform. Nginx servindo assets compilados, implantado a partir do GitLab CI.
Nota de engenharia: O valor principal do Pages é o pipeline de build; essa parte passa para o seu provedor de CI.

Cloudflare Tunnel (Argo)

O que usamos no lugar: Binadit Managed Cloud Platform. Túneis WireGuard, ou um reverse proxy Nginx na sua própria DMZ.
Nota de engenharia: A Netbird tem sede na Alemanha e fornece o padrão "sem IP público" com jurisdição da UE. Wireguard self-managed é a resposta soberana padrão.

Cloudflare Access (zero trust)

O que usamos no lugar: Binadit Managed Cloud Platform. WireGuard com Keycloak ou Authentik à frente dos serviços internos.
Nota de engenharia: Para aplicações apenas internas, um reverse proxy protegido por OIDC em infraestrutura da UE é funcionalmente equivalente.

Cloudflare Stream (video)

O que usamos no lugar: Transcodificação com FFmpeg na infraestrutura Binadit, entregue através de uma CDN europeia como a Bunny.net.
Nota de engenharia: A transcodificação é uma carga de trabalho em lote que corre em capacidade que já possui. A entrega é HTTP normal através de uma CDN que configuramos para si.

Cloudflare Bot Management

O que usamos no lugar: Binadit Managed Cloud Platform. CrowdSec para detecção comportamental, com rate limiting e challenge pages no edge.
Nota de engenharia: A CrowdSec tem sede em França e está cada vez mais capaz. Para e-commerce de alto tráfego, a DataDome (também francesa) é a alternativa enterprise.

Como migramos de Cloudflare

Uma migração típica de mid-market decorre em três fases. Os números abaixo assumem uma equipa de engenharia de 6 a 10 pessoas e uma stack de aplicação moderadamente complexa.

Dias 1-3

Inventário e classificação por risco

Liste todos os produtos Cloudflare em uso: CDN, DNS, regras WAF, Workers, Pages, R2, Tunnel, Access. Associe cada um a uma exposição de dados pessoais (afeta PII?) e à complexidade da migração. Resultado: lista de prioridades, geralmente CDN/DNS primeiro.
Dias 4-10

Substituição soft (CDN, DNS, R2)

Provisionar pull zones da Bunny para os mesmos hostnames. Testar com um hostname de staging. Cortar o DNS com pré-preparação de TTL baixo. Migração R2 → Bunny Storage via escrita paralela. Regras de WAF migradas manualmente para o WAF da Bunny.
Semanas 2-6

Peças difíceis (Workers, Tunnel, Access)

Código do worker revisto e portado para o Bunny Edge Scripting, reescrito como middleware do lado da origem, ou autoalojado no Knative. Tunnel substituído por Netbird ou Wireguard autogerido. Access substituído por Pomerium ou Authelia. Cargas de trabalho do Pages movidas para o GitLab Pages ou autoalojamento.

As migrações de Cloudflare para Bunny reduzem quase sempre a despesa mensal em 40-70% em volumes típicos de mid-market. As exceções são stacks fortemente dependentes de Workers (onde a infraestrutura self-hosted equivalente tem um custo fixo mais elevado) e stacks Pages de alto tráfego (onde o tier gratuito agressivo da Cloudflare é difícil de igualar).

Perguntas frequentes

Ver todas as perguntas frequentes

A Cloudflare tem agora planos de dados exclusivos para a UE - isso resolve o problema?

A "Data Localization Suite" da Cloudflare consegue manter o tráfego UE em edges UE e chaves UE, o que resolve a questão da residência. Não resolve a questão da jurisdição: a Cloudflare Inc. continua a ser uma corporação dos EUA sujeita ao CLOUD Act. Para a maioria das análises Schrems II, o produto de data localization é uma melhoria, mas não soberania total.

A mudança de CDN afetará o desempenho para visitantes europeus?

Para utilizadores europeus especificamente, o Bunny.net frequentemente tem um desempenho igual ou melhor que o Cloudflare porque a densidade de POPs na UE é maior por tráfego. Testes reais em migrações de e-commerce mostraram melhorias de TTFB de 10-30ms para tráfego específico da UE. Para utilizadores globais (EUA, APAC), o número de POPs do Cloudflare é maior.

Como lidamos com a substituição do Cloudflare Workers?

Três padrões dependendo do Worker: (1) reescritas de pedidos triviais migram para o Bunny Edge Scripting sem alterações, (2) Workers que comunicam com KV / Durable Objects precisam de re-arquitetura - tipicamente a lógica passa para a origin e usa Redis ou Postgres, (3) Workers que funcionam como endpoints de API tornam-se pequenos serviços Knative em infraestrutura na UE.

O Bunny.net é uma alternativa real e segura à luz do Schrems II?

A Bunny.net é a BunnyWay d.o.o., com sede em Liubliana, Eslovénia (Estado-Membro da UE). A entidade legal está totalmente sob jurisdição da UE. A sua lista publicada de subprocessadores é curta e focada na UE. Para o Schrems II, a análise reduz-se a "sem transferência para país terceiro", o que é substancialmente mais simples do que o caso da Cloudflare relativamente à localização de dados.

E quanto à Fastly ou Akamai?

Ambas com sede nos EUA. A Fastly está em San Francisco; a Akamai está em Cambridge, MA. Mesma análise do CLOUD Act que a Cloudflare. Não são mais fáceis do ponto de vista do Schrems II do que a Cloudflare; são fornecedores dos EUA diferentes, com conjuntos de funcionalidades diferentes.

Quanto tempo demora uma migração do Cloudflare?

Para uma carga de trabalho típica (CDN, DNS, WAF básico, sem Workers): 1-2 semanas decorridas. Para uma configuração fortemente dependente de Workers ou de Tunnel: 4-8 semanas. Podemos conduzir tudo como uma migração gerida se quiser que seja feito sem consumir a capacidade da sua equipa.

Planeie a sua saída de Cloudflare.

Chamada de scoping de 30 minutos. Mapeamos a sua stack contra alternativas apenas UE, estimamos o esforço de migração e dizemos-lhe se é a decisão certa.

Agendar uma chamada Comparar outro fornecedor