Azure प्राइसिंग कैलकुलेटर का उपयोग कैसे करें (स्टेप-बाय-स्टेप)

क्लाउड खर्च का कम आकलन करना आसान है—जब तक पहली इनवॉइस नहीं आ जाती। सौभाग्य से हमारे पास Azure प्राइसिंग कैलकुलेटर है, जो Microsoft का एक मुफ़्त, बिना लॉगिन वाला टूल है जो आपको कुछ भी डिप्लॉय करने से पहले Azure सेवाओं की लागत का अनुमान लगाने देता है।

कैच यह है कि Azure में प्रति सेवा एक ही कीमत नहीं होती। उदाहरण के लिए, एक वर्चुअल मशीन की कीमत उसके रीजन, आकार, महीने में कितने घंटे चलती है, और आप किस प्राइसिंग प्लान के लिए प्रतिबद्ध हैं—इन सभी पर निर्भर करती है। इसे पाँच–छह सेवाओं वाली वास्तविक आर्किटेक्चर पर गुणा कर दें, तो एकल लिस्ट प्राइस लगभग बेकार साबित होती है।

इस लेख में, मैं शून्य से एक अनुमान बनाऊँगा, आपको एक वर्चुअल मशीन के उदाहरण के साथ विस्तार से समझाऊँगा, और उन गलतियों को कवर करूँगा जो चुपचाप सावधानी से बनाए गए अनुमानों को भी बिगाड़ देती हैं।

त्वरित उत्तर: Azure प्राइसिंग कैलकुलेटर का उपयोग कैसे करें

खोलें Azure प्राइसिंग कैलकुलेटर और नीचे दिए गए चरणों का पालन करें:

1. प्रोडक्ट पिकर में उस Azure सेवा को खोजें जिसकी कीमत आपको चाहिए, जैसे Virtual Machines।
2. उसका चयन करें ताकि वह डिफ़ॉल्ट कॉन्फ़िगरेशन के साथ आपके अनुमान में जुड़ जाए।
3. रीजन, टियर, साइज़, और अन्य सेवा-विशिष्ट विकल्प सेट करें जिनका आप उपयोग करेंगे।
4. अपेक्षित उपयोग दर्ज करें, जैसे प्रति माह घंटे, स्टोरेज (GB में), या प्रति सेकंड रिक्वेस्ट—जो भी उस सेवा की बिलिंग का आधार हो।
5. एक प्राइसिंग विकल्प चुनें, जैसे Pay-As-You-Go, Reserved Instance, या Azure Savings Plan।
6. मासिक लागत और, जहाँ लागू हो, उस प्रोडक्ट के लिए दिखाई गई अग्रिम लागत की समीक्षा करें।
7. अपनी आर्किटेक्चर की हर अन्य सेवा—जैसे डेटाबेस, स्टोरेज अकाउंट, और लोड बैलेंसर—के लिए यह दोहराएँ।
8. पेज के निचले हिस्से में एक सपोर्ट प्लान जोड़ें।

आप जैसे ही कोई फ़ील्ड बदलते हैं, कुल लागत तुरंत अपडेट हो जाती है। यही वह जगह भी है जहाँ अधिकांश अनुमान प्रोडक्शन में असफल हो जाते हैं: टीमें जिस एक सेवा पर केंद्रित होती हैं उसकी कीमत लगा लेती हैं और जिन सेवाओं पर वह निर्भर है उन्हें भूल जाती हैं।

अपने अनुमान को समझना

कैलकुलेटर के तीन भाग सबसे महत्वपूर्ण हैं, और नंबर टाइप करने से पहले यह जानना उपयोगी रहता है कि हर भाग क्या करता है।

