20 अक्टूबर, 2025 के AWS आउटेज के पीछे की कहानी

20 अक्टूबर, 2025 को इंटरनेट के कुछ हिस्सों के लिए सुबह अच्छी नहीं रही। Amazon Web Services (AWS) ने अपने उत्तरी वर्जीनिया डेटा सेंटर क्लस्टर (US-EAST-1) में समस्याओं की सूचना दी। कई घंटों तक, कई लोकप्रिय ऐप्स और साइटें धीमी या अनुपलब्ध रहीं—जिनमें Vercel, Figma, Venmo, और Snapchat जैसे नाम शामिल हैं। समाचार आउटलेट्स और मॉनिटरिंग सेवाओं ने लाखों उपयोगकर्ता रिपोर्ट दर्ज कीं, और यहाँ तक कि कुछ Amazon सेवाओं में भी अस्थिरता देखी गई।

हालाँकि, Namefi के ग्राहकों के लिए यह एक सामान्य दिन था। हमारे सिस्टम हमेशा की तरह चलते रहे—संयोग से नहीं, बल्कि इसलिए क्योंकि हम उस इंजीनियरिंग और ऑपरेशनल मजबूती में भारी निवेश करते हैं जो DNS रिज़ॉल्यूशन को क्षेत्रीय गड़बड़ियों के प्रति लचीला (resilient) बनाती है।

इसके बावजूद, Namefi इंजीनियरिंग टीम इस तरह के वैश्विक आउटेज की समीक्षा करती है और उनसे सीखती है, जैसा कि वह सभी बड़ी घटनाओं के लिए करती है। यहाँ बताया गया है कि अब तक क्या सीखा गया है:

नोट: यह लेख लिखते समय, घटना अभी भी विकसित हो रही है। इस पोस्ट को समय-समय पर अपडेट किया जा सकता है। यदि आपको कोई गलती दिखाई देती है या सुधार की आवश्यकता है, तो कृपया namefi.io पर dev-team के साथ साझा करें। हम इसकी सराहना करते हैं।

AWS में वास्तव में क्या गलत हुआ—सरल शब्दों में

हर ऐप और वेबसाइट को यह "देखने" (look up) का तरीका चाहिए कि उसे कहाँ कनेक्ट करना है। इंटरनेट की उस एड्रेस बुक को DNS—यानी डोमेन नेम सिस्टम (Domain Name System)—कहा जाता है। 20 अक्टूबर को, AWS के अंदर एक नामकरण (naming) की समस्या का मतलब था कि कुछ कंप्यूटर नाम से एक प्रमुख AWS डेटाबेस सेवा को नहीं ढूँढ सके। यदि एड्रेस बुक सही समय पर सही एंट्री प्रदान नहीं कर सकती है, तो स्वस्थ सिस्टम भी एक-दूसरे से बात नहीं कर सकते।

AWS ने नामकरण की तत्काल समस्या को कुछ ही घंटों में ठीक कर दिया और फिर बाकी दिन बैकलॉग को क्लियर करने और सिस्टम को सामान्य स्थिति में लाने में बिताया। दोपहर तक (पैसिफिक समयानुसार), AWS ने कहा कि सब कुछ फिर से सामान्य रूप से काम कर रहा है, हालाँकि कुछ सेवाओं को पूरी तरह ठीक होने में अधिक समय लगा।

कौन प्रभावित हुआ (और यह आज के इंटरनेट के बारे में क्या कहता है)

इसका प्रभाव व्यापक था और आम उपयोगकर्ताओं के लिए जाना-पहचाना था। Snapchat और Reddit जैसे उपभोक्ता ऐप्स, Zoom और Signal जैसे संचार ऐप्स, और Fortnite और Roblox सहित गेमिंग प्लेटफॉर्म ने समस्याओं की सूचना दी। वित्तीय सेवाओं में Coinbase और Robinhood पर रुकावटें देखी गईं, जबकि यूके में कई सार्वजनिक सेवाओं—जिनमें HMRC (टैक्स पोर्टल) और Lloyds/Halifax/Bank of Scotland समूह के बैंक शामिल हैं—ने आउटेज का अनुभव किया। Vodafone और BT के टेलीकॉम ग्राहक ऐप्स भी प्रभावित हुए, भले ही उनके कोर नेटवर्क उपलब्ध रहे।

