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

Amazon Web Services मूल public cloud है - और मूल Schrems II समस्या भी। वही EU क्षेत्र जो AWS को यूरोपीय वर्कलोड के लिए तकनीकी रूप से उपयोग योग्य बनाते हैं, मूल jurisdiction को नहीं बदलते: AWS Inc. एक Delaware corporation है, AWS EMEA SARL एक Luxembourg सहायक कंपनी है जो इसके पूर्ण नियंत्रण में है, और CLOUD Act दोनों पर लागू होता है। audited वर्कलोड, नियमित उद्योगों और किसी भी व्यवसाय के लिए जिससे किसी ग्राहक ने पूछा है "क्या आपका provider US-subpoenable है?", AWS पर ईमानदार जवाब हां है। नीचे इससे बाहर निकलने के लिए engineering-grade मैप दिया गया है।

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

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

स्कोपिंग कॉल्स में हम जो ड्राइवर सुनते हैं वे लगातार एक जैसे हैं: एक प्रोक्योरमेंट गेट जो अब "थर्ड-कंट्री डेटा प्रोसेसर नहीं" (NIS2, DORA, पब्लिक सेक्टर) की मांग करता है, एक कस्टमर ऑडिट (आमतौर पर B2B एंटरप्राइज या हेल्थकेयर) जिसने AWS संबंध को फ्लैग किया है, बढ़ती egress और bandwidth लागत जो हर तिमाही और बदतर दिखती है, या 2024-2025 के EU-US ट्रांसफर मैकेनिज्म अनिश्चितता के दौर के बाद लीडरशिप-स्तर की चिंता। AWS छोड़ने का तकनीकी काम शायद ही कभी उतनी बड़ी बाधा होता है जितना यह दिखता है। असली दिक्कत कोरियोग्राफी की है: zero-downtime डेटाबेस माइग्रेशन, DNS कटओवर, ऑब्जर्वेबिलिटी निरंतरता। यहीं एक managed-infrastructure पार्टनर महीनों की बचत करता है।

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

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

EC2 (compute)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Ubuntu पर KVM virtual machines, Terraform से provision और Ansible से configure किए गए।
इंजीनियरिंग टिप्पणी
हम instances का size किसी catalogue tier के बजाय आपके actual load profile के हिसाब से तय करते हैं, इसलिए ज्यादातर migrations में कम, लेकिन बेहतर-उपयोग वाली machines मिलती हैं।

S3 (object storage)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. MinIO या Ceph RGW, S3-compatible।
इंजीनियरिंग टिप्पणी
S3-compatible APIs सार्वभौमिक हैं; अधिकांश application code में सिर्फ एक endpoint बदलाव होता है। अधिकतर EU providers पर कोई egress fees नहीं है।

RDS / Aurora (managed DB)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. failover के लिए Patroni के साथ PostgreSQL या MySQL, और point-in-time recovery के लिए pgBackRest.
इंजीनियरिंग टिप्पणी
Streaming replication zero-downtime cutover को संभव बनाता है। Managed EU PostgreSQL की pricing आम तौर पर equivalent RDS से 30-50% कम होती है।

CloudFront (CDN)

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

Route 53 (DNS)

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

Lambda (serverless)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. आपके Kubernetes cluster पर Knative या OpenFaaS।
इंजीनियरिंग टिप्पणी
sovereign deployments के लिए, EU compute पर self-hosted Knative सबसे clean विकल्प है। ज्यादातर Lambda workloads एक छोटे Kubernetes cluster में फिट हो जाते हैं।

SES (email)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. DKIM, SPF और DMARC के साथ Postfix, और फ़िल्टरिंग के लिए Rspamd.
इंजीनियरिंग टिप्पणी
1M/माह से कम transactional volume के लिए, एक सही ढंग से configure किया गया Postfix relay, SES की तुलना में operationally सरल और सस्ता है।

SQS / SNS

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

EKS (managed Kubernetes)

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Debian या Talos पर Kubernetes, Cilium networking और certificates के लिए cert-manager के साथ।
इंजीनियरिंग टिप्पणी
EU providers पर Managed K8s में 95% workloads के लिए feature parity है।

CloudWatch / X-Ray

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. Prometheus, Grafana, Loki और Tempo, OpenTelemetry के साथ जुड़े हुए.
इंजीनियरिंग टिप्पणी
OpenTelemetry standard, migration को बेहद आसान बना देता है; operational लाभ के रूप में consolidated dashboards और zero per-metric pricing मिलती है।

IAM

इसके बजाय हम क्या चलाते हैं
Binadit Managed Cloud Platform. identity provider के रूप में Keycloak या Authentik, OIDC और SAML के साथ।
इंजीनियरिंग टिप्पणी
कोई 1:1 रिप्लेसमेंट नहीं है; cross-platform identity को Vault, OIDC providers (Keycloak), और per-tool roles के साथ फिर से बनाया जाता है।

WAF / Shield

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

KMS

इसके बजाय हम क्या चलाते हैं
Binadit Private Infrastructure. Key management के लिए Vault Transit, जहां compliance regime की जरूरत हो वहां HSM-backed keys के साथ।
इंजीनियरिंग टिप्पणी
HYOK scenarios के लिए, cloud-side BYOK के साथ on-premises HSM स्टैंडर्ड sovereign पैटर्न है।

