కొత్త పరిమితి కేవలం కొన్ని Lambda Managed Instances ఇన్వొకేషన్లకు మాత్రమే వర్తిస్తుంది. ఎక్కువ టైమ్అవుట్ అంటే ప్రతి బ్యాచ్ జాబ్కు Lambda సరైన ఇల్లు అవుతుందని అర్థం కాదు.
పెద్ద టైమ్అవుట్ ఒక పెద్ద ఆర్కిటెక్చర్ నిర్ణయాన్ని దాచగలదు
AWS Lambda తన ఖ్యాతిని చిన్న, ఈవెంట్-డ్రివెన్ పని మీద నిర్మించుకుంది. ఒక ఫైల్ వస్తుంది, ఒక మెసేజ్ క్యూలో చేరుతుంది, ఒక API రిక్వెస్ట్ ఒక ఫంక్షన్ను పిలుస్తుంది, మరియు ఫంక్షన్ త్వరగా పూర్తవుతుంది.
సెప్టెంబర్ 2026లో, Lambda Managed Instancesపై నడిచే కొన్ని వర్క్లోడ్ల కోసం AWS గరిష్ట టైమ్అవుట్ను 90 నిమిషాలకు పెంచింది. ఇది ఒక సాధారణ విస్తరణలా అనిపిస్తుంది: ఇంతకుముందు Lambda యొక్క 15-నిమిషాల పరిమితిని దాటిన జాబ్లు ఇప్పుడు Lambdaలోనే ఉండగలవు.
కానీ ఇది సాధారణ Lambdaకు ఒక విశ్వవ్యాప్త మార్పు కాదు. ఇది Lambda Managed Instancesపై అసమకాలిక మరియు ఈవెంట్-సోర్స్-మ్యాపింగ్ ఇన్వొకేషన్లకు వర్తిస్తుంది. సింక్రొనస్ కాల్స్ 15 నిమిషాలకే పరిమితమై ఉంటాయి. Amazon MQ మరియు Amazon DocumentDB ఈవెంట్-సోర్స్ మ్యాపింగ్లు కూడా 15-నిమిషాల పరిమితిని కొనసాగిస్తాయి.
మరింత ముఖ్యంగా, Lambda Managed Instances కంప్యూట్, కాన్కరెన్సీ, స్కేలింగ్ మరియు ప్రైసింగ్ మోడల్ను మారుస్తాయి. నిర్ణయం కేవలం ఒక ఫంక్షన్కు మరో 75 నిమిషాలు అవసరమా అనేది కాదు. వర్క్లోడ్ ఈ భిన్నమైన Lambda రూపానికి సరిపోతుందా అనేదే.
ఏమి మారింది—ఏమి మారలేదు
| ఇన్వొకేషన్ లేదా కంప్యూట్ మోడ్ | గరిష్ట నిరంతర ఇన్వొకేషన్ |
|---|---|
| స్టాండర్డ్ Lambda సింక్రొనస్ ఇన్వొకేషన్ | 15 నిమిషాలు |
| స్టాండర్డ్ Lambda అసమకాలిక ఇన్వొకేషన్ | 15 నిమిషాలు |
| Lambda Managed Instances సింక్రొనస్ ఇన్వొకేషన్ | 15 నిమిషాలు |
| Lambda Managed Instances అసమకాలిక ఇన్వొకేషన్ | 90 నిమిషాలు |
| Managed Instancesపై చాలా ఈవెంట్-సోర్స్ మ్యాపింగ్లు | 90 నిమిషాలు |
| Amazon MQ లేదా DocumentDB ఈవెంట్-సోర్స్ మ్యాపింగ్ | 15 నిమిషాలు |
మీడియా ప్రాసెసింగ్, AI ఇన్ఫరెన్స్, సైంటిఫిక్ వర్క్, ఫైనాన్షియల్ కాలిక్యులేషన్స్, నెమ్మదైన ఫైల్ ట్రాన్స్ఫర్లు మరియు పెద్ద డేటా-ప్రాసెసింగ్ జాబ్లు వంటి యూజ్ కేసులను AWS వివరిస్తుంది. ఇవి సాంకేతికంగా సాధ్యమయ్యే అభ్యర్థులు. సాంకేతిక అర్హత మొదటి ఫిల్టర్ మాత్రమే.
Managed Instances అంటే పెద్ద గడియారంతో కూడిన సాధారణ Lambda కాదు
స్టాండర్డ్ Lambda AWS-నిర్వహించే, మల్టీ-టెనెంట్ ఇన్ఫ్రాస్ట్రక్చర్పై ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్లను నడుపుతుంది మరియు ప్రధానంగా రిక్వెస్ట్లు మరియు ఎగ్జిక్యూషన్ వ్యవధి ఆధారంగా చార్జ్ చేస్తుంది. ఇది ఖాళీగా ఉన్నప్పుడు జీరోకు స్కేల్ అవుతుంది.
Lambda Managed Instances మీ అకౌంట్లోని EC2 కెపాసిటీపై ఫంక్షన్లను నడుపుతాయి, అయితే AWS ఇన్స్టాన్స్ లైఫ్సైకిల్, రన్టైమ్ ప్యాచింగ్, రూటింగ్ మరియు స్కేలింగ్ను నిర్వహిస్తుంది. ఇవి మేనేజ్మెంట్ ఫీజుతో సహా ఇన్స్టాన్స్-ఆధారిత ప్రైసింగ్ను వాడతాయి మరియు స్కేల్-టు-జీరో స్టాండర్డ్ Lambda లాగా ప్రవర్తించే బదులు కాన్ఫిగర్ చేసిన కనీస కెపాసిటీని కొనసాగిస్తాయి.
ఇవి ఒక ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్ లోపల బహుళ ఏకకాల ఇన్వొకేషన్లను కూడా సపోర్ట్ చేస్తాయి. అది I/O-భారీ వర్క్లోడ్ల కోసం యుటిలైజేషన్ను మెరుగుపరచగలదు, కానీ షేర్డ్ మెమరీ, గ్లోబల్ వేరియబుల్స్, థ్రెడ్ సేఫ్టీ మరియు కాంటెక్స్ట్ ఐసొలేషన్ గురించి ఊహలను మారుస్తుంది. సాధారణ Lambda యొక్క సింగిల్-కాన్కరెన్సీ ప్రవర్తన కోసం రాసిన ఫంక్షన్కు Managed Instancesపై సురక్షితంగా ఉండటానికి ముందు ఇంజినీరింగ్ పని అవసరం కావచ్చు.
ఇది 90-నిమిషాల పరిమితిని ఒక విస్తృత నిర్ణయంలో భాగంగా చేస్తుంది:
- ఇన్స్టాన్స్ కెపాసిటీని సమర్థించడానికి మీకు తగినంత స్థిరమైన డిమాండ్ ఉందా?
- కోడ్ ఒక ఎన్విరాన్మెంట్లో ఏకకాల ఇన్వొకేషన్లను సురక్షితంగా హ్యాండిల్ చేయగలదా?
- వర్క్లోడ్కు CPU-ఆధారిత అసమకాలిక స్కేలింగ్ సముచితమా?
- 89వ నిమిషంలో విఫలమైన తర్వాత జాబ్ కోలుకోగలదా?
- ఒక కంటైనర్ లేదా బ్యాచ్ సర్వీస్ కంటే Lambda ఇప్పటికీ ప్రయోజనాన్ని అందిస్తుందా?
ఎక్కువసేపు నడవడం అంటే డ్యూరబుల్ అని కాదు
ఒక టైమ్అవుట్ కోడ్ ఎంతసేపు కొనసాగవచ్చో చెబుతుంది. అది పని పూర్తవుతుందని గ్యారంటీ ఇవ్వదు.
ఇన్స్టాన్స్లు విఫలమవుతాయి. డిపెండెన్సీలు టైమ్అవుట్ అవుతాయి. డిప్లాయ్మెంట్లు ఎన్విరాన్మెంట్లను రీప్లేస్ చేస్తాయి. ఒక మెసేజ్ మళ్లీ డెలివర్ చేయబడవచ్చు. వైఫల్యం తర్వాత ఒక 70-నిమిషాల జాబ్ మొదటి నుండి రీస్టార్ట్ అయితే, పెద్ద టైమ్అవుట్ కోల్పోగల పని మొత్తాన్ని పెంచింది.
అందువల్ల పొడవైన జాబ్లకు ఇవి అవసరం:
- ఇడెంపొటెంట్ ప్రాసెసింగ్, తద్వారా ఒక రిట్రై బిజినెస్ ఎఫెక్ట్లను డూప్లికేట్ చేయదు;
- చెక్పాయింట్లు లేదా పార్టిషన్లు, తద్వారా రికవరీ మొత్తాన్ని రీస్టార్ట్ చేయదు;
- స్పష్టమైన రిట్రై మరియు డెడ్-లెటర్ పాలసీ;
- ప్రోగ్రెస్ మరియు ఫెయిల్యూర్ టెలిమెట్రీ;
- పరిమితమైన ఇన్పుట్ సైజ్ మరియు ఎగ్జిక్యూషన్ సమయం;
- సురక్షితమైన క్యాన్సలేషన్ మరియు క్లీన్అప్.
AWS డ్యూరబుల్ ఫంక్షన్లు దశల మధ్య అప్లికేషన్ స్టేట్ను భద్రపరచగలవు మరియు చెక్పాయింట్ల నుండి తిరిగి ప్రారంభించగలవు. Step Functions అనేక టాస్క్లు, వెయిట్లు మరియు బ్రాంచ్లను సమన్వయం చేయగలదు. AWS Batch మరియు ECS వేర్వేరు రిసోర్స్ మరియు జాబ్-కంట్రోల్ మోడల్స్తో కంటైనరైజ్డ్ కంప్యూట్ను నడపగలవు. ఒక 90-నిమిషాల ఇన్వొకేషన్ ఆ సామర్థ్యాలను రీప్లేస్ చేయదు.
90-నిమిషాల Lambda ఎక్కడ సరిపోతుంది
వర్క్లోడ్ ఈ క్రింది విధంగా ఉన్నప్పుడు Lambda Managed Instances మంచి ఎంపిక కావచ్చు:
- అసమకాలికంగా లేదా సపోర్ట్ చేసే ఈవెంట్ సోర్స్ ద్వారా ట్రిగర్ అవుతుంది;
- సాధారణంగా 90 నిమిషాల లోపే బాగా పూర్తవుతుంది;
- ప్రొవిజన్ చేసిన ఇన్స్టాన్స్ కెపాసిటీని వాడగల అంచనావేయదగిన లేదా స్థిరమైన డిమాండ్ కలిగి ఉంటుంది;
- EC2 ఇన్స్టాన్స్ ఎంపికల నుండి ప్రయోజనం పొందుతుంది కానీ కంటైనర్ ప్లాట్ఫారమ్ను నిర్వహించడాన్ని సమర్థించదు;
- Managed Instances కాన్కరెన్సీ మోడల్ను తట్టుకోగలదు;
- ఇడెంపొటెంట్ మరియు పనిని సురక్షితంగా చెక్పాయింట్ చేయగలదు లేదా విభజించగలదు;
- ఇప్పటికే Lambda యొక్క ఈవెంట్, డిప్లాయ్మెంట్ మరియు అబ్జర్వబిలిటీ మోడల్కు సరిపోతుంది.
ఉదాహరణకు, SQS నుండి పెద్ద డాక్యుమెంట్ల స్థిరమైన స్ట్రీమ్ను ప్రాసెస్ చేసే ఒక టీమ్, పొడవైన ప్రాసెసింగ్ మరియు ప్రత్యేక కంప్యూట్ కోసం Managed Instancesను వాడుతూ Lambda ఇంటిగ్రేషన్ను విలువైనదిగా భావించవచ్చు.
మరో సర్వీస్ బహుశా మెరుగైనది ఎక్కడ
| వర్క్లోడ్ లక్షణం | మెరుగైన ప్రారంభ బిందువు | ఎందుకు |
|---|---|---|
| చిన్న, స్ఫుటమైన ఈవెంట్ ప్రాసెసింగ్ | స్టాండర్డ్ Lambda | జీరోకు స్కేల్ మరియు సరళమైన పర్-ఇన్వొకేషన్ ఎకనామిక్స్ |
| వెయిట్లు లేదా అప్రూవల్స్ ఉన్న మల్టీ-స్టెప్ ప్రాసెస్ | Step Functions లేదా డ్యూరబుల్ ఫంక్షన్లు | స్పష్టమైన స్టేట్, చెక్పాయింట్లు మరియు రికవరీ |
| పెద్ద కంటైనర్ ఇమేజ్ లేదా కస్టమ్ ఆపరేటింగ్ ఎన్విరాన్మెంట్ | ECS/Fargate | రన్టైమ్ మరియు టాస్క్ లైఫ్సైకిల్పై ఎక్కువ నియంత్రణ |
| వేర్వేరు CPU/GPU అవసరాలతో క్యూడ్ కంప్యూట్ | AWS Batch | జాబ్ క్యూలు, షెడ్యూలింగ్ మరియు కంప్యూట్ ఎన్విరాన్మెంట్లు |
| పని రొటీన్గా 90 నిమిషాలకు దగ్గరగా ఉంటుంది | ECS లేదా Batch | ఎక్కువ హెడ్రూమ్ మరియు స్పష్టమైన జాబ్ నియంత్రణలు |
| నిరంతర సర్వీస్ లేదా దీర్ఘకాలిక వర్కర్ | ECS/EKS/EC2 | ఇది సహజంగా ఒక ఇన్వొకేషన్ కాదు |
ఇవి ప్రారంభ బిందువులు, విశ్వవ్యాప్త నియమాలు కాదు. డేటా మూవ్మెంట్, టీమ్ నైపుణ్యాలు, ప్రాంతీయ లభ్యత, కంప్లయన్స్, స్టార్టప్ లేటెన్సీ మరియు ఖర్చు సమాధానాన్ని మార్చగలవు.
ఖర్చు ప్రశ్న కూడా భిన్నమైనది
ఒక 60-నిమిషాల స్టాండర్డ్-స్టైల్ ఇన్వొకేషన్ ధరను ఒక కంటైనర్ టాస్క్తో పోల్చడం ఆకర్షణీయంగా అనిపిస్తుంది. అది అసంపూర్తిగా ఉంటుంది ఎందుకంటే Managed Instances స్టాండర్డ్ Lambda యొక్క స్కేల్-టు-జీరో వ్యవధి మోడల్ కాకుండా EC2-ఆధారిత కెపాసిటీని వాడతాయి.
పూర్తి ఆపరేటింగ్ ప్యాటర్న్ను మోడల్ చేయండి:
- అందుబాటులో ఉండే కనీస ఇన్స్టాన్స్లు.
- సగటు మరియు గరిష్ట యుటిలైజేషన్.
- ఒక్కో ఎగ్జిక్యూషన్ ఎన్విరాన్మెంట్కు సాధించిన కాన్కరెన్సీ.
- ఇన్స్టాన్స్, స్టోరేజ్, డేటా-ట్రాన్స్ఫర్ మరియు మేనేజ్మెంట్ చార్జీలు.
- రిట్రైలు మరియు పునరావృత పని ఖర్చు.
- కంటైనర్లతో పోలిస్తే తప్పించిన ఆపరేషనల్ ప్రయత్నం.
కెపాసిటీ ఖాళీగా ఉన్నా లేదా పొడవైన రిట్రైలు పెద్ద జాబ్లను పునరావృతం చేసినా, తక్కువ ధర గల కంప్యూట్ నిమిషం ఇప్పటికీ ఖరీదైన సిస్టమ్ను తయారు చేయగలదు.
ఆర్కిటెక్ట్లు తర్వాత ఏమి చేయాలి?
డయాగ్రమ్ నుండి ఒక సర్వీస్ను తొలగించడం కోసం మాత్రమే ఒక Step Functions, ECS లేదా Batch వర్క్లోడ్ను మైగ్రేట్ చేయవద్దు.
ఒక అభ్యర్థి జాబ్ను ఎంచుకుని కొలవండి:
- నిజమైన వ్యవధి పంపిణీ, కేవలం సగటు మాత్రమే కాదు;
- CPU, మెమరీ, స్టోరేజ్ మరియు నెట్వర్క్ వాడకం;
- రాక ప్యాటర్న్ మరియు సాధించగల కాన్కరెన్సీ;
- వైఫల్య ఫ్రీక్వెన్సీ మరియు రీస్టార్ట్ ఖర్చు;
- అంతరాయం తర్వాత రికవరీ పాయింట్;
- ఆర్కెస్ట్రేషన్ మరియు ఆపరేషన్లతో సహా ప్రస్తుత మొత్తం ఖర్చు.
ఆపై ఒక చిన్న Managed Instances ట్రయల్ను ప్రస్తుత ఆర్కిటెక్చర్తో పోల్చండి. కొత్త డిజైన్ సరళంగా, రికవరబుల్గా మరియు ఆర్థికంగా బాగుంటే, పొడవైన టైమ్అవుట్ ఉపయోగకరంగా ఉంటుంది. ఏకైక వాదన “ఇప్పుడు ఇది 90 నిమిషాల లోపు సరిపోతుంది” అయితే, ఆర్కిటెక్చర్ సమీక్ష ఇంకా పూర్తి కాలేదు.
తెలుసుకోవడం, వాడటం లేదా నైపుణ్యం సాధించడం?
తెలుసుకోండి: 90-నిమిషాల పరిమితి ప్రతి Lambda ఫంక్షన్కు అందుబాటులో లేదని మరియు Managed Instances భిన్నమైన కెపాసిటీ మోడల్ను వాడతాయని క్లౌడ్ ప్రాక్టీషనర్లు అర్థం చేసుకోవాలి.
వాడండి: డెవలపర్లు మరియు DevOps ఇంజినీర్లు పొడవైన జాబ్ల కోసం ఇడెంపొటెన్సీ, చెక్పాయింటింగ్, కాన్కరెన్సీ సేఫ్టీ, రిట్రైలు మరియు టెలిమెట్రీని డిజైన్ చేయగలగాలి.
నైపుణ్యం సాధించండి: క్లౌడ్ ఆర్కిటెక్ట్లు వర్క్లోడ్ ప్రవర్తన, రికవరీ అవసరాలు మరియు మొత్తం ఖర్చును ఉపయోగించి Managed Instances, డ్యూరబుల్ ఫంక్షన్లు, Step Functions, ECS మరియు Batchలను పోల్చాలి.
ఉపయోగకరమైన ప్రశ్న, “Lambda దీన్ని 90 నిమిషాలు నడపగలదా?” అనేది కాదు. అది, “ఈ 90-నిమిషాల జాబ్ నెమ్మదిగా, డూప్లికేట్ అయ్యి, అంతరాయం కలిగి లేదా ఖాళీగా ఉన్నప్పుడు ఏమి జరుగుతుంది?” అనేది. ఆ సమాధానమే ఆర్కిటెక్చర్ను ఎంచుకోవాలి.
సూచనలు మరియు మరింత చదవడానికి
- Announcing 90-minute function timeout on AWS Lambda Managed Instances — AWS, 9 సెప్టెంబర్ 2026. అర్హత గల ఇన్వొకేషన్ రకాలు మరియు ఉద్దేశించిన యూజ్ కేసులను నిర్వచిస్తుంది. సెప్టెంబర్ 2026లో సమీక్షించబడింది.
- Configure Lambda function timeout — AWS Lambda డాక్యుమెంటేషన్. టైమ్అవుట్ పరిమితులు మరియు మినహాయింపులను నిర్ధారిస్తుంది. సెప్టెంబర్ 2026లో సమీక్షించబడింది.
- Lambda Managed Instances — AWS Lambda డాక్యుమెంటేషన్. కంప్యూట్, కాన్కరెన్సీ, స్కేలింగ్, ఐసొలేషన్ మరియు ప్రైసింగ్ తేడాలను వివరిస్తుంది. సెప్టెంబర్ 2026లో సమీక్షించబడింది.
- Best practices for Lambda Managed Instances — AWS Lambda డాక్యుమెంటేషన్. లభ్యత, కాన్కరెన్సీ మరియు దీర్ఘ-ఇన్వొకేషన్ పరిగణనలను కవర్ చేస్తుంది. సెప్టెంబర్ 2026లో సమీక్షించబడింది.