Amazon की अपनी संपत्तियों को भी परेशानी हुई: Amazon.com, Prime Video, Alexa और Ring सभी में व्यवधान देखा गया, जो यह दर्शाता है कि AWS अपनी मूल कंपनी की उपभोक्ता सेवाओं के साथ कितनी गहराई से जुड़ा हुआ है। Downdetector जैसे लाइव ट्रैकर्स ने दुनिया भर में लाखों उपयोगकर्ता समस्या रिपोर्ट दर्ज कीं, जो यह रेखांकित करता है कि कितने दैनिक जीवन के ऐप्स AWS पर निर्भर हैं। कुछ विश्लेषणों में मनोरंजन ऐप्स (जैसे Apple Music) और बड़े उपभोक्ता ब्रांडों के मोबाइल ऐप्स पर भी इसके प्रभाव को नोट किया गया।

तकनीकी गहराई में (Under the hood)

AWS की टाइमलाइन US-EAST-1 में DynamoDB API के लिए DNS रिज़ॉल्यूशन विफलताओं की ओर इशारा करती है। इसका मूल कारण एक आंतरिक EC2 सबसिस्टम को बताया गया जो नेटवर्क लोड बैलेंसर्स (NLBs) की सेहत (health) की निगरानी करता है; जब उस सबसिस्टम में खराबी आई, तो यह बाहरी रूप से DynamoDB एंडपॉइंट के लिए खराब 'नेम लुकअप' के रूप में सामने आया। AWS ने 2:24 AM PDT पर DNS समस्या को कम (mitigate) कर दिया और 3:01 PM PDT तक सभी सेवाओं को सामान्य घोषित कर दिया, जबकि बैकलॉग दोपहर भर क्लियर होते रहे। (Amazon, Reuters)

स्वतंत्र नेटवर्क टेलीमेट्री ने कोई व्यापक इंटरनेट रूटिंग विसंगति (उदाहरण के लिए, कोई BGP घटना नहीं) नहीं देखी, जो इस निष्कर्ष के साथ मेल खाती है कि गलती सार्वजनिक इंटरनेट के बजाय AWS के कंट्रोल प्लेन के अंदर थी। (ThousandEyes)

DNS के कुछ व्यवहार फिक्स के बाद की "लंबी देरी" (long tail) की व्याख्या करते हैं:

• कैशिंग, जिसमें नेगेटिव कैशिंग भी शामिल है: रिज़ॉल्वर्स TTL (टाइम-टू-लिव) नामक अवधि के लिए उत्तरों को स्टोर करते हैं। वे मानकों के अनुसार विफलताओं को भी कैश करते हैं। यदि किसी रिज़ॉल्वर ने घटना के दौरान "इसे ढूँढ नहीं सका" प्रतिक्रिया को कैश किया, तो वह उस विफलता को तब तक परोसता रह सकता है जब तक कि टाइमर समाप्त नहीं हो जाता, भले ही AWS ने स्रोत को सही कर दिया हो। (मानक: RFC 2308, RFC 9520 में अपडेट किया गया)
• कंट्रोल प्लेन बनाम डेटा प्लेन: क्लाउड प्लेटफ़ॉर्म ऑर्केस्ट्रेशन (कंट्रोल प्लेन) को स्थिर-स्थिति सेवा (डेटा प्लेन) से अलग करते हैं। एक कंट्रोल-प्लेन की गड़बड़ी जो 'नेम लुकअप' को तोड़ती है, वह अन्यथा स्वस्थ सर्विंग रास्तों को अवरुद्ध कर सकती है, क्योंकि क्लाइंट्स को अभी भी एंडपॉइंट्स को नाम से खोजने की आवश्यकता होती है। AWS का अपना रेसिलिएंस मार्गदर्शन इन प्लेन्स को अलग करता है और कंट्रोल सिस्टम में उच्च जटिलता और परिवर्तन दर को नोट करता है। (AWS whitepaper)
• क्षेत्रीय केंद्रीयता: US-EAST-1 उन घटकों को होस्ट करता है जिन पर कई वैश्विक सुविधाएँ निर्भर करती हैं; यह एकाग्रता बताती है कि क्यों एक क्षेत्रीय नामकरण (naming) मुद्दा प्रभाव में वैश्विक महसूस हुआ। (सामान्य रिपोर्टिंग में संदर्भ: Reuters)

