AWS से Hetzner पर migrate करके cloud लागत 76% घटाई

 (digitalsociety.coop)
9 पॉइंट द्वारा GN⁺ 2025-10-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS और DigitalOcean से migration करके Hetzner पर जाने से cloud लागत 76% कम हुई और resource capacity 3 गुना बढ़ गई
  • पहले AWS की reliability और DigitalOcean की simplicity के आधार पर दोनों cloud सेवाओं का साथ में उपयोग किया जाता था
  • free credits खत्म होने के बाद हर महीने $449 से अधिक की operating cost का बोझ बढ़ा, जिससे Hetzner जैसे विकल्पों की तलाश शुरू हुई
  • लागत घटाने के लिए Talos Linux आधारित Kubernetes, CloudNativePG, Ingress NGINX, ExternalDNS, cert-manager आदि को मिलाकर self-managed cloud stack बनाया गया
  • Hetzner के ARM shared vCPU servers और S3-compatible storage का उपयोग करके performance और stability बनाए रखते हुए बड़े पैमाने पर resource expansion हासिल किया गया
  • management convenience कुछ कम है, लेकिन यूरोप के भीतर एक alternative cloud के रूप में इसकी cost-performance efficiency शानदार है

पृष्ठभूमि

  • DigitalSociety में विकसित होने वाला सारा software cloud-based वातावरण में चलता है
  • migration से पहले मुख्य infrastructure को AWS (मुख्य services, authentication और mail आदि का प्रबंधन) और DigitalOcean (हल्की services, monitoring, Kubernetes) दोनों पर चलाया जाता था
  • AWS को 15 साल से अधिक के परिचय और उच्च API stability के कारण चुना गया
  • DigitalOcean को सरल Kubernetes environment, free control plane और cost efficiency की वजह से चुना गया
  • शुरुआत में सिर्फ DigitalOcean का इस्तेमाल था, लेकिन data-intensive SaaS tap जैसे workloads के लिए अधिक resources और अतिरिक्त credits की जरूरत पड़ी, इसलिए AWS startup credits ($1,000) का उपयोग किया गया

credits खत्म होना और लागत का बोझ

  • AWS Fargate (serverless container running) की वजह से शुरुआत में सस्ता setup संभव हुआ, लेकिन tap सेवा की data-intensive प्रकृति के कारण performance बनाए रखने के लिए कम-से-कम 2x CPU, 4 GiB RAM चाहिए था
  • Fargate के आधार पर इस specification वाले container की लागत $70+ प्रति माह थी, और दो worker instances तथा अन्य infrastructure जोड़ने पर यह $449.50 प्रति माह तक पहुंच गई
  • दिए गए free credits 6 महीने से पहले ही खत्म हो गए, और self-funded startup के लिए यह एक गंभीर fixed-cost burden बन गया

विकल्प तलाशने की प्रक्रिया

  • ऊंची operating cost घटाने और तकनीकी स्वतंत्रता हासिल करने के लिए UK/EU-based cloud providers की तलाश की गई
  • Hetzner की price competitiveness से प्रभावित होकर, self-managed VPS environment और operational complexity के बावजूद AWS और DigitalOcean दोनों से migration का फैसला लिया गया
  • चूंकि पहले से ज्यादातर services Kubernetes पर चल रही थीं, इसलिए Talos Linux की आसान cluster setup क्षमता की मदद से Hetzner environment में भी अपना Kubernetes cluster बनाया गया
  • AWS या DigitalOcean की तरह managed DB service यहां नहीं थी, लेकिन CloudNativePG की मदद से Kubernetes environment में PostgreSQL cluster का सुरक्षित integrated management (monitoring, backup, failure response आदि) किया गया

नया infrastructure stack

  • Hetzner: ARM servers, block storage, load balancer, network, firewall, S3-compatible object storage का उपयोग
  • Talos Linux: declarative configuration के जरिए Kubernetes nodes का management, जिससे operations automation संभव हुआ
  • CloudNativePG: Kubernetes manifests में DB cluster declare करना, automatic backup, failure response आदि के लिए integrated support
  • Ingress NGINX Controller: cluster के भीतर HTTP routing का integrated management
  • ExternalDNS: ingress resources के साथ DNS का automatic integration
  • cert-manager: HTTPS के लिए TLS certificates का automatic issuance
  • पूरा infrastructure Terraform और Helm के साथ code के रूप में प्रबंधित किया गया, और GitHub Actions के जरिए automated deployment से DevOps लागू किया गया

