अमेरिका के पूर्वी (Northern Virginia, US-East-1) रीजन में हुई Amazon DynamoDB सेवा बाधा का सार

 (aws.amazon.com)
3 पॉइंट द्वारा GN⁺ 2025-10-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 19~20 अक्टूबर 2025 को AWS N. Virginia रीजन (us-east-1) में Amazon DynamoDB सहित कई प्रमुख सेवाओं में लंबे समय तक बाधा रही
  • यह बाधा DynamoDB की स्वचालित DNS प्रबंधन प्रणाली में मौजूद एक latent race condition के कारण शुरू हुई, जिसकी वजह से गलती से एक खाली DNS record बन गया
  • इसके चलते EC2 instance creation failure, Network Load Balancer(NLB) connection errors, और Lambda·ECS·Redshift सहित कई सेवाओं में API latency और failures की श्रृंखलाबद्ध समस्या हुई
  • AWS ने समस्या की जड़ DynamoDB DNS Enactor के बीच असामान्य concurrent update conflict को बताया, और manual recovery के जरिए 20 अक्टूबर दोपहर 2:20 बजे के आसपास पूरी बहाली की
  • इस घटना ने AWS की आंतरिक automation systems के बीच interdependency की जटिलता को उजागर किया, और आगे DNS·EC2·NLB resilience मजबूत करने के लिए संरचनात्मक सुधारों के संकेत दिए

घटना का अवलोकन

  • बाधा 19 अक्टूबर 2025 को रात 11:48 बजे (PDT) शुरू हुई और 20 अक्टूबर को दोपहर 2:20 बजे (PDT) समाप्त हुई
    • प्रभाव के तीन प्रमुख चरण थे:
      1. 19 अक्टूबर 11:48PM~20 अक्टूबर 2:40AM: DynamoDB API error rate में तेज वृद्धि
      2. 20 अक्टूबर 5:30AM~2:09PM: NLB connection errors में वृद्धि
      3. 20 अक्टूबर 2:25AM~10:36AM: EC2 नए instance creation failures और network connectivity issues
  • बाधा की शुरुआत DynamoDB DNS management system की defect से हुई और यह EC2, NLB, Lambda, Redshift सहित कई सेवाओं तक फैल गई

DynamoDB बाधा का कारण और प्रभाव

  • DynamoDB की स्वचालित DNS management system में एक latent defect trigger हुआ, जिससे dynamodb.us-east-1.amazonaws.com का DNS record गलत तरीके से खाली स्थिति में update हो गया
    • यह system दो components में विभाजित है:
      • DNS Planner: load balancer की स्थिति monitor करता है और नया DNS plan बनाता है
      • DNS Enactor: Route53 पर changes apply करता है
  • तीन availability zones (AZ) में स्वतंत्र रूप से deploy किए गए DNS Enactor के बीच race condition हुई
    • पहला Enactor delay की स्थिति में पुराना plan apply कर बैठा
    • दूसरे Enactor ने latest plan apply करने के बाद पुराना plan delete किया, जिससे सभी IP addresses हट गए और system inconsistent state में चला गया
    • automatic recovery fail होने के कारण manual intervention की जरूरत पड़ी
  • रात 11:48PM पर बाधा शुरू होते ही DynamoDB पर निर्भर सभी services और customer traffic में connection failures होने लगे
    • global tables का उपयोग करने वाले ग्राहक दूसरे regions की replicas पर requests भेज सके, लेकिन replication lag हुआ
  • 12:38AM पर AWS engineers ने DNS state को root cause के रूप में पहचाना
    • 1:15AM पर अस्थायी recovery action से कुछ internal services की connectivity बहाल हुई
    • 2:25AM पर DNS information पूरी तरह restore हुई, और 2:40AM पर सभी connections सामान्य हो गए

