2025 में AWS: वे बातें जिन्हें आप जानते हैं, लेकिन अब वे गलत हैं

• AWS की मुख्य services तेज़ी से evolve हो रही हैं
• EC2, S3, Lambda जैसे प्रमुख features अब पहले से अलग, users की expectations से भी बेहतर performance और flexibility दे रहे हैं
• Networking, authentication, cost savings options आदि में भी कई बदलाव और optimizations हुए हैं
• गलतफहमी पुराने blog posts या outdated जानकारी की वजह से हो सकती है
• AWS का सही इस्तेमाल करने के लिए latest updates और बदली हुई policies को समझना ज़रूरी है

---

AWS 2025: अतीत की समझ से अलग आज की वास्तविकता

• AWS लगभग 20 साल के इतिहास वाला cloud platform है, और इसी वजह से इसकी services से जुड़ी ‘सामान्य समझ’ लगातार बदलती रहती है
• पुराने users के लिए भी बदलाव की रफ्तार के साथ चलना मुश्किल हो गया है, क्योंकि कई core features में बड़ा सुधार हुआ है
• अब भी कई blog posts पुरानी जानकारी देते हैं, इसलिए यह ठीक-ठीक समझना ज़रूरी है कि वास्तविक configuration किन-किन तरीकों से बदल चुकी है

EC2

• EC2 instances के security groups और IAM roles अब बिना interruption के बदले जा सकते हैं
• चल रहे instance पर EBS volumes का size बदलना, attach/detach करना संभव है
• अब हाल के EC2 instances को force stop या terminate किया जा सकता है, इसलिए लंबे timeout का इंतज़ार करने की ज़रूरत नहीं
• physical hosts के बीच live migration feature आ गया है, इसलिए instance performance degradation warnings अब कम ही दिखती हैं
• instances की reliability काफ़ी बढ़ गई है, और पहले की तरह बिना warning के instance गायब हो जाना अब लगभग नहीं के बराबर है
• Spot instances की price fluctuation अब gradual हो गई है, इसलिए उन्हें trading pit की तरह real time में लगातार monitor करने की ज़रूरत कम हो गई है
• dedicated instances की ज़रूरत वाले cases अब बहुत कम रह गए हैं (HIPAA BAA भी लगभग 10 साल पहले से ज़रूरी नहीं रहा)
• AMI Block Public Access नए accounts में default रूप से enabled है (2023 के अनुसार, उन accounts पर भी लागू जिनके पास 90 दिनों से अधिक समय तक public AMI नहीं था)

S3

• S3 अब Eventually Consistent नहीं है, बल्कि Read-After-Write Consistency देता है
• object key के शुरुआती हिस्से को randomize करने की ज़रूरत नहीं रही, इसलिए data distribution और hotspot issues की चिंता कम हुई है
• ACLs (Access Control List) अब recommended नहीं हैं, और नए buckets में ये default रूप से बंद रहती हैं
• नए buckets में Block Public Access default रूप से set रहता है
• storage encryption अपने आप लागू हो जाती है
• Glacier, S3 का storage class बनने से पहले एक अलग service था, लेकिन अब यह integrated है। इसका निशान केवल billing details जैसी जगहों पर बचा है
• Glacier restore cost और speed पहले की तुलना में काफ़ी अधिक predictable और सस्ती हो गई है। पहले वाले डरावने restore charges अब सही नहीं माने जाते

Networking

• EC2-Classic पूरी तरह समाप्त हो चुका है
• public IPv4 addresses अब मुफ़्त नहीं हैं, और इन पर Elastic IP के समान cost लगती है
• VPC Peering की जगह Transit Gateway, VPC/resource sharing, Cloud WAN जैसे बेहतर options आ गए हैं
• VPC Lattice और Tailscale से complex networking problems को आसानी से हल किया जा सकता है
• CloudFront updates लागू होने का समय 45 मिनट से घटकर लगभग 5 मिनट रह गया है (हालाँकि CloudFormation deployment के इंतज़ार में यह अब भी लंबा लग सकता है)
• ELB Classic में cross-AZ data transfer charges लगते थे, जबकि ALB में केवल LCU charges लगते हैं। ध्यान रहे कि NLB में अब भी cross-AZ charges लगते हैं
• Network Load Balancer में security group support जोड़ दिया गया है
• Availability Zone IDs पहले account के हिसाब से अलग-अलग होते थे, लेकिन अब Resource Access Manager से Zone ID alignment संभव है