लागत तुलना

  • migration से पहले मासिक लागत: AWS + DigitalOcean = $559.36
  • migration के बाद मासिक लागत: Hetzner = $132.96 (−76%)
  • resource वृद्धि:
    • CPU: 12 vCPU → 44 vCPU (+367%)
    • RAM: 24 GiB → 88 GiB (+367%)
    • resources बढ़ने के बावजूद कुल मासिक लागत काफी कम रही

migration प्रक्रिया की चुनौतियां और trial and error

  • Hetzner के network zones, AWS के Availability Zone से पूरी तरह समान नहीं हैं
    • AWS में एक region के भीतर कई availability zones होते हैं, और private networking region स्तर पर व्यापक रूप से जुड़ी होती है
    • Hetzner में एक network zone (eu-central) के तहत कई locations होती हैं, और इनके बीच network latency अधिक है
    • monitoring के जरिए यह अनुभव हुआ कि कई locations में distribution करने पर performance degradation जैसी समस्याएं आती हैं
    • विकल्प के तौर पर एक ही location (Nuremberg) में Placement Group का उपयोग कर physical server distribution के जरिए fault resilience हासिल की गई
  • Container-based services होने पर भी portability आसान नहीं थी
    • AWS ECS से Kubernetes में environment ले जाते समय, पूरी setup automation scripts (खासकर config files deployment आदि) को बदलने का काम उम्मीद से ज्यादा लंबा चला
    • आखिरकार Kustomize के जरिए sensitive settings integration और config file management structure को बेहतर बनाया गया, जिससे traceability और review convenience बढ़ी

