AWS Amplify की आधिकारिक गाइड फॉलो करने पर $1,100 का बिल आ गया

 (elliott-king.github.io)
1 पॉइंट द्वारा GN⁺ 2024-11-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS Amplify की OpenSearch integration आधिकारिक गाइड के साथ प्रयोग करने के बाद, usage ज़्यादा न होने के बावजूद Amazon OpenSearch Service की लागत एक महीने में $1,124.88 तक बढ़ गई
  • लागत इसलिए जमा हुई क्योंकि npx ampx sandbox द्वारा बनाया गया OpenSearch domain sandbox बंद/डिलीट होने के बाद भी बचा रहा, और अगली execution पर नया domain जुड़ता गया
  • आधिकारिक configuration default रूप से r5.large.search instance बनाती है, और कम से कम लगभग $134 प्रति माह की default लागत boilerplate code या guide में स्पष्ट नहीं दिखी
  • AWS Support ने OpenSearch और storage के लिए one-time credit दिया, और दोबारा ऐसा न हो इसके लिए AWS Budgets configure करने को कहा
  • Amplify और OpenSearch साथ इस्तेमाल करते समय, sandbox delete करने के बाद बचे resources और default instance type को खुद verify करना ज़रूरी है ताकि अनपेक्षित billing से बचा जा सके

अनपेक्षित OpenSearch billing

  • AWS Amplify में OpenSearch integration official guide follow करने के बाद, कुछ हफ्तों बाद AWS bill $1,200 से अधिक आया
  • Support request में दिखी service Amazon OpenSearch Service थी, और एक महीने का कुल amount $1,124.88 था
  • 2020 में भी Amplify और OpenSearch इस्तेमाल करने का अनुभव था, और निजी उपयोग के लिए आमतौर पर यह लगभग $50 प्रति माह महंगा तो था, लेकिन $1,200 के स्तर का नहीं था
  • AWS Customer Support ने detailed review के बाद अनपेक्षित लागत के लिए one time courtesy के रूप में billing adjustment process किया
  • Support process के दौरान OpenSearch और storage service credits दिए गए, और AWS Budgets configure करने को भी कहा गया
    • AWS Budgets किसी खास service या पूरे AWS के future spend का अनुमान लगा सकता है, और budget exceed होने की आशंका होने पर alert भेज सकता है

आधिकारिक guide द्वारा बनाए जाने वाले resources

  • Amplify quickstart AWS-provided code से TODO notes के लिए एक toy app बनाता है, और Amplify DynamoDB database व authenticated CRUD requests generate करता है
  • इसे local में चलाना भी संभव है, लेकिन Amplify साथ में access करने योग्य domain भी बनाता है
  • OpenSearch setup step में Amplify resources declare करने के लिए TypeScript boilerplate लिखा जाता है
    • DynamoDB table को variable में रखकर pipeline में reference किया जाता है
    • OpenSearch instance, index और indexMapping बनाए जाते हैं
    • OpenSearch में मौजूद data access करने वाली queries लिखी जाती हैं
    • DynamoDB से OpenSearch में copy करने वाली OpenSearchIngestionService pipeline बनाई जाती है
  • संबंधित configuration frontend code के साथ repository के अंदर TypeScript/JavaScript के रूप में manage होती है
  • npx ampx sandbox AWS services spin up करता है, configuration changes detect करता है और मौजूदा AWS services को अपने-आप modify करता है

sandbox delete करने के बाद भी बचा रहा domain

  • इस configuration में DynamoDB database, एक OpenSearch service, एक OSIS pipeline, IAM roles आदि कई resources शामिल हैं
  • आधिकारिक boilerplate default रूप से r5.large.search OpenSearch instance बनाता है
    • यह default value boilerplate code या guide में स्पष्ट रूप से दिखाई नहीं दी
    • r5.large.search की लागत कम से कम $134 प्रति माह है
  • दिन भर का काम खत्म करके CTRL-C से sandbox रोकने पर permanent deletion के बारे में prompt आता है, और user Y चुन सकता है
  • इस समय DynamoDB delete हो जाता है, लेकिन AWS console में देखने पर OpenSearch domain वैसा ही बचा रहता है
  • अगले दिन npx ampx sandbox फिर चलाने पर नया OpenSearch instance बनता है, और npx ampx sandbox delete भी original instance को delete नहीं करता
  • यही process दोहराने पर उसी project में कई OpenSearch domains background में बचे रहते हैं और costs जमा होती जाती हैं

