AWS अनुमानित बिल 1.7 अरब डॉलर दिखा रहा है, जबकि सामान्य उपयोग शुल्क 5 डॉलर से कम है

• जिस AWS अकाउंट का सामान्य उपयोग शुल्क 5 डॉलर से कम है, उसमें इस महीने का अनुमानित बिल 1.7 अरब डॉलर दिखाया गया
• वास्तविक उपयोग और बिल राशि के बीच अंतर बहुत ज़्यादा होने के कारण इसे अनुमानित बिलिंग डेटा के गलत होने की स्थिति माना जा रहा है
• पोस्ट करने वाले ने समस्या की पुष्टि और प्रतिक्रिया के लिए तत्काल AWS support ticket बनाया
• AWS सेवा की स्थिति AWS Health Dashboard में देखी जा सकती है
• यह भी पूछा गया कि क्या अन्य उपयोगकर्ताओं को भी यही समस्या हो रही है, और बाद में संबंधित Reddit पोस्ट भी जोड़ी गई

---

असामान्य अनुमानित बिल

• इस महीने का AWS अनुमानित बिल 1.7 अरब डॉलर दिखाया गया, जबकि उस अकाउंट का सामान्य उपयोग शुल्क 5 डॉलर से कम है
• पोस्ट करने वाले का मानना है कि इतना बड़ा अंतर वास्तविक उपयोग के कारण नहीं, बल्कि गलत अनुमानित बिलिंग डेटा के कारण है

पुष्टि और प्रतिक्रिया

• समस्या की पुष्टि के लिए तत्काल AWS support ticket बनाया गया
• सेवा की स्थिति AWS Health Dashboard में देखी जा सकती है
• अन्य उपयोगकर्ताओं से पूछा गया कि क्या उन्हें भी यही समस्या हुई है, और बाद में संबंधित Reddit पोस्ट साझा की गई

[GN⁺]

Hacker News की राय

• मैंने AWS में ऐसी ही एक गलती संभाली थी, वजह unit configuration error थी। GB पर करीब 5 cents चार्ज करने की कोशिश थी, लेकिन pricing plan में GB छूट गया तो system ने default unit यानी byte मान लिया, और byte पर 5 cents लगने लगे; कुछ ही घंटों में कुछ customers को मिलियन डॉलर के bills दिखने लगे
  रात करीब 2 बजे support team से call आया, 3–4 बजे तक fix और billing corrections पूरी हो गईं, और तुरंत apology email भी भेज दिया गया। Service जो usage value emit करती है, वह सीधे price से नहीं जुड़ी होती; हर SKU या billing item को pricing plan से define किया जाता है, जिसमें unit type, region और per-unit price शामिल होते हैं। Account ID, region, SKU आदि के आधार पर usage records और pricing plan को combine किया जाता है, इसलिए unit type गलत specify हो जाए तो conversion टूट जाता है और बेहूदा billing amount निकल आता है

  • क्या tests नहीं थे? मतलब एक मामूली-सी दिखने वाली detail गलत configure हो जाए तो लाखों admins को रात की emergency call और heart attack मिल सकते हैं?
    हां, आप जरूर कहेंगे “यह मामूली detail नहीं है, Michael!”: https://www.youtube.com/watch?v=3fGHaVn5rGo
  • मुझे हैरानी है कि क्या AWS billing system अब भी data transfer के लिए CSV files इस्तेमाल करता है। करीब 10 साल पहले AWS में अपनी पहली on-call duty के दौरान, किसी “smart” engineer ने production data के description field में “अगर इस field में comma डालें तो क्या होगा” जैसा experimental record डाल दिया, जिससे billing processing टूट गई
    वह record फैलता गया और मैंने देखा कि regions एक-एक कर उसी तरह fail होते गए; एक व्यक्ति ने बहुत सारे लोगों की शाम खराब कर दी। Test endpoint इस्तेमाल किया जा सकता था, लेकिन मूल रूप से उसने production में test कर दिया
  • यह मजाक में टालने वाली बात नहीं है। अगर किसी को cardiovascular disease जैसी underlying condition हो और अचानक ऐसा bill दिख जाए, तो anxiety, shock और helplessness की वजह से वास्तविक रूप से मौत भी हो सकती है
  • बेवकूफाना defaults चुनने के बजाय हमेशा fail loud बनाने की वजह यही है
  • सोच रहा हूं कि क्या यह वही दिन था जब gp3 EBS volume launch हुआ था

