us-east-1 क्षेत्र में AWS की कई सेवाओं में आउटेज हुआ

 (health.aws.amazon.com)
1 पॉइंट द्वारा GN⁺ 2025-10-21 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS के us-east-1 रीजन में मौजूद विभिन्न सेवाओं में आउटेज दर्ज हुआ
  • इस आउटेज के कारण क्लाउड इंफ्रास्ट्रक्चर का उपयोग करने वाली कंपनियों ने सेवा बंद होने की स्थिति झेली
  • API Gateway, Lambda जैसी मुख्य सेवाओं में उपलब्धता (availability) से जुड़ी समस्याओं की रिपोर्ट मिली
  • इंजीनियरों ने वैकल्पिक मार्ग (workaround) तैयार करने और आपातकालीन प्रतिक्रिया रणनीति पर पुनर्विचार की जरूरत पर जोर दिया
  • AWS Health Dashboard के जरिए वास्तविक समय में आउटेज की स्थिति और अपडेट उपलब्ध कराए गए

AWS us-east-1 रीजन में आउटेज का सारांश

  • 2025-10-21 को AWS Health Dashboard पर जानकारी दी गई कि us-east-1 रीजन से जुड़ी कई सेवाओं में आउटेज हुआ
  • खास तौर पर API Gateway, Lambda, S3 जैसी महत्वपूर्ण सेवाएँ प्रभावित हुईं, जिससे कई ग्राहकों ने सेवा व्यवधान (downtime) का अनुभव किया
  • आउटेज शुरू होने के तुरंत बाद AWS ने घटना को पहचानकर रूट कॉज़ एनालिसिस और रिकवरी कार्य शुरू कर दिए
  • इस रीजन पर निर्भर SaaS, स्टार्टअप और IT कंपनियों में सेवा में देरी और डाउनटाइम की रिपोर्ट मिली
  • इंजीनियर और IT मैनेजरों ने आपातकालीन फेलओवर पथ बनाने तथा क्रिटिकल सेवाओं के लिए रीजन मल्टीप्लिकेशन/मल्टी-रीजन स्ट्रैटेजी की जरूरत पर जोर दिया

प्रभाव और प्रतिक्रिया

  • us-east-1 रीजन, वैश्विक क्लाउड इंफ्रास्ट्रक्चर में सबसे अधिक ट्रैफिक वाले क्षेत्रों में से एक है, इसलिए किसी भी आउटेज का प्रभाव काफी व्यापक हो सकता है
  • अलग-अलग ग्राहक संगठनों में एक साथ सेवा बंदी, API response delay, डेटा प्रोसेसिंग समस्या जैसी स्थितियाँ देखी गईं
  • AWS ने Health Dashboard के माध्यम से स्थिति की लाइव अपडेट, सहायता दस्तावेज़ और आगे की जानकारी साझा की
  • ग्राहक कंपनियों की IT टीमें आउटेज मॉनिटरिंग, अस्थायी फेलओवर और उपयोगकर्ताओं को सूचित करने के जरिए नुकसान कम करने की कोशिश कर रही हैं

इंजीनियरों के लिए निष्कर्ष

  • आउटेज की स्थिति ने मॉनिटरिंग सिस्टम और अलर्टिंग फ्रेमवर्क की अहमियत फिर से रेखांकित की
  • मल्टी-रीजन डिप्लॉयमेंट, स्वचालित incident response, बैकअप रणनीतियों जैसी resilient architecture डिजाइन की जरूरत और स्पष्ट हो गई
  • AWS Health Dashboard का उपयोग इस दौरान तेजी से स्थिति समझने और निर्णय लेने के लिए एक महत्वपूर्ण स्रोत के रूप में हुआ

निष्कर्ष

  • हर बड़े क्लाउड सेवा प्रदाता को संभावित सेवा आउटेज के लिए पहले से तैयारियाँ करनी चाहिए
  • घटना के समय तेज़ रिकवरी, पारदर्शी कम्युनिकेशन और असरदार इंफ्रास्ट्रक्चर फॉल्ट-रिस्पॉन्स क्षमता का महत्व फिर सामने आया

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