Lambda

• Lambda का 5 मिनट limit बढ़कर 15 मिनट हो गया है, और इसमें container images (Docker), EFS shared storage, अधिकतम 10GB RAM, तथा /tmp 10GB support भी जुड़ गया है
• VPC के अंदर Lambda invocation speed में बड़ा सुधार हुआ है
• cold start issue पहले की तुलना में काफ़ी कम हो गया है

EFS

• EFS IO performance tuning अब capacity से अलग नियंत्रित की जा सकती है, इसलिए बेकार data भरकर space बढ़ाने की ज़रूरत नहीं

EBS

• नए EBS volumes में, अगर कोई baseline data नहीं है, तो तुरंत maximum performance मिल सकती है
• snapshots से बने volumes में पहली data read धीमी हो सकती है, इसलिए पूरी disk को एक बार पढ़ लेना recommended है (हालाँकि इसके लिए तेज़ options भी उपलब्ध हैं)
• io1 volumes को कई EC2 instances से एक साथ attach किया जा सकता है, लेकिन व्यवहार में यह केवल बहुत खास परिस्थितियों में ही recommended है

DynamoDB

• items के अंदर empty fields अब allowed हैं
• performance अब कहीं अधिक consistent हो गई है, इसलिए पहले की तरह hot key issues को अलग tools से monitor करने की ज़रूरत कम हुई है
• Pricing changes के बाद, ज़्यादातर users के लिए On Demand type अधिक व्यावहारिक है

Cost Savings Vehicles

• Reserved Instances धीरे-धीरे phase out हो रहे हैं, और Savings Plans आगे का standard हैं। Savings Plans का discount RI की तुलना में कम हुआ है, लेकिन flexibility अधिक है
• EC2 usage charges per-second billing पर हैं, इसलिए बहुत कम समय के लिए instance चलाना भी cost-effective हो सकता है
• Cost Anomaly Detector अप्रत्याशित usage patterns को बहुत अच्छी accuracy से detect करता है और मुफ़्त है
• Compute Optimizer EBS सहित कई resources के लिए recommendations देता है और भरोसेमंद है। Trusted Advisor की recommendations अब भी उतनी consistent नहीं हैं

Authentication

• permissions देने के लिए IAM roles recommended हैं, और IAM users केवल legacy apps के लिए उपयुक्त हैं
• IAM Identity Center ने AWS SSO की जगह ले ली है और account access के लिए इस्तेमाल होता है। इससे कुछ confusion बना हुआ है
• root account पर multiple MFA devices register किए जा सकते हैं
• organization member accounts के लिए अलग से root credentials configure करने की ज़रूरत नहीं है

Miscellaneous

• us-east-1 की reliability और durability पहले की तुलना में बहुत बेहतर हो चुकी है। पहले की तरह बार-बार होने वाले outages अब इतनी बड़ी बात हो गए हैं कि वे news बनते हैं
• AWS services की deprecation अब भी कम होती है, लेकिन यह trend बढ़ रहा है, इसलिए छोटे services पर dependency सोच-समझकर रखनी चाहिए
• CloudWatch data का आख़िरी point mismatch के कारण असामान्य रूप से कम दिखने वाली समस्या अब नहीं होती
• root account से organization के member accounts के AWS accounts को सीधे close भी किया जा सकता है

[roxie]

वाह, सच में बहुत कुछ बदल गया है।

[howudoin]

अब AWS में कोई एकल सेवा चुनकर इस्तेमाल नहीं की जा सकती।
कुछ भी करना हो तो कई चीज़ों को आपस में जोड़कर इस्तेमाल करना पड़ता है।
यह बिल्कुल भी सरल नहीं है।
startup में इसे इस्तेमाल करना हो तो सिर्फ cloud cost ही नहीं, बल्कि DevOps मैनपावर की लागत भी उठानी पड़ती है।
इसे ठीक से सेटअप करने के लिए development time इतना खिंच जाता है कि काम का बोझ जरूरत से ज्यादा बढ़ जाता है।
इसके अलावा managed services का इस्तेमाल ज़्यादा फायदेमंद होने वाले मामले बढ़ रहे हैं, इसलिए code level पर ही platform dependency बन जाती है.

[GN⁺]

Hacker News की राय

