केवल यूरोपीय विकल्प Cloudflare.

ज़्यादातर "EU" stacks में Cloudflare सबसे ज़्यादा US-exposed vendor है क्योंकि यह user के सामने बैठता है - हर visitor आपके origin तक पहुंचने से पहले एक Cloudflare edge server से connect होता है। Cloudflare के EU regions EU में स्थित edges हैं, लेकिन parent company एक Delaware corporation है जिसका key material और traffic logs US-controlled हैं। Schrems II के मकसद से, personal-data traffic के सामने Cloudflare को हटाना सबसे पहले हल करने लायक सबसे defensible समस्याओं में से एक है, क्योंकि alternatives - Bunny.net (SI) और KeyCDN (CH) - में तुलनीय feature sets हैं और कहीं ज़्यादा सरल legal story है।

United States केवल-EU रिप्लेसमेंट स्टैक 11 services मैप किए गए

कॉल शेड्यूल करें पहले अपना डोमेन स्कैन करें

प्रदाता: Cloudflare
मुख्यालय: San Francisco, CA
न्यायाधिकार: United States
विधिक शासन: CLOUD Act, FISA 702, EO 12333

"EU क्षेत्र" संप्रभुता नहीं है। चार प्रश्न इसे तय करते हैं।

डेटा रेजिडेंसी आपको बताती है कि बिट्स कहाँ स्थित हैं। सॉवरेनिटी आपको बताती है कि कौन-सी लीगल सिस्टम एक्सेस के लिए मजबूर कर सकती है। जवाब चारों पर सही होना चाहिए - नहीं तो स्टैक सॉवरेन नहीं है।

रेजीडेंसी

डेटा भौतिक रूप से कहाँ संग्रहीत है?

"cloud में" नहीं - बल्कि कौन सा datacenter, किस देश में, किस jurisdiction के अंतर्गत।

सबप्रोसेसर

आपके डेटा पथ में और कौन है?

हर विक्रेता जो डेटा को छूता है: CDN, ईमेल रिले, त्रुटि ट्रैकर, एनालिटिक्स पाइप।

न्यायाधिकार

किसके कानून प्रकटीकरण के लिए मजबूर कर सकते हैं?

US-headquartered प्रोवाइडर FISA 702 और CLOUD Act के अंतर्गत आता है - भले ही डेटा Frankfurt में हो।

कुंजी अभिरक्षा

वास्तव में एन्क्रिप्शन कुंजियाँ कौन रखता है?

अगर cloud provider के पास data और keys दोनों हैं, तो data उनके द्वारा पढ़ा जा सकता है - किसी भी DPA के बावजूद।

Fails AWS · Azure · GCP · EU रीजन

न्यायाधिकार और कुंजी अभिरक्षा पर असफल।

EU डेटा, अमेरिकी मुख्यालय वाली मूल कंपनी, डिफ़ॉल्ट पथ में अमेरिकी सबप्रोसेसर, प्रदाता-प्रबंधित कुंजियाँ।

पास होता है Binadit प्रबंधित स्टैक

सभी चारों पर सफल।

EU में होस्टेड EU मुख्यालय वाले बुनियादी ढांचे पर। डिफ़ॉल्ट पथ में शून्य अमेरिकी सबप्रोसेसर। ग्राहक-धारित या EU-KMS कुंजियाँ। आपके अनुच्छेद 28 DPA में नाम से सूचीबद्ध।

टीमें क्यों बाहर निकल रही हैं Cloudflare

जो पैटर्न हम देखते हैं: एक प्राइवेसी या DPO रिव्यू Cloudflare को एक US सबप्रोसेसर के रूप में पहचानता है जो हर विज़िटर रिक्वेस्ट को प्रोसेस करता है, जिसमें IP एड्रेस, ब्राउज़र फिंगरप्रिंट (Bot Management के जरिए) और कुकीज़ शामिल हैं। Schrems II के तहत यह एक ऐसा ट्रांसफर है जिसके लिए सप्लीमेंट्री उपायों की जरूरत होती है - आमतौर पर ऐसी एन्क्रिप्शन जिसे Cloudflare पढ़ नहीं सकता, जो WAF और Bot Management फीचर्स को बेकार कर देता है जो Cloudflare इस्तेमाल करने की वजह थे। सरल जवाब है एक EU-jurisdictional प्रोवाइडर में स्विच करना जहां लीगल एनालिसिस सिमट कर "कोई ट्रांसफर नहीं" रह जाता है। Bunny.net स्टैंडर्ड टारगेट है और माइग्रेशन वाकई कुछ घंटों का DNS और कॉन्फ़िगरेशन काम है।

Cloudflare सेवाएँ और उनके केवल-EU समकक्ष

