AWS पर लौटकर मुझे फिर याद आ गया कि मैं वहाँ से क्यों चला गया था

 (fourlightyears.blogspot.com)
18 पॉइंट द्वारा GN⁺ 2026-05-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • शुरुआत से AWS का समर्थक रहा, लेकिन जटिल billing structure और पूरे platform की complexity* जैसी जमा होती असंतुष्टियों के कारण अब AWS पसंद नहीं रहा
  • DynamoDB की ऊँची लागत, प्रति gigabyte 9 cent तक की egress fee, और internal data movement पर दोहरी-तिहरी billing अब भी महँगी और समझने में कठिन लगती है
  • AWS Bedrock पर Claude टेस्ट और 192-core machine benchmark के लिए वापस लौटा, लेकिन निष्क्रिय पड़े account में अचानक activity होने पर security breach suspicion alert आया और account suspend कर दिया गया
  • Account suspension के कारण business के लिए इस्तेमाल होने वाला AWS WorkMail भी बंद हो गया, और free support plan पर 4 दिन तक account recovery नहीं हुई
  • AWS पर छोड़ी गई बाकी services भी migrate करके पूरी तरह छोड़ देना चाहिए इस निष्कर्ष पर पहुँचा

शुरुआती AWS समर्थन से दूर होने तक

  • जब AWS, SQS, S3, EC2, SimpleDB जैसी कम services वाला platform था, तब से उसका प्रबल समर्थक था, और Melbourne में अमेरिका से आए AWS प्रतिनिधियों के साथ AWS को परिचित कराने वाला पहला event आयोजित भी किया था
  • Cloud computing एक बड़ा बदलाव था, जिसने startups को data center में system install और operate किए बिना कुछ ही मिनटों में अपना computer system चलाने लायक बनाया
  • लगभग 15 साल तक AWS पर गहरा भरोसा रहा, लेकिन समय के साथ असुविधाएँ जमा होती गईं और एक समय ऐसा आया जब AWS अब पसंद नहीं रहा

समय के साथ जमा हुई AWS को लेकर शिकायतें

  • Client libraries और Python migration

    • शुरुआती 6 साल तक AWS ने अपनी client libraries नहीं बनाईं और Python जैसी भाषाओं के लिए libraries community पर छोड़ दीं, जो ऐसे लगा मानो free में समय देने वाले programmers पर बोझ डाल दिया गया हो
    • AWS का Python 2 से Python 3 पर जाने में बहुत अधिक समय लेना भी एक बड़ी शिकायत रही

  • DynamoDB और लागत का अनुभव

    • DynamoDB इस्तेमाल करने के पहले ही दिन 75 dollar का bill आया, और सिर्फ लागत ही नहीं बल्कि system खुद भी कल्पना की जा सकने वाली सबसे खराब चीज़ों में से एक लगा

  • Data transfer cost और जटिल billing

    • AWS की data egress cost पहले 20 cent per GB थी और बाद में 9 cent per GB तक घटी, लेकिन फिर भी इसे बहुत महँगा माना गया
    • AWS के internal systems के बीच data movement पर भी charge लगता है, और कई बार यह दोहरी-तिहरी billing जैसा महसूस होता है, इसलिए गहराई से समझे बिना billing traps से बचना कठिन है

  • IAM और समग्र complexity

    • IAM (authentication और access control system) अत्यंत जटिल system है
    • AWS समर्थक कहते हैं कि अपना Linux, hardware, networking और security चलाना बहुत complex है इसलिए AWS इस्तेमाल करना चाहिए, लेकिन AWS का लगभग हर हिस्सा भी भारी complexity से भरा है, इसलिए अंततः महँगी expert team की ज़रूरत पड़ती है

  • AWS Lambda और lock-in

    • “Scalable” होने के फ़ायदे से प्रभावित हुआ था, लेकिन धीमे cold starts और भारी development complexity बड़ी समस्या हैं
    • अपने web server की तुलना में कोई वास्तविक लाभ नहीं लगा, नुकसान अधिक दिखे, और AWS छोड़ते समय Lambda सबसे मुश्किल हिस्सों में से एक साबित हुआ, जिससे vendor lock-in की गंभीरता समझ आई

  • Open source projects और hosting revenue

    • लेखक के अनुसार AWS ने OpenSearch, Valkey, DocumentDB को आगे बढ़ाया, जबकि Elasticsearch, Redis, MongoDB जैसे projects duplication और monetization को लेकर अनिच्छुक थे
    • इन communities और कंपनियों ने market बनाया, फिर AWS ने hosted services की कमाई ले ली, और उसके परिणामस्वरूप SSPL, Elastic License, RSAL जैसी defensive licenses और source-available model बढ़े

