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

Microsoft Azure वह cloud है जिसका बचाव अक्सर इन शब्दों से किया जाता है - "लेकिन हम तो पहले से ही सब कुछ के लिए Microsoft इस्तेमाल करते हैं।" यह बचाव Schrems II analysis में टिक नहीं पाता: Microsoft Corporation एक US कंपनी है, हर Azure subsidiary US-नियंत्रित है, और Microsoft ने कोर्ट में स्पष्ट रूप से स्वीकार किया है (Microsoft Ireland, 2018) कि वह globally कहीं भी स्थित data के लिए valid US legal process का पालन करेगा - यही बात बाद में CLOUD Act ने संहिताबद्ध की। "Microsoft Cloud for Sovereignty" और Bleu (Microsoft × Capgemini × Orange) initiatives दिलचस्प हैं लेकिन इनकी technology एक US parent से licensed है। वास्तविक EU sovereignty के लिए, आपको बाहर निकलना होगा। नीचे मैप दिया गया है।

United States केवल-EU रिप्लेसमेंट स्टैक 14 services मैप किए गए
कॉल शेड्यूल करें पहले अपना डोमेन स्कैन करें
प्रदाता
Microsoft Azure
मुख्यालय
Redmond, WA
न्यायाधिकार
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 में नाम से सूचीबद्ध।

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

Azure से बाहर निकलने की वजह आमतौर पर तीन ट्रिगर्स में से एक होती है: एक पब्लिक-सेक्टर टेंडर जो स्पष्ट रूप से US-jurisdiction प्रोसेसर्स को बाहर रखता है, एक healthcare या financial services ऑडिट जिसने DORA के तहत Microsoft 365 + Azure को एक ही concentration risk के रूप में फ्लैग किया, या एक CISO जिसने कैलकुलेट किया कि licence true-up लागत और "फ्री" Azure क्रेडिट्स वास्तव में छह अंकों के vendor lock-in में तब्दील होते हैं। Azure इकोसिस्टम में AWS की तुलना में ज़्यादा टाइट कपलिंग है - Active Directory, Office 365, Defender, Sentinel आमतौर पर सब मिक्स में होते हैं - जिससे यह माइग्रेशन AWS के मुकाबले ज़्यादा invasive हो जाता है। यह अब भी संभव है; हमने यह किया है।

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

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

Azure Virtual Machines

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Ubuntu पर KVM virtual machines, Terraform से provision और Ansible से configure किए गए।
इंजीनियरिंग टिप्पणी
IaaS migration सीधा है; Windows licensing का हिस्सा ज़्यादा सोच-विचार माँगता है (BYOL या जहाँ संभव हो Linux पर move करना)।

Azure Blob Storage

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. MinIO या Ceph RGW, S3-compatible।
इंजीनियरिंग टिप्पणी
S3-compatible EU storage ही migration target है; SDK में बदलाव न्यूनतम हैं।

Azure SQL Database

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. failover के लिए Patroni के साथ PostgreSQL या MySQL, और point-in-time recovery के लिए pgBackRest.
इंजीनियरिंग टिप्पणी
Azure SQL (T-SQL flavour) से schema porting सबसे लंबा single task है; AWS SCT या pgloader जैसे tools मदद करते हैं। यह अक्सर ORM choices को फिर से देखने का अच्छा मौका होता है।

Azure Front Door / CDN

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

Azure DNS

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

AKS (managed Kubernetes)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Talos पर Kubernetes, Cilium networking और certificates के लिए cert-manager के साथ।
इंजीनियरिंग टिप्पणी
Helm charts और YAML आसानी से transfer हो जाते हैं; Azure-specific addons (Application Gateway Ingress, Azure CNI) को standard equivalents से replace करना होगा।

Azure Functions

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. आपके Kubernetes cluster पर Knative या OpenFaaS।
इंजीनियरिंग टिप्पणी
ज्यादातर Azure Functions workloads Knative चलाने वाले एक छोटे EU Kubernetes cluster में फिट हो जाते हैं।

Azure Active Directory / Entra ID

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. identity provider के रूप में Keycloak या Authentik, OIDC और SAML के साथ।
इंजीनियरिंग टिप्पणी
सबसे कठिन सिंगल माइग्रेशन। 3 महीने की parallel-run विंडो की योजना बनाएं। SaaS में SSO integrations को दोबारा मैप करने की जरूरत होती है।

Azure Service Bus / Event Grid

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. delivery guarantees के अनुसार RabbitMQ, NATS, या Redis Streams.
इंजीनियरिंग टिप्पणी
EU sovereign space में managed queueing options सीमित हैं; self-managed मानक है।

Azure Monitor / Application Insights

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Prometheus, Grafana, Loki और Tempo, OpenTelemetry के साथ जुड़े हुए.
इंजीनियरिंग टिप्पणी
OpenTelemetry instrumentation application code के लिए swap को मैकेनिकल बना देता है।

Azure Cosmos DB

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. MongoDB replica sets, या JSONB के साथ PostgreSQL जहां document model दिखने से हल्का है।
इंजीनियरिंग टिप्पणी
ग्लोबल मल्टी-रीजन एक्टिव-एक्टिव के लिए कोई 1:1 रिप्लेसमेंट नहीं है; यदि आपके workload को वास्तव में यह pattern चाहिए, तो बातचीत अलग होगी।