माइग्रेशन "एक बॉक्स को दूसरे से बदलना" नहीं है। नीचे दी गई मैपिंग वह है जो हम निम्न को छोड़ने वाले ग्राहकों के लिए चलाते हैं: Cloudflare Schrems II आधार पर - पूरी EU jurisdiction, data path में कोई US parent नहीं।

Cloudflare सेवा	इसके बजाय हम क्या चलाते हैं	इंजीनियरिंग टिप्पणी
Cloudflare CDN	हम आपके लिए EU CDN implement और operate करते हैं: Bunny.net या KeyCDN, आपके origin पर Nginx और Varnish caching के साथ।	CDN उन कुछ लेयर्स में से एक है जिन्हें हम खुद नहीं चलाते। हम EU प्रोवाइडर चुनते हैं, cache headers, purge strategy और origin shielding कॉन्फ़िगर करते हैं, और इसे मैनेज्ड सर्विस के हिस्से के रूप में ऑपरेट करते हैं।
Cloudflare WAF	Binadit Managed Cloud Platform. OWASP Core Rule Set के साथ Coraza या ModSecurity, साथ ही behavioural blocking के लिए CrowdSec।	Rules आपके traffic के अनुसार tune किए जाते हैं, न कि default set के रूप में भेजे जाते हैं, और यही वह चीज़ है जो WAF को असली customers को चुपचाप block करने से रोकती है।
Cloudflare DDoS protection	Binadit Private Infrastructure. Upstream volumetric filtering, application edge पर rate limiting और CrowdSec के साथ।	Volumetric attacks आपके servers से पहले ही अवशोषित कर लिए जाते हैं। Application-layer abuse को वहां हैंडल किया जाता है जहां इसे वास्तव में समझा जा सकता है, आपके traffic के पास।
Cloudflare DNS	Binadit Managed Cloud Platform. PowerDNS या Knot, authoritative, DNSSEC signed.	Zones को standard zone files के रूप में export और import किया जाता है, इसलिए यह migration का सबसे कम घटनापूर्ण हिस्सा होता है। TTLs को एक हफ्ते पहले कम कर दें।
Cloudflare R2 (storage)	Binadit Managed Cloud Platform. MinIO या Ceph RGW, S3-compatible।	R2 की zero-egress story अनूठी है; EU providers पर भी egress आमतौर पर free या बहुत कम होता है, इसलिए cost argument वहां भी लागू होता है।
Cloudflare Workers	Binadit Managed Cloud Platform. आपके Kubernetes cluster पर Knative या OpenFaaS।	हम जो ज्यादातर functions migrate करते हैं वे छोटे HTTP handlers निकलते हैं जो सामान्य containers के रूप में आसानी से चलते हैं, अक्सर सस्ते और बिना cold start के।
Cloudflare Pages	Binadit Managed Cloud Platform. built assets serve करता Nginx, GitLab CI से deploy किया गया।	Pages का मुख्य मूल्य build pipeline है; वह हिस्सा आपके CI provider में चला जाता है।
Cloudflare Tunnel (Argo)	Binadit Managed Cloud Platform. WireGuard tunnels, या आपके अपने DMZ में Nginx reverse proxy.	Netbird का headquarter DE में है और यह EU jurisdiction के साथ "no-public-IP" पैटर्न प्रदान करता है। Wireguard self-managed मानक sovereign उत्तर है।
Cloudflare Access (zero trust)	Binadit Managed Cloud Platform. internal services के सामने Keycloak या Authentik के साथ WireGuard.	Internal-only applications के लिए, EU infrastructure पर एक OIDC-protected reverse proxy फंक्शनली इक्विवैलेंट है।
Cloudflare Stream (video)	Binadit infrastructure पर FFmpeg के साथ transcoding, Bunny.net जैसे EU CDN पर डिलीवर किया गया।	Transcoding एक batch workload है जो आपकी पहले से मौजूद capacity पर चलता है। Delivery, आपके लिए configure किए गए CDN पर सामान्य HTTP है।
Cloudflare Bot Management	Binadit Managed Cloud Platform. behavioural detection के लिए CrowdSec, edge पर rate limiting और challenge pages के साथ।	CrowdSec का headquarters FR में है और यह लगातार सक्षम होता जा रहा है। High-traffic e-commerce के लिए, DataDome (जो FR में भी है) enterprise alternative है।

Cloudflare CDN

इसके बजाय हम क्या चलाते हैं: हम आपके लिए EU CDN implement और operate करते हैं: Bunny.net या KeyCDN, आपके origin पर Nginx और Varnish caching के साथ।
इंजीनियरिंग टिप्पणी: CDN उन कुछ लेयर्स में से एक है जिन्हें हम खुद नहीं चलाते। हम EU प्रोवाइडर चुनते हैं, cache headers, purge strategy और origin shielding कॉन्फ़िगर करते हैं, और इसे मैनेज्ड सर्विस के हिस्से के रूप में ऑपरेट करते हैं।