Amazon EC2 पर प्रभाव और recovery process

  • 19 अक्टूबर 11:48PM~20 अक्टूबर 1:50PM के दौरान EC2 API error rate बढ़ी, instance creation failures हुए, और latency बढ़ी
    • पहले से चल रहे instances प्रभावित नहीं हुए
  • EC2 instance management में DropletWorkflow Manager (DWFM) और Network Manager नाम के दो sub-systems उपयोग होते हैं
    • DWFM physical servers (droplet) की state manage करता है और periodic health checks करता है
    • Network Manager instance network configuration propagate करता है
  • DynamoDB बाधा के कारण DWFM के state checks fail हुए और droplet lease expire हो गई
    • 2:25AM पर DynamoDB recovery के बाद DWFM ने reconnect करने की कोशिश की, लेकिन droplet की बहुत बड़ी संख्या के कारण congestive collapse हुआ
    • 4:14AM पर engineers ने चुनिंदा DWFM hosts restart किए ताकि queues साफ हों और recovery आगे बढ़े
    • 5:28AM पर सभी droplet leases restore हो गईं और नए instance creation फिर शुरू हुए
  • इसके बाद Network Manager ने delayed network state propagation backlog process किया, जिससे network connectivity delays हुईं
    • 10:36AM पर network propagation time सामान्य हुई
    • 11:23AM पर request throttling कम करना शुरू हुआ, और 1:50PM पर EC2 पूरी तरह recover हो गया

Network Load Balancer(NLB) पर प्रभाव

  • 20 अक्टूबर 5:30AM~2:09PM के दौरान कुछ ग्राहकों ने NLB connection errors में वृद्धि अनुभव की
    • NLB multi-tenant architecture पर काम करता है और backend EC2 instances की ओर traffic route करता है
  • बाधा का कारण network state propagation delays की वजह से health checks fail होना था
    • नए जोड़े गए EC2 instances की network configuration पूरी नहीं हुई थी, इसलिए health checks fail हुए
    • health check results अस्थिर रूप से बार-बार बदलते रहे, जिससे NLB nodes DNS से हटते और फिर लौटते रहे
  • 6:52AM पर monitoring system ने समस्या detect की और engineers ने response शुरू किया
    • health check subsystem पर load बढ़ने से automatic AZ DNS failover हुआ
    • 9:36AM पर automatic failover disable करने के बाद सभी healthy nodes वापस आए
    • 2:09PM पर EC2 recovery के बाद automatic failover फिर enable किया गया

अन्य AWS services पर प्रभाव

  • AWS Lambda:
    • 19 अक्टूबर 11:51PM~20 अक्टूबर 2:15PM के दौरान API errors और latency
    • DynamoDB बाधा के कारण function creation·update failures, और SQS/Kinesis event processing delays
    • 7:04AM पर NLB health check failures की वजह से internal systems scale down हुए और asynchronous invocations पर limits लगीं
    • 2:15PM पर सभी backlog process होकर service सामान्य हुई
  • ECS, EKS, Fargate:
    • 19 अक्टूबर 11:45PM~20 अक्टूबर 2:20PM के दौरान container launch failures और cluster scaling delays
  • Amazon Connect:
    • 19 अक्टूबर 11:56PM~20 अक्टूबर 1:20PM के दौरान call·chat·case processing errors
    • DynamoDB recovery के बाद अधिकांश functions सामान्य हुईं, लेकिन 7:04AM के बाद NLB और Lambda के प्रभाव से फिर errors आईं
    • 1:20PM पर पूरी recovery
  • AWS STS:
    • 19 अक्टूबर 11:51PM~20 अक्टूबर 9:59AM के दौरान authentication API errors और latency
    • DynamoDB recovery के बाद अस्थायी सामान्यीकरण हुआ, लेकिन NLB समस्या से फिर errors आईं
  • IAM login और Identity Center:
    • 19 अक्टूबर 11:51PM~20 अक्टूबर 1:25AM के दौरान authentication failures में वृद्धि
    • DynamoDB recovery के बाद सामान्य
  • Amazon Redshift:
    • 19 अक्टूबर 11:47PM~20 अक्टूबर 2:21AM के दौरान query और cluster modification failures
    • DynamoDB recovery के बाद भी कुछ clusters EC2 बाधा के कारण असामान्य रहे
    • 21 अक्टूबर 4:05AM पर पूरी recovery
    • IAM API dependency के कारण global regions में भी अस्थायी query failures हुए
  • अन्य सेवाएँ:
    • Managed Workflows for Apache Airflow, Outposts, AWS Support Center आदि भी प्रभावित हुए