bug की संभावना और default instance type

  • यह behavior एक बड़ा footgun लगा, और AWS Support ticket के बाद भी उस समय तक resolve नहीं हुआ था
  • पुराने related bug reports मौजूद थे, लेकिन पिछले 1 साल के अंदर का कोई item नहीं मिला
  • संभव है कि OpenSearch domain v1 में ठीक से delete होता था लेकिन v2 में नहीं, हालांकि यह confirmed cause नहीं है
  • मौजूदा flow Amplify CLI के बजाय npx के जरिए execute होता है
  • r5.large.search का default machine type होना भी risk factor बना हुआ है
    • बेहतर होगा कि इसे default value के बिना required field बनाया जाए
    • अगर guide r5.large.search को default value के रूप में दिखाए, तो users इसे ज्यादा आसानी से notice कर सकेंगे
    • यह default value सिर्फ Amplify-specific नहीं, बल्कि AWS CDK का हिस्सा है, इसलिए इसे केवल Amplify team की जिम्मेदारी नहीं माना गया

Amplify और OpenSearch इस्तेमाल करते समय सावधानियां

  • यह expected था कि नई technologies की development speed बढ़ाने वाले tools bare metal से महंगे हो सकते हैं, लेकिन यह लागत उस स्तर से आगे निकल गई
  • AWS का budget console इस्तेमाल करने पर expected spend budget से ऊपर जाने पर warning मिल सकती है
  • सिर्फ OpenSearch section follow करने पर भी IAM account, OpenSearch domain, OSIS pipeline, log group और S3 storage बन जाते हैं, जिससे hidden resources बहुत बढ़ जाते हैं
  • OpenSearch अक्सर enterprise customers द्वारा इस्तेमाल की जाने वाली service है, इसलिए इसे “advanced” service माना जा सकता है, और users से AWS ecosystem की बेहतर समझ expected हो सकती है
  • geo_point bounding-box query support के कारण OpenSearch इस्तेमाल किया गया, लेकिन यह किसी simpler product से possible था या नहीं, इस पर certainty नहीं थी
  • update के अनुसार AWS guide बाद में modify कर दी गई, और 3 महीने पहले जब पहली बार issue raise किया गया था तब यह update नहीं हुई थी, लेकिन post public होने से पहले documentation PR work शुरू हो चुका लगता है

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