छोटी इंटरनेट कंपनियाँ इससे क्या सीख सकती हैं

इस तरह की घटनाएं एक सरल विचार को रेखांकित करती हैं: नेमिंग लेयर (naming layer) ही सुरक्षा लेयर है। उपयोगकर्ताओं को कहाँ भेजा जाए, अगला कौन सा डेटा सेंटर आज़माया जाए, और मुसीबत के दौरान ट्रैफ़िक को कैसे संचालित किया जाए, यह सब DNS के माध्यम से होता है। उस लेयर को स्वतंत्र, रिडंडेंट (अतिरिक्त बैकअप के साथ) और बदलाव के लिए तैयार बनाने से रिकवरी तेज़ होती है और आउटेज छोटे होते हैं।

DNS महत्वपूर्ण क्यों है और इसमें Namefi कैसे फिट बैठता है

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

यही दर्शन Namefi के अस्तित्व का कारण है। Namefi का प्लेटफ़ॉर्म एक उत्पाद के रूप में डोमेन और DNS रेसिलिएंस प्रदान करता है, जो सर्वोत्तम प्रथाओं, सावधानीपूर्वक तैयार किए गए TTLs और संचार सतहों को एक साथ जोड़ता है। इसका परिणाम एक ऐसी नेमिंग लेयर है जिसे अंतर्निहित बादलों (clouds) के ठीक होने, थ्रॉटलिंग करने या वापस पटरी पर आने के दौरान भी अच्छे रूटिंग निर्णय लेते रहने के लिए डिज़ाइन किया गया है। Namefi को अपनाने वाली टीमों को यह स्थिति (posture) बॉक्स से बाहर मिलती है, साथ ही इसे देखने और समायोजित करने के लिए ऑपरेशनल टूलिंग भी मिलती है—बिना उन नियंत्रणों को उसी प्लेन से जोड़े जो शायद मुसीबत का सामना कर रहा हो।

जब 20 अक्टूबर जैसी घटनाएं होती हैं, तो वह अलगाव ही है जो नक्शे को बरकरार रखता है।

स्रोत और आगे पढ़ने के लिए

• Amazon — आधिकारिक घटना का समय और रिकवरी के चरण (2:24 AM PDT पर शमन; 3:01 PM PDT तक सभी सेवाएं सामान्य; रिकवरी के दौरान EC2 थ्रॉटलिंग)। (Amazon)
• Reuters — EC2 आंतरिक NLB स्वास्थ्य-निगरानी सबसिस्टम में मूल कारण; प्रभाव का दायरा; लाखों उपयोगकर्ता रिपोर्ट; बैकलॉग क्लियरिंग। (Reuters)
• ThousandEyes — US-EAST-1, DNS से DynamoDB, और व्यापक रूटिंग विसंगतियों की अनुपस्थिति पर केंद्रित टेलीमेट्री। (ThousandEyes)
• The Verge / Tom’s Guide — सार्वजनिक टाइमलाइन, पुष्टि कि घटना साइबर हमले के बजाय DNS/कंट्रोल-प्लेन से संबंधित थी, और प्रभावित प्लेटफार्मों के उदाहरण। (The Verge)
• IETF / Cloudflare Docs — DNS नेगेटिव कैशिंग व्यवहार (RFC 2308, RFC 9520) और मल्टी-प्रोवाइडर आधिकारिक परिनियोजन (authoritative deployments) के लिए मल्टी-साइनर DNSSEC पैटर्न (RFC 8901, ऑपरेटर डॉक्स)। (RFC Editor, RFC Editor)