AWS Lambda Web Functions: जब सर्वरलेस एक सामान्य वेब सर्वर चलाता है, तो क्या बदलता है?

AWS Lambda Web Functions डेवलपर्स को स्टैंडर्ड Node.js HTTP एप्लिकेशन को इवेंट हैंडलर के रूप में दोबारा लिखे बिना डिप्लॉय करने देता है। इसका कॉन्करेंट रिक्वेस्ट मॉडल, एक्टिव-CPU बिलिंग और मैनेज्ड स्केलिंग होस्टिंग के नए विकल्प देते हैं, लेकिन नेटवर्क, सुरक्षा और ऑपरेशन से जुड़ी सीमाएं इस पर असर डालती हैं कि यह कहां फिट बैठता है।

एक डेवलपर Express या Fastify से एक API बनाता है। एप्लिकेशन एक HTTP सर्वर शुरू करता है, किसी पोर्ट पर सुनता है और आने वाली रिक्वेस्ट को संभालता है। पारंपरिक AWS Lambda पर इस एप्लिकेशन को चलाने के लिए आमतौर पर उसे एक इवेंट-हैंडलर इंटरफ़ेस के अनुरूप ढालना पड़ता है।

12 अक्टूबर 2026 को AWS ने Lambda Web Functions पेश किए, जिनसे डेवलपर्स एक पारंपरिक Node.js HTTP सर्वर को सीधे Lambda पर डिप्लॉय कर सकते हैं। लॉन्च के समय AWS ने यह सेवा पांच रीजन में उपलब्ध कराई: US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo) और Europe (Ireland)। AWS और रीजन जोड़ सकता है, इसलिए इस सेवा के आधार पर योजना बनाने से पहले उसकी मौजूदा सूची देखें।

Web Functions एक अलग एक्ज़िक्यूशन मॉडल भी लाते हैं। कई HTTP रिक्वेस्ट एक ही एक्ज़िक्यूशन एनवायरनमेंट (execution environment) साझा कर सकती हैं, और शुल्क में एक्टिव CPU खपत को एनवायरनमेंट के पूरे जीवनकाल में आवंटित मेमोरी से अलग गिना जाता है। ये क्षमताएं Lambda को ज़्यादा वेब एप्लिकेशन के लिए एक विकल्प बनाती हैं, लेकिन सही होस्टिंग आर्किटेक्चर चुनने की ज़रूरत खत्म नहीं करतीं।

पारंपरिक Lambda की तुलना में क्या बदलता है?

AWS अब अपने मौजूदा Lambda हैंडलर मॉडल को Event Functions कहता है। नाम के इस बदलाव के लिए मौजूदा फ़ंक्शन को दोबारा लिखने की ज़रूरत नहीं है।

एक Event Function एक इवेंट प्राप्त करता है, अपना हैंडलर चलाता है और परिणाम लौटाता है। एक स्टैंडर्ड Event Function एक्ज़िक्यूशन एनवायरनमेंट एक समय में एक इनवोकेशन प्रोसेस करता है। इसके विपरीत, एक Web Function एक सामान्य Node.js HTTP सर्वर चलाता है। Lambda HTTP ट्रैफ़िक को सर्वर तक पहुंचाता है, जो एक साथ कई रिक्वेस्ट संभाल सकता है।

विशेषता	Event Functions	Web Functions
प्रोग्रामिंग मॉडल	इवेंट हैंडलर	पोर्ट पर सुनने वाला Node.js HTTP सर्वर
सामान्य वर्कलोड	इवेंट, क्यू, शेड्यूल्ड जॉब और API हैंडलर	HTTP API, वेब एप्लिकेशन, सर्वर-साइड रेंडरिंग और स्ट्रीमिंग
प्रति एनवायरनमेंट कॉन्करेंसी	एक समय में एक इनवोकेशन	कई HTTP रिक्वेस्ट
कंप्यूट बिलिंग का आधार	इनवोकेशन की अवधि	एक्टिव CPU खपत
मेमोरी बिलिंग का आधार	इनवोकेशन की अवधि	एक्ज़िक्यूशन एनवायरनमेंट का जीवनकाल
स्केलिंग	मैनेज्ड इनवोकेशन स्केलिंग	मैनेज्ड HTTP स्केलिंग, स्केल-टू-ज़ीरो सहित