बाद की कार्रवाई और सुधार योजना

  • DynamoDB DNS Planner और Enactor automation को पूरी तरह disable किया गया है; दोबारा enable करने से पहले race condition fix और safeguards जोड़े जाएंगे
  • NLB: health check failure के समय किसी एक NLB द्वारा हटाई जा सकने वाली capacity को सीमित करने के लिए rate control mechanism जोड़ा जाएगा
  • EC2:
    • DWFM recovery workflow सहित नया test suite बनाया जाएगा
    • data propagation system में smart throttling improvements के जरिए queue size के आधार पर request limiting जोड़ी जाएगी
  • AWS पूरे service ecosystem की interdependency analysis के जरिए recovery time घटाने और ऐसी घटनाओं की रोकथाम के अतिरिक्त उपायों की समीक्षा कर रहा है

निष्कर्ष और माफ़ी

  • AWS ने इस घटना से ग्राहकों पर पड़े प्रभाव के लिए आधिकारिक माफ़ी मांगी
  • कंपनी ने माना कि वह सामान्यतः अपनी services की high availability बनाए रखती रही है, लेकिन इस बार की बाधा ने ग्राहकों के business पर गंभीर प्रभाव डाला
  • AWS ने इस घटना से सीख लेकर automation systems की resilience और incident response procedures को और मजबूत करने का वादा किया

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

2 टिप्पणियां

 
shakespeares 2025-10-26

सुना है कि यह senior कर्मचारियों को निकालने के बाद का असर है.. क्या यह सही है?
 