• मुझे लगातार तीन warning emails मिले कि budget 18 डॉलर की limit पार कर गया है; check किया तो cost 78 million dollars थी। पहले लगा phishing है, इसलिए actual account में directly login किया, लेकिन वहां भी 78 million dollars ही था, तो काफी बड़ा मानसिक झटका लगा

  • शर्त लगानी है कि क्या आज के अंदर इस job posting का description बदलेगा: “Software Development Engineer II, AWS Invoicing”
    https://www.amazon.jobs/de/jobs/10428480/software-developmen...
    इसमें generative AI, large language models, knowledge graphs और agentic architecture के जरिए launch readiness, cloud-native services orchestration और continuous verification automate करने जैसी चमकदार job description लगी हुई है
  • मेरा bill 1 billion dollars से ज्यादा था। पहले लगा phishing है और लगभग ignore करने ही वाला था, लेकिन यह बहुत असली जैसा लगा, इसलिए सीधे AWS में login किया; estimated bill देखकर लगभग heart attack आ गया
    बाद में support page पर outage banner मिला, लेकिन जिस billing page पर “आप पर 1 billion dollars बकाया हैं” दिख रहा था, वहां information banner क्यों नहीं था, यह समझ नहीं आया
  • मुझे भी awstrack.me URL बहुत suspicious लगा और ऐसी warning पहली बार मिली थी, इसलिए phishing ही समझा। Link click किए बिना console में गया तो billing amount गलत दिखने वाली outage थी, लेकिन email warning का कोई जिक्र नहीं था; उल्टा चिंता हुई कि कहीं attacker ने outage का फायदा उठाकर detection से बचने की कोशिश तो नहीं की
    Logs check करने के बाद समझ आया कि outage notice ने बस impact scope पूरा नहीं लिखा था, और मैं फिर coffee पीने चला गया। अगली बार सबसे पहले यहीं check करना होगा
  • पुराने joke को बदलकर कहें तो, अगर AWS bill 78 हजार dollars का है तो वह मेरी problem है, लेकिन 78 million dollars है तो Amazon की problem है
  • enterprise account में 3 trillion dollars से ज्यादा का bill दिख रहा था

• यह error इतना बेतुका है कि जल्दी fix हो जाएगा, लेकिन 2010s की शुरुआत में मैंने actual bill में छिपी एक गलती पकड़ी थी। कुछ servers के लिए EC2 reserved discount गलत calculate हो रहा था, और 18 tabs वाली spreadsheet से detailed usage का regular analysis करने पर भी amount match नहीं हो रहा था, इसलिए कई महीनों तक difference track किया
  वजह मिल जाने के बाद भी AWS system गलत है यह convince कराने में काफी समय लगा, और तब तक difference जमा होता रहा। 14 महीने बाद 7,000 dollars refund मिला; सुना कि इसके लिए AWS के एक senior person की approval चाहिए थी, और उसके बाद AWS की calculation error फिर नहीं देखी

  • 7,000 dollars credit खुद उस समय किसी नजदीकी product manager या director द्वारा भी ज्यादा oversight के बिना issue किया जा सकता था। असली problem 14 महीने की अवधि थी; उसी billing cycle में correction आसान होता है और पिछला cycle भी झंझट वाला लेकिन common होता है, जबकि पिछले financial years तक correction करना हो तो finance department से गुजरना पड़ता है, इसलिए यह कहीं ज्यादा painful हो जाता है
  • Colleagues को लगता है कि मैं Cost Explorer को जरूरत से ज्यादा detail में देखता हूं, लेकिन weird costs पकड़ने में लगा समय आम तौर पर पूरा वसूल हो जाता है, बल्कि उससे ज्यादा भी। इस error को track करने में 7,000 dollars के बराबर समय तो नहीं लगा होगा, और इस process में उससे बड़े cost optimization opportunities भी मिले होने की संभावना है
    पैसे बर्बाद करके Jeff Bezos की yacht और बड़ी बनाने का भी मन नहीं है
  • “जल्दी fix हो जाएगा” कहना मुश्किल है, क्योंकि अब तक 12 घंटे हो चुके हैं। लगता है इंसान उस code को समझ नहीं पा रहे जिसे agent ने लिखकर deploy कर दिया है