दोनों मॉडल के उद्देश्य अलग-अलग बने रहते हैं। कोई एप्लिकेशन API के लिए Web Functions का उपयोग कर सकता है और क्यू प्रोसेसिंग या शेड्यूल्ड कार्यों के लिए Event Functions को बनाए रख सकता है। Event Functions के टाइमआउट नियम एक अलग विषय हैं, जिन पर Lambda के 90 मिनट के टाइमआउट पर हमारे लेख में चर्चा की गई है।

स्रोत: AWS, Announcing AWS Lambda Web Functions, 12 अक्टूबर 2026।

कॉन्करेंट रिक्वेस्ट से एक्ज़िक्यूशन कैसे बदलता है

मुख्य बदलाव यह है कि एक ही एक्ज़िक्यूशन एनवायरनमेंट एक साथ कई रिक्वेस्ट पर काम कर सकता है, जैसा कि एक सामान्य वेब सर्वर करता है। लॉन्च के समय Web Functions, Arm64 पर Node.js 24 को सपोर्ट करते हैं, और हर एक्ज़िक्यूशन एनवायरनमेंट में 2 vCPU और 2 GB मेमोरी होती है। पारंपरिक Event Function एनवायरनमेंट के विपरीत, एक Web Function एनवायरनमेंट एक साथ कई रिक्वेस्ट सर्व कर सकता है।

AWS देखे गए संसाधन उपयोग के आधार पर गतिशील रूप से तय करता है कि एक एनवायरनमेंट कितनी रिक्वेस्ट संभाले। maxConcurrencyPerEnvironment सेटिंग 1 से 128 के बीच एक ऊपरी सीमा तय करती है, और इसका डिफ़ॉल्ट मान 64 है। यह मान गारंटीशुदा कॉन्करेंसी (concurrency) नहीं है। जब CPU या मेमोरी का उपयोग अतिरिक्त रिक्वेस्ट को अनुपयुक्त बना दे, तब Lambda एक कम प्रभावी सीमा चुन सकता है।

इससे उन एप्लिकेशन को लाभ हो सकता है जिनमें एसिंक्रोनस I/O की प्रधानता है। उदाहरण के लिए, एक Node.js API अपने रिक्वेस्ट समय का बड़ा हिस्सा डेटाबेस क्वेरी या बाहरी सेवाओं की प्रतीक्षा में बिता सकता है। जब एक रिक्वेस्ट प्रतीक्षा करती है, तब इवेंट लूप दूसरी रिक्वेस्ट को प्रोसेस कर सकता है।

CPU-गहन सिंक्रोनस काम अलग तरह से व्यवहार करता है। अगर कोई रिक्वेस्ट इवेंट लूप को ब्लॉक करती है, तो उसी प्रोसेस को साझा करने वाली दूसरी रिक्वेस्ट में भी देरी हो सकती है।

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

पारंपरिक Node.js सर्वर के लिए लिखा गया एप्लिकेशन शायद पहले से इन स्थितियों का ध्यान रखता हो। फिर भी डेवलपर्स को मैनेज्ड Lambda एनवायरनमेंट में उसके वास्तविक व्यवहार की जांच करनी चाहिए।

स्रोत: AWS, Execution environment lifecycle, Scaling behavior और Runtime support।

एक्टिव-CPU बिलिंग का क्या अर्थ है?

एक्टिव-CPU बिलिंग का अर्थ है कि आपसे उस CPU समय का शुल्क लिया जाता है जिसका आपका कोड वास्तव में उपयोग करता है, न कि उस समय का जो कोई रिक्वेस्ट दूसरे सिस्टम की प्रतीक्षा में बिताती है। ग्राहक रिक्वेस्ट, एक्टिव CPU खपत, एक्ज़िक्यूशन एनवायरनमेंट के जीवनकाल में मेमोरी उपयोग और लागू डेटा ट्रांसफ़र के लिए भुगतान करते हैं। यह पारंपरिक Lambda अवधि मॉडल से अलग है, जिसमें वह समय भी शामिल होता है जो कोई इनवोकेशन डाउनस्ट्रीम ऑपरेशन की प्रतीक्षा में बिताता है।