1 टिप्पणियां

 
GN⁺ 2024-11-15
Hacker News की रायें

  • बिलिंग अलर्ट मज़ाक जैसे हैं; असल में हार्ड स्पेंडिंग लिमिट देनी चाहिए
    ऑनबोर्डिंग के दौरान वह लिमिट सेट करने का तरीका भी देना चाहिए
    ब्लैंक चेक और आकस्मिक चार्जिंग के ऊपर बिज़नेस खड़ा करना संदिग्ध है, और adoption barrier भी बड़ा है
    डेवलपर्स जितने ज़्यादा ऐसे उदाहरण देखते हैं कि “20 मिनट का tutorial follow किया और ज़िंदगी भर की बचत जितना बिल आ गया; इस बार customer support ने waive कर दिया, लेकिन अगली बार तो घर तक ले जाने पर उतारू थे”, उतना ही AWS products explore करने का मन नहीं करता

    • यह सिर्फ AWS की समस्या नहीं है; cloud providers आम तौर पर दो तरह के ही लगते हैं
      AWS या DigitalOcean जैसे जो जोखिम ग्राहक पर डाल देते हैं, और वे जो संदिग्ध “unlimited”·“no metering” pricing plans बेचते हैं
      दोनों ही वह रूप नहीं हैं जो चाहिए
      काश कोई provider होता जिसके साफ़ और documented limits के साथ capacity planning ठीक से की जा सके, availability risk ग्राहक उठाए लेकिन financial risk provider उठाए
      बहुत ज़्यादा न हो तो ज़्यादा fixed fee देने को भी तैयार हूँ
    • हार्ड स्पेंडिंग लिमिट AWS के core customers यानी enterprise customers के लिए लगभग उलटा असर डालती है
      critical applications में downtime या data loss पैदा करने से सस्ती accidental billing लगभग कोई नहीं होती
      अगर यह सिर्फ option के रूप में भी हो, तो accounting team इसके उपयोग के लिए दबाव डाल सकती है, और दिक्कत आने पर यह data loss incident में बदलने का जोखिम रखता है
      indie developers या छोटे-मझोले business केंद्रित cloud companies के लिए यह बात समझ में आ सकती है
    • HN comments में कई बार यह बात आई है कि AWS billing code विशाल spaghetti code है, इसलिए बड़े changes छेड़ने को लेकर internally बहुत डर है
      यहां पता चली अंदरूनी बातों में यह काफ़ी दिलचस्प चीज़ों में से एक है
    • AWS में रुचि तो थी, लेकिन इन्हीं वजहों से कभी ठीक से कदम नहीं रख पाया
      पछताने से बेहतर है सस्ता और flat-rate VPS इस्तेमाल करना सुरक्षित है
    • regulation होना चाहिए
      Amazon से कुछ करने की request करना ज़्यादा मायने नहीं रखता
      Amazon और दूसरी कंपनियों को users के पैसे का सम्मान करने के लिए क़ानून से मजबूर करना चाहिए
      कंपनियां मूल रूप से ethics या economy के लिए अच्छी चीज़ नहीं, बल्कि पैसे कमाने वाली चीज़ करती हैं

  • तुलना में यह छोटी बात है, लेकिन ECS पर app deploy करने की कोशिश में 100 dollar का बिल मिला और तय कर लिया कि AWS दोबारा नहीं इस्तेमाल करूंगा
    service न चलने वाली error मेरी app की तरफ़ की समस्या थी, लेकिन CloudWatch logs सिर्फ करीब 20% ही दिख रहे थे, इसलिए logs पाने के लिए पांच बार redeploy और fix करना पड़ा, फिर फिर से पांच बार redeploy करना पड़ा
    हर failed deployment पर charge लगा, और करीब दो दिन जूझने के बाद account delete किया और DigitalOcean App Platform पर deploy किया
    वहां भी app error की वजह से deployment fail हुआ, लेकिन logs हर बार आए, 10 मिनट में fix करके चला लिया, और कुल बिल कुछ cents था
    उस दिन के बाद कसम खाई कि अगर विकल्प हो तो AWS कभी इस्तेमाल नहीं करूंगा और recommend भी नहीं करूंगा

    • मैंने सिर्फ Azure इस्तेमाल किया है, लेकिन ECS शायद Azure Container Apps जैसा लगता है
      development·testing के लिए consumption-based billing model बहुत सस्ता था
      बड़े workloads में कैसा है नहीं पता, लेकिन हर deployment पर charge करना अजीब है
    • यह जानकर AWS छोड़ दिया कि GCP की तरह containers को सीधे EC2 पर deploy नहीं कर सकते
      बड़े projects के लिए support शायद बेहतर होगा, लेकिन छोटे से मध्यम scale में GCP कहीं बेहतर है
      इसमें आजकल containers के उपयोग के तरीके के हिसाब से basic building blocks हैं, और BigQuery भी है

  • उस npx command द्वारा चलाए जाने वाले script में साफ़ bug दिखता है
    लेखक सही कह रहा है, और अगर यह tutorial है तो 100% सबसे सस्ते resources चुनने चाहिए, और delete sub-script चलाने पर resources clean up होने चाहिए
    ऐसा कुछ चलाने के बाद developer से यह उम्मीद करना कि वह पूरे AWS account को paranoid होकर खंगाले और stray resources ढूंढे, fair नहीं है
    अगर कोई startup इस तरह व्यवहार करता तो क्या हम “ऐसी चीज़ें होती हैं, इसलिए सावधान रहना चाहिए” कहकर छोड़ देते?
    समझ नहीं आता AWS के लिए अलग standard क्यों लागू करते हैं

    • AWS में सबसे annoying बात यही है
      अभी मैं जिन सभी resources के लिए पैसे दे रहा हूँ, उन्हें आसानी से देखने का कोई तरीका नहीं है
      अगर है भी तो मुझे मिला नहीं
      समझने लायक overview न हो तो लगता है कि अपने account पर मेरा पूरा control नहीं है
    • नई चीज़ इस्तेमाल करनी हो तो सबसे पहले देखता हूँ कि क्या हर महीने fixed bill मिल सकता है
      उससे ज़्यादा इस्तेमाल करने पर क्या होगा, और unexpected charges को limit कर सकते हैं या नहीं, यह भी देखता हूँ
      अगर नहीं, तो कुछ और ढूंढता हूँ
      कुछ साल पहले Google Maps billing change के बाद से “free” Google services में खुद को गहराई से बांधने को लेकर भी बहुत सावधान हूँ, और आखिर में इसकी cost काफ़ी आई
    • क्या AWS account में मौजूद सभी resources को सरल तरीके से list करने का कोई तरीका है भी?
      हमेशा service-wise, region-wise check करना पड़ा, और यह boring होने के साथ error-prone भी था
    • Amazon के नज़रिए से देखें तो आसानी से 1000 dollars कमा सकते हैं, इसलिए यह bug नहीं, feature है
      भले ही इसे bug मानें, यह उनके profit-loss पर सीधे चोट करने वाली दूसरी चीज़ों की तुलना में बहुत lower priority होगा
    • मैं सहमत हूँ कि developer से paranoid checking की उम्मीद करना fair नहीं है
      हालांकि practical तौर पर यह reasonable है
      AWS पर कुछ बनाते समय AWS को बेकाबू hostile financial institution की तरह treat करता हूँ

  • ऐसे मामलों की वजह से मैं कई सालों से AWS को गहराई से आज़माने का काम टाल रहा हूँ
    एक standard education course होना चाहिए, जिसमें credit card जानकारी मांगे बिना लोग मुफ्त में प्रयोग कर सकें
    इसके बजाय लगता है कि कुछ white-collar लोग यह हिसाब लगा रहे हैं कि “user mistake” के नाम पर जगह-जगह से हजारों डॉलर निकाले जा सकते हैं
    ऐसे charges को dispute करना भी मुश्किल होता है, और कुछ मामलों में तो बिल्कुल असंभव
    भारी-भरकम bill देखकर ऐसा हो सकता है—इस वाजिब डर की वजह से AWS environment से दूर रहने वाला मैं अकेला नहीं होऊंगा

    • ऐसे हालात में AWS का refund न देना काफी असामान्य है, इसलिए इसे user mistakes से हजारों डॉलर निचोड़ने की strategy मानना मुश्किल है
      संभवतः उन्होंने यह माना होगा कि सही और सस्ता tutorial देने की तुलना में refund processing कम बोझिल है
      इससे उनका व्यवहार सही नहीं ठहरता, लेकिन AWS Textract इस्तेमाल करते समय सही तरीके से बने 600 डॉलर के charge को भी मैंने cancel करवाया था
      उस समय मैं एक कई billion-dollar वाली company में काम कर रहा था
    • मुझे लगता है लोग ऐसी payment स्थितियों में इसलिए फंसते हैं क्योंकि वे असल में AWS को गहराई से नहीं समझते
      price list आसानी से उपलब्ध है और हमेशा समझने में आसान नहीं होती, लेकिन अधिकांश costs लगभग linear बढ़ती हैं, इसलिए test करना अपेक्षाकृत आसान है
      AWS Amplify, CloudFormation और तरह-तरह के Stack जैसे wrapper services से बचना बेहतर है
      core services को सीधे इस्तेमाल करें
      हर service में API है, और IAM user से बंधी API key पाना एक button click जितना आसान है
      बाकी चीजें सही caching और cost model को revenue model के साथ align करके manage की जा सकती हैं
      auto-scaling services की cost को current demand से अलग revenue का लगभग fixed percentage बनाना चाहिए
      bandwidth AWS में सचमुच nightmare है, लेकिन console में automatic long-term discounts मिलते हैं और sales rep के जरिए थोड़ा बेहतर contract discount भी मिल सकता है
      इसी वजह से मुझे लगता है EC2 से बचना चाहिए, और EC2 की internal bandwidth भी ज्यादा महंगी है, इसलिए Lambda + S3 + CloudFront को सीधे इस्तेमाल करना बेहतर है
      करीब 3 महीने बाद, कोई नया user-facing feature implement करते समय कौन-सा service combination सबसे cost-efficient होगा, इसका अनुमान लगाना काफी आसान हो गया था
    • A Cloud Guru / Pluralsight में “Cloud Playground” या “sandboxes” कहे जाने वाले features हैं
      वे शायद ऐसे use case के लिए उपलब्ध कराते हों, लेकिन मैंने खुद इस्तेमाल नहीं किया, इसलिए पक्का नहीं कह सकता
    • इस तरह की user mistake से बनने वाला पैसा AWS के कुल scale में ऊंट के मुंह में जीरा ही होगा
      मेरे अनुभव में AWS उन समस्याओं से बचने की कोशिश करता था जिनसे reputation damage के कारण ज्यादा बड़ा cost बन सकता है
      AWS सस्ता नहीं है, और कुछ मामलों में, खासकर data transfer costs में, बेहद महंगा है; लेकिन customers को धोखे से कुछ सौ डॉलर accidental ज्यादा खर्च करवाना उनका तरीका नहीं लगता

  • यह AWS जैसा ही लगता है
    कुछ महीने पहले Llama 2 चलाने के लिए मैंने official SageMaker quick start guide follow किया था; सच में बहुत जल्दी spin up हो गया, लेकिन अगले दिन देखा तो एक दिन में 400 डॉलर खर्च हो रहे थे
    charge cancel हो गया, लेकिन इतना जरूर सीख लिया कि official guide पर भरोसा नहीं करना चाहिए

    • SageMaker product perspective से सबसे निराशाजनक चीजों में से एक है, और enshittification का साफ example है
      product के शुरुआती दौर 2017–2018 में setup काफी intuitive था
      notebook instances, inference, serving के लिए REST API, थोड़ा EFS, और service का center S3 है—यह सब स्पष्ट था
      pricing भी bounded थी, इसलिए surprises नहीं होते थे
      कुल मिलाकर DigitalOcean जैसा feel था, और infrastructure की basic knowledge व curiosity रखने वाला data scientist भी कम खर्चीला, predictable और simple setup बना सकता था
      अब Wrangler, Feature Store, RStudio हैं, notebook console user experience भयानक है, और अंदर कई services data move करती हैं और उसका charge लगाती हैं

  • AWS के bloated SDK के बजाय मजबूरी में raw HTTP requests भेजनी पड़ीं; content-type: application/json header से fail हुआ और content-type: application/x-amz-json-1.0 से succeed हुआ
    ऐसी nonsense सच में बंद होनी चाहिए

    • career में AWS के लगभग हर हिस्से को छूते हुए मुझे ऐसा ही महसूस हुआ
      साफ benefit के बिना बहुत ज्यादा bloated, बहुत ज्यादा complex, या अजीब custom implementations से भरा हुआ
    • सच कहें तो यह internal details leak होने जैसा है
      internally ज्यादातर apps पुराने Coral framework का उपयोग करते हैं, और input/output/error shapes अच्छी तरह defined वाले इसी JSON format का इस्तेमाल करते हैं

  • हर official AWS guide इस तरह design की गई है कि आप जितनी हो सके उतनी AWS services इस्तेमाल करें, और उसी अनुपात में spending risk भी बढ़ता है
    AWS जो recommend करता है—यानी GUI defaults, CLI tools, guides, recommended architectures वगैरह—उसे बेहद critical नजरिए से देखना चाहिए
    companies में AWS को cost-efficient और low-risk तरीके से इस्तेमाल करने के लिए colleagues को guide करने वाली high-salary role होती है, इसकी वजह है

    • सही
      छोटे deployments या tests में सबसे महंगे हिस्से लगभग हमेशा side things होते हैं, या वे latest services जिन्हें simpler alternatives की जगह recommend किया जाता है

  • अगर आप geo_point bounding box query की वजह से OpenSearch इस्तेमाल कर रहे हैं, तो PostgreSQL + PostGIS कैसा रहेगा?
    https://postgis.net/docs/using_postgis_query.html

  • मुझे लगता है ऐसे frictionless setup, कम intuitive user experience/interface, credit card registration को लेकर कम सतर्कता, और AWS Batch + Lambda + EC2 जैसी services के बीच bundled charging business model का हिस्सा हैं
    इसे कैसे कहूं समझ नहीं आता, लेकिन यह modern amusement park जैसा है जहां entry fee देकर अंदर जाने के बाद हर ride और यहां तक कि toilet के लिए भी अलग से पैसे देने पड़ते हैं

    • मुझे भी ऐसा ही लगता है
      cloud billing model “flexibility” और “customization” के नाम पर responsibility user पर डाल देता है
      कल्पना कीजिए कोई rental car company engine camshaft rotations, tire rotations, wiper operations, seat-heating time जैसे हर component को millisecond के हिसाब से charge करे, और फिर कहे कि हर item पर alert set कर सकते हैं, इसलिए customer usage और budget को “control” करता है
      default से ही user-hostile और risky cost model है