Europe में Sovereign cloud: residency, jurisdiction के समान नहीं है।

यह पेज engineering perspective प्रस्तुत करता है। यदि आपका DPO, आपका auditor या कोई procurement gate यह पूछ रहा है कि 2026 में "sovereign" का वास्तव में क्या अर्थ है, तो यही वह version है जो scrutiny में टिका रहता है।

Residency बनाम sovereignty: वह अंतर जो सब कुछ तय करता है

Cloud industry ने पिछले पंद्रह वर्षों में खरीदारों को गलत सवाल पूछना सिखाया है। "Data कहाँ hosted है?" यह एक residency संबंधी सवाल है। इसका जवाब technically सही और legally अर्थहीन, दोनों एक साथ हो सकता है, क्योंकि sovereignty geography के बारे में नहीं है। यह इस बारे में है कि कौन सी courts किसी provider को कार्रवाई के लिए बाध्य कर सकती हैं।

US hyperscaler पर एक EU region, जैसे AWS Frankfurt, Azure West Europe या GCP Belgium, bits को EU में रखता है। यह parent company को US jurisdiction से बाहर नहीं निकालता। US CLOUD Act (2018) के तहत, एक US-headquartered provider को दुनिया में कहीं भी रखे गए customer data को उजागर करने के लिए मजबूर किया जा सकता है, EU regions में भी। FISA 702 surveillance पक्ष के लिए भी वही exposure लगाता है। European Data Protection Board ने इसे स्पष्ट रूप से एक Schrems II समस्या के रूप में चिन्हित किया है।

"सॉवरेन" का मतलब इसलिए तीन ठोस चीज़ें हैं, सब एक साथ:

1. आपका data रखने वाली legal entity का कोई parent किसी third country में नहीं है जिसके पास extraterritorial data-disclosure laws हों।
2. Data path में कोई भी subprocessor भी ऐसे किसी country में नहीं है।
3. आप, न कि प्रोवाइडर, एन्क्रिप्शन कीज़ को कंट्रोल करते हैं, या कीज़ थर्ड कंट्री के बाहर किसी कस्टोडियन के पास रहती हैं।

तीनों में पास हों तो sovereignty है। किसी एक में भी फेल हों तो residency है। आपके DPA, आपकी privacy policy और आपके customer-facing pages की terminology यह दर्शानी चाहिए कि वास्तव में यह कौन सा है।

"EU सब्सिडियरी" जवाब क्यों नहीं है

US hyperscalers द्वारा पेश किया जाने वाला एक आम workaround EU subsidiary structure है। Microsoft Ireland, AWS EMEA SARL, Google Cloud EMEA Ltd। तर्क यह है कि EU कानून के तहत यूरोपीय entity ही contracting counterparty है।

इससे jurisdictional समस्या हल नहीं होती। CLOUD Act के तहत, test यह नहीं है कि किस subsidiary ने contract पर हस्ताक्षर किए। यह है कि क्या parent company के पास data का "possession, custody or control" है। एक wholly owned EU subsidiary, अपनी design से ही, parent द्वारा नियंत्रित होती है। Schrems II में CJEU और EDPB का विश्लेषण parent के exposure को ही operative मानता है।

इसलिए जब कोई vendor एक "European" plan offer करता है जिसे किसी US group की EU subsidiary द्वारा operate किया जाता है, तो सही सवाल यह पूछना है: "क्या आपकी US parent company को हमारी सहमति या जानकारी के बिना data disclose करने का निर्देश देने के लिए बाध्य किया जा सकता है?" ईमानदार जवाब है, हाँ।

Pseudo-sovereign middle tier

2024 से 2026 के बीच "सॉवरेन" पार्टनरशिप्स की एक लहर देखी गई, जिसमें आमतौर पर एक यूरोपीय सिस्टम्स इंटीग्रेटर किसी US हाइपरस्केलर के टेक्नोलॉजी स्टैक को लाइसेंस लेकर उसे यूरोपीय प्रबंधन के तहत ऑपरेट करता है। आज मार्केट में मौजूद उदाहरण:

• लाइसेंस्ड सॉवरेन ऑफरिंग्स, US हाइपरस्केलर टेक्नोलॉजी पर बनी हुई, एक यूरोपीय Telekom सब्सिडियरी द्वारा ऑपरेट की जाने वाली।
• Bleu, Microsoft Azure टेक्नोलॉजी पर बना एक फ्रेंच सॉवरेन क्लाउड, जिसे Capgemini और Orange द्वारा ऑपरेट किया जाता है।
• S3NS, फ्रांस में Thales और Google का एक joint venture।