एक API रिक्वेस्ट पर विचार करें जो थोड़ी देर गणना करती है और फिर डेटाबेस के जवाब की प्रतीक्षा करती है। Web Functions में प्रतीक्षा की अवधि में शायद बहुत कम एक्टिव CPU खर्च हो। हालांकि, जब तक एक्ज़िक्यूशन एनवायरनमेंट मौजूद रहता है, मेमोरी का शुल्क जारी रहता है, जिसमें रिक्वेस्ट के बीच का निष्क्रिय समय भी शामिल है। ट्रैफ़िक रुकने के बाद एक एंडपॉइंट शून्य तक स्केल हो सकता है, लेकिन ज़रूरी नहीं कि हर रिक्वेस्ट के तुरंत बाद एनवायरनमेंट खत्म हो जाए।

यह अंतर Web Functions को कुछ I/O-प्रधान एप्लिकेशन के लिए संभावित रूप से आकर्षक बनाता है। इससे यह साबित नहीं होता कि यह सेवा हर एप्लिकेशन के लिए सस्ती है। लागत की तुलना में ट्रैफ़िक पैटर्न, औसत रिक्वेस्ट अवधि, CPU उपयोग, मेमोरी खपत, डेटा ट्रांसफ़र और मौजूदा होस्टिंग प्लेटफ़ॉर्म के व्यवहार पर विचार करना ज़रूरी है। लगातार CPU-गहन वर्कलोड वाले एप्लिकेशन का अर्थशास्त्र उन एप्लिकेशन से अलग हो सकता है जिनमें नेटवर्क प्रतीक्षा प्रमुख है।

स्रोत: AWS, Lambda Web Functions overview।

डिप्लॉयमेंट और स्केलिंग कैसे काम करते हैं

एक Web Function में रिविज़न और एंडपॉइंट होते हैं। एक रिविज़न (revision) एप्लिकेशन कोड और कॉन्फ़िगरेशन का एक अपरिवर्तनीय स्नैपशॉट है। एक एंडपॉइंट (endpoint) HTTP एंट्री पॉइंट देता है और अपने ट्रैफ़िक कॉन्फ़िगरेशन के अनुसार रिक्वेस्ट को एक या दो रिविज़न तक भेजता है।

यह अलगाव नियंत्रित रोलआउट में मदद करता है। टीमें एक नया रिविज़न बना सकती हैं, उसे टेस्ट कर सकती हैं और ट्रैफ़िक का एक हिस्सा उसकी ओर भेज सकती हैं।

AWS स्केलिंग के तीन मुख्य नियंत्रण देता है।

सेटिंग	उद्देश्य
maxConcurrencyPerEnvironment	एक एनवायरनमेंट के भीतर कॉन्करेंट रिक्वेस्ट की ऊपरी सीमा
maxEnvironments	हर रीजन में प्रति एंडपॉइंट एनवायरनमेंट की वैकल्पिक अधिकतम संख्या
rateLimit	हर रीजन में प्रति एंडपॉइंट रिक्वेस्ट आगमन की वैकल्पिक सीमा

यह सेवा अकाउंट-स्तर की सीमाएं भी लागू करती है, जिनमें रीजनल vCPU क्षमता और रिक्वेस्ट-दर कोटा शामिल हैं। किसी एंडपॉइंट की सेटिंग बढ़ाने से ये अकाउंट कोटा ओवरराइड नहीं होते।

