एक सेवा केवल कुछ ही अनुरोधों का उत्तर देती है और फिर भी अपेक्षा से अधिक महंगी पड़ती है। दूसरी सेवा बहुत-सी छोटी कॉल सस्ते में संभाल लेती है। इसलिए जो केवल अनुरोधों की संख्या सीमित करता है, वह अपने-आप वह नहीं माप रहा होता जो बाद में इन्फ्रास्ट्रक्चर के बिल में दिखाई देता है। लागत नियंत्रण और लोड नियंत्रण अलग-अलग बिंदुओं पर काम करते हैं।
12 अक्टूबर 2026 को Google ने घोषित किया: Cloud Run के लिए Budget spend caps अब सामान्य रूप से उपलब्ध हैं। सेट अप हो जाने के बाद, खर्च सीमा प्रभावित वर्कलोड को रोक सकती है। यह इन्फ्रास्ट्रक्चर में एक प्रासंगिक बदलाव है। लेकिन इसे तभी समझा जा सकता है जब आप बजट अलर्ट, खर्च सीमा और अलग-अलग अनुरोधों पर लगी सीमा के बीच अंतर करें।
तीन प्रश्न, तीन अलग-अलग सीमाएँ
अनुरोध सीमा ऐसे प्रश्नों का उत्तर देती है: कोई विशेष क्लाइंट एक निश्चित अवधि में कितनी कॉल भेज सकता है? समवर्ती कार्य पर सीमा यह पूछती है: एक साथ कितना कुछ चल सकता है? दूसरी ओर, लागत सीमा अपने दायरे के भीतर मूल्य-निर्धारित संसाधन खपत को देखती है। ये मात्राएँ आपस में जुड़ी हैं, लेकिन एक-दूसरे का विकल्प नहीं हैं।
हमारी काल्पनिक सेवा के दो कार्य हैं। एक छोटा स्टेटस उत्तर लौटाता है। दूसरा एक लंबे दस्तावेज़ को प्रोसेस करता है। दोनों ठीक एक अनुरोध से शुरू होते हैं, लेकिन उनमें अलग-अलग मात्रा में काम लगता है। भले ही दोनों उपयोगकर्ताओं को समान संख्या में कॉल की अनुमति हो, इससे यह नहीं निकलता कि वे इन्फ्रास्ट्रक्चर पर समान भार डालते हैं। एक अकेला काउंटर अपनी प्रविष्टियों के अलग-अलग महत्व को छिपा देता है।
बजट अलर्ट अभी रोक नहीं है
आधिकारिक बिलिंग दस्तावेज़ीकरण केवल-अलर्ट वाले बजट और खर्च सीमाओं के बीच अंतर करता है। वर्णित सीमाएँ अनुमानित सकल लागतों का उपयोग करती हैं; बचत और क्रेडिट शामिल नहीं होते। दायरा एक अकेला प्रोजेक्ट और एक समर्थित सेवा है, और अवधि मासिक है। किसी ऑपरेटर को कुछ भी कॉन्फ़िगर करने से पहले इन शर्तों को अवश्य पढ़ना चाहिए।
प्रवर्तन भी तात्कालिक नहीं होता। Google बताता है कि देरी के कारण हुई अधिकता का शुल्क फिर भी लिया जाता है। इसलिए दर्ज की गई राशि कोई गणितीय वादा नहीं है कि अंतिम बिल ठीक वहीं रुक जाएगा। नई सुविधा एक तकनीकी हस्तक्षेप प्रदान करती है, यह समझने का विकल्प नहीं कि इसका बिल कैसे बनता है।
Cloud Run के लिए उत्पाद दस्तावेज़ीकरण विशिष्ट प्रभावों का वर्णन करता है: सेवाएँ अब अनुरोधों को सर्व नहीं कर सकतीं और 5xx श्रेणी की त्रुटियाँ लौटाती हैं; अन्य संसाधन प्रकारों के अपने परिणाम होते हैं। इसलिए लागत रोक उपलब्धता से जुड़ा निर्णय भी है। यह परिणाम योजना का हिस्सा होना चाहिए, केवल घटना रिपोर्ट का नहीं।
एक ड्राई रन दिखाता है कि कौन-सा नियम कब लागू होता है
मॉडल को समझने के लिए आपको किसी चालू सेवा को रोकने की ज़रूरत नहीं है। तीन स्वतंत्र काउंटरों का खाका बनाइए: प्रति क्लाइंट कॉल, एक ही समय में चल रहा काम, और विचाराधीन अवधि में अनुमानित लागत। हर एक को एक प्रतिक्रिया सौंपिए। पहला नियम किसी क्लाइंट की आगे की कॉल अस्वीकार करता है, दूसरा समानांतरता को सीमित करता है, और तीसरा सेवा के एक पूरे परिभाषित दायरे को रोक सकता है।
Client limit: Who may send requests, and how often?
Concurrency limit: How much work runs at the same time?
Spend cap: When is the service in question paused?फिर दो काल्पनिक मामलों को आज़माइए: बहुत-से छोटे अनुरोध और कुछ भारी अनुरोध। केवल गुणात्मक अंतर दर्ज कीजिए, गढ़ी हुई यूरो राशियाँ नहीं। यह अभ्यास दिखाता है कि कौन-सा नियम किस मामले को देख भी पाता है। यह एक विचार मॉडल है, मापा गया लोड या लागत परीक्षण नहीं।
ऑपरेटर का इन्फ्रास्ट्रक्चर ग्राहक का कोटा नहीं है
KENJTEC प्लेटफ़ॉर्म सेवाओं के लिए Cloud Run का उपयोग करता है; इसे प्रोजेक्ट के इन्फ्रास्ट्रक्चर और डिप्लॉयमेंट स्रोतों में देखा जा सकता है। इससे यह नहीं निकलता कि नई Google सुविधा अपने-आप सक्रिय हो गई है। न ही इससे हर KENJTEC ग्राहक खाते को व्यक्तिगत रूप से समायोज्य इन्फ्रास्ट्रक्चर सीमा मिलती है। ऑपरेटर प्रोजेक्ट और ग्राहक सदस्यता अलग-अलग बिलिंग सीमाएँ हैं।
इसलिए व्यवहार में महत्वपूर्ण प्रश्न यह है: कोई सीमा किस उपयोग की रक्षा के लिए है, और उसके सक्रिय होने पर कौन-सा काम भी रुक जाएगा? एक समझदारी भरी योजना चेतावनी, हस्तक्षेप और पुनः आरंभ का एक साथ वर्णन करती है। तभी आप आँक सकते हैं कि खर्च सीमा अनुरोध सीमाओं और आपकी अपनी उपलब्धता आवश्यकताओं के साथ कैसे मेल खाती है।
स्रोत और स्थिति
25 अक्टूबर 2026 तक का शोध और दस्तावेज़ीकरण। Cloud Run रिलीज़ नोट्स — अक्टूबर 12, 2026 · सेवाओं के लिए बिलिंग सेटिंग्स — Budget spend caps · खर्च सीमा वाले बजट प्रबंधित करें।