ये offerings विशिष्ट compliance regimes के लिए उपयोगी हो सकते हैं, लेकिन इन्हें किसी engineering team द्वारा बिना किसी qualification के sovereign नहीं कहा जाना चाहिए। Technology stack, platform updates, security patches और, सबसे महत्वपूर्ण, operational know-how, US partner से आते हैं। सबसे खराब threat model में, जहाँ US पक्ष सहयोग वापस ले लेता है या ऐसा करने के लिए बाध्य होता है, European operator को ऐसा stack विरासत में मिलता है जिसे वह स्वतंत्र रूप से maintain नहीं कर सकता।

अधिकतर buyers के लिए, cleaner architectural जवाब यह है कि ऐसे infrastructure पर बनाया जाए जहां supply chain में US पर कोई निर्भरता ही न हो। Binadit में sovereign stack की बात करते समय हमारा यही मतलब होता है।

एक सॉवरेन EU स्टैक वास्तव में कैसा दिखता है

यह एक concrete reference architecture है एक mid-market SaaS या regulated workload के लिए जो पूरी तरह EU jurisdiction के अंतर्गत चलता है। इनमें से कोई भी exotic नहीं है; सभी production-grade हैं।

• कंप्यूट & स्टोरेज: Binadit मैनेज्ड कंप्यूट और डेडिकेटेड हार्डवेयर, EU जुरिस्डिक्शन के तहत EU इंफ्रास्ट्रक्चर पर।
• ऑब्जेक्ट स्टोरेज: Ceph या MinIO, S3-compatible, हमारे द्वारा उसी इंफ्रास्ट्रक्चर पर ऑपरेट किया जाता है।
• CDN: Bunny.net (SI), KeyCDN (CH), या पूर्ण नियंत्रण के लिए edge पर self-managed.
• DNS: PowerDNS या Knot, authoritative और DNSSEC signed, या Bunny DNS जहां आप इसे CDN के साथ बंडल करना चाहते हैं।
• ईमेल डिलीवरी: Mailgun EU (सावधानी के साथ, क्योंकि इसकी पैरेंट कंपनी US में है), या पूरी तरह EU विकल्प जैसे Postmark EU, Mailpace, Tuta business, या उसी इंफ्रास्ट्रक्चर पर self-hosted Postfix.
• एरर ट्रैकिंग: Self-hosted GlitchTip या Sentry, या Sentry का EU-region डिप्लॉयमेंट, जिसके ट्रेड-ऑफ्स डॉक्यूमेंटेड हैं।
• एनालिटिक्स: Plausible (EU-hosted), Matomo (self-hosted या EU cloud), Pirsch.
• Observability: Self-hosted Prometheus + Grafana + Loki, या EU-managed समकक्ष (Grafana Cloud EU, Last9 EU region के साथ)।
• की मैनेजमेंट: EU इंफ्रा पर Hashicorp Vault, या EU-managed KMS प्रोवाइडर्स; हाई-ट्रस्ट सिनेरियोज़ के लिए, cloud-side BYOK के साथ on-premises HSM.
• CI/CD: GitLab self-hosted, Forgejo, Gitea, या GitLab.com का EU instance। पर्सनल डेटा को छूने वाले कोड के लिए, बिना सप्लीमेंट्री मेज़र्स के, कभी भी डिफ़ॉल्ट github.com नहीं।

मुद्दा यह नहीं है कि इनमें से कोई एक "वह" जवाब है। मुद्दा यह है कि पूरा stack EU-headquartered providers के साथ assemble किया जा सकता है, और एक managed-infrastructure partner इसे उसी तरह आपके लिए चला सकता है जैसे एक AWS-native partner AWS को चलाता है।

Four-question test, विस्तार में

1. रेजिडेंसी: कहां, बिल्कुल सटीक रूप से

"EU में" नहीं बल्कि कौन सा datacenter, किस country में, किस jurisdiction के अंतर्गत। EU कोई single legal regime नहीं है; GDPR harmonised है लेकिन supervisory authority local होती है, और legal recourse भी local होता है अगर कोई provider विफल हो जाए। अपने DPA में primary, secondary और backup locations का country code document करें।

2. सबप्रोसेसर: उनमें से हर एक