जब कोई एंडपॉइंट रिक्वेस्ट-दर सीमा पार कर जाता है या उसकी उपलब्ध सर्विंग क्षमता खत्म हो जाती है, तो Lambda HTTP 429 रिस्पॉन्स लौटा सकता है। कुछ और स्थितियों पर भी विचार करना होगा। rateLimit को शून्य पर सेट करने से ट्रैफ़िक बंद हो जाता है और एक विशिष्ट प्लेटफ़ॉर्म एरर संकेतक के साथ HTTP 503 मिलता है। सेवा की सुरक्षा के लिए लोड घटाते समय भी AWS HTTP 503 लौटा सकता है।

क्लाइंट को केवल उचित होने पर ही रीट्राई (retry) करना चाहिए, हर विफलता के बाद ज़्यादा देर प्रतीक्षा करते हुए और एक रैंडम देरी जोड़ते हुए (backoff और jitter)। राइट ऑपरेशन के लिए आइडेम्पोटेंसी कीज़ (idempotency keys) या डीडुप्लिकेशन की ज़रूरत हो सकती है, ताकि रीट्राई से व्यावसायिक प्रभाव दोबारा न हों।

डिप्लॉय किया गया रिविज़न ज़रूरी नहीं कि काम करता हुआ एप्लिकेशन हो

AWS रिविज़न और एंडपॉइंट रिसोर्स की स्थितियों को एप्लिकेशन की वास्तविक तैयारी से अलग मानता है। कोई रिविज़न सक्रिय (active) हो सकता है, भले ही उसका HTTP सर्वर ठीक से शुरू न हो पाए।

डिप्लॉयमेंट के बाद टीमों को एक वास्तविक HTTP रिक्वेस्ट भेजनी चाहिए, एप्लिकेशन लॉग देखने चाहिए और पुष्टि करनी चाहिए कि एंडपॉइंट अपेक्षित रिस्पॉन्स दे रहा है। प्रोडक्शन रोलआउट के लिए, वेटेड रिविज़न डिप्लॉयमेंट और जांचा हुआ रोलबैक (rollback) रास्ता इस धारणा से ज़्यादा भरोसेमंद हैं कि रिसोर्स बन जाने का अर्थ एप्लिकेशन का सफल डिप्लॉयमेंट है।

स्रोत: AWS, Scaling behavior और Core concepts।

स्ट्रीमिंग काम करती है, प्रोटोकॉल की सीमाओं के साथ

Web Functions HTTP रिस्पॉन्स स्ट्रीमिंग को सपोर्ट करते हैं। इससे एप्लिकेशन सर्वर पर रेंडर की गई सामग्री, क्रमिक API परिणाम या AI द्वारा जनरेट किया गया आउटपुट उपलब्ध होते ही पहुंचा सकते हैं।

हालांकि, रिक्वेस्ट और रिस्पॉन्स के रास्ते में एक महत्वपूर्ण सीमा है। AWS, HTTP/1.1 के हाफ़-डुप्लेक्स (half-duplex) व्यवहार का दस्तावेज़ीकरण करता है। Lambda एप्लिकेशन का रिस्पॉन्स पहुंचाने से पहले आने वाली रिक्वेस्ट की पूरी बॉडी आगे भेजता है।

इसलिए एप्लिकेशन को अपना रिस्पॉन्स लिखने से पहले रिक्वेस्ट बॉडी पूरी पढ़ लेनी चाहिए। यह उन डिज़ाइनों के लिए मायने रखता है जो क्लाइंट के डेटा अपलोड करते समय ही द्विदिशात्मक (bidirectional) स्ट्रीमिंग की अपेक्षा करते हैं।

WebSocket अपग्रेड सपोर्ट नहीं किए जाते। सर्वर से क्लाइंट तक एकतरफ़ा स्ट्रीमिंग के लिए सर्वर-सेंट इवेंट (server-sent events) उपयुक्त हो सकते हैं, लेकिन जिन एप्लिकेशन को लगातार द्विदिशात्मक WebSocket संचार चाहिए, उन्हें किसी दूसरे सपोर्टेड आर्किटेक्चर की ज़रूरत है।

