AWS आउटेज से वैश्विक इंटरनेट के कुछ ही कंपनियों पर निर्भर रहने को लेकर चिंता बढ़ी

 (theguardian.com)
7 पॉइंट द्वारा GN⁺ 2025-10-23 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • विश्व की सबसे बड़ी AWS क्लाउड सेवा में आउटेज के कारण हजारों वेबसाइट और ऐप बंद हो गए, जिससे इंटरनेट इंफ्रास्ट्रक्चर में कुछ ही कंपनियों पर अत्यधिक निर्भरता का खतरा उजागर हुआ।
  • Snapchat, Roblox, Signal, Duolingo जैसी प्रमुख सेवाओं के साथ Lloyds Bank, Ring, HMRC जैसी सार्वजनिक और वित्तीय संस्थाएँ भी इस आउटेज के दायरे में आईं।
  • AWS ने कारण के रूप में अमेरिकी पूर्वी रिजन की आंतरिक सिस्टम गड़बड़ी बताया, साइबर अटैक की संभावना को खारिज किया, और अधिकांश सेवाएँ कुछ ही घंटों में बहाल हो गईं।
  • विशेषज्ञों ने कहा कि “लोकतांत्रिक विमर्श और स्वतंत्र पत्रकारिता की बुनियाद को कुछ चुनिंदा कंपनियों पर निर्भर नहीं होना चाहिए” और क्लाउड इंफ्रास्ट्रक्चर के विविधीकरण की जरूरत पर जोर दिया।
  • बड़े क्लाउड कंपनियों पर केंद्रित ढांचे को वैश्विक इंटरनेट की कमजोरियों को उजागर करने वाला माना गया, तथा पब्लिक इंफ्रास्ट्रक्चर की टेक्नोलॉजी संप्रभुता पर नई बहस शुरू हुई।

आउटेज का सार

  • AWS के अमेरिका के पूर्वी रिजन (US-East-1) में हुई आंतरिक त्रुटि से वैश्विक सेवाओं में व्यापक रुकावट आई।
    • स्थानीय समयानुसार सोमवार सुबह 8 बजे (यूके समय लगभग 4 बजे) से आउटेज शुरू हुआ।
    • Amazon ने कहा कि “API error rate और latency बढ़ गई थी।”
    • Downdetector के अनुसार दुनिया भर में करीब 2,000 कंपनियाँ प्रभावित हुईं, और अमेरिका में 19 लाख+, यूके में 10 लाख+, ऑस्ट्रेलिया में 41 लाख+ से अधिक उपयोगकर्ताओं ने समस्या की रिपोर्ट की।
  • AWS ने “आंतरिक लोड बैलेंसर मॉनिटरिंग सबसिस्टम” में खराबी को कारण बताया और साइबर अटैक की संभावना से इनकार किया।
    • AWS के DynamoDB से जुड़े error के कारण API responses असफल हो रहे थे।
    • ट्रैफिक स्पाइक रोकने के लिए अस्थायी रूप से request rate limiting लागू की गई।
  • AWS ने शाम को “नॉर्मल ऑपरेशन” में वापसी की आधिकारिक घोषणा की, लेकिन कुछ सेवाओं में लगातार आउटेज की रिपोर्ट मिली।

प्रभाव क्षेत्र

  • प्रमुख सेवाएँ: Snapchat, Roblox, Signal, Duolingo, Coinbase, Slack, Wordle, PlayStation Network, Peloton आदि कई अन्य
  • यूके में Lloyds, Halifax, Bank of Scotland जैसी वित्तीय सेवाओं और HMRC (हिज मैजेस्टी रेवेन्यू एंड कस्टम्स) वेबसाइट एक्सेस में समस्या आई।
  • Ring डोरबेल उपयोगकर्ताओं ने शिकायत की कि दरवाज़ा खुलने की मॉनिटरिंग सेवा बंद हो गई।
  • Epic Games, Pokémon Go, Wordle जैसी वैश्विक प्लेटफॉर्म पर भी पहुँच न हो पाने की रिपोर्टें मिलीं।