• जिस unit को असल में GB of storage consumed होना चाहिए था, वह Bytes of storage consumed के साथ गड़बड़ा गई लगती है, जिससे 2^30 गुना की गलती हुई
  “गणना पर शक किया जा सकता है। मैंने field definition देखने की कोशिश की, लेकिन MCP server से connection fail हो गया, और verification के बजाय अनुमान लगा लिया। मेरी गलती है। लेकिन बढ़ी हुई revenue देखिए!”

  • ग्राहक से bill करने की राशि calculate करने को कहा और 0.45, 1.67, 2.50 दिए, तो sum 4.62 है, लेकिन कोई और number भी हो सकता है। शायद उन्हें जोड़कर लिखना हो, और अगर dot multiplication का मतलब है, तो 0 . 45 . 1 . 67 . 2 . 50 3,015,000 बन जाता है
    0 से multiply करने पर 0 होना चाहिए, लेकिन कुछ भी charge न करना तो संभव नहीं, इसलिए 3,015,000 हजार डॉलर सही जवाब है
  • “गणना पर शक किया जा सकता है” parody है या असली response, अब तो यह फर्क करना भी मुश्किल है। LLM से कहें कि ऐसा मूर्खतापूर्ण वाक्य लिखो जो वह कभी नहीं दे सकता, तब भी ऐसी मूर्खता की कोई सीमा नहीं लगती
  • आज local agent को human-readable size units वाली CSV देकर GB ranges के हिसाब से rows गिनने को कहा, लेकिन उसने अजीब तरह से MB को GB समझ लिया और पूरी तरह गलत हो गया। पीछे मुड़कर देखें तो Excel में सीधे calculate करना ही ज्यादा तेज होता
  • अगर 2*30 है तो 60 होता है, इसलिए सिर्फ 2.83 करोड़ डॉलर देने होंगे, लेकिन मंशा शायद 2^30 थी, और तब यह 1.5 डॉलर बनता है
  • billing system को vibe coding से बनाकर revenue 9,000% बढ़ा दी, तो promotion material के लिए बढ़िया है

• सुबह billing alert mail देखा तो लगा कि मैंने गलती से AWS key leak कर दी और 437 अरब डॉलर खर्च कर डाले। शुक्र है मेरे पास इतना पैसा नहीं है, और coffee के बिना ही पहले कभी न आया adrenaline rush मिल गया, इसलिए AWS का धन्यवाद

  • अगर मुझ पर AWS का 4,37,000 डॉलर बकाया होता तो यह मेरी बड़ी समस्या होती, लेकिन अगर 437 अरब डॉलर बकाया है तो यह AWS की बड़ी समस्या है
  • इस वजह से किसी को सचमुच heart attack आया हो या मौत हुई हो सकती है। Amazon का ऐसे values users को जस-का-तस दिखाना गैर-जिम्मेदाराना handling है
  • सोने ही वाला था कि alert मिला, और यह मेरे set किए हुए 16 डॉलर limit से निश्चित रूप से ज्यादा amount था
  • hijacked account के कारण दो महीने तक AWS से लड़ता रहा। पिछले 3 सालों में monthly usage करीब 20 डॉलर था, फिर भी 20,000 डॉलर गंवाए और दसियों हजार डॉलर के और bills आते रहे, और AWS ने तब तक मदद नहीं की जब तक मैंने खुद breach रोक नहीं दिया
    office के बाद रात भर जागकर AWS infrastructure scripting सीखी और breach को control किया, लेकिन account closure भी refuse कर दिया गया, और case review करने के लिए shared responsibility agreement पर sign करने की मांग भी मैंने ठुकरा दी। आखिरकार state attorney general office से contact किया, तो उन्होंने AWS को सीधे email किया, और 24 घंटे से भी कम में AWS manager का call आया; उसने account clean up किया और 20,000 डॉलर refund कर दिए। फिर भी account closure आखिर तक refuse किया गया, लगता है AWS से पूरी तरह निकलने का कोई तरीका नहीं है, और यह सबसे खराब business practice जैसी लगती है
  • मेरे मामले में यह 500 मिलियन डॉलर था और हाथ इतने कांप रहे थे कि password तक type करना मुश्किल था

• account manager को budget situation बता दें, और विनम्रता से पूछें कि हालत सुधरने तक क्या हर महीने अरबों डॉलर की ईमानदार किश्तों में repayment कर सकते हैं

  • कमजोरी नहीं दिखानी चाहिए। सामने से निपटें और higher limit वाला credit card जारी करवाएं

• अगर bank का 100 डॉलर बकाया हो तो मेरी समस्या है, लेकिन 1.7 अरब डॉलर बकाया हो तो bank की समस्या है

  • मेरी पत्नी ने अपने पिछले workplace में जब mid-sized company events संभाले, तो event के बाद corporate Amex balance आम तौर पर 300,000 डॉलर से ऊपर होता था। maternity leave के दौरान replacement ने bill pay नहीं किया, तो लौटने पर overdue amount 500,000 डॉलर से ज्यादा था और Amex के emails और voice messages का ढेर लगा था
    messages शुरुआत में polite थे और धीरे-धीरे urgent होते गए, लेकिन एक बार भी threatening या hostile नहीं हुए
  • यह joke असल में तभी लागू होता है जब आपने AWS पर 1.7 अरब डॉलर का cost सचमुच लगा दिया हो। अगर बिना वजह सिर्फ invoice issue किया गया है, तो यह अब भी user की समस्या है
  • तो अगला सवाल यह है कि अगर bank का 1.7 ट्रिलियन डॉलर बकाया हो तो क्या होता है
  • Elon Musk हो तो शायद लागू न हो