Cloudflare WAF

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. OWASP Core Rule Set के साथ Coraza या ModSecurity, साथ ही behavioural blocking के लिए CrowdSec।
इंजीनियरिंग टिप्पणी: Rules आपके traffic के अनुसार tune किए जाते हैं, न कि default set के रूप में भेजे जाते हैं, और यही वह चीज़ है जो WAF को असली customers को चुपचाप block करने से रोकती है।

Cloudflare DDoS protection

इसके बजाय हम क्या चलाते हैं: Binadit Private Infrastructure. Upstream volumetric filtering, application edge पर rate limiting और CrowdSec के साथ।
इंजीनियरिंग टिप्पणी: Volumetric attacks आपके servers से पहले ही अवशोषित कर लिए जाते हैं। Application-layer abuse को वहां हैंडल किया जाता है जहां इसे वास्तव में समझा जा सकता है, आपके traffic के पास।

Cloudflare DNS

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. PowerDNS या Knot, authoritative, DNSSEC signed.
इंजीनियरिंग टिप्पणी: Zones को standard zone files के रूप में export और import किया जाता है, इसलिए यह migration का सबसे कम घटनापूर्ण हिस्सा होता है। TTLs को एक हफ्ते पहले कम कर दें।

Cloudflare R2 (storage)

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. MinIO या Ceph RGW, S3-compatible।
इंजीनियरिंग टिप्पणी: R2 की zero-egress story अनूठी है; EU providers पर भी egress आमतौर पर free या बहुत कम होता है, इसलिए cost argument वहां भी लागू होता है।

Cloudflare Workers

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. आपके Kubernetes cluster पर Knative या OpenFaaS।
इंजीनियरिंग टिप्पणी: हम जो ज्यादातर functions migrate करते हैं वे छोटे HTTP handlers निकलते हैं जो सामान्य containers के रूप में आसानी से चलते हैं, अक्सर सस्ते और बिना cold start के।

Cloudflare Pages

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. built assets serve करता Nginx, GitLab CI से deploy किया गया।
इंजीनियरिंग टिप्पणी: Pages का मुख्य मूल्य build pipeline है; वह हिस्सा आपके CI provider में चला जाता है।

Cloudflare Tunnel (Argo)

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. WireGuard tunnels, या आपके अपने DMZ में Nginx reverse proxy.
इंजीनियरिंग टिप्पणी: Netbird का headquarter DE में है और यह EU jurisdiction के साथ "no-public-IP" पैटर्न प्रदान करता है। Wireguard self-managed मानक sovereign उत्तर है।

Cloudflare Access (zero trust)

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. internal services के सामने Keycloak या Authentik के साथ WireGuard.
इंजीनियरिंग टिप्पणी: Internal-only applications के लिए, EU infrastructure पर एक OIDC-protected reverse proxy फंक्शनली इक्विवैलेंट है।

Cloudflare Stream (video)

इसके बजाय हम क्या चलाते हैं: Binadit infrastructure पर FFmpeg के साथ transcoding, Bunny.net जैसे EU CDN पर डिलीवर किया गया।
इंजीनियरिंग टिप्पणी: Transcoding एक batch workload है जो आपकी पहले से मौजूद capacity पर चलता है। Delivery, आपके लिए configure किए गए CDN पर सामान्य HTTP है।

Cloudflare Bot Management

इसके बजाय हम क्या चलाते हैं: Binadit Managed Cloud Platform. behavioural detection के लिए CrowdSec, edge पर rate limiting और challenge pages के साथ।
इंजीनियरिंग टिप्पणी: CrowdSec का headquarters FR में है और यह लगातार सक्षम होता जा रहा है। High-traffic e-commerce के लिए, DataDome (जो FR में भी है) enterprise alternative है।

हम कैसे माइग्रेट करते हैं Cloudflare

एक सामान्य mid-market माइग्रेशन तीन फेज़ में चलता है। नीचे दिए गए आंकड़े 6-10 लोगों की इंजीनियरिंग टीम और मध्यम रूप से कॉम्प्लेक्स एप्लिकेशन स्टैक को मानकर दिए गए हैं।

1-3 दिन

Inventory और risk-rank

उपयोग में मौजूद हर Cloudflare product की list बनाएं: CDN, DNS, WAF rules, Workers, Pages, R2, Tunnel, Access। प्रत्येक को personal-data exposure (क्या यह PII को touch करता है?) और migration complexity से map करें। Output: priority list, आमतौर पर CDN/DNS सबसे पहले।
4-10 दिन

Soft swap (CDN, DNS, R2)

