AWS Emulator Amazon Web Services (AWS) के API का एक लोकल विकल्प है। डेवलपर इसे अपने कंप्यूटर, डेवलपमेंट सर्वर या CI यानी ऑटोमेटेड बिल्ड और टेस्ट प्रक्रिया में चला सकते हैं। इससे ऐप के AWS अनुरोध क्लाउड के बजाय एमुलेटर तक जाते हैं—और इसके लिए AWS खाते की जरूरत नहीं होती।
8
Amazon ने इसे 11 नवंबर 2026 को उपलब्ध कराया। इसका मकसद कोड पर जल्दी प्रतिक्रिया पाना है: हर बदलाव को क्लाउड पर तैनात किए बिना, डेवलपर या कोड लिखने वाला AI एजेंट स्थानीय स्तर पर अनुरोध चला सकता है और नतीजा देख सकता है।
8
13
438 API मॉडल, 200 से अधिक सेवाएं
AWS Emulator Rust में बना है। लॉन्च की जानकारी के मुताबिक, इसे AWS के 438 सार्वजनिक API मॉडल से तैयार किया गया है और यह 200 से अधिक सेवाओं को कवर करता है।
4
14 मॉडल और सेवाओं की यह संख्या इसकी व्यापकता बताती है—यह अपने आप में इस बात का सबूत नहीं कि हर सुविधा या हर किनारे के मामले में इसका व्यवहार असली AWS जैसा ही होगा।
AWS के दस्तावेज़ों के अनुसार, एमुलेटर संसाधन बनाने, उनकी जानकारी देखने, उन्हें बदलने और हटाने वाले अनुरोधों से सबसे अधिक मेल खाता है। जिन ऑपरेशनों का समर्थन है, उनमें गलत अनुरोध पर AWS जैसे त्रुटि-संदेश भी मिल सकते हैं। फिर भी, किसी सेवा का API मौजूद होना और उसके हर व्यवहार का हूबहू अनुकरण होना अलग बातें हैं।
इसे AI एजेंटों ने कैसे बनाया?
Amazon का कहना है कि AWS Emulator की हर कोड लाइन स्वायत्त AI एजेंटों ने लिखी और उसकी इंजीनियर टीम ने कोड न तो लिखा, न उसकी समीक्षा की।
3
5 यह Amazon का अपने विकास-प्रक्रिया के बारे में दिया गया विवरण है।
Amazon ने काम को तीन एजेंट समूहों में बांटने की बात कही है: एक समूह असली AWS पर जांचे गए टेस्ट तैयार करता है; दूसरा उन्हीं टेस्ट को एमुलेटर पर चलाकर अंतर ढूंढता है; और तीसरा उन समस्याओं को ठीक करता है।
5 कंपनी के मुताबिक, हजारों एजेंट परियोजना को बनाने और संभालने में शामिल रहे हैं।
5 उपलब्ध जानकारी से यह अलग दावा पुष्ट नहीं होता कि वे हर दिन हजारों समस्याएं ठीक करते हैं।
कोड को GitHub पर CC0 सार्वजनिक समर्पण के तहत जारी किया गया है।
1
3 कुछ रिपोर्टों के मुताबिक, AI-लिखे कोड के कॉपीराइट को लेकर अनिश्चितता भी इस लाइसेंस के चुनाव के पीछे हो सकती है; इसे Amazon की पुष्टि की हुई वजह नहीं समझना चाहिए। रिपोर्टों में यह भी कहा गया है कि परियोजना बग रिपोर्ट लेती है, लेकिन बाहरी योगदानकर्ताओं के pull request स्वीकार नहीं करती।
11
शुरुआती बग और मिली-जुली प्रतिक्रिया
लॉन्च के शुरुआती दिनों की एक रिपोर्ट में GitHub पर 70 से अधिक बग रिपोर्ट और DynamoDB तथा Lambda से जुड़ी समस्याओं का उल्लेख था। उसी रिपोर्ट में एक डेवलपर की इसे “बेकार” कहने वाली प्रतिक्रिया भी आई; रिपोर्ट का आकलन था कि टूल काम करता है, लेकिन अभी अधूरा है।
17 शुरुआती कमियां यह दिखाती हैं कि असली AWS से व्यवहार का अंतर हो सकता है—लेकिन उनसे यह साबित नहीं होता कि कमियों की वजह AI से कोड लिखवाना ही था।
सबसे अहम सावधानी: IAM और असली क्लाउड का व्यवहार
IAM, AWS में पहचान और अनुमतियां तय करने वाली व्यवस्था है। उपलब्ध दस्तावेज़ों और रिपोर्टों के अनुसार, AWS Emulator IAM और संसाधन-आधारित नीतियों का मूल्यांकन उसी तरह नहीं करता जैसे असली AWS करता है। इसलिए कोई अनुरोध लोकल टेस्ट में सफल हो सकता है, जबकि AWS उसे अनुमति न दे।
19
21
इसी वजह से लोकल टेस्ट पास होने को सुरक्षा जांच या प्रोडक्शन अनुमतियों की पुष्टि न मानें। AWS भी अपने उत्पाद विवरण में कहता है कि Emulator विकास और परीक्षण के लिए है, प्रोडक्शन के लिए नहीं; सुरक्षा सेटिंग्स की जांच असली AWS पर करनी चाहिए।
स्टेट, आइसोलेशन और क्षमता की सीमाएं
एमुलेटर संसाधनों की स्थिति अपनी मेमोरी में रखता है; उसे रोकने पर यह स्थिति बनी नहीं रहती। AWS के अनुसार, हर चलाया गया इंस्टेंस अपने पोर्ट, कुंजियों और इन-मेमोरी स्थिति के साथ अलग रहता है।
8 दूसरी ओर, उपलब्ध तकनीकी रिपोर्टों में क्षेत्र (Region) और AWS खाते के बीच वास्तविक आइसोलेशन न होने की सीमा बताई गई है।
18
19 इसलिए स्थायी डेटा या अलग-अलग खातों और क्षेत्रों के व्यवहार पर निर्भर वर्कफ़्लो को लोकल नतीजों के आधार पर प्रमाणित नहीं किया जा सकता।
क्षमता भी काम के प्रकार पर निर्भर हो सकती है। AWS के एक सर्वरलेस उदाहरण में Step Functions के निष्पादन-स्टोर की साझा सीमा 64 MiB पर पहुंचने के बाद EventBridge अनुरोध ExecutionLimitExceeded त्रुटि के साथ विफल हुए। यह एक खास कार्यभार का उदाहरण है—इसे हर उपयोग के लिए सामान्य क्षमता-सीमा नहीं समझना चाहिए, लेकिन बड़े या लंबे वर्कफ़्लो को जांचने की जरूरत जरूर दिखती है।
प्रति-सेवा fidelity score भी संदर्भ के साथ पढ़ें: ऐसी गणना बताती है कि किसी सेवा के प्रकाशित टेस्ट में से कितने पास हुए। यह हर संभावित AWS व्यवहार की गारंटी नहीं है।
19
तो इसका सही इस्तेमाल क्या है?
AWS Emulator को तेज स्थानीय प्रतिक्रिया पाने के साधन की तरह देखना सबसे उपयोगी है। शुरुआती विकास, API कॉल की बुनियादी जांच और CI में कुछ वर्कफ़्लो चलाने के लिए यह मददगार हो सकता है। लेकिन अहम अनुमतियों, सेवाओं के आपसी व्यवहार और प्रोडक्शन से जुड़े नतीजों की पुष्टि असली AWS पर करें। लोकल एमुलेटर क्लाउड तक जाने से पहले की जांच है—क्लाउड का प्रमाणपत्र नहीं।