मिड-मार्केट environments के अपने audits में, हमने पाया है कि unmapped subprocessor chain सबसे common finding है। Application EU infrastructure पर है, जो अच्छी बात है। लेकिन जिस image-optimisation API को यह call करता है, वह US-hosted है। Transactional email एक US ESP के ज़रिए भेजी जाती है। Error tracker US default है। Customer support widget एक US CDN से JavaScript load करता है। इनमें से हर एक अलग data flow है। अगर data किसी third country में जाता है, तो हर एक के लिए legal basis की ज़रूरत होती है।

एक sovereign stack के लिए एक पूर्ण subprocessor list चाहिए, जिसमें केवल infrastructure providers ही नहीं बल्कि आपके application द्वारा कॉल किए जाने वाले third-party APIs भी शामिल हों। हमारी सूची data-processing agreement में पूरी तरह से दी गई है, और आपके sign करने से पहले हम इसे भेज देंगे।

3. जुरिस्डिक्शन: कौन डिस्क्लोज़र के लिए मजबूर कर सकता है

Legal-process से जुड़ा सवाल। आपके data path में मौजूद हर entity के लिए, parent company के headquarters की पहचान करें। यदि कोई parent US, China, Russia या किसी अन्य ऐसे देश में है जिसके पास extraterritorial data-access laws हैं, तो वह entity exposed है। किसी US parent की EU subsidiary status होने से यह समस्या हल नहीं होती।

यहीं architecture diagram एक legal document बन जाता है। इसे एक बार बनाएं, त्रैमासिक रूप से review करें।

4. की कस्टडी: तकनीकी रूप से डेटा कौन पढ़ सकता है

Encryption at rest जरूरी है लेकिन पर्याप्त नहीं। सवाल यह है कि keys किसके पास हैं। Provider-managed keys provider के decrypt करने के लिए मजबूर होने की स्थिति में कोई सुरक्षा नहीं देतीं। BYOK (Bring Your Own Key) compliance narrative में मदद करता है; फिर भी provider के पास runtime copy रहती है। HYOK (Hold Your Own Key) ही एकमात्र model है जहाँ cloud provider आपके key custodian से active call के बिना physically data नहीं पढ़ सकता। जो threat model मांगता है वही model चुनें।

Migration path: AWS Frankfurt से एक sovereign stack तक

किसी hyperscaler से हटने का डर आमतौर पर actual project से बड़ा होता है। एक typical mid-market migration तीन चरणों में चलता है:

1. इन्वेंटरी और ऑडिट (1-2 हफ्ते). हर डेटा फ्लो को मैप करें, हर सबप्रोसेसर की पहचान करें, US एक्सपोज़र के आधार पर वर्गीकृत करें। आउटपुट: रिस्क और माइग्रेशन जटिलता के आधार पर रैंक की गई एक रेमेडिएशन लिस्ट।
2. Quick-win removals (2-4 weeks)। पहले soft dependencies को बदलें: error tracking, analytics, CDN, DNS, email। इनमें बहुत कम या बिल्कुल भी application बदलाव नहीं करना पड़ता।
3. कोर माइग्रेशन (4-8 हफ्ते). कंप्यूट, स्टोरेज, डेटाबेस। ज़ीरो-डाउनटाइम डेटाबेस मूव्स के लिए स्ट्रीमिंग रेप्लिकेशन का उपयोग करें; एप्लिकेशन टियर पर blue-green या DNS-failover पैटर्न्स का उपयोग करें। मुश्किल हिस्सा शायद ही कभी टेक्नोलॉजी होता है। यह कोरियोग्राफी है।

6-8 सदस्यों की इंजीनियरिंग टीम को अपने रेगुलर काम के साथ यह करने में लगने वाला कुल समय: दस से सोलह हफ्ते। एक managed-infrastructure partner के माइग्रेशन को लीड करने पर, चार से बारह। हमारे अनुभव में, sovereign stack चलाने और hyperscaler चलाने के बीच लागत का अंतर predictable workloads के लिए न्यूट्रल से नेगेटिव है, spiky workloads के लिए थोड़ा ज़्यादा है, और egress व bandwidth को शामिल करने पर काफी कम हो जाता है।

"क्या सॉवरेन क्लाउड ज़्यादा महंगा है?" ईमानदार जवाब