Secrets Manager / SSM Parameter Store

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

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

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

  1. हफ्ते 1-2

    ऑडिट और डिपेंडेंसी मैप

    उपयोग में आने वाली हर AWS service, हर IAM role, हर Lambda, हर cross-service call की inventory बनाएं। personal data flows को tag करें। Output: risk-ranked findings और प्रति service effort estimate के साथ एक remediation plan।

  2. हफ्ते 3-6

    Soft dependencies और egress तैयारी

    पहले CloudFront, Route 53, SES और CloudWatch को replace करें - ज्यादातर के लिए zero application code changes। cutover के दौरान dual-write के साथ S3 buckets को S3-compatible EU storage के पीछे move करें। EU में RDS के replicas pre-stage करें।

  3. सप्ताह 6-14

    Core compute & DB cutover

    DNS-लेवल ट्रैफ़िक शिफ्ट के साथ Blue-green compute माइग्रेशन। low-traffic विंडो के दौरान streaming-replication डेटाबेस कटओवर। EKS वर्कलोड्स को managed EU K8s या self-managed Talos में शिफ्ट किया गया। वेरिफाई होने के बाद AWS अकाउंट को डीकमिशन करें।

उन वर्कलोड्स पर 5-वर्षीय TCO मॉडलिंग जिन्हें हमने वास्तव में माइग्रेट किया है: predictable workloads के लिए EU sovereign infrastructure पर आमतौर पर 30-55% सस्ता, जबकि highly bursty workloads के लिए जो sub-second autoscaling से लाभान्वित होते हैं, यह neutral से लेकर थोड़ा अधिक तक हो सकता है। अकेले egress savings ही अक्सर positive और negative ROI के बीच का अंतर तय करती हैं।

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

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

क्या AWS EU region (Frankfurt, Ireland, Stockholm) का उपयोग करने से Schrems II problem हल हो जाती है?
नहीं। Data residency EU में है लेकिन Amazon Web Services Inc. US कानून के तहत infrastructure का controller है। CLOUD Act US अधिकारियों को दुनिया में कहीं भी US-controlled entities के पास रखे data को disclose करने के लिए मजबूर करने की अनुमति देता है। EDPB ने स्पष्ट रूप से इसे Schrems II मुद्दे के रूप में चिह्नित किया है। AWS EMEA SARL एक Luxembourg subsidiary है जो पूरी तरह से AWS Inc. के स्वामित्व में है; यही ownership chain है जिस पर यह विश्लेषण निर्भर करता है।
व्यवहार में AWS एग्ज़िट में कितना समय लगता है?
एक mid-market application (10-50 EC2 instances, कुछ RDS databases, S3, CloudFront, SES) के लिए, 6-10 लोगों की engineering team और सक्षम operational support के साथ: 10-16 सप्ताह का elapsed time। choreography चला रहे managed-infrastructure partner के साथ (जो असल काम का ज़्यादातर हिस्सा है), 6-10 सप्ताह।
AWS GovCloud या AWS Sovereign Cloud Europe के बारे में क्या?
AWS GovCloud US संघीय वर्कलोड के लिए है और EU खरीदारों के लिए प्रासंगिक नहीं है। AWS European Sovereign Cloud (2023 में घोषित, निर्माणाधीन) EU क्षेत्रों में EU-मुख्यालय वाले AWS स्टाफ द्वारा संचालित है, लेकिन मूल कानूनी इकाई Amazon Web Services Inc. ही बनी रहती है। क्या यह "पर्याप्त रूप से sovereign" है, यह आपके विशिष्ट compliance regime पर निर्भर करता है; कई Schrems II विश्लेषणों के लिए यह पर्याप्त नहीं है क्योंकि मूल jurisdiction नहीं बदलता।
क्या AWS छोड़ने से हम features खो देंगे?
विशिष्ट managed services (DynamoDB single-digit-ms, Aurora Serverless v2, Bedrock model access, H100s पर SageMaker training) के पास कोई स्पष्ट EU sovereign equivalent नहीं है। 90% mid-market workloads के लिए - web applications, APIs, e-commerce, B2B SaaS, warehouses पर analytics - EU sovereign stack इसे cover करता है। अगर आपका workload उस 10% category में आता है तो हम आपको पहले ही बता देते हैं।
क्या हम कुछ AWS सर्विसेज़ रख सकते हैं और बाकी माइग्रेट कर सकते हैं?
हाँ - कभी-कभी hybrid approach ही सही जवाब होता है। अनुशासन यह है कि AWS को केवल स्पष्ट रूप से non-personal workloads के लिए रखा जाए, और boundary को अपने DPA में document किया जाए। हमने ऐसे hybrids चलाए हैं जहाँ AWS ML training संभालता है (कोई personal data नहीं, केवल batch) और EU sovereign stack सभी customer-facing infrastructure संभालता है।
managed exit की cost क्या है?
audit के बाद scope की गई project-based pricing। typical mid-market AWS exit: project के लिए €25-80k, साथ ही नए EU stack के लिए ongoing managed-infrastructure retainer। AWS spend पर पहले साल की savings आमतौर पर project cost से अधिक होती हैं।

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

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

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