1 टिप्पणियां

 
GN⁺ 2025-10-21
हैकर न्यूज़ टिप्पणी
  • आज का दिन वाक़ई बहुत दिलचस्प था। मैं रात 3 बजे से इंसीडेंट-रिस्पॉन्स ब्रिज पर मौजूद था। सिस्टम का ज्यादातर हिस्सा रिकवर हो चुका है, लेकिन बैकऑफिस टीम अभी भी संसाधन की कमी से जूझ रही है। हमारी बड़ी गलती यह थी कि हमने मल्टी-रीजन फेलओवर के लिए डिज़ाइन तो कर लिया, लेकिन वास्तविक फेलओवर प्रक्रिया चला ही नहीं सके। वजह यह कि सिक्योरिटी टीम ने हमें Identity Center पर शिफ्ट कर दिया और उसे सिर्फ us-east-1 में रखा, जिससे कंपनी का पूरा ऑपरेशन्स सेटअप AWS कंट्रोल प्लेन में पूरी तरह लॉक-इन हो गया। जब रूट क्रेडेंशियल वॉल्ट से निकाले, तब सिस्टम लगभग रिकवर हो चुका था। इस घटना ने फिर याद दिलाया कि किसी भी मजबूत सिस्टम की कुल मजबूती एक कमजोर कड़ी पर निर्भर होती है।
    • कुछ साल पहले गूगल के पेरिस डेटा सेंटर में बाढ़ के बाद लगी आग का मामला याद आया। हमने सीधे वहीं compute संसाधन नहीं रखे थे, लेकिन हमारा रनिंग वर्कलोड AWS EU डेटा सेंटर पर था और Google सेवाओं के लिए DNS resolver पेरिस में होस्ट था, इसलिए ट्रैफिक प्राथमिकता से पेरिस की ओर route हो रहा था। जुगाड़ का समाधान काफी मज़ेदार था। उसी समय पता चला कि Kubernetes में deployed /etc/hosts file को ग्लोबली आसान तरीके से बदल सकते हैं, और सच में इतनी मजबूरी आ गई कि यही करना पड़ा। सामान्यतः हम इस मकसद के लिए /etc/hosts नहीं इस्तेमाल करते, लेकिन टेम्पररी पैच के लिए यह ठीक-ठाक abstraction निकला।
    • Facebook में एक बार BGP अपडेट की गलती से vault access पूरी तरह असंभव हो गया था, वैसा केस याद आता है। अगर auth path cyclic हो और DNS एक बार गिर जाए तो कुछ भी नहीं कर सकते।
    • अंततः किसी को हार्डवेयर टोकन लेकर दूसरी जगह/डेटा सेंटर फ्लाइट से जाना पड़ा ताकि पूरे ग्लोबल सिस्टम को फिर चालू करने वाला crucial device reset किया जा सके।
    • सुनने में आया कि Identity Center केवल us-east-1 में रखा गया था—जिज्ञासा है कि क्या इसे कई regions में deploy किया जा सकता है? आख़िरी बार मैंने जो चेक किया था, वह केवल एक ही रीजन में संभव था और relocate करने के लिए पहले delete करना पड़ता था।
    • ज़्यादा सुरक्षा-दीवारें अक्सर agility को रोक देती हैं। पता नहीं सिक्योरिटी टीम इस incident की जवाबदेही लेगी भी या नहीं। लगता है आगे हर प्रोजेक्ट धीमा हो जाएगा। टीम ने अब तक शायद बहुत ओवर-स्पीड चलना जारी रखा था। और सवाल यह भी है कि गार्ड पर गार्ड की नज़र कौन रखता है।
  • लगता है मुख्य आउटेज अभी जारी है; स्थिति चार घंटे पहले की तुलना में और खराब दिख रही है। मैं data engineer हूँ और Redshift तथा Airflow (AWS managed service) पूरी तरह गड़बड़ा गए हैं।
    • आउटेज काफी लंबा खिंच गया है, और अब सोचता हूँ कितने '9' खत्म हुए। 365 दिन × 24 घंटे × 0.0001 करने पर लगभग 8 घंटे आते हैं, यानी 99.99% availability पहले ही जा चुकी है।
    • अभी भी समझ नहीं आता कि इतनी कंपनियाँ us-east-1 पर ही क्यों अटकी हुई हैं। अगर outage frequency के हिसाब से देखें तो यह साफ़ तौर पर सबसे खराब विकल्प है। हमारी कंपनी ने पहले ही तय कर लिया था कि हम us-east-1 avoid करके बाकी regions में ही चलेंगे। हाँ, अगर सर्विस को 'global' कहा जाता है तो कई बार व्यावहारिक रूप से मतलब ही us-east-1 हो जाता है, और तब काम नहीं आता।
    • Lambda create-function का control-plane ऑपरेशन अभी भी InternalError दे रहा है। अन्य सेवाएँ (Lambda, SNS, SQS, EFS, EBS, CloudFront) रिकवर हो चुकी हैं। मैं cloud availability पर अपना CS master's research कर रहा हूँ, इसलिए कई AWS test accounts में रन करके मैंने outage timeline और impact नोट किए हैं। विश्लेषण पोस्ट
    • Down Detector दिखा रहा है कि AWS आउटेज अभी भी गंभीर है। Amazon की तरफ़ से 'service is getting restored' का बयान आ रहा है, लेकिन वास्तविकता में Amazon.com पर भी product search नहीं चल रहा। AWS हेल्थ पेज
    • Down Detector के हिसाब से 12:52 AM Pacific (3:53 Eastern) पर AWS incident reports 5,755 थे; 4:22 AM Pacific (7:22 Eastern) पर 1,190 पर गिर गए, और 9:32 AM Pacific (12:32 Eastern) पर फिर 9,230 पर तेज़ी से चढ़ गए। हो सकता है West US जागने पर रिपोर्टें बढ़ी हों, लेकिन लगता है AWS अभी स्थिति को पूरी तरह कंट्रोल नहीं कर पाया है।
  • यह आउटेज सीधे मेरे रोज़मर्रा पर असर डाल रहा है। New York Hudson Yards Whole Foods में चॉकलेट बार खरीदने गया था, लेकिन prime discount लागू नहीं हुआ—तो मैंने नहीं खरीदा; अब मेरा चॉकलेट स्टॉक बहुत कम है।
    • आज सुबह "alexa, कॉफी मशीन चालू करो" भी नहीं हुआ; दिमाग सुन्न-सा हो गया।
    • लंच में Hotbar से खाना डालकर self-checkout करने गया था, और कुछ देर तक समझ नहीं आया कि Whole Foods का barcode क्यों काम नहीं कर रहा। लगभग 20 सेकंड बाद समझ आया कि यह outage की वजह से है।
    • बढ़िया केस शेयर करने के लिए बढ़िया लगा। लेकिन इसी मौके पर सोचता हूँ कि जब AWS आउटेज हो तो Amazon Go में मौजूद लोग कैसे manage कर रहे होंगे?
  • आज AWS account owner से मीटिंग है। आगे मैं समझाऊँगा कि हम “All in on AWS” से बाहर निकल कर workloads को spread करने की रणनीति क्यों चाहते हैं। मुख्य कारण ये हैं: core services की innovation धीमी हो गई है और AI services भी competitors की तुलना में पीछे छूट रही हैं। AWS टीम हमेशा कहती रही कि AWS ultra stable है, इसलिए multi-cloud या workload distribution मत करो। आज की मीटिंग का इंतज़ार है।
    • AWS, Cloudflare, Google Cloud, Akismet—किसी में भी कभी न कभी outage आता ही है। हर बार ऐसा होता है तो इन-house hosting पर वापस जाने का भी ख्याल आता है। आख़िरकार वही मॉडल और खर्च के साथ फिर ऑपरेट करना होता है—आउटपुट लगभग वही रहता है, तो शायद अतिरिक्त कोशिश की ज़रूरत नहीं।
    • पिछले earnings call में जब Andy Jassy पर यह criticism आया कि AWS innovation में पीछे है, तो जवाब में उन्होंने reliability, resilience और durability को सामने रखा। लेकिन अभी की स्थिति देखकर यह बहाना नहीं चलता।
    • us-east-1 को छोड़ दें तो बाकी regions काफी stable तरीके से चल रहे हैं। हमारी कंपनी का अधिकतर workload भी सिर्फ eu-west-1 पर है और वह बिना खास समस्या के ठीक चल रहा है।
    • AWS धीरे-धीरे decline में है। अभी तो बस existing services को ही maintain रखने की कोशिश लगती है। शायद innovative लोग अंदरूनी bureaucracy और performance pressure में दब गए हैं, और AI side में भी पीछे जा रहे हैं।
    • AWS की 'बहुत स्थिर' होने वाली claim शुरुआत से ही पूरी तरह सच नहीं थी। मैंने पहले कई क्लाउड और निजी servers से मिलाकर multi-cloud monitoring सेट किया था, जहाँ तुरंत दिख जाता था कि पहले कौन-सा गिरता है। नतीजे में AWS हमेशा first नहीं था; netcraft.com के डेटा से लगभग मेल खाता था।
  • आज की Premier League में VAR और automatic offside decision system भी AWS outage की वजह से सीमित रूप से ही चलने वाले हैं। सच में अजीब ज़माना है। BBC लिंक
    • क्लाउड आउटेज में भी एक छोटी-सी positive thing देखी जा सकती है।
  • यदि primary region us-east-1 हो, तो outage में एक साथ सभी सेवाएँ down होंगी—कोई अकेला परेशान नहीं होगा। यूएस के अन्य regions में यह privilege नहीं मिलता।
    • जब हमने पहले on-prem से AWS migrate किया था, एक unexpected benefit यह था कि जब कोई एक पूर्ण region ही गिर जाए तो customers ज्यादा समझदारी दिखाते हैं; सब एक साथ परेशान होने पर शिकायतें comparatively कम कठोर लगती हैं।
    • कभी-कभी हर किसी को technical downtime का taste लेना पड़ता है।
    • ठीक है, चलो हम सब अपनी infrastructure US-East-1 पर डाल देते हैं।
    • किसी enterprise में वास्तविकता में क्या वास्तव में मायने रखता है, यह समझने में वक्त लगता है। अक्सर availability से ज्यादा “किसी को blameable बनाना” ज़्यादा practical होता है। अगर इंसानी भूल से साल में 5 मिनट का डाउनटाइम हो तो CTO responsible माना जाता है, लेकिन AWS outage से 5 घंटे बंदी पर सबको बस असुविधा होती है, इसलिए इसे 'forced' या 'unavoidable' मान लेते हैं। AWS, Crowdstrike जैसी कंपनियों में आख़िरकार robustness, cost efficiency या risk management से ज्यादा यह सच है कि बाकी लोग भी साथ में परेशान हैं। असुविधाजनक सच्चाई है, पर यही हक़ीक़त है; जो तकनीक को smooth देखना चाहते हैं, उनके लिए irritate करने वाली।
    • Tokyo region अभी ठीक चल रहा है! बस console login जैसी कुछ functionalities में अभी भी issue है।
  • “जांच के दौरान पता चला कि US-EAST-1 में DynamoDB API endpoint की DNS resolution समस्या के आसपास मामला है। हम recovery को accelerate करने के लिए parallel path से काम कर रहे हैं” ऐसा कहा गया था। और हाँ, culprit शायद DNS ही रहा।
    • देखना है कि यह सचमुच DNS resolution की समस्या थी या DNS server की अंदरूनी सेटिंग/डाटा स्टोर की गड़बड़ी। लगता है दूसरा कारण ज्यादा likely है।
    • बाद की outage नोटिस में network load balancer failure को कारण बताया गया। DNS शायद root cause का symptom था—यह केवल प्रभाव था। DNS ने health checks खराब किए हों, संभव है, लेकिन मेरा अंदाज़ा है कि मुख्य कारण network side का था।
    • ऐसा भी हो सकता है कि BGP ने DNS issue का रूप ले लिया हो।
    • कारण हमेशा us-east-1 ही निकलता है।
    • DNS न भी हो, तो आखिरकार DNS ही होता है।
  • अच्छा, resilience को ध्यान में रखकर हमने जो डिज़ाइन किया था, वह काम आ रहा है। हमने CloudFront से multi-region static site origins सेट किए थे, इसलिए इस outage का कोई प्रभाव नहीं पड़ा। control plane भी native multi-region design पर है, इसलिए कई services पर depend करते हुए भी availability बनी रही। प्रत्येक region independently काम करता है; data replication होती है लेकिन us-east-1 replication न हो तब भी फर्क नहीं पड़ता। सेवा खुद मल्टी-रीजन संरचना में है और failover DNS, routing तथा destination selection के कई layers पर handle करती है। यह तरीका पूर्ण नहीं है और fail points भी कई हैं, पर इस बार ठीक चला। जो मैंने किया वो कोई rocket science या महँगा काम नहीं था, बस अलग approach था। कोई भी सवाल हो तो पूछिए।
    • CloudFront से multi-region static origin रखकर outage से बचना—2025 में यह baseline हो जाना चाहिए—लेकिन अभी भी इसकी तारीफ हो रही है।
    • क्या यह active/active setup है, और data stack कैसा है—जिज्ञासा है। लगता है यही हिस्सा मुश्किल होता है।
    • keys और certificates के लिए resilient auth आपने कैसे implement किया?
  • एक बड़ा मुद्दा यह भी रहा कि IAM/auth stack के ओवरलोड/डाउन होने से cascade failures बने। सुनने में आया कि कारण शायद DynamoDB था; देखना था कि IAM अंदर से कहीं Dynamo पर rely करता है या नहीं। बड़े/complex distributed systems में dependencies उलझी हुई होती हैं, इसलिए Auth/IAM का global single point-of-failure बनना आसान है—इसलिए dependency कम करना बेहतर लगेगा। पर scalability और consistency जैसी आवश्यकताएँ भी हैं, इसलिए verified DB ही लेनी पड़ती है। आख़िरकार, जब कोई चीज़ डाउन होती है तो bootstrap path बेहद जटिल हो सकता है; ऐसा लगता है कि तब सिस्टम को कठिन क्रम से शुरू करना पड़ता है। कैसे handle करते हैं, पूछना चाहूँगा।
    • करीब 2017 के आसपास DynamoDB outage में बड़ा डाउनटाइम हुआ था। EC2 ने server list DynamoDB में रखी थी; जब DynamoDB नीचे गया तो EC2 भी गिर गया। ऊपर से DynamoDB खुद EC2 पर चल रहा था, इसलिए नए EC2 instances उठाकर recovery भी नहीं कर पाए—कुछ दिन manual instance restart करके recover करना पड़ा। तब से हमने S3, DynamoDB, EC2 जैसी tier-1 systems के बीच dependencies अलग करने की कोशिश की। साफ़, पूर्ण अलगाव फिर भी आसान नहीं।
    • कई AWS ग्राहक गलत retry policies के कारण एक घटक के outage में दूसरा भी overload कर देते हैं। DynamoDB outage का असर IAM तक बढ़ गया।
    • Amazon के अंदर अलग से Dynamo नाम का KV-store platform भी है, जो DynamoDB से अलग है। इसलिए कारण DNS routing या node rollout से भी हो सकता है। ऐसे मुद्दे बड़े postmortems में बार-बार दिखते हैं।
    • जब मैं Amazon में काम करता था, तब IAM Dynamo पर निर्भर नहीं था। अब पता नहीं बदल गया है या नहीं—पक्का नहीं कह सकता। लगता है बड़े network issue की वजह से spillover ज्यादा संभव है। Auth/IAM का global single point नहीं होना चाहिए, इसलिए architecture इसी दिशा में dependencies कम रखती है। IAM के पास प्रत्येक region में अपना read-only cache है और AWS SigV4 भी region-wise काम करे इस हिसाब से designed है। (reference doc)
    • हाल ही के GCP outage के कारण में भी यही pattern दिखना दिलचस्प है।
  • AWS ने 3:03AM PT पर बताया कि वह recovery कर रहा है, लेकिन स्थिति उलटे और खराब हो गई। 9:13AM PT तक फिर कहा कि root cause analysis अभी चल रहा है। AWS को भी exact कारण पता नहीं लग रहा दिखता है, जो चिंता वाली बात है।
    • शायद इसलिए भी कि यह दिवाली के हफ्ते के आसपास हो रहा है और कुछ भारत के इंजीनियर छुट्टी पर हैं। सच में टाइमिंग बहुत खराब है।