• प्रोडक्ट पिकर: यह पेज के शीर्ष पर मौजूद सर्च और श्रेणी ब्राउज़र है। श्रेणियों में compute, storage, databases, networking, और AI तथा machine learning शामिल हैं। यदि आपको सटीक प्रोडक्ट नाम नहीं पता, तो श्रेणी अनुसार ब्राउज़ करना अक्सर खोज शब्दों का अंदाज़ा लगाने से तेज़ होता है।
• सेवा कॉन्फ़िगरेशन: आप जो भी प्रोडक्ट जोड़ते हैं उसे अपना अलग कॉन्फ़िगरेशन ब्लॉक मिलता है, और उसके अंदर क्या होगा यह उसी सेवा पर निर्भर करता है। उदाहरण के लिए, VM में OS, साइज़ और रीजन पूछा जाता है। दूसरी ओर, स्टोरेज अकाउंट में रिडंडेंसी टियर और एक्सेस फ़्रीक्वेंसी दर्ज करनी होती है। कोई सार्वभौमिक फ़ॉर्म नहीं है, इसलिए हर सेवा को उसकी अपनी शर्तों पर कॉन्फ़िगर करना होता है।
• अनुमानित उपयोग: यहाँ पर प्रोजेक्टेड खपत—जैसे घंटे, GB, और ट्रांज़ैक्शंस—डॉलर आंकड़े में बदलती है। यही फ़ील्ड सबसे अधिक बार डिफ़ॉल्ट पर छोड़ दी जाती है, जिसकी गलती पर मैं आगे इस लेख में बात करता हूँ।

कुछ सेवाएँ अग्रिम लागत और मासिक लागत दोनों दिखाती हैं। यह विभाजन मुख्यतः रिज़र्वेशन में होता है, जहाँ आप अभी एक हिस्सा चुकाकर कम आवर्ती दर लॉक कर लेते हैं। केवल मासिक आंकड़ा और कोई अग्रिम लागत न दिखना आमतौर पर बताता है कि आप Pay-As-You-Go पर हैं।

वॉकथ्रू: एक वर्चुअल मशीन की प्राइसिंग

स्टेजिंग एनवायरनमेंट के लिए एक जनरल-पर्पज़ VM पर विचार करें। 

सबसे पहले, हम “Virtual Machine” खोजते हैं और उसे अनुमान में जोड़ते हैं। प्रोडक्ट एक प्रीसेट साइज़ और रीजन पर डिफ़ॉल्ट रहता है। रीजन को पहले बदलें, क्योंकि यह पेज की हर कीमत को प्रभावित करता है, और फिर अपना OS और VM साइज़ चुनें। ध्यान दें कि Windows में Linux के मुकाबले लाइसेंसिंग सरचार्ज लगता है, जब तक कि आप Azure Hybrid Benefit को टॉगल न करें।

अब अपेक्षित उपयोग सेट करें। Microsoft का डिफ़ॉल्ट अनुमान 730 घंटे प्रति माह है, जो कि एक महीने में औसत घंटों की संख्या है। यानी, कैलकुलेटर मानता है कि VM 24/7 चलता है। यह आमतौर पर प्रोडक्शन सर्वर के लिए सही मान्यता है, लेकिन ऐसे स्टेजिंग बॉक्स के लिए गलत, जिसे केवल ऑफिस घंटों में चालू रहना है।

घंटों को 730 से घटाकर, मान लीजिए 200 कर दें, और अनुमान तुरंत अपडेट हो जाता है। बदलाव अक्सर अनुपाती नहीं होता, क्योंकि कुछ प्राइसिंग टियर्स में न्यूनतम या स्टेप फ़ंक्शंस शामिल होते हैं। घंटों में 70% कमी हमेशा लागत में 70% कमी नहीं लाती। यह गैर-रैखिकता बताती है कि एक स्थिर रेट कार्ड आपको वास्तविक लागत क्यों नहीं दे सकता, और यही व्यावहारिक कारण है कि केवल लिस्ट प्राइस से अनुमान लगाने के बजाय कैलकुलेटर का उपयोग करें।

प्राइसिंग प्लान की तुलना

एक बार जब आपके पास बेसलाइन अनुमान हो, तो कैलकुलेटर का वास्तविक मूल्य सामने आता है। आप एक ही VM को अलग-अलग कमिटमेंट स्तरों पर चला कर देख सकते हैं और ठीक-ठीक समझ सकते हैं कि क्या बदलता है।

Pay-As-You-Go में कोई कमिटमेंट नहीं होता और प्रति घंटे की दर सबसे अधिक होती है, साथ ही कभी भी रिसाइज़ या डिलीट करने की पूरी लचीलापन भी मिलता है। Reserved Instances आपको किसी विशिष्ट रीजन में किसी विशिष्ट VM साइज़ के लिए एक या तीन साल की प्रतिबद्धता करने देती हैं और बदले में एक काफ़ी कम दर मिलती है। जनरल-पर्पज़ साइज़ पर बचत आमतौर पर 40–70% रेंज में रहती है, जो टर्म की लंबाई पर निर्भर करती है।