विशेषज्ञ विश्लेषण

  • Dr. Corinne Cath-Speth (Article 19): “लोकतांत्रिक विमर्श और स्वतंत्र मीडिया का आधार कुछ चुनिंदा कंपनियों के इंफ्रास्ट्रक्चर पर निर्भर होना खतरनाक है। क्लाउड विविधीकरण बेहद जरूरी है।”
  • Cori Crider (Future of Technology Institute): “यूके को अमेरिकी बिग टेक निर्भरता से बाहर आना चाहिए। AWS के एक स्थान पर आउटेज से पूरी आधुनिक अर्थव्यवस्था रुक जाने का उदाहरण सामने आया।”
  • Madeline Carr (UCL): “बड़ी क्लाउड कंपनियों की पूंजी शक्ति से सुरक्षा और scalability बनी रह सकती है, लेकिन विश्व को एक ही जोखिम में बाँधने वाली संरचना बहुत खतरनाक है।”
  • Steven Murdoch (UCL): “साइबर अटैक के बजाय अनुमान है कि यह AWS की आंतरिक ऑपरेशनल गलती थी।”

सरकारी और नियामक प्रतिक्रिया

  • यूके सरकार ने कहा कि उसने AWS के साथ आपातकालीन संपर्क तंत्र सक्रिय किया और रिकवरी की स्थिति की मॉनिटरिंग की।
  • यूके हाउस ऑफ कॉमन्स की फाइनेंस कमेटी ने कहा कि AWS को वित्तीय क्षेत्र के ‘critical third party’ के रूप में नामित किया जाना चाहिए।
    • नामित होने पर यह फाइनेंस रेगुलेटरी बॉडीज़ की निगरानी में आएगा और वित्तीय इंफ्रास्ट्रक्चर की स्थिरता सुनिश्चित की जा सकेगी।
    • अध्यक्ष Meg Hillier ने कहा कि AWS ने खुद को ‘resilience’ देने वाला बताया, लेकिन उसने अपनी vulnerability सामने लाई।

पृष्ठभूमि और निहितार्थ

  • AWS के पास विश्व क्लाउड बाजार में 30% से अधिक शेयर है और यह नंबर एक पर बना हुआ है।
  • Microsoft Azure और Google Cloud के साथ मिलकर ‘3 बड़े क्लाउड प्लेटफॉर्म का एकछत्र नियंत्रण’ बन रहा है।
  • 2024 में CrowdStrike की सॉफ्टवेयर गलती से दुनिया भर के Windows PC पर फिर से ‘Blue Screen’ की घटना हुई थी।
  • इस घटना ने फिर से दिखाया कि डिजिटल इंफ्रास्ट्रक्चर के केंद्रीकरण से जो सिस्टम रिस्क पैदा होता है, वह बड़ा है, और कई देशों की सरकारों में टेक्नोलॉजी संप्रभुता और क्लाउड विविधीकरण रणनीतियों की चर्चा तेज़ हो गई है।

संबंधित पढ़ाई

3 टिप्पणियां

 
chickendreamtree 2025-10-24

हिम्मत मत हारिए, Naver Cloud!
 
kimjoin2 2025-10-23

“अगर आपको क्लाउड पसंद नहीं है तो इसे खुद सेटअप करके इस्तेमाल कीजिए” इसलिए कोई चर्चा संभव है क्या, ऐसा लगता है।
मल्टी-क्लाउड? निर्माण और मैनेजमेंट भी तो किसी के लिए कोई "Josangnim" जैसा नहीं करेगा।
 
