AWS Lambda Web Functions తో డెవలపర్లు సాధారణ Node.js HTTP అప్లికేషన్లను ఈవెంట్ హ్యాండ్లర్లుగా తిరిగి రాయకుండానే డిప్లాయ్ చేయవచ్చు. దీని కాంకరెంట్ రిక్వెస్ట్ మోడల్, యాక్టివ్-CPU బిల్లింగ్, మేనేజ్డ్ స్కేలింగ్ కొత్త హోస్టింగ్ ఆప్షన్లను అందిస్తాయి, కానీ నెట్‌వర్క్, సెక్యూరిటీ, ఆపరేషనల్ పరిమితులు ఇది ఎక్కడ సరిపోతుందో ప్రభావితం చేస్తాయి.
ఒక డెవలపర్ Express లేదా Fastify ఉపయోగించి ఒక API నిర్మిస్తారు. ఆ అప్లికేషన్ ఒక HTTP సర్వర్‌ను ప్రారంభిస్తుంది, ఒక పోర్ట్‌పై వింటుంది (listen), వచ్చే రిక్వెస్ట్‌లను నిర్వహిస్తుంది. ఆ అప్లికేషన్‌ను సంప్రదాయ AWS Lambdaపై నడపాలంటే సాధారణంగా దాన్ని ఒక ఈవెంట్-హ్యాండ్లర్ ఇంటర్‌ఫేస్‌కు అనుగుణంగా మార్చాల్సి వస్తుంది.
అక్టోబర్ 12, 2026న AWS, Lambda Web Functions ను పరిచయం చేసింది. దీనితో డెవలపర్లు ఒక సంప్రదాయ Node.js HTTP సర్వర్‌ను నేరుగా Lambdaకు డిప్లాయ్ చేయవచ్చు. ప్రారంభ సమయంలో AWS ఈ సర్వీస్‌ను ఐదు రీజియన్లలో (Regions) అందుబాటులోకి తెచ్చింది: 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 ఎగ్జిక్యూషన్ ఎన్విరాన్‌మెంట్ ఒకసారికి ఒక ఇన్వొకేషన్‌ను (invocation) మాత్రమే ప్రాసెస్ చేస్తుంది. దానికి బదులుగా ఒక Web Function సాధారణ Node.js HTTP సర్వర్‌ను నడుపుతుంది. Lambda HTTP ట్రాఫిక్‌ను ఆ సర్వర్‌కు పంపుతుంది, అది కాంకరెంట్ (concurrent) రిక్వెస్ట్‌లను నిర్వహించగలదు.
| లక్షణం | Event Functions | Web Functions |
|---|---|---|
| ప్రోగ్రామింగ్ మోడల్ | ఈవెంట్ హ్యాండ్లర్ | పోర్ట్‌పై వినే Node.js HTTP సర్వర్ |
| సాధారణ వర్క్‌లోడ్‌లు | ఈవెంట్లు, క్యూలు, షెడ్యూల్డ్ జాబ్‌లు, API హ్యాండ్లర్లు | HTTP APIలు, వెబ్ అప్లికేషన్లు, సర్వర్-సైడ్ రెండరింగ్, స్ట్రీమింగ్ |
| ఒక్కో ఎన్విరాన్‌మెంట్‌కు కాంకరెన్సీ | ఒకసారికి ఒక ఇన్వొకేషన్ | అనేక HTTP రిక్వెస్ట్‌లు |
| కంప్యూట్ బిల్లింగ్ ఆధారం | ఇన్వొకేషన్ వ్యవధి | యాక్టివ్ CPU వినియోగం |
| మెమరీ బిల్లింగ్ ఆధారం | ఇన్వొకేషన్ వ్యవధి | ఎగ్జిక్యూషన్ ఎన్విరాన్‌మెంట్ జీవితకాలం |
| స్కేలింగ్ | మేనేజ్డ్ ఇన్వొకేషన్ స్కేలింగ్ | మేనేజ్డ్ HTTP స్కేలింగ్, సున్నాకు స్కేల్ అవడం (scale-to-zero) సహా |
రెండు మోడళ్లకూ వేర్వేరు ప్రయోజనాలు కొనసాగుతాయి. ఒక అప్లికేషన్ 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 మధ్య ఒక గరిష్ఠ పరిమితిని (upper bound) నిర్ణయిస్తుంది, దాని డిఫాల్ట్ విలువ 64. ఆ విలువ హామీ ఇచ్చిన కాంకరెన్సీ కాదు. CPU లేదా మెమరీ వినియోగం వల్ల అదనపు రిక్వెస్ట్‌లు సరికానప్పుడు, Lambda అమలయ్యే (effective) పరిమితిని అంతకంటే తక్కువగా ఎంచుకోవచ్చు.
అసింక్రొనస్ I/O ఎక్కువగా ఉండే అప్లికేషన్లకు ఇది ప్రయోజనం చేకూర్చవచ్చు. ఉదాహరణకు, ఒక Node.js API తన రిక్వెస్ట్ సమయంలో ఎక్కువ భాగం డేటాబేస్ క్వెరీలు లేదా బయటి సర్వీసుల కోసం వేచి ఉండవచ్చు. ఒక రిక్వెస్ట్ వేచి ఉన్నప్పుడు, ఈవెంట్ లూప్ (event loop) ఇతర రిక్వెస్ట్‌లను ప్రాసెస్ చేయగలదు.
CPU ఎక్కువగా వాడే సింక్రొనస్ పని భిన్నంగా ప్రవర్తిస్తుంది. ఒక రిక్వెస్ట్ ఈవెంట్ లూప్‌ను బ్లాక్ చేస్తే, అదే ప్రాసెస్‌ను పంచుకునే ఇతర రిక్వెస్ట్‌లు కూడా ఆలస్యం కావచ్చు.
రిక్వెస్ట్‌ల మధ్య ఒకే ప్రాసెస్‌ను పంచుకోవడం ఒక స్టేట్ (state) సమస్యను కూడా సృష్టిస్తుంది. ఒక రిక్వెస్ట్‌కు మాత్రమే సంబంధించిన సమాచారాన్ని, మార్చగలిగే షేర్డ్ గ్లోబల్స్‌లో (shared mutable globals) నిల్వ చేయకూడదు. అసింక్రొనస్ ఆపరేషన్లు ఒకదానితో ఒకటి కలిసిపోయి (interleave) నడిచినప్పుడు క్యాష్‌లు, కౌంటర్లు, ఇతర షేర్డ్ ఆబ్జెక్ట్‌లను తగిన విధంగా నిర్వహించాలి.
సంప్రదాయ Node.js సర్వర్ కోసం రాసిన అప్లికేషన్ ఇప్పటికే ఈ పరిస్థితులను పరిగణనలోకి తీసుకుని ఉండవచ్చు. అయినా, మేనేజ్డ్ Lambda ఎన్విరాన్‌మెంట్‌లో దాని వాస్తవ ప్రవర్తనను డెవలపర్లు ధ్రువీకరించాలి.
మూలాలు: AWS, Execution environment lifecycle, Scaling behavior, Runtime support.
యాక్టివ్-CPU బిల్లింగ్ అంటే ఏమిటి?
యాక్టివ్-CPU బిల్లింగ్ అంటే, ఒక రిక్వెస్ట్ ఇతర సిస్టమ్‌ల కోసం వేచి ఉండే సమయానికి కాకుండా, మీ కోడ్ నిజంగా ఉపయోగించే CPU సమయానికే మీకు ఛార్జీ పడుతుంది. కస్టమర్లు రిక్వెస్ట్‌లకు, యాక్టివ్ CPU వినియోగానికి, ఎగ్జిక్యూషన్ ఎన్విరాన్‌మెంట్ జీవితకాలం అంతటా మెమరీ వినియోగానికి, వర్తించే డేటా ట్రాన్స్‌ఫర్‌కు చెల్లిస్తారు. ఇది సంప్రదాయ Lambda వ్యవధి (duration) మోడల్‌కు భిన్నం, ఆ మోడల్‌లో ఒక ఇన్వొకేషన్ డౌన్‌స్ట్రీమ్ ఆపరేషన్ల కోసం వేచి ఉండే సమయం కూడా లెక్కలోకి వస్తుంది.
ఒక చిన్న గణన చేసి, ఆ తర్వాత డేటాబేస్ రెస్పాన్స్ కోసం వేచి ఉండే ఒక API రిక్వెస్ట్‌ను పరిశీలించండి. Web Functions లో, ఆ వేచి ఉండే సమయం తక్కువ యాక్టివ్ CPUను మాత్రమే వినియోగించవచ్చు. అయితే, ఎగ్జిక్యూషన్ ఎన్విరాన్‌మెంట్ ఉన్నంత కాలం, రిక్వెస్ట్‌ల మధ్య ఖాళీ (idle) సమయంతో సహా, మెమరీ ఛార్జీలు కొనసాగుతాయి. ట్రాఫిక్ ఆగిపోయిన తర్వాత ఒక ఎండ్‌పాయింట్ సున్నాకు స్కేల్ కాగలదు, కానీ ప్రతి రిక్వెస్ట్ తర్వాత ఎన్విరాన్‌మెంట్ వెంటనే అదృశ్యం కావాలనేమీ లేదు.
ఈ తేడా కొన్ని I/O ఎక్కువగా ఉండే అప్లికేషన్లకు Web Functions ను ఆకర్షణీయంగా మార్చే అవకాశం ఉంది. ఈ సర్వీస్ ప్రతి అప్లికేషన్‌కూ చౌకైనదని ఇది నిరూపించదు. ఖర్చు పోలికలో ట్రాఫిక్ నమూనాలు, సగటు రిక్వెస్ట్ వ్యవధి, CPU వినియోగం, మెమరీ వినియోగం, డేటా ట్రాన్స్‌ఫర్, ప్రస్తుత హోస్టింగ్ ప్లాట్‌ఫారమ్ ప్రవర్తనను పరిగణించాలి. నిరంతరంగా CPU ఎక్కువగా వాడే వర్క్‌లోడ్‌లు ఉన్న అప్లికేషన్ల ఆర్థిక లెక్కలు, నెట్‌వర్క్ నిరీక్షణలు ఎక్కువగా ఉండే అప్లికేషన్ల కంటే భిన్నంగా ఉండవచ్చు.
మూలం: AWS, Lambda Web Functions overview.
డిప్లాయ్‌మెంట్, స్కేలింగ్ ఎలా పనిచేస్తాయి
ఒక Web Functionలో రివిజన్లు, ఎండ్‌పాయింట్లు ఉంటాయి. ఒక రివిజన్ (revision) అనేది అప్లికేషన్ కోడ్, కాన్ఫిగరేషన్‌ల మార్చలేని (immutable) స్నాప్‌షాట్. ఒక ఎండ్‌పాయింట్ (endpoint) HTTP ప్రవేశ ద్వారాన్ని (entry point) అందిస్తుంది, తన ట్రాఫిక్ కాన్ఫిగరేషన్ ప్రకారం రిక్వెస్ట్‌లను ఒకటి లేదా రెండు రివిజన్లకు పంపుతుంది.
ఈ విభజన నియంత్రిత రోల్‌అవుట్‌లకు (controlled rollouts) తోడ్పడుతుంది. టీమ్‌లు ఒక కొత్త రివిజన్‌ను సృష్టించి, దాన్ని పరీక్షించి, ట్రాఫిక్‌లో కొంత భాగాన్ని దానికి మళ్లించవచ్చు.
క్లయింట్ కాల్ చేస్తుంది
ప్రతి Web Function ఎండ్‌పాయింట్‌కు పబ్లిక్‌గా చేరుకోగల ఒక డొమైన్ పేరు ఉంటుంది.
IamAuthతో, Lambda తగిన అధికారం ఉన్న, సంతకం చేసిన (signed) రిక్వెస్ట్‌లను కోరుతుంది.
ApplicationManagedతో, Lambda కాలర్ ఆథెంటికేషన్ చేయకుండానే రిక్వెస్ట్‌లను ముందుకు పంపుతుంది.
ఎండ్‌పాయింట్ రివిజన్ ఎంపిక
ఒక ఎండ్‌పాయింట్ HTTP ప్రవేశ ద్వారాన్ని (entry point) అందిస్తుంది, తన ట్రాఫిక్ కాన్ఫిగరేషన్ ప్రకారం రిక్వెస్ట్‌లను ఒకటి లేదా రెండు రివిజన్లకు పంపుతుంది.
టీమ్‌లు ఒక కొత్త రివిజన్‌ను సృష్టించి, దాన్ని పరీక్షించి, ట్రాఫిక్‌లో కొంత భాగాన్ని దానికి మళ్లించవచ్చు.
ఒక ఎన్విరాన్‌మెంట్, పలు రిక్వెస్ట్‌లు
సంప్రదాయ Event Function ఎన్విరాన్‌మెంట్‌లా కాకుండా, ఒక Web Function ఎన్విరాన్‌మెంట్ ఒకేసారి అనేక రిక్వెస్ట్‌లను అందించగలదు.
maxConcurrencyPerEnvironment సెట్టింగ్ 1 నుంచి 128 మధ్య ఒక గరిష్ఠ పరిమితిని (upper bound) నిర్ణయిస్తుంది, దాని డిఫాల్ట్ విలువ 64.
CPU లేదా మెమరీ వినియోగం వల్ల అదనపు రిక్వెస్ట్‌లు సరికానప్పుడు, Lambda అమలయ్యే (effective) పరిమితిని అంతకంటే తక్కువగా ఎంచుకోవచ్చు.
రెస్పాన్స్, టైమ్‌అవుట్
అప్లికేషన్ రెస్పాన్స్‌ను అందించే ముందు Lambda వచ్చే రిక్వెస్ట్ బాడీ మొత్తాన్ని ఫార్వర్డ్ చేస్తుంది.
Web Function రిక్వెస్ట్‌లకు డిఫాల్ట్ టైమ్‌అవుట్ 30 సెకన్లు, కాన్ఫిగర్ చేయగల గరిష్ఠం 900 సెకన్లు, అంటే 15 నిమిషాలు.
రెస్పాన్స్ హెడర్లు పంపిన తర్వాత టైమ్‌అవుట్ ముగిస్తే, క్లయింట్‌కు స్పష్టమైన అప్లికేషన్ ఎర్రర్‌కు బదులు కత్తిరించిన (truncated) రెస్పాన్స్ అందవచ్చు.
AWS మూడు ప్రధాన స్కేలింగ్ నియంత్రణలను అందిస్తుంది.
| సెట్టింగ్ | ప్రయోజనం |
|---|---|
maxConcurrencyPerEnvironment | ఒక ఎన్విరాన్‌మెంట్‌లో కాంకరెంట్ రిక్వెస్ట్‌లపై గరిష్ఠ పరిమితి |
maxEnvironments | ప్రతి రీజియన్‌లో ఒక్కో ఎండ్‌పాయింట్‌కు ఎన్విరాన్‌మెంట్ల ఐచ్ఛిక గరిష్ఠ సంఖ్య |
rateLimit | ప్రతి రీజియన్‌లో ఒక్కో ఎండ్‌పాయింట్‌కు రిక్వెస్ట్‌లు వచ్చే రేటుపై ఐచ్ఛిక పరిమితి |
ఈ సర్వీస్ అకౌంట్ స్థాయి పరిమితులను కూడా అమలు చేస్తుంది, వీటిలో రీజియనల్ vCPU సామర్థ్యం, రిక్వెస్ట్-రేట్ కోటాలు (quotas) ఉన్నాయి. ఒక ఎండ్‌పాయింట్ సెట్టింగ్‌ను పెంచినంత మాత్రాన ఆ అకౌంట్ కోటాలను అధిగమించలేరు.
ఒక ఎండ్‌పాయింట్ రిక్వెస్ట్-రేట్ పరిమితిని దాటినప్పుడు లేదా అందుబాటులో ఉన్న సర్వింగ్ సామర్థ్యం అయిపోయినప్పుడు, Lambda HTTP 429 రెస్పాన్స్‌లను తిరిగి ఇవ్వవచ్చు. పరిగణించాల్సిన అదనపు సందర్భాలు ఉన్నాయి. rateLimit ను సున్నాకు సెట్ చేస్తే ట్రాఫిక్ నిలిచిపోతుంది, ఒక నిర్దిష్ట ప్లాట్‌ఫారమ్ ఎర్రర్ సూచికతో HTTP 503 వస్తుంది. సర్వీస్‌ను కాపాడటానికి లోడ్‌ను తగ్గిస్తున్నప్పుడు (load shedding) కూడా AWS HTTP 503 ను తిరిగి ఇవ్వవచ్చు.
క్లయింట్లు తగిన సందర్భాల్లో మాత్రమే మళ్లీ ప్రయత్నించాలి (retry), ప్రతి వైఫల్యం తర్వాత మరింత ఎక్కువసేపు వేచి ఉండి, ఒక యాదృచ్ఛిక ఆలస్యాన్ని జోడించాలి (backoff, jitter). రీట్రైలు వ్యాపార ప్రభావాలను పునరావృతం చేయకుండా ఉండటానికి, రైట్ (write) ఆపరేషన్లకు ఐడెంపొటెన్సీ కీలు (idempotency keys) లేదా డీడూప్లికేషన్ (deduplication) అవసరం కావచ్చు.
డిప్లాయ్ అయిన రివిజన్ తప్పనిసరిగా పనిచేసే అప్లికేషన్ కాదు
AWS రివిజన్, ఎండ్‌పాయింట్ రిసోర్స్ స్టేట్‌లను వాస్తవ అప్లికేషన్ సంసిద్ధత నుంచి వేరుగా చూస్తుంది. ఒక రివిజన్ యొక్క HTTP సర్వర్ సరిగ్గా ప్రారంభం కావడంలో విఫలమైనా, ఆ రివిజన్ యాక్టివ్ కావచ్చు.
డిప్లాయ్‌మెంట్ తర్వాత, టీమ్‌లు ఒక నిజమైన HTTP రిక్వెస్ట్ పంపాలి, అప్లికేషన్ లాగ్‌లను పరిశీలించాలి, ఎండ్‌పాయింట్ ఉద్దేశించిన రెస్పాన్స్‌ను అందిస్తోందని నిర్ధారించుకోవాలి. ప్రొడక్షన్ రోల్‌అవుట్‌ల కోసం, రిసోర్స్ సృష్టి అంటే అప్లికేషన్ డిప్లాయ్‌మెంట్ విజయవంతమైనట్లే అని భావించడం కంటే, వెయిటెడ్ రివిజన్ డిప్లాయ్‌మెంట్ (weighted revision deployment), ధ్రువీకరించిన రోల్‌బ్యాక్ (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 సిఫార్సు చేస్తుంది.
ప్రైవేట్ రిసోర్స్‌లకు ఒక ముఖ్యమైన పరిమితి
ఒక ఎగ్రెస్ నెట్‌వర్క్ కనెక్టర్ (egress network connector) ద్వారా Amazon VPC లోపల ఉన్న రిసోర్స్‌లకు అవుట్‌బౌండ్ కనెక్టివిటీని కూడా Web Functions సపోర్ట్ చేస్తాయి. ఎండ్‌పాయింట్లు మూడు రకాలు. HomeRegion ఎండ్‌పాయింట్ హోమ్ రీజియన్ నుంచి మాత్రమే ట్రాఫిక్‌ను అందిస్తుంది, MultiRegion, PerRegion ఎండ్‌పాయింట్లు అనేక రీజియన్ల నుంచి ట్రాఫిక్‌ను అందిస్తాయి.
నవంబర్ 6, 2026 నాటికి, ఆ కనెక్టర్లకు HomeRegion ఎండ్‌పాయింట్లతో మాత్రమే సపోర్ట్ ఉంది.
MultiRegion లేదా PerRegion ఎండ్‌పాయింట్ల ద్వారా అందించే రివిజన్లతో VPC ఎగ్రెస్ కనెక్టర్‌ను అనుసంధానించడాన్ని AWS సపోర్ట్ చేయదు. కాబట్టి, అలాంటి కనెక్టర్ ద్వారా ఒక ప్రైవేట్ డేటాబేస్‌కు నేరుగా యాక్సెస్ అవసరమైన అప్లికేషన్, Web Functions లో అంతర్నిర్మితంగా ఉన్న మల్టీ-రీజియన్ ఎండ్‌పాయింట్ పంపిణీని కూడా ఉపయోగించుకోగలదని భావించలేం. ఈ పరిమితిని డిప్లాయ్‌మెంట్ తర్వాత కాకుండా, ఆర్కిటెక్చర్ ఎంపిక సమయంలోనే పరిష్కరించాలి.
అంతేకాదు, VPC ఎగ్రెస్ కనెక్టివిటీ Web Function ఇన్‌కమింగ్ HTTPS ఎండ్‌పాయింట్‌ను ప్రైవేట్‌గా మార్చదు. ఇన్‌బౌండ్ యాక్సెస్, అవుట్‌బౌండ్ నెట్‌వర్క్ కనెక్టివిటీ వేర్వేరు అంశాలు.
ఇన్‌బౌండ్ పబ్లిక్
ప్రతి Web Function ఎండ్‌పాయింట్‌కు పబ్లిక్‌గా చేరుకోగల ఒక డొమైన్ పేరు ఉంటుంది.
IAM ఆథెంటికేషన్ ఎండ్‌పాయింట్‌ను ప్రైవేట్ నెట్‌వర్క్ రిసోర్స్‌గా మార్చదు.
అవుట్‌బౌండ్ ప్రైవేట్ కావచ్చు
ఒక ఎగ్రెస్ నెట్‌వర్క్ కనెక్టర్ (egress network connector) ద్వారా Amazon VPC లోపల ఉన్న రిసోర్స్‌లకు అవుట్‌బౌండ్ కనెక్టివిటీని కూడా Web Functions సపోర్ట్ చేస్తాయి.
అంతేకాదు, VPC ఎగ్రెస్ కనెక్టివిటీ Web Function ఇన్‌కమింగ్ HTTPS ఎండ్‌పాయింట్‌ను ప్రైవేట్‌గా మార్చదు.
ఇన్‌బౌండ్ యాక్సెస్, అవుట్‌బౌండ్ నెట్‌వర్క్ కనెక్టివిటీ వేర్వేరు అంశాలు.
కేవలం HomeRegion
MultiRegion లేదా PerRegion ఎండ్‌పాయింట్ల ద్వారా అందించే రివిజన్లతో VPC ఎగ్రెస్ కనెక్టర్‌ను అనుసంధానించడాన్ని AWS సపోర్ట్ చేయదు.
కాబట్టి, అలాంటి కనెక్టర్ ద్వారా ఒక ప్రైవేట్ డేటాబేస్‌కు నేరుగా యాక్సెస్ అవసరమైన అప్లికేషన్, Web Functions లో అంతర్నిర్మితంగా ఉన్న మల్టీ-రీజియన్ ఎండ్‌పాయింట్ పంపిణీని కూడా ఉపయోగించుకోగలదని భావించలేం.
ముందే తేల్చు
ఈ పరిమితిని డిప్లాయ్‌మెంట్ తర్వాత కాకుండా, ఆర్కిటెక్చర్ ఎంపిక సమయంలోనే పరిష్కరించాలి.
అయితే, అప్లికేషన్‌ను అనేక రీజియన్లలో డిప్లాయ్ చేసినంత మాత్రాన దాని డేటాబేస్‌లు, సెషన్లు, సీక్రెట్లు లేదా డౌన్‌స్ట్రీమ్ డిపెండెన్సీలు ఆటోమేటిక్‌గా రెప్లికేట్ కావు.
మూలాలు: AWS, Configuring networking for Web Functions, Core concepts, Best practices for Lambda Web Functions.
సెక్యూరిటీ పబ్లిక్ ఎండ్‌పాయింట్ దగ్గరే మొదలవుతుంది
ప్రతి Web Function ఎండ్‌పాయింట్‌కు పబ్లిక్‌గా చేరుకోగల ఒక డొమైన్ పేరు ఉంటుంది. AWS రెండు ఆథెంటికేషన్ విధానాలను అందిస్తుంది.
IamAuthతో, Lambda తగిన అధికారం ఉన్న, సంతకం చేసిన (signed) రిక్వెస్ట్‌లను కోరుతుంది. ApplicationManagedతో, Lambda కాలర్ ఆథెంటికేషన్ చేయకుండానే రిక్వెస్ట్‌లను ముందుకు పంపుతుంది. అవసరమైన ఆథెంటికేషన్, ఆథరైజేషన్‌ను అప్లికేషన్ లేదా అప్‌స్ట్రీమ్ సర్వీస్ అమలు చేయాలి.
IAM ఆథెంటికేషన్ ఎండ్‌పాయింట్‌ను ప్రైవేట్ నెట్‌వర్క్ రిసోర్స్‌గా మార్చదు. పబ్లిక్ అప్లికేషన్ల కోసం, డెవలపర్లు ఇన్‌పుట్ ధ్రువీకరణ (input validation), రేట్ దుర్వినియోగం, రిక్వెస్ట్ ఆథరైజేషన్, సున్నితమైన సమాచార రక్షణను కూడా చూసుకోవాలి.
Web Function ఎండ్‌పాయింట్లు కస్టమ్ డొమైన్ పేర్లకు గానీ, నేరుగా AWS WAF అనుసంధానానికి గానీ సపోర్ట్ ఇవ్వవు. కస్టమ్ డొమైన్, క్యాషింగ్, AWS WAF రక్షణను అందించడానికి Amazon CloudFront ను ఒక Web Function ముందు ఉంచవచ్చు.
IamAuth ఎండ్‌పాయింట్ కోసం, CloudFront ఆరిజిన్‌కు పంపే తన రిక్వెస్ట్‌లపై సంతకం చేసేలా CloudFront ఆరిజిన్ యాక్సెస్ కంట్రోల్‌ను (origin access control, OAC) AWS సిఫార్సు చేస్తుంది. ఇతర ఫ్రంట్ డోర్లతో (front doors) ఎండ్‌పాయింట్ నేరుగా చేరుకోగలిగేలానే ఉంటుంది, కాబట్టి అప్లికేషన్ ఒక షేర్డ్ సీక్రెట్ లేదా టోకెన్‌ను ధ్రువీకరించాలి. తగిన ఆరిజిన్ ఆంక్షలు లేకపోతే, నేరుగా వచ్చే రిక్వెస్ట్‌లు ఉద్దేశించిన ఫ్రంట్ డోర్‌ను దాటవేయవచ్చు.
బ్రౌజర్ అప్లికేషన్లకు తగిన Cross-Origin Resource Sharing (CORS) కాన్ఫిగరేషన్ కూడా అవసరం. Web Functions కోసం Lambda 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 starts), టైమ్‌అవుట్ నిర్వహణ, స్ట్రీమింగ్ రెస్పాన్స్‌లు, సురక్షితమైన క్లయింట్ రీట్రైలను ధ్రువీకరించండి. ఆ తర్వాత ఎండ్‌పాయింట్ ఆథెంటికేషన్, CloudFront ఆరిజిన్ రక్షణ, VPC అవసరాలు, రీజియనల్ డిప్లాయ్‌మెంట్ ప్రవర్తనను ధ్రువీకరించండి. చివరగా, రెండో రివిజన్‌ను డిప్లాయ్ చేసి, ట్రాఫిక్‌ను మునుపటి పనిచేసే వెర్షన్‌కు తిరిగి మళ్లించగలమని నిరూపించండి.
విజయవంతమైన ఒక ప్రదర్శన (demonstration) నుంచి, విశ్వసనీయంగా నిర్వహించగల అప్లికేషన్‌ను వేరు చేసి చూడటంలో ఈ తనిఖీలు సహాయపడతాయి.
Web Functions నిజంగా ఏం మారుస్తాయి
AWS Lambda Web Functions సంప్రదాయ హ్యాండ్లర్ మోడల్ అవసరం లేకుండానే, అలవాటైన Node.js వెబ్ అప్లికేషన్లను Lambdaలోకి తెస్తుంది. కాంకరెంట్ HTTP ప్రాసెసింగ్, మేనేజ్డ్ స్కేలింగ్, యాక్టివ్-CPU బిల్లింగ్ దీన్ని ఒక అర్థవంతమైన కొత్త హోస్టింగ్ ఆప్షన్‌గా మారుస్తాయి.
ఫీచర్లు ఎంత ముఖ్యమో పరిమితులూ అంతే ముఖ్యం. కాంకరెంట్ రిక్వెస్ట్‌ల సమయంలో అప్లికేషన్లు సురక్షితంగా పనిచేయాలి. ఎన్విరాన్‌మెంట్లు ఉన్నంత కాలం మెమరీ బిల్లింగ్ కొనసాగుతుంది.
WebSocket అప్‌గ్రేడ్‌లు అందుబాటులో లేవు. VPC ఎగ్రెస్ కనెక్టర్లను ప్రస్తుతం అంతర్నిర్మిత మల్టీ-రీజియన్ ఎండ్‌పాయింట్ రకాలతో కలపలేం.
ఆచరణాత్మక నిర్ణయం Lambda ఒక సాధారణ వెబ్ సర్వర్‌ను నడపగలదా అన్నది కాదు.
Web Functions ఎగ్జిక్యూషన్, నెట్‌వర్కింగ్, ఆపరేషనల్ మోడల్, ఇప్పటికే ఉన్న హోస్టింగ్ ప్రత్యామ్నాయాల కంటే అప్లికేషన్‌కు బాగా సరిపోతుందా అన్నదే అసలు నిర్ణయం.
రిఫరెన్సులు, మరింత చదవడానికి
- AWS, Announcing AWS Lambda Web Functions. అక్టోబర్ 12, 2026. ప్రారంభ రీజియన్లు, రన్‌టైమ్, మూడు Lambda ఫారమ్ ఫ్యాక్టర్లు (form factors).
- AWS, Lambda Web Functions overview. ప్రోగ్రామింగ్ మోడల్, బిల్లింగ్, సపోర్ట్ ఉన్న వర్క్‌లోడ్‌లు.
- AWS, Core concepts. రివిజన్లు, ఎండ్‌పాయింట్లు, రిక్వెస్ట్ ప్రాసెసింగ్.
- AWS, Scaling behavior. డైనమిక్ కాంకరెన్సీ, కోటాలు, థ్రాట్లింగ్.
- AWS, Execution environment lifecycle. కాంకరెన్సీ భద్రత, షట్‌డౌన్, ఎన్విరాన్‌మెంట్ పునర్వినియోగం.
- AWS, Configuring networking. HTTP స్ట్రీమింగ్, VPC ఆంక్షలు, ఎండ్‌పాయింట్ కనెక్టివిటీ, CORS.
- AWS, Best practices. సెక్యూరిటీ, రీట్రై ప్రవర్తన, రోల్‌అవుట్ ధ్రువీకరణ, మల్టీ-రీజియన్ ఆపరేషన్లు.
- AWS, Runtime support. Node.js రన్‌టైమ్ అవసరాలు, మెమరీ.
మూలాలను నవంబర్ 5, 2026న ధ్రువీకరించి, నవంబర్ 6, 2026న మళ్లీ తనిఖీ చేశాం. సాంకేతిక సామర్థ్యాలు, పరిమితులు ఆ తేదీల నాటి AWS డాక్యుమెంటేషన్‌ను ప్రతిబింబిస్తాయి, కొత్త సర్వీస్ త్వరగా మారుతుంది, కాబట్టి చర్య తీసుకునే ముందు పై మూలాలను తనిఖీ చేయండి. ఖర్చు, పనితీరు ప్రభావాలు ఆర్కిటెక్చరల్ విశ్లేషణ మాత్రమే, స్వతంత్ర TechiesJournal బెంచ్‌మార్క్ ఫలితాలు కావు.