AWS छोड़ने के बाद भी बची कुछ services

  • AWS के प्रति लगाव खत्म होने के बाद लगभग सब कुछ AWS से बाहर migrate कर दिया और अधिकतर accounts बंद कर दिए
  • फिर भी उस समय जिन कुछ services को वास्तव में सही समाधान माना, सिर्फ वही छोड़ीं
  • Domains Route53 पर, कुछ backups S3 पर, और business email AWS WorkMail पर छोड़ा गया
    • AWS WorkMail को 12 महीनों के भीतर service बंद होने की सूचना मिल चुकी है

AWS पर थोड़ी देर के लिए वापस क्यों आया

  • हाल की research और testing के लिए AWS में फिर login किया
  • Claude/Anthropic, AWS Bedrock पर कितना अच्छा काम करता है यह देखना चाहा; Claude Code के संदर्भ में काम तो वैसा ही था, लेकिन धीमा और Anthropic subscription से बहुत अधिक महँगा था
  • घर में उपलब्ध सबसे तेज़ machine 20-core CPU और 32GB RAM वाली थी, और यह benchmark करना था कि code 192-core और 1TB RAM वाली machine पर कितनी तेज़ी से चलता है
  • लगभग एक महीने पहले AWS Bedrock test बिना समस्या के पूरा हुआ था, और test के बाद सब बंद कर दिया गया था
  • Privacy की ज़रूरत हो तो AWS Bedrock उपयोगी हो सकता है, लेकिन लागत की वजह से Claude को दोबारा AWS Bedrock पर इस्तेमाल करने का इरादा नहीं है

EC2 Spot test के दौरान account restriction

  • इसके बाद 192-core EC2 Spot instance चलाकर लगभग 3 घंटे test करते समय AWS से “Suspected security breach of your account” ईमेल मिला
  • लगभग निष्क्रिय पड़े account ने अचानक महँगे compute resources इस्तेमाल करने शुरू किए, जिससे AWS का internal security alert trigger हुआ हो सकता है
  • उपयोगकर्ता की सुरक्षा करने की AWS की मंशा को समझा गया और सकारात्मक रूप से देखा गया
  • लेकिन AWS ने account suspend या restrict कर दिया, और परिणामस्वरूप मुख्य business email account, जो AWS WorkMail पर था, काम करना बंद कर गया
  • अब कोई ईमेल भेज नहीं सकता था, और कोई भी AWS resource बनाया नहीं जा सकता था, इसलिए मूल test भी जारी नहीं रखा जा सका

Support response और delay

  • AWS support alert का reply देकर बताया गया कि account hack नहीं हुआ, कोई समस्या या abnormal billing भी नहीं है, लेकिन कोई जवाब नहीं मिला
  • Premium support न होने के कारण AWS द्वारा बताए गए 24 घंटे के response time का इंतज़ार करना पड़ा, और 3 दिन बाद भी AWS support से जवाब नहीं आया
  • AWS forum पर मदद माँगने के बाद, ईमेल में दिए गए निर्देश पूरे करने और web के बजाय chat इस्तेमाल करने की सलाह मिली
  • Password change, access tokens delete, billing history check जैसी सभी माँगी गई कार्रवाइयाँ पूरी कीं, और chat connect होने के लिए लगभग 30 मिनट इंतज़ार करने के बाद AWS representative से लंबी बातचीत हुई
  • Representative संतुष्ट दिखा और कहा कि वह संबंधित internal team से कार्रवाई करवाएगा, लेकिन 24 घंटे बाद भी restriction नहीं हटाई गई
  • 8 घंटे बाद follow-up करने पर सिर्फ “कृपया इंतज़ार करें” जैसा जवाब मिला