Defender / Sentinel (security)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. OWASP Core Rule Set के साथ Coraza या ModSecurity, साथ ही behavioural blocking के लिए CrowdSec।
इंजीनियरिंग टिप्पणी
CrowdSec का headquarters FR में है और यह SIEM/IDS space में लगातार competitive होता जा रहा है।

Key Vault

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. HashiCorp Vault या Infisical, self-hosted, automatic lease rotation के साथ।
इंजीनियरिंग टिप्पणी
Vault production-grade sovereign जवाब है; हम इसे क्लाइंट्स के लिए ऑपरेट करते हैं।

Microsoft 365 (email, Teams, OneDrive)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. DKIM, SPF और DMARC के साथ Postfix, और फ़िल्टरिंग के लिए Rspamd.
इंजीनियरिंग टिप्पणी
अक्सर यह infrastructure migration से ज्यादा कठिन political बातचीत होती है। अक्सर इसे migrate करने के बजाय documented exposure के साथ M365 पर ही रखा जाता है।

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

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

  1. हफ्ते 1-3

    Audit और ID-मैपिंग

    Azure services, Entra ID dependencies, SSO integrations और licensing की inventory बनाएं। identity layer सबसे लंबा हिस्सा है। Output: SSO migration को अलग से scope करते हुए phased plan।

  2. हफ्ते 3-6

    Edge, monitoring, soft dependencies

    Front Door, Azure DNS, App Insights और Blob Storage को replace करें। EU compute pre-stage करें और database replicate करें। यदि applicable हो तो CI/CD को Azure DevOps से हटाएं।

  3. सप्ताह 6-18

    Compute, DB, identity cutover

    AKS workloads को managed EU K8s में। SQL Database को PostgreSQL में live cutover के लिए logical replication के साथ। parallel-run के साथ identity migration; प्रत्येक application के लिए SSO को अलग से cut over किया जाता है।

हमारे द्वारा किए गए Azure exits का 5-वर्षीय TCO: आमतौर पर 25-45% सस्ता, जिसमें सबसे बड़ी बचत licence true-up avoidance और bandwidth/egress से आती है। ध्यान रखें: यदि आपकी टीम Microsoft 365 का उपयोग करती है और उस पर बनी रहती है, तो identity-layer migration केवल आंशिक रूप से decouple होता है - यह निर्णय board level पर लिया जाना चाहिए।

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

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

क्या Microsoft Cloud for Sovereignty, Schrems II problem को हल करता है?
यह documentation story को बेहतर बनाता है लेकिन underlying jurisdiction को नहीं बदलता: Microsoft Corporation parent बनी रहती है। उन workloads के लिए जहां analysis parent-jurisdiction पर टिका होता है (यानी Schrems II के बाद अधिकांश regulated workloads), यह अपने आप में पर्याप्त नहीं है।
Bleu के बारे में क्या?
Licensed sovereign offerings, जहां एक EU entity US technology को licence के तहत operate करती है, pseudo-sovereign होती हैं - जो US technology partner के licence के तहत EU-headquartered entities द्वारा operate की जाती हैं। ये specific regulatory requirements को पूरा कर सकती हैं (खासकर Bleu के लिए French SecNumCloud certification) लेकिन ऐसा stack inherit करती हैं जिसे वे independently maintain नहीं कर सकतीं। अधिकांश buyers के लिए, एक clean EU-native stack architecturally सरल जवाब है।
क्या हम Azure छोड़ सकते हैं लेकिन Microsoft 365 रख सकते हैं?
हाँ, और हमारे कई clients वह hybrid चलाते हैं। trade-off यह है कि M365 से गुजरने वाला personal data (email content, OneDrive files, Teams chat) Microsoft processing के अंतर्गत ही रहता है। इसे अपने DPA में document करें, supplementary measures लागू करें (sensitive folders के लिए EU-held keys के साथ encryption at rest), और customer-data infrastructure को sovereign stack पर रखें।
इससे हमारे Microsoft Enterprise Agreement पर क्या असर पड़ता है?
मौजूदा EAs की आमतौर पर annual या multi-year terms होती हैं; migration का लक्ष्य next renewal को रोकना या उसे right-size करना है, न कि current contract को तोड़ना। जब आपका account manager "we are evaluating sovereign alternatives" सुनेगा, तो वह concessions देगा। इसका उपयोग करें।
क्या Active Directory को व्यवहार में replace किया जा सकता है?
चरणों में प्रतिस्थापित किया जा सकता है। Keycloak, OIDC/SAML/SCIM को अच्छी तरह हैंडल करता है; फिजिकल डेस्कटॉप पर Windows-domain authentication के लिए, FreeIPA के साथ Samba 4 स्थापित open-source रास्ता है। यह ट्रांजिशन आमतौर पर एक "modern workplace" simplification के साथ चलता है - कम per-app SSO, ज्यादा standard OIDC।
Azure एग्ज़िट में कितना समय लगता है?
एक mid-size workload (50-200 VMs, 1-2 SQL DBs, AKS, Entra ID) के लिए: 16-24 सप्ताह का elapsed time। choreography चला रहे managed-infrastructure partner के साथ: 10-16 सप्ताह। identity layer schedule का जोखिम है, compute नहीं।

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

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

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