निष्कर्ष

  • Hetzner आसान managed service नहीं है, लेकिन self-management करने वाली टीमों के लिए बहुत efficient विकल्प है
  • self-operated setup के जरिए detailed configuration control बनाए रखते हुए cost के मुकाबले performance को maximize किया जा सकता है
  • इस तरीके से data-intensive SaaS tap को उचित लागत और स्थिर performance के साथ लगातार विकसित और संचालित करने की नींव तैयार हुई

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-10-18
Hacker News राय

  • मैं ज़ोर देकर कहना चाहता हूँ कि bare metal पर सीधे deploy करने पर जो performance gain महसूस होता है, वह सच में बहुत बड़ा होता है। हमारी service में performance 2 गुना बढ़ गया और predictable, stable performance मिला। इसके कई कारण हैं:

    • कम latency: नेटवर्क को सीधे manage करने पर बड़े datacenter के complex shared network का हिस्सा नहीं बनना पड़ता, इसलिए latency 10 गुना से भी ज़्यादा कम हो जाती है

    • cache optimization: hardware-optimized deployment के जरिए modern CPU की असली performance का पूरा फायदा उठाया जा सकता है

    • dedicated NVMe का उपयोग: disk IO speed बेहद तेज़ होती है

    • एक और फ़ायदा यह है कि autoscaler की ज़रूरत लगभग नहीं रह जाती। उसी कीमत में hardware performance 10 गुना ज़्यादा और speed 2 गुना होने से full size में चलाना ज़्यादा तार्किक लगता है। पूरा system ज़्यादा stable होता है और manage करना आसान हो जाता है

    • S3 billing की भी चिंता नहीं करनी पड़ती। हर server में 15TB NVMe drive लगाकर MinIO/garage cluster चलाया जा सकता है। हम 10-node cluster में 20GiB प्रति सेकंड और 50,000 API calls प्रति सेकंड संभाल रहे हैं। अगर यह S3 पर होता, तो सिर्फ API call का खर्च $20~$250 प्रति सेकंड होता — फ़र्क चौंकाने वाला है

    • बस महीने का fixed bill आता है

    • और सस्ता high-speed storage, बड़े PostgreSQL instances को कम लागत में चलाना, और cloud में महसूस होने वाली constraints व बेकार की जद्दोजहद — सब काफ़ी कम हो जाती है

    • अगर इस तरह की architecture में invest भी करें, तब भी AWS की तुलना में लागत 10वें हिस्से के बराबर रहती है

    • अगर इसे खुद manage करना बोझ लगे, तो हम (https://lithus.eu) AWS की आधी कीमत पर इसे manage कर सकते हैं और DevOps support भी देते हैं। संपर्क के लिए domain पर adam@ देखें

    • तकनीकी पृष्ठभूमि: bare metal का मतलब है कि यह virtualization (VM) नहीं, बल्कि सीधे वास्तविक server पर चलता है

    • मैं सच में चाहता हूँ कि हम उस पुराने दौर से आगे बढ़ें जिसमें कहा जाता था, 'बस और machines जोड़ो तो सब तेज़ हो जाएगा', 'खर्च की कोई खास अहमियत नहीं'। अपने career में .NET दौर में मैंने single cabinet server पर लाखों users तक service चलती देखी है। उसके बाद जब मैं cloud-based, container, Node microservices इस्तेमाल करने वाली company में गया, तो billing और performance issues की अफ़रातफ़री रोज़ झेलनी पड़ी — आज भी सोचकर कभी-कभी सिहरन होती है

    • बदलाव हमेशा खुद को दोहराता लगता है। हमारी company को देखकर कभी-कभी लगता है कि बिना नई technology के भागे, बस चीज़ों को चलाते रहना ही local cloud/edge/on-prem IDC की धारा के सबसे आगे होना है

    • S3 API इस्तेमाल करना प्याज़ छीलने जैसा लगता है। जितना ज़्यादा इस्तेमाल करो, उतने ज़्यादा आँसू आते हैं

    • bare metal पर जाने का मतलब है network management, security · monitoring, patching, upgrades आदि के लिए dedicated staff चाहिए। ऐसे specialist manpower का खर्च सिर्फ एक तय scale के बाद ही efficient होता है। इसलिए SMB के लिए अब भी cloud security और operational cost के लिहाज़ से फ़ायदेमंद है

    • AWS खुद अपने docs में मानता है कि Lambda में 1 vCPU allocation के मामले में वास्तव में लगभग 50% ही दिया जाता है। memory·CPU allocation बढ़ाने पर ratio बेहतर होता है, लेकिन 100% performance हमेशा नहीं मिलती

  • मैं लंबे समय से सोचता था कि dedicated servers का इस्तेमाल करने से efficiency को maximization तक ले जाया जा सकता है। मैं Hetzner पर कुछ nodes चला रहा हूँ, और 3 साल पुराने पुराने servers भी अगर auction के ज़रिए किराए पर लिए जाएँ, तो VM से बिल्कुल अलग स्तर की performance मिलती है। server hardware core count और IO के हिसाब से optimized होता है, और ज़्यादातर cloud providers hardware को overcommit करके देते हैं। यहाँ तक कि disk IO के लिए भी NAS पर चलाकर local disk जैसा emulate करने जैसी तरह-तरह की तरकीबें लगाते हैं। ज़्यादातर startups को इतनी over-virtualization या NAS-based disks की ज़रूरत नहीं होती। उल्टा, Hetzner जैसे provider से server rent पर लेकर कहीं ज़्यादा दूर, कहीं सस्ते में जाया जा सकता है। मैं जानना चाहूँगा कि North America, खासकर Canada में, Hetzner जैसी price·quality देने वाले कौन providers हैं। OVH के बारे में पता है, तो अगर कोई similar provider हो तो बताइए

    • लगता है बहुत से लोग मानते हैं कि Google·Facebook जैसा infra तुरंत copy करना चाहिए। हम Europe के VPS पर काफ़ी सादगी से काम चला रहे हैं। लेकिन हर नया hire (business हो या dev) आते ही cloud migration project शुरू करने की बात करता है। हर बार समझाना पड़ता है, "हम पहले से ही cloud इस्तेमाल कर रहे हैं, तुम्हारे resume के लिए cloud migration project नहीं करेंगे"

    • मैंने वास्तव में cloud और bare metal server CPU performance का benchmark किया है, चाहें तो देख सकते हैं https://jan.rychter.com/enblog/cloud-server-cpu-performance-comparison-2019-12-12

    • हाल में एक site मिली जो मददगार हो सकती है: https://vpspricetracker.com इसका concept काफ़ी प्रभावशाली है। यहाँ listed ज़्यादातर providers dedicated servers भी देते हैं

    • अगर मतलब यह है कि "अमेरिका में Hetzner quality चलेगी, बस local brand होना ज़रूरी नहीं", तो Hetzner के अपने भी अमेरिका में 2 datacenters हैं

    • Canada के संदर्भ में देखने लायक providers में https://www.hostpapa.ca/, https://www.cacloud.com/, https://www.keepsec.ca/, https://www.canspace.ca/ शामिल हैं

  • हम भी यही trend देख रहे हैं। कई teams Hetzner पर move करके इसके price-to-performance से प्रभावित होती हैं, लेकिन फिर समझती हैं कि Postgres operations — backup, failover, monitoring वगैरह — सब फिर से खुद बनाना पड़ेगा। इसलिए हमने Hetzner पर सीधे चलने वाला managed Postgres बनाया। वही hardware-optimized structure, साथ में high availability (HA), backups, और point-in-time recovery (PITR) भी। यह open source है, hardware के काफ़ी करीब चलता है, और AWS में आम तौर पर दिखने वाले I/O charges या data outbound के hidden traps भी नहीं हैं। दिलचस्पी हो तो blog देखें 1, 2

    • इसी वजह से मैं Big Cloud, खासकर PaaS और managed SQL का आकर्षण गहराई से महसूस करता हूँ (जिन dev teams को मैं सलाह देता हूँ, वे भी)। भले operational experience कम हो, database backup/restore, patching, access restrictions, port management, anomaly detection, DoS attack response जैसी चीज़ें अपने-आप हो जाती हैं, इसलिए इसे अपनाने में मानसिक सुकून मिलता है। राजनीतिक और तकनीकी दोनों मायनों में लोकप्रिय cloud कंपनियों का इस्तेमाल करना एक psychological safety net जैसा लगता है

    • अगर self-configured, self-managed Postgres से जुड़ी समस्याएँ हैं, तो https://www.elephant-shed.io/ देखना उपयोगी हो सकता है

  • इस तरह के लेखों और comments में मज़ेदार बात यह है कि सलाह लगभग कभी context के साथ नहीं आती। यह spare time में church newsletter चलाने की बात है, या global customers वाली high-traffic enterprise SaaS की — इन दोनों में ज़रूरतें पूरी तरह अलग होंगी। अपने environment का विवरण दिए बिना price, performance, availability पर सलाह देना लगभग बेअर्थ है। web infra ज़रूरत से ज़्यादा complex होने का एक कारण यह भी है कि अलग-अलग requirements वाले लोग एक-दूसरे की सलाह नकल करते रहते हैं

    • मैं अपनी बात में यह जोड़ना चाहूँगा कि "requirements अलग होने पर भी सलाह को बिना सोचे-समझे follow करना सिर्फ़ वास्तविकता को और जटिल बनाता है"। कुछ कंपनियों में cloud account manager C-level executives के lunch तक में घुसकर AWS इस्तेमाल करवाता है। उस process में AWS के architects हमारी team के साथ सीधे जुड़ते हैं, और फिर स्वाभाविक रूप से सबसे महंगे serverless options ही recommend किए जाते हैं। लेकिन हक़ीक़त यह है कि अंत में बार-बार Docker OS images deploy करनी पड़ती हैं और उन्हें वैसे ही लगातार manage करना पड़ता है जैसे किसी सामान्य bare metal server को patch किया जाता है

    • मेरी personal Pastebin भी bare metal के बिना नहीं चल सकती (मज़ाक)

    • यही IT industry की एकदम क्लासिक तस्वीर है

    • requirements, technical maturity, cost structure और problem domain — सब पूरी तरह अलग होते हैं। Hetzner और AWS ऊपर-ऊपर से cloud जैसे दिखते हैं, लेकिन असल में पूरी तरह अलग services हैं। यह मैं दोनों इस्तेमाल करने के अनुभव से कह रहा हूँ

    • पूरी तरह सहमत। मैंने इस पर अपना विचार blog में भी लिखा है, देखें https://news.ycombinator.com/item?id=45616366। संक्षेप में: "hosting providers को DIY से enterprise तक एक pricing ladder की तरह समझो, और अगर ज़रूरत नहीं है (YAGNI), तो सिर्फ़ नाम के लिए मत चुनो"

  • मैं 10 साल से ज़्यादा समय से Hetzner पर SaaS चला रहा हूँ। पूरी तरह dedicated hardware, Germany·Finland datacenters में cluster setup, और ansible से management करता हूँ। servers के बीच VPN connectivity के लिए vpncloud इस्तेमाल करता हूँ (यह software वाकई शानदार है)। monthly hosting cost AWS वगैरह के मुकाबले बेहद कम है, और servers कहीं ज़्यादा तेज़ हैं। simple architecture और कम servers से काम चल जाता है। ज़रूरत पड़े तो बस servers जोड़ते हैं, लेकिन bare metal होने की वजह से यह मिनटों में scale नहीं होता। कुछ घंटे या कुछ दिन पहले planning कर लेनी पड़ती है। database के लिए RethinkDB का distributed structure इस्तेमाल कर रहे हैं (अब FoundationDB में migrate करने का इरादा है), ताकि failures से निपटा जा सके

    • मैं भी rethinkdb के साथ कुछ ऐसा ही चला रहा हूँ। लेकिन खास तौर पर FoundationDB चुनने की वजह जानने में दिलचस्पी है। RethinkDB अब भी maintained है, और कभी-कभी नए features भी आते हैं। Slack community भी उम्मीद से ज़्यादा active है

    • यह देखकर अच्छा लगा कि अब भी लोग RethinkDB इस्तेमाल कर रहे हैं

    • क्या आप Hetzner DE/FI centers के बीच vpncloud से direct connect करते हैं? मुझे लगा Hetzner खुद भी ऐसी सुविधा काफ़ी सस्ते में देता है

  • हाल में मैंने कई teams को AWS से Hetzner (और Netcup) में जाने में मदद की है, और लोगों के लिए सबसे बड़ा surprise cost या performance नहीं, बल्कि यह होता है कि जब आप management abstractions (services) की 15 परतें हटा देते हैं, तो architecture अचानक कितना सरल हो जाता है। S3/EFS/FSx की दिक्कतें, Lambda cold start, EBS burst credits जैसी चिंताएँ गायब हो जाती हैं। बस तेज़ NVMe पर Docker deploy करो और चीज़ें चल पड़ती हैं। हाँ, DevOps capability — monitoring, backup, patching वगैरह — थोड़ी ज़्यादा चाहिए। लेकिन इस तरह के operations automate हो जाएँ तो हर हफ़्ते बदलने वाली चीज़ नहीं रहते। Elestio में हम इसी simplification पर ध्यान देते हैं, और 400 से अधिक open source software की fully managed stacks किसी भी cloud पर देते हैं (CI/CD सहित)। Hetzner जैसी जगहों से लेकर production तक सब cover होता है https://elest.io (संदर्भ: मैं Elestio में काम करता हूँ और Multi-Cloud open source services देता हूँ)

    • तुम्हारी managed Postgres service दिलचस्प लगी। क्या यह streaming replicas और streaming backups support करती है, या सिर्फ़ s3 में dump store करती है?

  • अपने career की शुरुआत में मैं एक बेहद अच्छी company में था, लेकिन उस समय RDS जिस Postgres version को support नहीं करता था, वही चाहिए था, इसलिए EC2 पर कई बार सीधे Postgres setup करना पड़ा। वह Docker से पहले का दौर था, इसलिए setup करना धीरे-धीरे सिर्फ़ समय की बर्बादी बनता गया। जैसे ही RDS ने वह version support करना शुरू किया, सब कुछ अचानक आसान हो गया। रात 3 बजे तक बार-बार Postgres install करने की याद आज भी ताज़ा है। यह लेख अच्छा है, लेकिन आखिरकार बचत महीने के कुछ सौ डॉलर की ही है। अगर एक engineer महीने में सिर्फ़ 1 घंटा भी maintenance में लगा दे, तो savings neutralize हो सकती हैं। अगर अचानक outage हो जाए, तो साल भर की बचत एक ही दिन में उड़ सकती है। जिन personal projects में समय की कीमत उतनी मायने नहीं रखती, और बड़े servers चाहिए होते हैं, वहाँ bare metal बेहतर हो सकता है। लेकिन अंत में मेरे समय की कीमत ज़्यादा हो जाती है। जैसे Ghost blog को official hosting पर चलाने के लिए महीने के $10 ही लगते हैं, जबकि कई blogs Hetzner instance पर भी चलाए जा सकते हैं। लेकिन फिर लगता है, अगर कुछ टूट गया और उसे ठीक करने में 2~3 घंटे लगने हैं, तो क्या $20 extra देना बेहतर नहीं?

  • Hetzner के (कुछ) dedicated servers का सबसे बड़ा फ़ायदा unlimited bandwidth है। मैं image-heavy sites host करता हूँ, और Hetzner पर आने के बाद 3 साल से सिर्फ़ fixed bill भरकर रात को चैन से सो पा रहा हूँ

  • Hetzner में scale-out की सीमाएँ साफ़ हैं। हमने भी शुरुआत में Hetzner-based setup पर सैकड़ों VM चलाए, और peak समय में 1,000 से ज़्यादा तक scale करना पड़ता था। लेकिन तब समस्याएँ आईं: कभी-कभी blacklist में पड़े IP assign हो जाते थे, जिससे AWS, Google (खासकर S3) से connectivity में दिक्कत होती थी। यहाँ तक कि एक समय ऐसा आया जब हमारे region में VM बिल्कुल बचे ही नहीं, इसलिए नई allocations रुक गईं। आखिर में नतीजा यह रहा कि अगर बहुत बड़े scale की ज़रूरत नहीं है तो Hetzner शानदार है, लेकिन जब सच में massive scaling चाहिए, तो दूसरी services को mix करना पड़ता है

    • किसी region में VM का पूरी तरह खत्म हो जाना शायद सिर्फ़ किसी एक cloud की समस्या नहीं है। GCP में भी कुछ साल पहले ऐसा था। peak hours में अगर एक साथ सैकड़ों VM माँगे जाएँ, तो शायद कोई भी cloud provider दबाव महसूस करेगा

    • Microsoft द्वारा Hetzner·Scaleway services को block करने की घटना काफ़ी जानी-पहचानी है https://www.linkedin.com/posts/jeroen-jacobs-8209391_something-interesting-happened-today-it-activity-7382774062164516864-GSKT/. यह नहीं पता था कि AWS और GCP ने भी ऐसा किया था, लेकिन हैरानी भी नहीं होती। Big Cloud कंपनियाँ इसे "spam inflow" के बहाने से justify करती हैं, जबकि असल में यह anti-competitive behavior जैसा लगता है

    • यहाँ शायद Hetzner के actual hardware (Server Auction आदि) users और virtual server (VM) users के अनुभवों का अंतर सामने आ रहा है। असली physical servers value-for-money और speed में कहीं बेहतर होते हैं, जबकि VM भले revolutionary न हों, फिर भी competitors की तुलना में सस्ते रहते हैं

    • यह विवाद Hetzner Cloud product (VM) को लेकर है। Cloud product dedicated servers की तुलना में अपेक्षाकृत हाल में आया है। कई users अब भी Hetzner को उसके dedicated servers की वजह से ज़्यादा चुनते हैं

    • सच में जानना चाहूँगा कि ऐसी कौन-सी service थी जिसमें सैकड़ों से हज़ारों VM चाहिए थे, और dedicated servers के बजाय VM चुनने की वजह क्या थी। Hetzner के सबसे बड़े VM specs (48 cores, 192GB RAM, 960GB SSD) बताए जाते हैं, तो उस scale की ज़रूरत दिलचस्प लगती है

  • Hetzner इस्तेमाल करने की वजहें हैं, लेकिन कुछ सावधानियाँ भी हैं। availability AWS से कुछ कम हो सकती है, और regions की diversity भी सीमित है। इसलिए मैं इसे Cloudflare के साथ इस्तेमाल करने की सलाह दूँगा। Hetzner पर core systems (K8s) चलाओ, और data को R2/D1/KV, Edge Durable Objects में distribute करो। customer data को हर DO के हिसाब से shard करने पर core database पर load distribution भी मिलता है और security benefit भी

    • AWS में भी आश्चर्यजनक रूप से बड़े outages काफ़ी हुए हैं। आख़िरकार, अगर multi-region architecture नहीं है, तो availability की समस्या को structurally टालना मुश्किल है

    • मैंने भी Hetzner पर bare metal में core और storage redundancy बनाई है, और OVH पर global edge nodes जोड़कर अपनी तरह का CDN जैसा setup किया है

    • अगर customer data edge पर है, तो फिर "core" से आपका मतलब ठीक-ठीक क्या है?