• S3 का "Block Public Access" अब नए buckets पर डिफ़ॉल्ट रूप से लागू होता है, और यह साफ़ तौर पर सही फ़ैसला लगता है, क्योंकि गलत तरह से कॉन्फ़िगर किए गए S3 buckets की वजह से बहुत बड़े डेटा लीक होते रहे हैं, लेकिन कभी-कभी मैं public read permissions वाला S3 bucket बनाकर फाइलें सार्वजनिक रूप से serve करना चाहता हूँ, और हर बार कुछ न कुछ बदल जाता है, पुरानी recipe काम नहीं करती, और मुझे फिर से शुरुआत से सीखना पड़ता है
  • मैं कहना चाहूँगा कि "Block Public Access" सेटिंग को ध्यान से देखें, यह लोगों को बड़ी गलती करने से बचाने वाला एक तरह का safety catch है, अगर आप बहुत ढीली bucket policy या ACL (पुराना है लेकिन अभी भी इस्तेमाल होता है) सेट कर दें, तब भी अगर Block Public Access चालू है तो public access संभव नहीं होगा, दूसरी तरफ अगर Block Public Access बंद है और आपने बहुत अच्छी तरह से डिज़ाइन की हुई bucket policy लिखी है, तो वह ठीक है, bucket policy ही पूरी तरह तय करती है कि कौन access कर सकता है, बेशक लंबे समय में policy गलती से बदल सकती है, या कोई IAM role अनपेक्षित रूप से जुड़ सकता है, या trust policy बदल सकती है, इसलिए उसका प्रबंधन महत्वपूर्ण है
  • मैं ऐसी स्थिति में अक्सर LLM का उपयोग करता हूँ, उससे docs पढ़वाता हूँ और AWS की official docs में इधर-उधर पड़े demo code निकलवाने को कहता हूँ, फिर जो मिलता है उसके बाद अपनी ज़रूरत के custom बदलाव भी तुरंत पूछ लेता हूँ
  • इसे देखकर deja vu जैसा लगता है, जैसे यह पहले भी किया गया हो, 10 साल पहले भी लोग buckets खुले छोड़ देते थे, इसलिए शायद ऐसे कदम उठाए गए थे
  • ऐसे बदलावों की वजह से interview में "क्या आप इस technology से परिचित हैं?" जैसा सवाल बहुत अस्पष्ट हो जाता है, technology हर महीने बदलती है, तो मन करता है पूछूँ कि किस समय के मानदंड पर जानना है
  • आधिकारिक तौर पर सीखना हो तो $250 देकर certification exam भी दिलवा देते हैं
• EC2 में instance terminate किए बिना security group या IAM role बदलना कई सालों से संभव था, spot instances पहले bidding market थे, लेकिन अब bidding ही हट गई है, इसलिए अचानक price swings या केवल कुछ users तक access जैसी समस्याएँ भी खत्म हो गईं, और यह कहीं बेहतर है, साथ ही पहले object key का शुरुआती हिस्सा random बनाना पड़ता था ताकि hotspot से बचा जा सके, लेकिन अब उसकी ज़रूरत नहीं रही, सहकर्मियों को समझाने में काफी समय लगा, लेकिन वे लोग वैसे भी सिर्फ़ बेहद छोटे files स्टोर कर रहे थे जिनका S3 backend bottlenecks से कोई लेना-देना नहीं था, Lambda में पहले 5 मिनट की limit थी और container images का support भी नहीं था, लेकिन अब यह 15 मिनट runtime, Docker images, EFS sharing, अधिकतम 10GB RAM, और /tmp storage space 10GB तक support करता है, मुझे भी एक बात बाद में समझ आई कि Python global scope भी /tmp की तरह बना रहता है
• Glacier restore अब ज़रूरी नहीं कि तकलीफ़देह रूप से धीमा हो, Amazon के अंदाज़ में मैंने कभी सोचा था कि पुराना Glacier शायद सचमुच कहीं Amazon के किसी warehouse में चलता होगा, जैसे data request आने पर कोई worker shelf से removable media निकालकर server में लगाता हो, यह पुराने time-sharing computers की tape backup शैली जैसा लगता था, उस समय tape को सचमुच physical तौर पर बदलना पड़ता था
  • असल में ज़्यादा संभावना है कि वहाँ tape robots जैसे automated equipment इस्तेमाल होते रहे हों, संबंधित फोटो उदाहरण, यानी इंसान नहीं बल्कि robot tape निकालता, उसे drive में डालता, offset तक wind करता, पढ़ता, फिर rewind करके वापस रख देता, इंतज़ार tape खोजने, rewind करने, और drive उपलब्ध होने की वजह से होता, शायद efficiency के लिए एक बार tape डालकर उससे जुड़े सारे requests निपटाए जाते होंगे
  • मैं अंदरूनी बातों पर खुलकर नहीं बोल सकता, लेकिन मैंने किसी को Glacier की डिज़ाइन को पूरी तरह सही समझते नहीं देखा, मैं पहले AWS में था, और इतना कह सकता हूँ कि Glacier भी दूसरे AWS services की तरह उसी data center infrastructure में चलता था, engineering या product management में असली बात customer expectations को सही तरह manage करना है, अगर आप कहें कि upload limit 10 है लेकिन 12 upload करने दें, तो customer आगे से 12 की उम्मीद करने लगता है, expectation management बहुत महत्वपूर्ण है
  • hard disks एकरूप होते हैं, इसलिए मुझे लगता है warehouse automation robots से चल सकता है, इंसानों की ज़रूरत ज़्यादातर अलग-अलग आकार, रूप या दूसरे non-standard मामलों के लिए पड़ती है
  • वैसे भी ऐसे systems दशकों से robotic होते आए हैं