उन्हीं hostnames के लिए Bunny pull zones provision करें। staging hostname के साथ test करें। low TTL pre-stage के साथ DNS cut over करें। parallel-write के जरिए R2 → Bunny Storage migration। WAF rules manually Bunny WAF में port किए गए।
हफ्ते 2-6

कठिन हिस्से (Workers, Tunnel, Access)

Worker code को review किया गया और फिर उसे Bunny Edge Scripting में port किया गया, origin-side middleware के रूप में फिर से लिखा गया, या Knative पर self-hosted किया गया। Tunnel को Netbird या self-managed Wireguard से बदला गया। Access को Pomerium या Authelia से बदला गया। Pages workloads को GitLab Pages या self-hosted setup में स्थानांतरित किया गया।

Cloudflare-to-Bunny migrations लगभग हमेशा typical mid-market volumes पर monthly spend को 40-70% तक कम कर देते हैं। अपवाद Workers-heavy stacks हैं (जहां equivalent self-hosted infrastructure की fixed cost ज़्यादा होती है) और high-traffic Pages stacks (जहां Cloudflare के aggressive free tier का मुकाबला करना मुश्किल है)।

अक्सर पूछे जाने वाले प्रश्न

सभी अक्सर पूछे जाने वाले प्रश्न देखें

Cloudflare के पास अब EU-only data plans हैं - क्या इससे यह समस्या हल हो जाती है?

Cloudflare का "Data Localization Suite" EU traffic को EU edges और EU keys पर रख सकता है, जो residency को address करता है। यह jurisdiction को address नहीं करता: Cloudflare Inc. फिर भी एक US corporation है जो CLOUD Act के अधीन है। ज़्यादातर Schrems II analyses के लिए, data-localization product एक सुधार है लेकिन पूर्ण sovereignty नहीं।

क्या CDN बदलने से यूरोपीय visitors के लिए performance प्रभावित होगी?

European users के लिए विशेष रूप से, Bunny.net अक्सर Cloudflare जितना या उससे बेहतर परफॉर्म करता है क्योंकि उनकी EU POP density per-traffic ज़्यादा है। e-commerce migrations पर real-world tests में EU-specific traffic के लिए TTFB में 10-30ms का सुधार देखा गया है। global users (US, APAC) के लिए, Cloudflare की POP count ज़्यादा है।

हम Cloudflare Workers रिप्लेसमेंट को कैसे हैंडल करते हैं?

Worker के आधार पर तीन पैटर्न: (1) साधारण रिक्वेस्ट रीराइट्स बिना बदलाव के Bunny Edge Scripting में चले जाते हैं, (2) KV / Durable Objects से बात करने वाले Workers को री-आर्किटेक्ट की जरूरत होती है - आमतौर पर लॉजिक origin पर शिफ्ट होकर Redis या Postgres का इस्तेमाल करता है, (3) API एंडपॉइंट के रूप में काम करने वाले Workers EU इंफ्रास्ट्रक्चर पर छोटे Knative सर्विसेज बन जाते हैं।

क्या Bunny.net वाकई एक Schrems II-safe विकल्प है?

Bunny.net असल में BunnyWay d.o.o. है, जिसका मुख्यालय Ljubljana, Slovenia (EU सदस्य) में है। लीगल एंटिटी पूरी तरह EU jurisdiction के अंतर्गत है। उनकी प्रकाशित subprocessor सूची छोटी और EU-केंद्रित है। Schrems II के लिए, विश्लेषण "कोई third-country transfer नहीं" तक सिमट जाता है, जो Cloudflare की data-localization स्थिति से काफी आसान है।

Fastly या Akamai के बारे में क्या?

दोनों US-headquartered हैं। Fastly, San Francisco में है; Akamai, Cambridge, MA में है। Cloudflare जैसा ही CLOUD Act विश्लेषण लागू होता है। ये Cloudflare से Schrems II के लिहाज़ से आसान नहीं हैं; ये अलग-अलग फीचर सेट वाले अलग US प्रोवाइडर हैं।

Cloudflare माइग्रेशन में कितना समय लगता है?

एक सामान्य workload (CDN, DNS, basic WAF, बिना Workers के) के लिए: 1-2 हफ्ते का समय लगता है। Workers-heavy या Tunnel-dependent सेटअप के लिए: 4-8 हफ्ते। अगर आप चाहें कि यह आपकी टीम की क्षमता खर्च किए बिना हो जाए, तो हम पूरी चीज़ को managed migration के रूप में चला सकते हैं।

अपनी निकास योजना बनाएँ Cloudflare.

30-मिनट का स्कोपिंग कॉल। हम आपके स्टैक को केवल-EU विकल्पों के विरुद्ध मैप करते हैं, माइग्रेशन प्रयास का अनुमान लगाते हैं, और आपको बताते हैं कि क्या यह सही निर्णय है।

कॉल शेड्यूल करें किसी अन्य provider से तुलना करें