GN⁺ 2025-10-23
Hacker News टिप्पणी

  • अभी AWS us-east-1 में कई सेवाएँ डाउन होने पर चर्चा चल रही है, और उससे जुड़ा लंबा थ्रेड यहाँ मौजूद है

  • 2021 में Fastly आउटेज के समय भी ऐसे ही ‘विशेषज्ञ’ों ने समान आलोचना की थी, लेकिन कोई स्पष्ट बदलाव नहीं दिखा. ऐसे मुद्दे एक हफ्ते बाद खबरों में भी नहीं दिखते. काम करने वाले लोग जानते हैं कि AWS के स्केल पर ऑपरेशन कितना कठिन होता है. इस तरह की स्थिति के लिए असली बैकअप बनाना बहुत महँगा है, इसलिए ज़्यादातर कंपनियों के लिए इसका लाभ बहुत कम होता है. अगर कोई सेवा सच में “मिशन-क्रिटिकल” हो, तो उसे ऐसे आउटेज के खिलाफ डिज़ाइन किया जाना चाहिए. Fortnite में लॉगिन न कर पाना यह दिखाता है कि ऐसी तैयारी व्यवहार में कितनी कठिन और कितनी महँगी है. मीडिया भी सामान्यतः मल्टी-रीजन या मल्टी-क्लाउड की अहमियत पर चर्चा नहीं करता, लेकिन हादसा होते ही याद करता है और जल्द भूल जाता है. आख़िरकार सवाल बस यही रहता है कि तकनीकी कारण क्या था. फॉलो-अप के बिना ‘विशेषज्ञ’ों की निंदा का कोई खास मतलब नहीं; असली बात है ब्लेम-फ्री, निर्माणात्मक postmortem.

    • यहाँ जिन ‘विशेषज्ञों’ की चर्चा हो रही है, उनके पास वास्तविक इंफ्रास्ट्रक्चर या क्लाउड ऑपरेशन का अनुभव नहीं है. उदाहरण के लिए Dr Corinne Cath-Speth एक anthropologist हैं, Cori Crider एक वकील हैं, और Madeline Carr राजनीति विज्ञान की प्रोफेसर हैं. यानी ये लोग शोधपत्र लिखते हैं और मीडिया इंटरव्यू देते हैं, लेकिन असली hosting सेवाएँ रन करने का कोई वास्तविक अनुभव नहीं रखते.
    • क्लाउड निर्भरता की आलोचना करते हुए आख़िरकार यह मानना पड़ता है कि साल में 16 घंटे से ज्यादा डाऊनटाइम के लिए तैयार रहना होगा. कुछ घंटों की आउटेज व्यक्ति को बहुत महसूस होती है, लेकिन वास्तविक खतरा बाकी 8,742 घंटों में परफॉर्मेंस डिग्रेडेशन से भी अधिक हो सकता है. अगर सिर्फ़ 16 घंटे डाऊनटाइम से कंपनी बंद होने वाली हो, तो या तो मैं या दूसरा पक्ष बिज़नेस को ठीक से नहीं समझता. मुझे हाई उपलब्धता, जियो-रिडंडेंसी और अधिक स्थायी सिस्टम में ज्यादा दिलचस्पी है.
    • इसका मतलब यह नहीं कि हमेशा भारी निवेश की जरूरत हो. हर सेवा को एक जैसी सहनशीलता की जरूरत नहीं होती. अलग-अलग providers रखने से ये संभव है कि सबकुछ एक साथ प्रभावित न हो.
    • मीडिया में बताई गई मल्टी-रीजन/मल्टी-कエ्लाउड रेडंडेंसी की प्रभावकारिता अक्सर कमजोर पड़ती है. बाहर से लगता है कि शायद सिर्फ एक रीजन की समस्या हो, लेकिन अक्सर सेवाएँ कई रीजन में एक साथ प्रभावित होती हैं. मल्टी-क्लाउड hot standby में infra जितना जटिल होगा, लागत का बोझ उतना ही अधिक होगा. शुरुआत में प्लानिंग बिना बाद में इसे लागू करना काफी कठिन होता है.
    • AWS की अपनी रिपोर्टों में भी देखें तो फोकस कुछ चुने हुए रीजन और सेवाओं (जैसे DynamoDB) पर बहुत ज्यादा रहता है. यह केंद्रीकृत आर्किटेक्चर 10 वर्षों से भी ज़्यादा समय से दिख रहा है. फिर भी यह बदलता क्यों नहीं? इस घटना में 2,000 से अधिक सेवाएँ लंबी अवधि तक डाऊन रहीं. AWS स्थिति पृष्ठ देखें.

  • अगर “क्लाउड” या “इंटरनेट” के बजाय “वर्जीनिया का गोदाम” शब्द प्रयोग करने की आदत डालें तो क्या बेहतर समझ बनेगी, यह देखने की जरूरत है. जैसे, “हमारी सेवा पूरी तरह वर्जीनिया के गोदाम में है”, “मेरी सभी फाइलें वर्जीनिया के गोदाम में हैं”, “वर्जीनिया का गोदाम परमाणु युद्ध सहन करने के लिए डिज़ाइन किया गया है” आदि. मूल पोस्ट

    • वास्तव में यह गोदाम (वर्जीनिया का गोदाम) बुरा नहीं है. क्लाउड के आस-पास की मज़ाकिया उपमाएँ वास्तविक विकल्पों को नज़रअंदाज़ कर देती हैं. अधिकांश व्यवसायों के लिए क्लाउड का व्यवहारिक विकल्प अक्सर ऑफिस के कॉरिडोर में मौजूद शेल्फ ही होता है. पहले ऐसा आम था कि कोई भी व्यक्ति code pull कर दे तो पूरी कंपनी डाउन हो जाती थी जब तक कि IT टीम न आ जाए.

  • पहले से ही कई VPS providers मौजूद हैं, और ऐसे में शिफ्ट करने पर लागत घटने के कई उदाहरण मिलते हैं; हकीकत में यह क्लाउड लॉक-इन और मार्केटिंग का ही मामला है.

    • आज की कंपनियाँ सिर्फ low-level IaaS (जैसे EC2) नहीं, बल्कि AWS की high-level PaaS सेवाएँ इस्तेमाल करती हैं—DynamoDB, RedShift आदि. Azure और Google Cloud की स्थिति भी लगभग ऐसी ही है. जब कोई high-level सेवाओं पर निर्भर हो जाता है तो Hetzner जैसी VPS या self-hosting में शिफ्ट करना मतलब पूरी AWS stack को दोबारा install/operate करना, जो बेहद कठिन हो जाता है. सिर्फ PostgreSQL इंस्टॉल करने भर से काम नहीं चलेगा.
    • जो भी लेख VPS पर जाकर लागत घटाने की बात करते हैं, उनके नीचे अक्सर comment आता है: “AWS web-scale है इसलिए कभी नहीं गिरता, VPS तो महीने में सिर्फ एक दिन का ही uptime देता है.”
    • Amazon खुद EC2 जैसी VPS देता है; सवाल यह है कि क्या इस आउटेज में EC2 भी प्रभावित हुआ.

  • विशेषज्ञों की राय में असल फोकस तकनीक पर कम और भू-राजनीतिक संदर्भ पर ज्यादा होता है (जैसे किसी देश की पूरी सिस्टम के विदेश की कंपनियों पर रियल-टाइम निर्भरता). सामान्य कंपनी के लिए अक्सर single provider पर निर्भर रहना complexity घटाता है और outage frequency के हिसाब से भी ज्यादा बोझिल नहीं होता. ज़रूरी नहीं कि मल्टी-क्लाउड उपयोग ही किया जाए; सिर्फ एक side उपयोग करने से भी शायद डाउनटाइम frequency बेहतर हो.

    • मीडिया में दिखने वाले ऐसे विशेषज्ञ वास्तविक समस्या समाधान में योगदान नहीं देते. आम तौर पर वे तभी सामने आते हैं जब issue फट पड़ता है और headlines बनता है.

  • मुझे लगता है उद्योग-भर cloud lock-in में फँसा है. आगे इसे कैसे उलटा जा सकता है, यही बड़ा सवाल है. Docker को भी मैं बड़े cloud vendors की तरह lock-in के कारणों में से एक मानता/मानती हूँ.

    • field इंजीनियर या support टीम के नज़रिए से, जब रात 1 बजे पता चलता है कि AWS-wide failure में सब कुछ टूट गया है, कठोर सच यह है कि कोई इस स्थिति को बदलने के लिए कोशिश नहीं करेगा.
    • Docker में समस्या क्या है, यह समझ में नहीं आता.

  • मुझे क्लाउड operations छोड़े कई साल हो गए, लेकिन उस समय foundational primitives सभी providers में लगभग standardized हो चुके थे. समझ नहीं आता कि मल्टी-क्लाउड redundancy की लागत बहुत ज्यादा थी, तकनीकी gap बड़ा था, या इसे बिज़नेस की नज़र से तौलना ही शायद ज़रूरी नहीं समझा गया. pets vs cattle स्लाइड

    • कई क्लाउड पर deployment/operations टीम के perspective से बेहद अधिक संचालन और cognitive load डालता है. दो या अधिक क्लाउड इंफ्रास्ट्रकट्चर में विशेषज्ञता बनाए रखने के लिए काफी manpower चाहिए. छोटे या तेज़ी से काम करने वाले teams के लिए यह उपयुक्त नहीं. एक ही क्लाउड का सादापन सीधे uptime में मदद करता है. बड़े संगठन भी आमतौर पर एक ही cloud में bulk procurement करके बेहतर कीमत पाने में लाभ देखते हैं. और कोई सिर्फ AWS चुनने पर fired नहीं किया जाता.
    • अगर किसी अन्य cloud में भी उसी कंपनी का कोई region फेल हो जाए तो respond नहीं कर पाने की वजह से मल्टी-क्लाउड की utility कम हो जाती है. providers अब भी 100% अपने अलग-अलग standards रखते हैं और control plane लगभग सभी जगह Kubernetes ही है. अंत में सभी ने Kubernetes ही अपना लिया है.
    • सभी cloud compute सस्ते देते हैं, लेकिन network egress बेहद महँगा होता है. मल्टी-क्लाउड सेटअप करने पर traffic खर्च तेजी से बढ़ता है; लगता है शायद यह जानबूझकर सेट किया गया है.
    • लगता है कि cloud providers egress billing से ही कमाई संतुलित करते हैं. शायद इसलिए मल्टी-क्लाउड सेटअप, और यहाँ तक कि single cloud के भीतर regions और AZs के बीच redundancy भी कई cloud और applications में अत्यधिक महँगी है. single cloud में global outage होने पर region redundancy भी बेअसर हो जाती है. ऊपर से यदि एक cloud down हो तो अन्य पर traffic shift करना मुश्किल है और ROI की तुलना में labor लागत बहुत ज्यादा. अधिकांश applications के लिए बेहतर यही है कि इन कुछ घंटों की outage को स्वीकार कर बाकी खर्च और प्रयास कहीं और लगाए जाएँ.
    • कई ग्राहक cloud में files/data रखते हैं; अगर provider बदलकर किसी अलग cloud में आना पड़े तो service चलाना आसान नहीं होता और वास्तविक ग्राहक आकर्षण भी कठिन हो जाता है. जब provider खुद market standard बन जाता है और ग्राहक उसी cloud में data concentrate करते हैं, तो दोनों clouds में storage खर्च justify करना कठिन हो जाता है. मैंने भी platform-independent होने की कोशिश की थी, लेकिन वास्तविकता में जब सभी संभावित ग्राहक लगभग एक ही cloud इस्तेमाल कर रहे हैं, तो complexity कम हो जाती है.

  • इस साल पहले से यह अनुमान नहीं लगाया जा सकता था कि AWS us-east-1 शायद दो अंकों वाला “9” यानी केवल लगभग 99% uptime ही दे पाएगा.

    • AWS को करीब 20 साल से उपयोग करने वाले के तौर पर मुझे समझ नहीं आता कि सबसे ज्यादा traffic और महत्व वाली us-east-1 को ही क्यों चुना गया. यह शायद सबसे पुराना और सबसे अधिक unstable स्थान है.
    • यह भी पूछने जैसा है कि EC2 जैसी instances वास्तव में प्रभावित हुईं या नहीं.

  • सबका साथ में down होने से immunity मिल जाएगी, ऐसा सोचना गलत है; सामान्य ग्राहक-facing service के साथ यह काम नहीं करता—मेरे अनुभव में ऐसा नहीं होता.

  • इस आउटेज की जड़ में नेटवर्क लोड बैलेंसर की health check सँभालने वाली internal sub-system में fault था. AWS सेवा स्थिति पृष्ठ