GN⁺ 2025-10-24
Hacker News राय

  • मैं इस विषय पर हमेशा एक ही बात दोहराने वालों में से हूँ। अगर आपने अभी तक Richard Cook का लेख नहीं पढ़ा है, तो इस postmortem को अभी रोककर पहले How Complex Systems Fail पढ़ने की सलाह दूँगा। जटिल सिस्टम failures पर यह सबसे बेहतरीन तकनीकी लेखों में से एक है। Cook खुद “root cause” जैसी अवधारणा को ही अस्वीकार करते हैं, और इस घटना में भी मुझे लगता है कि वे सही हैं

    • Cook का लेख अच्छा है, लेकिन सच कहूँ तो यह सहज दावों की एक सूची जैसा लगता है। उसे सच में गहराई से समझने के लिए शायद उसकी references भी पूरी पढ़नी होंगी। MIT की systems class 6.033 में भी इसी तरह के विषय पर 1962 का paper और एक दूसरा क्लासिक paper पढ़ाया जाता है। मुझे लगता है कि ऐसे मुद्दे आखिरकार ‘Wicked problem’ स्तर की जटिलता तक पहुँच जाते हैं
    • Cook के लेख में जो बात मुझे खास लगी, वह यह थी कि दुर्घटना के बाद सिस्टम को “ज़्यादा सुरक्षित” बनाने की कोशिश उल्टा सुरक्षा को कम भी कर सकती है। मानवीय गलती रोकने के उपाय सिस्टम की coupling और complexity बढ़ा देते हैं, जिससे संभावित failure points बढ़ते हैं और detection तथा prevention और मुश्किल हो जाते हैं
    • एक और दृष्टिकोण ‘Normal Accidents’ सिद्धांत का है। इसका तर्क है कि जैसे-जैसे components आपस में ज़्यादा tightly coupled होते हैं, interactions जटिल होते जाते हैं, और failure के परिणाम गंभीर होते हैं, सिस्टम स्वभावतः ज़्यादा जोखिमपूर्ण हो जाता है। Normal Accidents wiki देखें
    • मैंने दोनों दस्तावेज़ पूरे नहीं पढ़े हैं, लेकिन मैं इस बात से सहमत नहीं हूँ कि सिर्फ सिस्टम जटिल है, इसलिए failure का root cause तय ही नहीं किया जा सकता। खेल में भी स्कोर कई कारकों का नतीजा होता है, लेकिन अंत में ‘स्कोरर’ होता है। व्यापक नज़रिया अच्छा है, लेकिन मुख्य कारण की पहचान भी व्यावहारिक है
    • मैं oncall करने वाला एक contractor हूँ। ज़्यादातर कंपनियाँ oncall को गंभीरता से नहीं लेतीं। documentation भी कम होती है, और दूसरों का जटिल code पढ़ने के लिए समय भी नहीं दिया जाता। AWS जैसी ऐसी culture का अनुभव करना चाहूँगा जहाँ oncall को सीखने और जिम्मेदारी का हिस्सा माना जाता हो

  • इंटरनेट धीरे-धीरे एक केंद्रीकृत single network (mononet) में बदल रहा है। शीत युद्ध के दौर में एक distributed network के रूप में जन्मा इंटरनेट अब ऐसी संरचना बन गया है जहाँ एक deployment mistake से दुनिया भर की banking, shopping और travel रुक सकती है। cloud metaphor अब अपनी सीमा पार कर चुका है।
    startup या R&D के लिए यह अभी भी उपयोगी है, लेकिन growth-stage कंपनियों या सरकारों के पास अपने server, अपना cloud, अपनी core services होनी चाहिए। तकनीक और लोग दोनों पर्याप्त हैं

  • AWS के postmortem में सटीक timeline visualization प्रभावशाली लगी। GDC की मशहूर talk “I Shot You First” की तरह, समय के प्रवाह को तिरछे arrows से दिखाते हुए “delay कहाँ हुआ?” पूछने का तरीका उपयोगी था।
    लेकिन मुझे उससे भी ज़्यादा हैरानी इस बात पर हुई कि EC2 node lease management service के लिए recovery procedure (runbook) था ही नहीं। AWS की core service के लिए तो लगा था कि लगभग हर exceptional स्थिति की तैयारी होगी

    • ऐसी स्थिति से डरना नहीं चाहिए, बल्कि इसे complex systems का अंतर्निहित pattern मानना चाहिए। संभावित failures fractal की तरह हर स्तर पर मौजूद होते हैं, और हर संभव स्थिति के लिए runbook होना असंभव है

  • इस घटना का सार मुझे DNS system की cache invalidation समस्या के एक रूप जैसा लगता है। दो DNS Enactor अलग-अलग timing पर plan apply कर रहे थे, जिससे race condition बना, और पुराने plan ने नए plan को overwrite कर दिया

    • यह सिर्फ आम पाठकों के लिए समझाने का तरीका है; असल में अंदरूनी स्तर पर incident resolve होने के बाद recurrence risk assessment और mitigation (runbook) तैयार करना होता है। फिर संगठन-स्तर पर learning और sharing होती है
    • मेरी नज़र में यही race condition खुद root cause थी। अगर वह bug न होता, तो यह incident नहीं होता
    • DNS Planner और Enactor को अलग क्यों किया गया, यह सवाल है। अगर यह एक ही service होती, तो ऐसी contention state शायद अधिक स्पष्ट दिखती। हो सकता है यह microservices के अति-उपयोग से बढ़ी complexity का नतीजा हो
    • मुझे एक मिलती-जुलती समस्या का अनुभव है, जहाँ कारण JVM GC delay और खराब hardware था। यहाँ भी वैसी संभावना हो सकती है
    • लेकिन AWS ने यह स्पष्ट नहीं किया कि अगर ऐसा delay फिर से हो, तो उसके लिए preventive measure क्या है

  • Enactor को नया value apply करने से पहले मौजूदा record का version compare (CAS) करना चाहिए था। efficiency थोड़ी कम होती, फिर भी यह एक बुनियादी safety mechanism है। शायद यह DynamoDB के भीतर ही handle किया जा सकता था

  • यह पढ़कर हैरानी हुई कि DynamoDB region के हिसाब से DNS के लाखों records manage करता है। dynamodb.us-east-1.amazonaws.com का resolution अगर लाखों IP तक जा सकता है, तो यह Route53 की सीमाओं से आगे की चीज़ लगती है। शायद कम TTL रखकर हर बार सिर्फ कुछ हिस्से update किए जाते होंगे

    • वास्तव में AWS DNS ऐसे ही काम करता है। Route53 resource record set (RRSet) यूनिट पर काम करता है, और health checks या latency-based selection logic के माध्यम से उपयुक्त set लौटाता है
    • CDN भी इसी तरह काम करते हैं। वे system metrics इकट्ठा करके हर network के लिए optimal PoP निकालते हैं। bunny.net SmartEdge इसका अच्छा उदाहरण है
    • मैंने भी S3 के साथ test किया था, और कुछ ही सेकंड में सैकड़ों अलग-अलग IP मिले। एक ही region में भी इतनी विविधता होती है

  • bugs हमेशा रहेंगे। formal verification कठिन है, और कम संभावना वाले bugs कई साल बाद फट सकते हैं।
    इसलिए यह मानकर सिस्टम डिजाइन करना चाहिए कि failure होगा ही, और नुकसान सीमित करने वाली संरचना बनानी चाहिए। cell-based architecture, gradual rollout, और isolated zones इसके उदाहरण हैं।
    AWS भी cell-based तरीका अपनाने की कोशिश करता है, लेकिन खासकर us-east-1 में अभी भी legacy cross-dependencies मौजूद हैं। लंबी अवधि में regions को पूरी तरह स्वतंत्र रूप से design किया जाना चाहिए।
    इस तरह का काम senior executive support के बिना आगे नहीं बढ़ता, लेकिन shareholder के नज़रिए से यह कंपनी के अस्तित्व के जोखिम को घटाने वाला अहम निवेश है

  • रिपोर्ट में UTC की जगह PT timezone का इस्तेमाल देखना अप्रत्याशित था

    • “epoch fail?” जैसा मज़ाक बन सकता है, लेकिन ज़्यादातर customers अगर अमेरिका-आधारित हैं तो PT उन्हें ज़्यादा सहज लग सकता है
    • शायद इसका मकसद रात के incident response की कठिनाई को उभारना भी रहा हो

  • यह देखकर आश्चर्य हुआ कि per-endpoint versioning या 2PC, single writer lease जैसे patterns नहीं थे। फिर भी AWS ने इसे इतने पारदर्शी तरीके से सार्वजनिक किया, यह सराहनीय है

    • वास्तव में DNS change API CAS करती है, लेकिन कई asynchronous writers logical ordering के बिना आपस में प्रतिस्पर्धा कर रहे थे, जिससे समस्या हुई। ordering को serialize करने के लिए zone serial या sentinel record का उपयोग होना चाहिए था

  • मेरे हिसाब से इस incident का प्रत्यक्ष कारण DynamoDB DNS management system में मौजूद एक latent race condition था। पुराने plan ने नए plan को overwrite कर दिया, जिससे regional endpoint के DNS records खाली हो गए

    • लेकिन “root cause” जैसी अवधारणा के साथ सावधानी ज़रूरी है। यह एक metastable collapse था, और असली केंद्रीय समस्या recovery procedure (runbook) की अनुपस्थिति थी।
      संदर्भ: How Complex Systems Fail