• लगता है AWS ने देखा कि Anthropic ने zero usage वाले व्यक्ति को 16 मिलियन डॉलर bill किया, और सोचा कि लाखों डॉलर पर रुकने की क्या जरूरत है
  https://www.techtimes.com/articles/320266/20260712/anthropic...

  • अगर AI billing audit startup Vaudit ने 60 enterprise customers के 34 मिलियन डॉलर के bills review करके करीब 1.7 मिलियन डॉलर की overbilling, यानी लगभग 5% error rate पाई, तो यह काफी गंभीर है

• हाल ही में Whole Foods में payment करते समय पता चला कि Chase Amazon Prime card अब अपने-आप reliably recognize नहीं होता, इसलिए discount price automatic apply नहीं होता। सोचता हूं कितने customers सालों से ठीक चल रहे तरीके से pay करते हुए full price दे रहे होंगे
  store customer service staff के मुताबिक पिछले एक साल में यह बदला है, और उनका अनुमान है कि palm payment feature हटाने का यह unintended side effect है। सीधे related नहीं है, लेकिन याद आता है कि Amazon और क्या-क्या ठीक से calculate नहीं कर पा रहा होगा

  • अब class action lawsuit या हजारों small claims cases का समय है। arbitration clause हो तब भी इसे handle करने का burden बहुत बड़ा होगा, इसलिए उम्मीद है कोई सही फैसला लेकर automatic refund करेगा
  • पहले simple और reliable रहे systems में अब ऐसी छोटी-छोटी समस्याएं अनगिनत पैदा हो रही हैं। सब कुछ vibe coding की वजह से नहीं होगा, लेकिन उनमें से कितनी समस्याएं vibe coding का नतीजा हैं, यह सोचने लायक है

• एक बार 20,000 डॉलर का बिल सच में बैंक खाते से कट गया था, और इसे सुलझाकर पैसे वापस पाने में कई महीने लगे और राज्य के Attorney General के दफ्तर को दखल देना पड़ा। इसके बाद AWS products बिल्कुल इस्तेमाल नहीं किए और छोटे काम भी Azure पर शिफ्ट कर दिए।
  AWS billing की समस्या कई सालों से चली आ रही है; ऑनलाइन ऐसे मामले आसानी से मिल जाते हैं जहाँ hijacked account में cryptocurrency mining servers महीनों तक चलते रहे और एक छात्र को 60,000 डॉलर का बिल आ गया, फिर भी AWS इसे detect या block नहीं कर पाया।

  • AWS असल में लगभग public utility provider जैसा है, इसलिए अगर वह billing को लापरवाही से संभालता रहा तो आखिरकार उसे वैसी ही regulation झेलनी पड़ेगी।
  • variable cost services के लिए हमेशा spending-limit card इस्तेमाल करना चाहिए।
  • मुझे नहीं लगता कि compromised account detection 100% accurate हो सकता है। इंसान सीधे देखे तो बात साफ हो सकती है, लेकिन हर account की usage को कोई इंसान पहले से manually review नहीं कर सकता।
  • service provider इस्तेमाल करने का पहला सबक है: auto-payment कभी enable न करें। सुविधा या discount से कहीं बड़ा खतरा यह है कि vendor अपनी मर्जी से आपके खाते का सारा पैसा निकाल ले।
  • कुछ समय तक मैंने अपने homelab का एक हिस्सा AWS पर रखा था। मैं उन classrooms में educator था जहाँ students cloud सीखते थे, और instructor ने practice environment बनाने की सलाह दी थी, इसलिए मैंने भी free tier EC2 पर LAMP stack MediaWiki install किया। शुरुआती configuration मुश्किल नहीं था, लेकिन दो वजहों से मैं हमेशा के लिए वहाँ से चला गया।
    पहली, आज भी internet पर exposed एक साधारण Linux system को ठीक से सुरक्षित करना या तो नामुमकिन है या बहुत ज्यादा मेहनत वाला काम है। fail2ban install करने और कई ports बंद करने के बाद भी spam attacks application layer से आते रहे। दूसरी, हर billing cycle में cloud spending cap को enforce करना वास्तव में असंभव था। ज्यादातर usage free limit में रहे, तब भी अगर कोई setting गलत हो जाए या resources runaway हो जाएँ तो ऐसा बड़ा bill बन सकता है जिस पर dispute करना मुश्किल होता है; खासकर बाहरी users द्वारा VPC resources और external transfer traffic consume करने जैसे आपके control से बाहर कारणों से भी ऐसा हो सकता था। इसलिए मैंने account बंद कर दिया, और उन कंपनियों से गहरी सहानुभूति हो गई जिन्हें अपने infrastructure के बजाय cloud इस्तेमाल करने के लिए मजबूर किया जाता है, लेकिन costs control करने का भरोसेमंद तरीका नहीं मिलता।