Azure Savings Plan में आप किसी विशिष्ट VM के बजाय प्रति घंटे के खर्च की एक राशि के लिए प्रतिबद्ध होते हैं, और Azure यह छूट सभी पात्र compute पर लागू करता है—even अगर आप साइज़ बदल दें या वर्कलोड इधर-उधर कर दें।

यहाँ कोई एकमात्र सही विकल्प नहीं है। यह इस पर निर्भर करता है कि आपका वर्कलोड कितना स्थिर है और आपको कितनी लचीलापन चाहिए।

वास्तव में क्या राशि बदलता है

कुछ आर्किटेक्चर निर्णय—वित्तीय नहीं—आपके बिल के अधिकांश हिस्से को नियंत्रित करते हैं:

रीजन

रीजन की बड़ी भूमिका होती है, क्योंकि एक ही VM साइज़ की लागत एक रीजन में दूसरे की तुलना में स्पष्ट रूप से अधिक हो सकती है। यदि अनुपालन आपको किसी विशिष्ट रीजन से बाँधता नहीं है, तो आस-पास के कुछ विकल्प जाँचें।

सेवा टियर और साइज़

सेवा टियर और साइज़ भी मायने रखते हैं, क्योंकि “सुरक्षा के लिए” एक टियर ऊपर जाना एक आम और महँगा चलन है। अपने वास्तविक आवश्यकताओं को मॉडल करें, उन पर बफर नहीं।

ऑपरेटिंग सिस्टम और लाइसेंसिंग

ऑपरेटिंग सिस्टम आपकी कीमत को भी प्रभावित करता है, क्योंकि Windows और SQL Server लाइसेंसिंग वास्तविक लागत जोड़ते हैं। जैसा ऊपर उल्लेख किया, Azure Hybrid Benefit उन टीमों के लिए टॉगल है जिनके पास पहले से लाइसेंस हैं—और इसे नज़रअंदाज़ करना आसान है।

उपयोग मात्रा और प्राइसिंग प्लान

उपयोग मात्रा और प्राइसिंग प्लान—जिनका ऊपर ज़िक्र हुआ—यहीं पर सबसे अधिक उतार-चढ़ाव होता है।

वे आम गलतियाँ जो अनुमान बिगाड़ देती हैं

एक सावधानी से बना अनुमान भी कुछ पूर्वानुमेय तरीकों से गलत हो सकता है। अपने नंबर पर भरोसा करने से पहले इन बातों की जाँच करना फायदेमंद है।

डिफ़ॉल्ट उपयोग को यथावत छोड़ देना

पहली गलती है डिफ़ॉल्ट उपयोग को यथावत छोड़ देना। 730 घंटे का डिफ़ॉल्ट एक अच्छा शुरुआती बिंदु है और किसी भी ऐसी चीज़ के लिए बुरा अंतिम उत्तर जो चौबीसों घंटे नहीं चलती। 

सहायक सेवाएँ भूल जाना

दूसरी गलती है सहायक सेवाएँ भूल जाना: एक VM को डिस्क चाहिए, और एक एप्लिकेशन को आमतौर पर डेटाबेस चाहिए। जो अनुमान केवल प्राथमिक सेवा की कीमत लगाते हैं और उसके आस-पास की इन्फ्रास्ट्रक्चर को छोड़ देते हैं, वे वास्तविक बिल को लगातार कम आँकेंगे। 

गलत रीजन चुन लेना

तीसरी गलती है गलत रीजन चुन लेना, जो तब आसानी से हो जाता है जब आप किसी ऐसे क्लाइंट या टीम के लिए अनुमान लगा रहे हों जो आपसे अलग लोकेशन में हो। 

डेटा ट्रांसफ़र और नेटवर्किंग लागतों को नज़रअंदाज़ करना

चौथी गलती है डेटा ट्रांसफ़र और नेटवर्किंग लागतों को नज़रअंदाज़ करना, जो आपकी खपत के साथ बदलती हैं। 

रिटेल प्राइसिंग की तुलना नेगोशिएटेड प्राइसिंग से करना