फिर से स्पष्ट हुआ निष्कर्ष

  • Account restrict हुए 4 दिन बीत जाने के बाद भी बड़े hardware पर test करने वाले काम बचे हुए थे, और इसके लिए फिर से “quota” request करनी पड़ेगी यह सोचकर चिंता होने लगी
  • Business email system अब भी काम नहीं कर रहा है
  • इस वापसी के अनुभव ने फिर से पुष्टि कर दी कि AWS क्यों छोड़ा था, और अब AWS WorkMail से बाहर निकलकर Route53 के domains भी migrate कर देने और कभी वापस न आने का निर्णय लिया गया
  • पहले से AWS से अधिकांश चीज़ें हटाकर रखना सौभाग्यपूर्ण था, लेकिन जिस email system पर भरोसा करके छोड़ा था, वही AWS पर वापसी की प्रक्रिया में बंद हो गया और इससे वास्तविक नुकसान हुआ
  • AWS कभी account restriction हटा भी दे, तब भी यह कब होगा इसका कोई भरोसा नहीं है

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

1 टिप्पणियां

 
GN⁺ 2026-05-11
Hacker News की राय

  • कुछ साल पहले मैं एक कंपनी में शामिल हुआ, dev टीम की ज़िम्मेदारी ली, और मुझसे कहा गया कि 3 महीने के भीतर product लॉन्च करना है। AWS में नया machine जोड़ने लगा तो कीमत UI में दिखती ही नहीं थी — यह ढांचा खुद मुझे शत्रुतापूर्ण और शोषणकारी रिश्ते का संकेत लगा।
    specs table और pricing table अलग-अलग खोलकर मिलान करना पड़ता था, और पिछले अनुभव से मेरा मानना था कि ऐसे संकेत देखकर भी अगर कोई न जाए, तो बाद के नतीजों की ज़िम्मेदारी उसी की होती है।
    इसलिए मैंने DigitalOcean account बनाया, सब कुछ वहाँ migrate किया, CI/CD भी वहीं deploy होने के लिए सेट किया, और बचे हुए 2 महीने product पर फोकस किया — नतीजा यह कि तय समय से 1 महीना पहले लॉन्च कर दिया।
    मैंने कभी एक वीडियो देखा था जिसमें नदी किनारे गड्ढा खोदकर उसे pipe से नदी से जोड़ा गया था, ताकि मछलियाँ खुद फंदे में आ जाएँ। उस वीडियो ने मेरे दिमाग में यह बात बिठा दी कि सबसे कम प्रतिरोध वाले रास्ते को चुनना और गलतियों को वापस न पलटना, आखिर में उसी मछली जैसा अंजाम देता है।

    • Azure की जो बातें मुझे पसंद हैं, उनमें से एक यह है कि हर individual item बनाते समय वह कीमत को आक्रामक ढंग से सामने नहीं ठेलता, लेकिन जिन items की कीमत ज़्यादा हो सकती है, वहाँ आम तौर पर कीमत दिखाने का संतुलन मौजूद रहता है।
      अभी तक billing देखकर चौंकना नहीं पड़ा।
    • लगता है Amazon की engineering culture काफ़ी engineer-driven product culture है, इसलिए अक्सर developers को UX और flow तक की ज़िम्मेदारी उठानी पड़ती है।
      मैंने पहले एक junior developer को hire किया था जिसने AWS internship की थी। उसने summer में product manager या designer की मदद के बिना अकेले बनाया dashboard दिखाया, और वह सच में बहुत भयानक लग रहा था।
      कुछ developers में product/UX की समझ अच्छी होती है, लेकिन ज़्यादातर UX में बहुत कमज़ोर होते हैं; इसलिए यह जानबूझकर किया गया कम और बस खराब UX culture ज़्यादा लगता है।
    • सही तरीका यह है कि ऐसा infra provider चुना जाए जो launch में मदद करे।
      AWS अच्छा है, लेकिन हर किसी के लिए सही नहीं। यह Heroku जैसी services और bare metal के बीच कहीं आता है — maintenance का काफ़ी abstraction देता है, लेकिन scaling architecture पर कुछ control भी रहने देता है।
      यानी cloud provider के रूप में AWS scale करने में मदद करता है, लेकिन सबसे सस्ती और सरल setup बनाने का tool नहीं है।
      अगर VC funding है और growth की कहानी आगे रखनी है, तो AWS सुरक्षित विकल्प हो सकता है, और accelerator के 2 साल वाले startup credits की वजह से शुरुआती 18 महीनों में infra budget से ज़्यादा build पर ध्यान दिया जा सकता है।
      अगर आप bootstrap या indie developer हैं, तो कुछ ऐसा चुनिए जो साध्य और सरल हो; Hetzner या DigitalOcean काफ़ी अच्छे से चल जाते हैं।
    • AWS के पास काफ़ी ठीक pricing calculator और काम के presets हैं, लेकिन जाहिर है वह पूरी तरह अलग app है।
      Amazon शायद चाहता हो कि pricing information तक आसानी से पहुँचने में थोड़ा friction रहे, लेकिन मुख्य वजह ज़्यादा Conway’s Law जैसी लगती है।
      AWS अब भी अपनी org chart को product की तरह बाहर भेज रहा है।
    • मैं कुछ हद तक सहमत हूँ, लेकिन AWS pricing इतनी सरल नहीं है कि UI में दिखने वाले किसी एक static number से पता चल जाए कि कितना bill आएगा।
      अगर cost compare करने के लिए 2 tabs खोलना ही असुविधा है, तो शायद AWS ही नहीं, सभी cloud providers से दूर रहना बेहतर हो।
      NAT Gateway, CloudFront, S3, auto scaling, load balancer जुड़ जाएँ तो cost calculation exact science से ज़्यादा art बन जाती है।
      अगर आप यह सब इस्तेमाल ही नहीं कर रहे, तो AWS इस्तेमाल करने की वजह भी कम बचती है, और सस्ते VPS providers बहुत हैं।

  • OpenSearch और Valkey के मामले में “AWS ने fork बनाया, इसलिए license change हुआ” वाली बात पूरी तरह उलटी है।
    AWS ने fork तब बनाया जब upstream project ने license बदल दिया था, और खासकर Valkey तो Redis core team के पुराने सदस्यों ने बनाया था।

    • ऐसे कई projects का business model यह होता है कि core product open source रखा जाता है, और advanced services, installation, maintenance, managed service जैसी चीज़ों से कमाई की जाती है।
      AWS ने managed service देकर उन्हें bypass किया, इसलिए इस मामले में मैं project बनाने वालों के पक्ष में हूँ।
      मूल बात यह है कि AWS ने उनका रोज़गार छीन लिया, और उनके पास license बदलने के अलावा ज़्यादा विकल्प नहीं था।
    • वह license change खुद AWS द्वारा upstream project के काम को अस्थिर और टिकाऊ न रहने वाले तरीके से monetize करने की प्रतिक्रिया था।
    • सोचता हूँ, अगर Amazon अपने द्वारा बेचे जाने वाले open source software के creators और maintainers को हर billing period पर सिर्फ़ 1 cent ही दे, तो उस पर कितना असर पड़ेगा।
      शायद open source teams के लिए वह कुछ meaningful पैसा बन जाए, और वे बिना ज़्यादा जोखिम के product improvement में योगदान भी कर सकें।
    • जब मैंने पहली बार Redis में patch भेजा था, तो एक committer ने मेरे message का जवाब तक नहीं दिया और वही patch अपने नाम से डाल दिया। उसके बाद से कई open source project philosophies के लिए मेरी सहानुभूति कम हो गई।
      वे Valkey deserve करते हैं।
      JBoss और Marc Fleury भी अभी याद हैं।
    • AWS ने fork तभी बनाया जब license बदलकर उसे उस project के code से पैसा कमाने से रोका गया।
      बात का सार यही है।

  • मैं cloud services और self-hosting के बीच कई बार आ-जा चुका हूँ।
    शुरू में Vercel इस्तेमाल किया। Project Next.js में था, इसलिए experience ठीक था, लेकिन 100 users से भी कम वाले project के लिए $20/month देना low-performance जरूरतों के हिसाब से महँगा लगा।
    बाद में Hetzner और Coolify से अपना server setup बनाया। Coolify open source था, इसलिए सिर्फ़ VPS का खर्च था, और $5/month में PostgreSQL instance और web server चल जाता था।
    लेकिन PostgreSQL और Redis maintenance में फिर भी काफ़ी हाथ लगाना पड़ता था, और Docker container में होने के बावजूद services के बीच system variables और environment variables पास करना झंझट था।
    इसलिए बाद में मैं Cloudflare Workers, D1 Database, Cloudflare KV पर चला गया। Worker के अंदर से ही call किया जा सकता था, इसलिए env vars पास करने की ज़रूरत नहीं रही।
    local development experience भी अच्छा है और pricing भी reasonable, इसलिए तब से Cloudflare ecosystem ही इस्तेमाल कर रहा हूँ।

    • Cloudflare की offerings अब उस चीज़ के काफ़ी करीब आ गई हैं जो मैं AWS से चाहता था।
      basic full-stack app और file deployment बहुत सरल है, और AWS तो self-hosting से भी कहीं ज़्यादा कठिन हो गया है।
    • जिज्ञासा है कि क्या Docker ने PostgreSQL management सच में आसान बनाया?
      PostgreSQL में मुझे आम तौर पर बस major version upgrade के समय थोड़ी migration work ही दिक्कत लगती है।
      यह भी जानना है कि services के बीच system variables और environment variables पास करना Docker की वजह से और कठिन तो नहीं हुआ।
    • मैं Cloudflare Workers को पसंद करना चाहता था, और तकनीकी रूप से उसके पक्ष में अच्छे कारण भी हैं, लेकिन email activation जैसी चीज़ों के लिए Wrangler project इस्तेमाल करने का तरीका platform lock-in के बहुत करीब लगा।
      email allow करने के लिए ज़रूरी bindings सेट करनी पड़ती थीं, लेकिन console में उन्हें configure भी नहीं कर सकते थे, और Wrangler से सेट होने के बाद जैसे उन्हें देख भी नहीं सकते थे।

  • हैरानी है कि लेखक को DynamoDB पसंद नहीं है।
    यह मेरी सबसे पसंदीदा AWS services में से एक है — availability अच्छी है, operational burden नहीं के बराबर है, और जब-जब इस्तेमाल किया, cost भी काफ़ी कम रही।
    हाँ, data model पहले से सोच-समझकर design करना पड़ता है, और उसके लिए docs पढ़कर समझना ज़रूरी है।

    • DynamoDB को उसके intended तरीके से इस्तेमाल करें तो यह काफ़ी अच्छा है।
      इसे मूलतः अच्छी durability और लगभग असीम table scaling वाले एक अपेक्षाकृत सरल key-value store की तरह देखना चाहिए, न कि SQL database की तरह।
      prototype code से $75 का bill बनाने का सबसे आसान तरीका है इसे vibe coding के भरोसे SQL database की तरह treat करना, जहाँ JOIN और GROUP BY जैसा सोचा जाए।
      यह तब सबसे ज़्यादा चमकता है जब आपको छोटे persistent storage के लिए 1-2 tables चाहिएँ लेकिन पूरा RDBMS manage नहीं करना, या जब बहुत बड़ी table को सरल तरीके से query करना हो और RDBMS में फिट करने की ज़रूरत न हो।
    • DynamoDB और Lambda जैसी कई services के बहुत specific use cases हैं।
      एक खुशमिज़ाज key-value store को database की तरह मत चलाइए।
    • कुछ साल पहले एक app बनाते समय मुझे लगभग 5 करोड़ records, हर महीने करीब 10 हज़ार read+write operations, और 1 index store करने वाला DB चाहिए था।
      initial load cost लगभग $50 थी, और उसके बाद maintenance cost 10 cent/month जैसी थी।

  • ऐसे पोस्ट देखकर मुझे हमेशा हँसी आती है।
    बात सही भी है और ग़लत भी, और systems को “जितना संभव हो उतना सरल, लेकिन उससे ज़्यादा सरल नहीं” बनाना चाहिए।
    अगर आप सोचते हैं कि details को बस rough तरीके से पार कर लेंगे, तो बाद में और बड़ी झंझट होगी।
    IAM बस जटिल है।
    users, groups, roles, policies, identity providers, OIDC जैसी चीज़ों का कोई सचमुच सरल implementation मुझे याद नहीं आता।
    मैंने पहले एक ऐसे व्यक्ति को देखा था जिसने Kubernetes adoption का विरोध “बहुत complex” कहकर किया, और बाद में वही Vault, Consul, systemd, Nomad, iSCSI, Ansible, Jenkins, Puppet, Bash, थूक, घास-फूस से Kubernetes का बेहद घटिया और अस्थायी पुनर्निर्माण करता दिखा — और खूब गलतियाँ भी कीं।
    कुछ features शुरू में अनावश्यक लगते हैं, फिर आखिरकार वही ज़रूरी निकलते हैं।
    startup में solo infra engineer के तौर पर काम करने के अनुभव से कहूँ, तो AWS ज़्यादातर लोगों की सीखने की क्षमता के भीतर है, और इसके खराब हिस्सों से आम तौर पर बचा जा सकता है।
    अगर Lambda पसंद नहीं है, तो मत इस्तेमाल कीजिए — EKS, ECS, EC2 इस्तेमाल करिए।

    • अंदरूनी नज़रिए से IAM में शायद हज़ारों options हैं, लेकिन असल में सवाल यह है: “यह role किस चीज़ तक पहुँच सकता है और वहाँ क्या कर सकता है (action + resource)?” और “इस role तक कौन पहुँच सकता है?”
      10,000-foot view से देखें तो बस यही है।
      IAM अच्छा इसलिए है क्योंकि यह बाहर और अंदर दोनों पर एक जैसा लागू होता है।
      AWS की internal teams को कोई अतिरिक्त access इसलिए नहीं मिलता कि वे AWS हैं। अगर customer account में किसी specific service के लिए कुछ करने का हक़ है, तो इसलिए कि customer ने IAM trust relationship में उस service principal को access दिया है, और customer उसे देख और audit कर सकता है।
      उदाहरण के लिए Lambda के लिए Lambda role होता है, क्योंकि आप यह नहीं चाहेंगे कि सिर्फ़ “हम AWS हैं” कहकर Lambda service आपका S3 bucket पढ़ ले।
      AWS internal access भी customer साफ़ तौर पर देख और control कर सकता है।
    • “X बहुत complex है” कहकर adoption रोकना, और फिर आखिर में X का घटिया पुनर्निर्माण कर देना — यह pattern tech और software में आश्चर्यजनक रूप से आम है।
      कुछ चीज़ें अब साफ़ तौर पर standard हैं, फिर भी बहुत से लोग उन्हें ठीक से सीखने में समय देना नहीं चाहते।
    • self-hosting की तुलना में AWS महँगा हो सकता है, लेकिन वह बचत engineering cost के सामने छोटी पड़ जाती है।
      अगर एक अच्छा infra engineer “पैसा बचाने” के लिए OVH setup में 2 महीने लगा दे, तो सिर्फ़ Fargate या RDS न इस्तेमाल करने से जितना बचता, उससे ज़्यादा खर्च हो चुका होगा।

  • सोचता हूँ, Anthropic और OpenAI जैसी कंपनियों के बारे में भी यही बातें कब शुरू होंगी।
    मौजूदा AI wave में शुरुआती AWS जैसी गंध है — सब लोग चढ़ रहे हैं, और बाद में महसूस होगा कि उन्होंने एक ऐसी बड़ी dependency बना ली है जिसे आसानी से हटाया नहीं जा सकता।

  • Lambda सच में शानदार है, और बिना ज़्यादा सिरदर्द के तेज़ iteration cycle के साथ deployment service चलाने का बेहतरीन तरीका है।
    ज़रूरी नहीं कि आप microservices पर जाएँ या code को अरबों छोटे repos में तोड़ दें।
    अगर आप request के बीच server-side state share होने की उम्मीद नहीं करते, तो एक standard web server को Lambda पर ले जाया जा सकता है।

  • मैं उस field में काम नहीं करता, इसलिए AWS को कभी-कभी सिर्फ़ personal fun projects के लिए छूता हूँ, और हर बार यह दुःस्वप्न जैसा लगता है।
    मैं बस एक experimental card game server बनाना चाहता हूँ, कोई नई financial institution नहीं खड़ी कर रहा, लेकिन हर चीज़ ऐसे लगती है जैसे कल ही infinite scale के लिए तैयार होनी चाहिए, और मान लिया गया हो कि आपके पास 1,000 लोगों की org और VC budget है।
    शुक्र है कि Netlify जैसी services ऊपर एक layer दे देती हैं, जिससे पूरा समंदर उबालना नहीं पड़ता।
    शायद किसी दिन मुझे सच में IAM, VPN, और न जाने क्या-क्या सीखना पड़े, लेकिन तब तक AWS को छूते ही आँखें बाहर आने लगती हैं।

    • EC2 या Lightsail पर एक raw VPS चलाइए, public IP जोड़िए, और काम खत्म।
      हर enterprise pattern implement करना ज़रूरी नहीं है।
    • हैरानी होती है कि Heroku ने लगभग 20 साल पहले ही ज़्यादातर web apps की ज़रूरतों को कितना सटीक पकड़ा था।
    • अगर आपने Azure नहीं संभाला, तो AWS ही nightmare लगेगा।
    • मैं Cloudflare पर चला गया और सच में राहत मिली।
      ज़रूरत की सब चीज़ें हैं, और pricing भी reasonable है।
    • AWS personal projects नहीं, enterprise को target करता है।
      personal projects से आखिर में सिर्फ़ cost matter करती है, इसलिए वे AWS को कोई meaningful revenue नहीं देते।

  • 2023 के बाद से AWS में technical talent को व्यवस्थित रूप से खाली किया जा रहा है।
    यह बड़े layoffs या performance improvement plans के दो दौर से हुआ, और presales या support में जो capable लोग थे, उनमें से कई अब AWS में नहीं हैं।
    इसके उलट, जिन लोगों का कामकाजी इतिहास सबसे धुँधला था, वे बचे भी और promote भी हुए — ऐसा मैंने कई बार देखा।
    AWS को हर किसी को अपने जोखिम पर इस्तेमाल करना चाहिए; Paul Vixie आकर बचाने नहीं वाले।

  • बहुत पहले से ElastiCache मुझे खास तौर पर खटकता रहा है।
    RDS में scalability, reasonably optimized settings, और backups जैसी value add होती है जिनके लिए पैसा देना समझ में आता है।
    लेकिन ElastiCache में अतिरिक्त value लगभग नहीं के बराबर है, जबकि pricing शोषणकारी लगती है।
    basic Redis install की तुलना में यह धीमा है, कम optimized है, कम stable है, और बिना config वाला Redis कई DBs support करता है जबकि ElastiCache सिर्फ़ एक।
    scaling में कुछ सुधार ज़रूर हैं, लेकिन basic Redis समान instance पर ElastiCache से इतना आगे निकल जाता है कि उन सुधारों की वास्तविक ज़रूरत बहुत कम पड़ती है।

    • ElastiCache वाकई उन services में से है जहाँ self-hosting पर गंभीरता से विचार किया जा सकता है।
      AWS API या polish के मामले में बहुत कुछ extra नहीं देता, और दूसरी तरफ़ Redis/Valkey खुद host करने के लिए सबसे सरल services में से हैं।