• मैं अब अपने AWS account में लॉग इन नहीं कर सकता, क्योंकि मैंने पहले से MFA सेट नहीं किया था, device जारी करवाने की कोशिश करूँ तो उसके लिए भी पहले login चाहिए, पहले से warning मिली थी, लेकिन login के बिना MFA device request न कर पाने की यह व्यवस्था काफ़ी परेशान करने वाली है
  • support team से संपर्क करना अच्छा रहेगा
    AWS Support से संपर्क करें
  • यह support team के लिए आसानी से हल किया जा सकने वाला issue लगता है
• मुझे लगता है मेरे जैसे बहुत लोग होंगे, जो AWS की पारंपरिक शैली—API Gateway, serverless Lambda, IAM roles सब मिलाकर जटिल setup—को अब छोड़कर सिर्फ़ EC2 या LightSail VPS, S3 bucket, और Route53 से domain जोड़कर बाकी चीज़ों की चिंता नहीं करना चाहते
  • अगर सिर्फ़ storage + VPS चाहिए, तो AWS की तुलना में पारंपरिक VPS काफ़ी सस्ता पड़ता है, मेरी सोच उलटी है: अगर AWS इस्तेमाल करना है, तो ठीक से और भरपूर करना चाहिए, जो भी delegate किया जा सकता है वह सब Amazon को सौंपकर efficiency और cost savings लेनी चाहिए, Step Functions, Lambda, और DynamoDB भी alternatives से बेहतर साबित हुए हैं, बस अफ़सोस यह है कि developers अक्सर vendor optimization का पूरा फायदा नहीं उठा पाते
  • वास्तव में cloud को सरल बनाने वाली कंपनियाँ भी बहुत हैं, और उसके कारण service-region restrictions या predictable billing जैसे मुद्दे हैं
  • IAM management इतना समय खा जाता है कि पहले जो समय system administration में जाता था, अब वह permissions management में चला जाता है, IAM इतना कठिन है कि कुल मिलाकर यह घाटे का सौदा लगता है, शायद VPS और अत्यधिक serverless least-privilege management के बीच कहीं sweet spot है, Fargate उसका एक उम्मीदवार लगता है, इसलिए मैं और migration करके प्रयोग करना चाहता हूँ
• काश AWS दूसरे क्षेत्रों का पीछा करने के चक्कर में AI में बेतरतीब चीज़ें निकालने के बजाय, उन "बुनियादी लेकिन महत्वपूर्ण services" पर ज़्यादा ध्यान देता जिनमें वह पहले से अच्छा है, AWS leadership GenAI में दिशा खोती हुई लगती है, लेकिन बुनियादी infrastructure वह अच्छा बनाता है, AI की वजह से वह panic mode में दिखता है, और customers के लिए यह बहुत बिखरा हुआ और असुविधाजनक हो गया है
  • मौजूदा leadership की दिशा यह है कि infrastructure को इस तरह बनाया जाए कि हर कोई बस model चुने और तुरंत इस्तेमाल कर सके, बिना जटिल setup के तुरंत चलने वाला environment बनाया जाए