पाँचवीं गलती है रिटेल प्राइसिंग की तुलना नेगोशिएटेड प्राइसिंग से करना: यदि आपके संगठन के पास एंटरप्राइज़ एग्रीमेंट है, तो पब्लिक कैलकुलेटर की लिस्ट प्राइस तब तक आपकी वास्तविक भुगतान दर से मेल नहीं खाएगी जब तक आप साइन इन करके अपना एग्रीमेंट लागू नहीं करते। 

अनुमान को अंतिम बिल मान लेना

अंत में, अनुमान को अंतिम बिल न मानें। Microsoft स्वयं नोट करता है कि सेव किए गए अनुमान के टोटल Azure की प्रकाशित प्राइसिंग बदलने पर शिफ्ट हो सकते हैं, इसलिए एक मार्जिन शामिल करें।

Azure प्राइसिंग कैलकुलेटर बनाम Azure Cost Management

ये दो अलग टूल हैं जो अलग समस्याएँ हल करते हैं। प्राइसिंग कैलकुलेटर किसी भी चीज़ को डिप्लॉय करने से पहले लागत का अनुमान लगाता है, जिससे आप काल्पनिक कॉन्फ़िगरेशन मॉडल कर सकते हैं और अभी मौजूद न होने वाले परिदृश्यों की तुलना कर सकते हैं। दूसरी ओर, Azure Cost Management उन संसाधनों के लाइव होने के बाद आप वास्तव में क्या खर्च कर रहे हैं, उसका विश्लेषण करता है। यह वास्तविक उपयोग, वास्तविक इनवॉइस, और वास्तविक विसंगतियों से निपटता है।

आपको दोनों की ज़रूरत पड़ती है, अलग-अलग समय पर। निर्माण से पहले अनुमान और बजट योजना के लिए कैलकुलेटर का उपयोग करें। बाद में यह जाँचने के लिए Cost Management का उपयोग करें कि वास्तविकता योजना से मेल खाती है या नहीं, और वह ड्रिफ़्ट पकड़ें जो वास्तविक ट्रैफ़िक के वास्तविक इन्फ्रास्ट्रक्चर पर आने के बाद अनिवार्य रूप से दिखती है।

Azure लागतों का अनुमान लगाने के सर्वोत्तम अभ्यास

कुछ सर्वोत्तम अभ्यास लगातार अधिक विश्वसनीय अनुमान पैदा करते हैं

• यथार्थवादी उपयोग का मॉडल बनाइए—न अधिकतम क्षमता, न न्यूनतम।
• आर्किटेक्चर के हर कंपोनेंट को शामिल करें, केवल महँगे दिखने वालों को नहीं।
• यदि आपके अनुपालन नियम अनुमति दें, तो दो–तीन रीजन की तुलना करें।
• किसी एक को चुनने से पहले उसी वर्कलोड को Pay-As-You-Go और एक कमिटमेंट टियर—दोनों पर चलाकर देखें।
• एक संख्या के बजाय तीन परिदृश्य बनाइए (अपेक्षित, कम, और अधिक उपयोग), ताकि आपके पास योजना बनाने के लिए एक रेंज हो।
• जब आर्किटेक्चर या Azure की प्राइसिंग बदले, तो अनुमान को फिर से देखें—क्योंकि दोनों लंबे समय तक स्थिर नहीं रहते।

निष्कर्ष

वर्कफ़्लो सीधा है: जिन सेवाओं की ज़रूरत है उन्हें जोड़ें, उन्हें वैसा कॉन्फ़िगर करें जैसा वे वास्तव में चलेंगी, यथार्थवादी उपयोग आँकड़े दर्ज करें, एक प्राइसिंग प्लान चुनें, और कुल की समीक्षा करें। गणित कैलकुलेटर संभाल लेता है।

परिणाम की सटीकता पूरी तरह इस पर निर्भर करती है कि इनपुट वास्तविकता के कितने करीब हैं। गलत उपयोग मान्यता पर आधारित बारीकी से गणना किया गया अनुमान भी गलत ही होगा।

किसी आर्किटेक्चर पर प्रतिबद्ध होने से पहले कई परिदृश्य बनाएँ, और संसाधन डिप्लॉय होने के बाद Azure Cost Management में वास्तविक खर्च के साथ अनुमान की तुलना करें। दोनों के बीच कोई भी अंतर सूचनात्मक है: यह दिखाता है कि आपकी मूल मान्यताएँ वास्तविक उपयोग से कहाँ अलग पड़ीं।