Web Function रिक्वेस्ट का डिफ़ॉल्ट टाइमआउट 30 सेकंड है और कॉन्फ़िगर करने योग्य अधिकतम सीमा 900 सेकंड, यानी 15 मिनट है। टाइमआउट में रिक्वेस्ट बॉडी प्राप्त करना और रिस्पॉन्स पहुंचाना, दोनों शामिल होने चाहिए। अगर यह रिस्पॉन्स हेडर भेजे जाने के बाद समाप्त होता है, तो क्लाइंट को साफ़ एप्लिकेशन एरर के बजाय अधूरा (truncated) रिस्पॉन्स मिल सकता है।

स्रोत: AWS, Configuring networking for Web Functions।

मल्टी-रीजन डिप्लॉयमेंट और VPC कनेक्टिविटी एक-दूसरे का विकल्प नहीं हैं

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

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

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

निजी संसाधनों के लिए एक महत्वपूर्ण सीमा

Web Functions एक इग्रेस नेटवर्क कनेक्टर (egress network connector) के ज़रिए Amazon VPC के भीतर के संसाधनों तक आउटबाउंड कनेक्टिविटी को भी सपोर्ट करते हैं। एंडपॉइंट तीन प्रकार के होते हैं। HomeRegion एंडपॉइंट केवल होम रीजन से ट्रैफ़िक सर्व करता है, जबकि MultiRegion और PerRegion एंडपॉइंट कई रीजन से ट्रैफ़िक सर्व करते हैं।

6 नवंबर 2026 तक, ये कनेक्टर केवल HomeRegion एंडपॉइंट के साथ सपोर्टेड हैं।

AWS, MultiRegion या PerRegion एंडपॉइंट के ज़रिए सर्व किए जाने वाले रिविज़न के साथ VPC इग्रेस कनेक्टर जोड़ने को सपोर्ट नहीं करता। इसलिए जिस एप्लिकेशन को ऐसे कनेक्टर के ज़रिए किसी निजी डेटाबेस तक सीधी पहुंच चाहिए, वह यह नहीं मान सकता कि वह Web Functions के बिल्ट-इन मल्टी-रीजन एंडपॉइंट वितरण का भी उपयोग कर सकता है। इस बाधा को आर्किटेक्चर चुनते समय सुलझाना होगा, डिप्लॉयमेंट के बाद नहीं।

VPC इग्रेस कनेक्टिविटी भी Web Function के इनकमिंग HTTPS एंडपॉइंट को निजी नहीं बनाती। इनबाउंड एक्सेस और आउटबाउंड नेटवर्क कनेक्टिविटी अलग-अलग विषय हैं।

स्रोत: AWS, Configuring networking for Web Functions, Core concepts और Best practices for Lambda Web Functions।

सुरक्षा सार्वजनिक एंडपॉइंट से शुरू होती है

हर Web Function एंडपॉइंट का एक सार्वजनिक रूप से पहुंच योग्य डोमेन नाम होता है। AWS प्रमाणीकरण के दो तरीके देता है।

IamAuth के साथ, Lambda उचित रूप से अधिकृत और साइन की गई रिक्वेस्ट की मांग करता है। ApplicationManaged के साथ, Lambda कॉलर का प्रमाणीकरण किए बिना रिक्वेस्ट को आगे भेज देता है। आवश्यक प्रमाणीकरण और प्राधिकरण एप्लिकेशन या किसी अपस्ट्रीम सेवा को लागू करना होगा।

IAM प्रमाणीकरण एंडपॉइंट को निजी नेटवर्क रिसोर्स में नहीं बदलता। सार्वजनिक एप्लिकेशन के लिए डेवलपर्स को इनपुट वैलिडेशन, रेट के दुरुपयोग, रिक्वेस्ट प्राधिकरण और संवेदनशील जानकारी की सुरक्षा पर भी ध्यान देना होगा।

Web Function एंडपॉइंट कस्टम डोमेन नाम या सीधे AWS WAF जुड़ाव को सपोर्ट नहीं करते। कस्टम डोमेन, कैशिंग और AWS WAF सुरक्षा देने के लिए Amazon CloudFront को Web Function के आगे रखा जा सकता है।