80% मिड-मार्केट वर्कलोड्स के लिए, sovereign stack पांच वर्षों में सस्ता पड़ता है, मुख्यतः इसलिए क्योंकि EU providers punitive egress fees नहीं लेते और dedicated व bare-metal pricing equivalent hyperscaler instance types से काफी बेहतर है। जिन मामलों में sovereign stack महंगा पड़ता है, वे हैं: highly bursty workloads जिन्हें sub-second autoscaling से फायदा मिलता है, ऐसे workloads जो किसी specific managed service (DynamoDB, BigQuery, Lambda) पर निर्भर हैं जिसका कोई clean equivalent नहीं है, और ML training workloads जिन्हें किसी specific accelerator generation की जरूरत होती है।

एक सक्षम engineering review एक हफ्ते में बता देगी कि आप किस category में हैं। अगर आपको एक चाहिए, तो यही हमारा काम है।

Regulatory tailwind: NIS2, DORA, EHDS, और AI Act

2025 से 2027 तक regulatory direction सख्त supply-chain accountability की ओर बढ़ रही है:

• NIS2 (आर्टिकल 21): एसेंशियल और इंपॉर्टेंट एंटिटीज़ को सप्लाई-चेन रिस्क असेसमेंट्स करनी होंगी और कॉन्ट्रैक्चुअल रूप से सिक्योरिटी ऑब्लिगेशन्स को सबप्रोसेसर्स तक पहुंचाना होगा। बिना सप्लीमेंट्री मेज़र्स के, इस असेसमेंट में एक US-jurisdiction सबप्रोसेसर को डिफेंड करना मुश्किल है।
• DORA (जनवरी 2025 से लागू): वित्तीय संस्थाओं को ICT थर्ड-पार्टी प्रोवाइडर्स का एक रजिस्टर और क्रिटिकल प्रोवाइडर्स के लिए एक एग्ज़िट स्ट्रेटेजी बनाए रखनी होगी। कॉन्सन्ट्रेशन रिस्क से जुड़ी भाषा स्पष्ट रूप से डॉमिनेंट non-EU प्रोवाइडर्स पर निर्भरता को टारगेट करती है।
• European Health Data Space (EHDS): हेल्थ डेटा के सेकेंडरी-यूज़ को केवल EU जुरिस्डिक्शन के तहत प्रोसेसिंग एनवायरनमेंट्स तक सीमित रखा गया है।
• EU AI Act: हाई-रिस्क AI सिस्टम्स के लिए ट्रेसेबल ट्रेनिंग-डेटा प्रोवेनेंस ज़रूरी है, जो किसी US फाउंडेशन-मॉडल API पर व्यवहारिक रूप से बहुत मुश्किल है।

इनमें से कोई भी regulation US providers को ban नहीं करता। ये documentation और supplementary-measure का burden इतना अधिक बना देते हैं कि, अधिकतर use cases के लिए, sovereign stack ही कम-friction वाला विकल्प बन जाता है।

हम क्या दावा नहीं करते

ईमानदारी से कहें तो: कुछ workloads ऐसे हैं जहां sovereign EU stack hyperscaler से ज़्यादा कठिन है। Multi-region active-active with sub-50ms global latency। Specific managed analytics warehouses। नवीनतम accelerators पर hyperscale ML inference। हम आपको बताएंगे जब आपका workload उस category में आता है। जो 90% SaaS, e-commerce, B2B platforms और regulated workloads हम देखते हैं, उनके लिए sovereign stack सिर्फ compliant ही नहीं है। यह तेज़, सस्ता और समझने में भी आसान है।

Binadit कहाँ फिट होता है

हम Rotterdam, नेदरलैंड्स में हेडक्वार्टर वाले Article 28 data processor हैं। हमारा infrastructure footprint 100% EU-headquartered providers पर है। हमारी subprocessor लिस्ट data-processing agreement में पूरी तरह नामित है और मांगने पर उपलब्ध है। हम ऐसे engagements नहीं लेते जिनमें default data path में US-jurisdiction subprocessor की जरूरत हो। जहां किसी workload को वास्तव में इसकी जरूरत होती है (एक third-party SaaS जिसे customer इस्तेमाल करने पर जोर देता है), वहां हम इसे लिखित रूप में डॉक्यूमेंट करते हैं, supplementary measures शामिल करते हैं, और साइन करने से पहले residual risk को DPO के सामने रखते हैं।

अगर यह उस तरह के partner जैसा लगता है जिसकी आप तलाश कर रहे थे, तो अगला कदम 30-मिनट की scoping call है।