कंप्यूट, मैनेज्ड डेटाबेस, egress, बैकअप और ops घंटों का लाइन-दर-लाइन हिसाब, साथ में 37signals के आँकड़े, रुकने या शिफ़्ट करने का फ़ैसला-पेड़ और ऐसी माइग्रेशन योजना जिसमें आख़िरी क़दम तक रोलबैक का रास्ता खुला रहता है।
Author
Anichur Rahaman
cloud के invoice पर रक़म लिखी है $9,400। 40 लोगों की एक ऑनलाइन रिटेल कंपनी की मालिक ने उसे महीने की तीन तारीख़ को खोला है। पिछले अक्टूबर में $6,100 थी, जबकि traffic सिर्फ़ एक-तिहाई बढ़ा है, आधा भी नहीं। "data transfer out" की एक लाइन दोगुनी होकर $1,150 हो गई है, और टीम में कोई नहीं बता पा रहा कि किस feature की वजह से।
वे सोचने लगती हैं कि क्या पूरा system किराये के servers पर सस्ता पड़ता। आधे लोग कहते हैं हाँ। बाक़ी आधे कहते हैं कि कंपनियाँ ऐसे ही रात 3 बजे के आउटेज में फँसती हैं, और फ़ोन करने को कोई नहीं होता।
दोनों सही हैं, बस कंपनियाँ अलग हैं। cloud रिपैट्रिएशन यानी वर्कलोड को पब्लिक cloud से हटाकर अपने किराये या ख़रीदे हुए servers पर वापस लाना। यह तब फ़ायदे का सौदा है जब लोड स्थिर हो, data बड़ा हो और ऑपरेशंस की ज़िम्मेदारी किसी के पास हो। जब लोड अचानक उछलता हो, टीम बहुत छोटी हो या मैनेज्ड सर्विस सच में काम कर रही हो, तब cloud में रहना बेहतर है। यह लेख इस सौदे की हर लाइन पर आँकड़ा रखता है, ताकि आप अपनी दुकान का हिसाब ख़ुद लगा सकें।
यह शब्द एक पूरे दायरे को ढकता है। एक छोर पर है अपने हार्डवेयर पर कोलोकेशन रैक में पूरी तरह लौट जाना। दूसरे छोर पर सिर्फ़ महँगे और स्थिर हिस्से, जैसे database या फ़ाइल स्टोरेज, एक डेडिकेटेड server पर ले जाना और बाक़ी सब वहीं छोड़ देना। ज़्यादातर छोटे और मझोले कारोबारों को पहले दूसरे छोर के बारे में सोचना चाहिए।
सबसे अच्छी तरह दर्ज मिसाल 37signals की है, जो Basecamp और HEY की कंपनी है। मई 2025 की The Register की report के मुताबिक़ उसने Dell servers पर क़रीब $7,00,000 ख़र्च किए और cloud बिल सालाना लगभग $20 लाख घटा लिया। फिर उसने क़रीब 18 पेटाबाइट स्टोरेज Amazon S3 से हटाकर Pure Storage ऐरे पर पहुँचाया, जिस पर लगभग $15 लाख लगे; उम्मीद है कि हर साल $13 लाख और बचेंगे। निकलते समय AWS ने क़रीब $2,50,000 की egress फ़ीस माफ़ कर दी, और कंपनी का अनुमान है कि पाँच साल में $1 करोड़ बचेंगे। उसके CTO का कहना है कि अतिरिक्त स्टाफ़ की ज़रूरत नहीं पड़ी।
इसे ध्यान से पढ़िए। 37signals का सालाना बिल $32 लाख था, ऑपरेशंस का बरसों का अनुभव था और माँग सपाट और अनुमान लगाने लायक़ थी। आँकड़े असली हैं, पर उस कंपनी के हैं जिसमें ये तीनों बातें थीं। ब्योरे के लिए The Register की report पढ़ने लायक़ है।
दबाव सिर्फ़ दाम का नहीं, बर्बादी का भी है। Flexera की 2026 State of the Cloud report, जो 750 से ज़्यादा cloud निर्णयकर्ताओं और यूज़र्स का सर्वे है, अनुमान लगाती है कि cloud ख़र्च का 29% बर्बाद हो रहा है। पाँच साल में यह पहली बढ़ोतरी है, और AI वर्कलोड इसकी एक वजह हैं। उसी सर्वे में 85% लोगों ने cloud ख़र्च सँभालना बड़ी चुनौती बताया (Flexera की प्रेस विज्ञप्ति)। cloud के भीतर जो बर्बादी ठीक हो सकती है, वही सबसे सस्ती बचत है, और वह किसी भी शिफ़्ट से पहले आती है।
cloud invoice और server किराये के बीच के फ़र्क़ को चार ख़र्चे ज़्यादातर समझा देते हैं।
cloud में data डालना मुफ़्त है, इंटरनेट पर निकालना मीटर से चलता है। AWS की सूची में हर महीने पहले 100 GB मुफ़्त हैं, फिर पहले 10 TB पर $0.09 प्रति GB, और उसके ऊपर सस्ती सीढ़ियाँ। product इमेज, invoice PDF और API रेस्पॉन्स देने वाला स्टोर बिना पता चले 8 TB पार कर सकता है। डेडिकेटेड server के मासिक किराये में आम तौर पर 20 TB या उससे ज़्यादा traffic शामिल रहता है।
दूसरे ज़ोन में स्टैंडबाय replica वाला मैनेज्ड database, नीचे के कच्चे कंप्यूट से कई गुना महँगा पड़ता है। आप ऑटोमैटिक failover, पैचिंग और point-in-time recovery के पैसे दे रहे हैं। टीम में ये काम करने वाला कोई न हो तो दाम वाजिब है, और कोई हो तो महँगा।
सबसे व्यस्त दिन के हिसाब से बने इंस्टेंस बाक़ी दिनों में 15% लोड पर चलते हैं। autoscaling तभी काम आता है जब app साफ़-सुथरे ढंग से scale out हो सके। पीक के हिसाब से बने एक फ़िक्स्ड server में भी यही सुस्ती रहती है, पर यूनिट दाम बहुत कम होता है।
GPU इंस्टेंस, वेक्टर स्टोरेज और उनसे बनने वाले traffic का बिल घंटे और गीगाबाइट के हिसाब से आता है। Flexera बर्बादी की बढ़त को ठीक इन्हीं वर्कलोड से जोड़ती है। प्रयोग cloud में चलाइए, जहाँ जब चाहें बंद कर सकते हैं, और स्थिर inference लोड का दाम अलग से निकालिए।
एक काल्पनिक दुकान लीजिए: एक वेब app, बैकग्राउंड worker, एक PostgreSQL database और महीने में क़रीब 8 TB आउटबाउंड traffic। ये आँकड़े अभ्यास के लिए गोल किए गए हैं, कोई कोटेशन नहीं। ops का समय $75 प्रति घंटे के हिसाब से गिना गया है।
| मद (उदाहरण) | हाइपरस्केलर, on-demand | दो डेडिकेटेड server + database के लिए दो और |
|---|---|---|
| कंप्यूट (app और worker) | $900 | $230 |
| database (प्राइमरी + replica) | $1,100 मैनेज्ड | $230 ख़ुद चलाया हुआ |
| Egress, 8 TB | $711 | $0 (किराये में शामिल) |
| backup और स्नैपशॉट | $190 | $60 ऑफ़-साइट ऑब्जेक्ट स्टोरेज |
| लोड बैलेंसर, लॉग, monitoring | $450 | $90 |
| Ops के घंटे | 25 घंटे = $1,875 | 45 घंटे = $3,375 |
| महीने का कुल | $5,226 | $3,985 |
Egress की लाइन सीधा गणित है: 8,000 GB में से मुफ़्त 100 GB घटाइए तो 7,900 GB, गुणा $0.09, यानी $711। महीने की बचत $1,241 है, लगभग 24%, या साल के $14,892।
जश्न मनाने से पहले आख़िरी पंक्ति देखिए। हार्डवेयर और बैंडविड्थ $3,351 से घटकर $610 हो गए, पर ops का समय 20 घंटे बढ़ गया। ब्रेक-ईवन वहाँ है जहाँ $610 जमा $75 गुणा घंटे बराबर हो $5,226 के, यानी महीने में क़रीब 61 घंटे। उससे ऊपर cloud ही सस्ता था।
अब cloud के कंप्यूट और database पर एक साल की कमिटमेंट का 30% discount मान लीजिए। cloud का कुल $4,626 रह जाता है, फ़र्क़ घटकर $641 हो जाता है और ब्रेक-ईवन क़रीब 54 घंटे पर आ जाता है। 200 इंजीनियरिंग-घंटे का माइग्रेशन $15,000 का पड़ता है, जो पुराने फ़र्क़ पर लगभग बारह महीने में वसूल होता है और छोटे फ़र्क़ पर काफ़ी ज़्यादा समय में।
फ़ैसला शायद ही कभी सिर्फ़ दाम पर टिकता है। इसी क्रम में चार सवाल ज़्यादातर कारोबारों को छाँट देते हैं।
पहला, क्या लोड स्थिर है और बिल इतना बड़ा कि बचत मायने रखे? महीने के लगभग $3,000 से नीचे बचत से अतिरिक्त देखभाल का ख़र्च नहीं निकलता। तब बर्बादी छाँटिए और committed क्षमता ख़रीदिए।
दूसरा, क्या traffic अचानक उछलता है या सचमुच दुनिया भर से आता है? एक घंटे की फ़्लैश सेल में traffic दस गुना हो जाए तो इलास्टिक क्षमता इसी काम के लिए है। पूरे साल पीक के हिसाब से किराया देना, पीक के चंद घंटों के cloud दाम से ज़्यादा पड़ता है। ऐसे उछाल को system कैसे सँभालता है, यह इस सीरीज़ के autoscaling वाले लेख में है। दुनिया भर वाले हिस्से का बड़ा भाग फ़िक्स्ड origin के आगे लगा CDN सँभाल लेता है।
तीसरा, क्या पैचिंग, backup और on-call किसी की ज़िम्मेदारी है? नाम लेकर कोई न हो तो बचत असली नहीं है। तब बीच का कोई मैनेज्ड विकल्प चुनिए।
चौथा, क्या ग्राहक या नियामक तय करते हैं कि data कहाँ रहेगा? हाँ हो तो जवाब है क्षेत्रीय या देसी होस्ट, जो आपका मौजूदा प्रोवाइडर शायद न हो।
चुनाव सिर्फ़ हाइपरस्केलर और अपने रैक के बीच का नहीं है।
शिफ़्ट कितना सस्ता होगा, यह पोर्टेबिलिटी तय करती है। जो app container और एक compose फ़ाइल में पैक है, जैसे StoreConsole जैसे self-hosted platform, वह इनमें से किसी भी विकल्प पर एक दोपहर में पहुँच जाता है। जो app प्रोप्राइटरी queue और serverless फ़ंक्शन से जकड़ा है, उसे पहले दोबारा लिखना पड़ता है।
बड़े ख़रीदार अब पूछते हैं कि data कहाँ रखा जाता है, कौन उस तक क़ानूनी तौर पर पहुँच माँग सकता है, और क्या वे चाहें तो छोड़कर जा सकते हैं। ये प्रोक्योरमेंट के सवाल हैं, और जो दुकान इनका जवाब नहीं दे पाती वह डील गँवाती है।
नियम-क़ानून भी छोड़कर जाने की लागत घटा रहे हैं। EU Data Act के तहत बदलाव की अवधि में प्रोवाइडर स्विच करने के लिए सिर्फ़ अपनी सीधी लागत ले सकते हैं, और egress समेत सारे स्विचिंग चार्ज 12 जनवरी 2027 को ख़त्म हो जाते हैं। EU में ग्राहक या EU का कॉन्ट्रैक्ट हो तो यह तारीख़ आपकी योजना में होनी चाहिए। EU के बाहर शुरू करने से पहले exit-फ़ीस की छूट लिखित में माँगिए, जैसा 37signals ने किया।
लोकेशन का मतलब सुरक्षा नहीं है। अपने देश का server, ठीक से कॉन्फ़िगर किए cloud रीजन से ज़्यादा सुरक्षित नहीं होता। वह क़ानूनी सवाल का जवाब है, तकनीकी का नहीं।
रिपैट्रिएशन कोई वीकेंड का काम नहीं, छोटे और पलटे जा सकने वाले क़दमों की कड़ी है। नीचे हर क़दम में आख़िरी तक लौटने का रास्ता खुला रहता है।
सबसे बड़ा जोखिम ऑपरेशंस की महारत है: कर्नेल और database पैचिंग, सर्टिफ़िकेट रिन्यूअल, डिस्क-फ़ुल alert और failover ड्रिल अब आपके ज़िम्मे हैं। दूसरा जोखिम monitoring है, क्योंकि जिस cloud कंसोल पर आप टिके थे वह अब नहीं रहा। कोई critical CVE आए तो सिक्योरिटी पैच की मियाद दिनों में नापी जाती है। कम से कम दो लोगों का on-call रोटेशन तय कीजिए, या कोई मैनेज्ड परत ख़रीद लीजिए।
हर महीने पाँच संख्याएँ देखिए। एक, ops घंटों समेत कुल इन्फ़्रास्ट्रक्चर ख़र्च, क्योंकि मेहनत का दाम जोड़े बिना ख़र्च ज़्यादा अच्छा दिखता है। दो, महीने के ops घंटे, अपने ब्रेक-ईवन के सामने रखकर। तीन, पिछली restore ड्रिल का recovery time, मिनटों में। चार, पैच की उम्र, यानी सबसे पुराना जाना-पहचाना सिक्योरिटी अपडेट कितने दिन पहले लगा था। पाँच, मुख्य ग्राहक-क्षेत्रों से p95 latency, क्योंकि ग्लोबल network छोड़ने पर कुछ मिलीसेकंड गँवा सकते हैं।
ops घंटे ब्रेक-ईवन से आगे निकल जाएँ या restore ड्रिल फ़ेल हो जाए तो शिफ़्ट फ़ायदा नहीं दे रहा, और उस नतीजे पर क़दम उठाना ही काम की बात है।
लौटते हैं उस मालिक और उनके $9,400 के invoice पर। मद के हिसाब से बाँटने पर वे पाती हैं कि egress और मैनेज्ड database मिलकर बिल का 40% हैं, और egress का ज़्यादातर हिस्सा origin से सीधे परोसी जा रही product इमेज से आता है।
पहले वे सामने एक CDN लगाती हैं, जिससे इस परिदृश्य में एक हफ़्ते के भीतर egress आधे से ज़्यादा घट जाता है। फिर 13 हफ़्ते की योजना में स्थिर database और worker डेडिकेटेड server पर ले जाती हैं, स्टोरफ़्रंट का edge और सेल-दिन की अतिरिक्त क्षमता cloud में ही रखती हैं, और restore ड्रिल को कैलेंडर में दर्ज कर देती हैं। invoice अब ऐसा दस्तावेज़ है जिसे वे लाइन-दर-लाइन समझा सकती हैं, और अगली बढ़ोतरी पर एक नाम लिखा होगा।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