IamAuth एंडपॉइंट के लिए AWS, CloudFront ओरिजिन एक्सेस कंट्रोल (OAC) की सलाह देता है, ताकि CloudFront ओरिजिन को भेजी जाने वाली अपनी रिक्वेस्ट साइन करे। दूसरे फ्रंट डोर (front door) के साथ एंडपॉइंट सीधे पहुंच योग्य बना रहता है, इसलिए एप्लिकेशन को एक साझा सीक्रेट या टोकन की जांच करनी चाहिए। उपयुक्त ओरिजिन प्रतिबंधों के बिना सीधी रिक्वेस्ट इच्छित फ्रंट डोर को बायपास कर सकती हैं।

ब्राउज़र एप्लिकेशन को उचित Cross-Origin Resource Sharing (CORS) कॉन्फ़िगरेशन की भी ज़रूरत होती है। Lambda, Web Functions के लिए CORS हेडर नहीं जोड़ता, इसलिए एप्लिकेशन या उसके फ्रंट डोर को उन्हें संभालना होगा। CORS प्रमाणीकरण का तरीका नहीं है।

स्रोत: AWS, Best practices for Lambda Web Functions और Configuring networking for Web Functions।

डेवलपर्स को Web Functions पर कब विचार करना चाहिए?

चुनाव वर्कलोड के वास्तविक व्यवहार के आधार पर होना चाहिए।

वर्कलोड	मूल्यांकन योग्य तरीका
एसिंक्रोनस डेटाबेस या नेटवर्क कॉल वाले Node.js API	Web Functions
Node.js सर्वर-साइड रेंडरिंग	Web Functions
HTTP रिस्पॉन्स स्ट्रीमिंग या सर्वर-सेंट इवेंट	Web Functions, टाइमआउट और प्रोटोकॉल सीमाओं के भीतर
क्यू प्रोसेसिंग और शेड्यूल्ड बैकग्राउंड काम	Event Functions
लगातार WebSocket संचार	WebSocket सपोर्ट करने वाला कोई दूसरा होस्टिंग आर्किटेक्चर
ऐसी वेब सेवा जिसे सीधी निजी VPC पहुंच और बिल्ट-इन मल्टी-रीजन वितरण चाहिए	कोई दूसरा डिज़ाइन या होस्टिंग तरीका
असमर्थित रनटाइम या कस्टम रनटाइम संसाधनों की ज़रूरत वाले एप्लिकेशन	कंटेनर होस्टिंग या कोई दूसरी उपयुक्त कंप्यूट सेवा

लॉन्च के समय Web Functions केवल Node.js को सपोर्ट करते हैं। जो एप्लिकेशन कोई दूसरा रनटाइम इस्तेमाल करते हैं, अलग कंप्यूट संसाधन मांगते हैं या असमर्थित नेटवर्किंग व्यवहार पर निर्भर हैं, उन्हें केवल इसलिए इस सेवा में नहीं धकेलना चाहिए कि यह सर्वरलेस है। मौजूदा ECS या Fargate एप्लिकेशन शायद पहले से अपनी ज़रूरतें प्रभावी ढंग से पूरी कर रहे हों। माइग्रेशन प्रमाणित ऑपरेशनल या आर्थिक लाभों के आधार पर होना चाहिए।

प्रोडक्शन के लिए तैयारी की एक केंद्रित जांच

Web Functions अपनाने से पहले एक प्रतिनिधि नॉन-प्रोडक्शन HTTP सेवा चुनें। पुष्टि करें कि सर्वर ठीक से शुरू होता है और ज़रूरी एंडपॉइंट पर सुनता है। कॉन्करेंट रिक्वेस्ट, साझा स्टेट, डेटाबेस कनेक्शन और इवेंट लूप ब्लॉकिंग को टेस्ट करें। यथार्थवादी ट्रैफ़िक में CPU और मेमोरी बिलिंग के वास्तविक व्यवहार को मापें।