• यह सचमुच बेमानी लगता है कि S3 bucket अगर VPC के उसी region में हो, तब भी अगर public internet के रास्ते जाए तो NAT Gateway charges लगते हैं, डिफ़ॉल्ट को opt-out होना चाहिए, लेकिन opt-in डिफ़ॉल्ट होना शायद इसलिए है क्योंकि AWS इस architecture से extra revenue कमाता है, शायद बहुत कम users वास्तव में मौजूदा path चाहते होंगे
  • यह security-by-default को ध्यान में रखकर किया गया design है, जब तक NAT Gateway, VPC Gateway Endpoint (S3), या अन्य internet egress सेट न हों, workload S3 तक पहुँच ही नहीं सकता, networking का बंद होना सही है, और अगर user path को ठीक से समझे बिना कुछ बनाता है, तो उसकी ज़िम्मेदारी customer की है, AWS को Infrastructure as a Service (IaaS) के कच्चे tools देने वाला provider समझना चाहिए
  • S3 VPC Gateway Endpoint का उद्देश्य यही है, और इसका charge भी नहीं है
    AWS official docs
  • VPC, subnets, PrivateLink endpoints वगैरह सब सेट करने के बाद यह सचमुच हास्यास्पद लगता है, PrivateLink नाम रखने में भी काफ़ी मेहनत की गई है (तकनीकी तौर पर अर्थ भी है), लेकिन लगता है ऐसी चीज़ें तो शुरुआत से बिना setup के मिलनी चाहिए थीं, यहाँ तक कि अगर private subnet इस्तेमाल करें तो S3 जैसी services तक पहुँचने का यही एकमात्र तरीका नहीं है क्या, यह अजीब लगता है
  • मुझे लगता है VPC endpoints सबके लिए मुफ़्त और डिफ़ॉल्ट रूप से लागू होने चाहिए, अपनी ही service APIs इस्तेमाल करने पर भी extra billing कुछ ज़्यादा ही है
  • यह price discrimination के लिए है, जो customers price-sensitive नहीं हैं वे इसकी परवाह नहीं करते, और जिन्हें परवाह है वे cost कम करने की कोशिश करते हैं, और ऐसी स्थिति में भी अक्सर मजबूरी में AWS ही इस्तेमाल करना पड़ता है
• इस लेख की वजह से मुझे राहत मिली, मैं हमेशा चिंतित रहता था कि कहीं Amazon कुछ बहुत बड़ा बदलकर migration के लिए मजबूर न कर दे, लेकिन 2013 से मैं EC2 instances को लगभग बिना manage किए आराम से इस्तेमाल कर रहा हूँ, यह अच्छा है कि कोई अप्रत्याशित बदलाव नहीं हुआ
• यह जानकर हैरानी हुई कि पहले Availability Zones का mapping account के हिसाब से random हुआ करता था
  • इसका उद्देश्य load balancing था, अगर कई accounts एक ही AZ जैसे 1b को चुनते, तो भी असली physical distribution समान रहे, बाद में AZ के canonical names दिए गए, शायद इसलिए कि hotspot बनाने वाले accounts और metadata की ज़रूरत वाले accounts अलग थे
  • मेरा मानना है कि डिफ़ॉल्ट settings में अगर सब us-east-1a ही चुन लेते, तो एक ही AZ पर ज़्यादा load पड़ने से बचाने के लिए ऐसा किया गया था
  • शुरुआत में यह load balancing के लिए अच्छा था, लेकिन कई accounts के बीच networking (जैसे PrivateLink) जोड़ते समय यह बहुत भ्रमित करता था, क्योंकि हर बार देखना पड़ता था कि कौन-सा AZ किससे match करता है, इसलिए हमने account-दर-account one-to-one mapping methodology बनाई और internal lookup tables भी बनाए, बाद में AWS ने metadata में zone ID जोड़ दिया ताकि उसे आसानी से देखा जा सके
  • इस policy की वजह से मुझे सच में बहुत परेशानी हुई है
• एक बात सुधारना चाहता हूँ, बेकार-सी trivia भी पूरी तरह उलट सकती है
  Weird Al: Everything You Know is Wrong
  Firesign Theatre: Everything You Know is Wrong