थ्रॉटलिंग (throttling), कोल्ड स्टार्ट (cold start), टाइमआउट हैंडलिंग, स्ट्रीमिंग रिस्पॉन्स और सुरक्षित क्लाइंट रीट्राई की जांच करें। फिर एंडपॉइंट प्रमाणीकरण, CloudFront ओरिजिन सुरक्षा, VPC आवश्यकताओं और रीजनल डिप्लॉयमेंट व्यवहार को सत्यापित करें। अंत में, एक दूसरा रिविज़न डिप्लॉय करें और साबित करें कि ट्रैफ़िक को पिछले काम करते हुए वर्ज़न पर वापस ले जाया जा सकता है।

ये जांचें एक सफल डेमो और भरोसेमंद ढंग से चलाए जा सकने वाले एप्लिकेशन के बीच अंतर करने में मदद करती हैं।

Web Functions वास्तव में क्या बदलते हैं

AWS Lambda Web Functions पारंपरिक हैंडलर मॉडल की ज़रूरत के बिना जाने-पहचाने Node.js वेब एप्लिकेशन को Lambda में लाते हैं। कॉन्करेंट HTTP प्रोसेसिंग, मैनेज्ड स्केलिंग और एक्टिव-CPU बिलिंग इसे होस्टिंग का एक अर्थपूर्ण नया विकल्प बनाते हैं।

सीमाएं उतनी ही मायने रखती हैं जितनी सुविधाएं। एप्लिकेशन को कॉन्करेंट रिक्वेस्ट में सुरक्षित रहना चाहिए। जब तक एनवायरनमेंट मौजूद हैं, मेमोरी बिलिंग जारी रहती है।

WebSocket अपग्रेड उपलब्ध नहीं हैं। VPC इग्रेस कनेक्टर को फ़िलहाल बिल्ट-इन मल्टी-रीजन एंडपॉइंट प्रकारों के साथ नहीं जोड़ा जा सकता।

व्यावहारिक निर्णय यह नहीं है कि Lambda एक सामान्य वेब सर्वर चला सकता है या नहीं।

निर्णय यह है कि क्या Web Functions का एक्ज़िक्यूशन, नेटवर्किंग और ऑपरेशनल मॉडल एप्लिकेशन के लिए उसके मौजूदा होस्टिंग विकल्पों से बेहतर बैठता है।

---

संदर्भ और आगे पढ़ने के लिए

1. AWS, Announcing AWS Lambda Web Functions। 12 अक्टूबर 2026। लॉन्च रीजन, रनटाइम और Lambda के तीन फ़ॉर्म फ़ैक्टर।
2. AWS, Lambda Web Functions overview। प्रोग्रामिंग मॉडल, बिलिंग और सपोर्टेड वर्कलोड।
3. AWS, Core concepts। रिविज़न, एंडपॉइंट और रिक्वेस्ट प्रोसेसिंग।
4. AWS, Scaling behavior। डायनेमिक कॉन्करेंसी, कोटा और थ्रॉटलिंग।
5. AWS, Execution environment lifecycle। कॉन्करेंसी सुरक्षा, शटडाउन और एनवायरनमेंट का पुनः उपयोग।
6. AWS, Configuring networking। HTTP स्ट्रीमिंग, VPC प्रतिबंध, एंडपॉइंट कनेक्टिविटी और CORS।
7. AWS, Best practices। सुरक्षा, रीट्राई व्यवहार, रोलआउट सत्यापन और मल्टी-रीजन ऑपरेशन।
8. AWS, Runtime support। Node.js रनटाइम की आवश्यकताएं और मेमोरी।

स्रोतों का सत्यापन 5 नवंबर 2026 को किया गया और 6 नवंबर 2026 को फिर से जांचा गया। तकनीकी क्षमताएं और सीमाएं उन तारीखों पर AWS के दस्तावेज़ीकरण को दर्शाती हैं, और नई सेवा तेज़ी से बदलती है, इसलिए कोई कदम उठाने से पहले ऊपर दिए गए स्रोत देखें। लागत और प्रदर्शन से जुड़े निष्कर्ष आर्किटेक्चर संबंधी विश्लेषण हैं, TechiesJournal के स्वतंत्र बेंचमार्क परिणाम नहीं।