← कोर्सच्या मुख्य पानाकडे परत

⏮️ आधी काय होते & फायदे-तोटे

प्रत्येक साधनाने काहीतरी वाईट गोष्ट बदलली — आणि तेच साधन कुठेतरी चुकीचे ठरते. या कोर्समधील प्रत्येक मोठ्या कल्पनेसाठी: ती येण्याआधी जीवन कसे होते, तिचे प्रामाणिक फायदे ✅ आणि तोटे ❌, आणि कुठे वापरावी 👍 विरुद्ध कुठे नाही 👎.

🪪 IAM — ओळख & प्रवेश व्यवस्थापन (धडे 01–06)

⏮️ IAM च्या आधी (2011 मध्ये सुरू)

सुरुवातीच्या AWS खात्यांना मुळात एकच login: root होते. टीम तो पासवर्ड spreadsheet किंवा chat मध्ये वाटून घेत. प्रत्येकजण सर्वशक्तिमान; कोणीही जबाबदार नाही ("bucket कोणी हटवले?" — शांतता); कर्मचारी सोडून गेला की सगळ्यांसाठी "तो" पासवर्ड बदलावा लागे. त्याआधी on-prem: सामायिक admin खाती आणि चिकट चिठ्ठ्या. IAM ने प्रत्येक व्यक्तीला ओळख, प्रत्येक कृतीला परवानगी, आणि audit trail आणले.

✅ फायदे

  • प्रत्येक व्यक्ती/रोबोटला स्वतःची तपासलेली ओळख
  • least privilege मुळात शक्य (प्रत्येक कृतीसाठी चिठ्ठी)
  • audit: प्रत्येक कॉल कोणाचा ते सांगता येते (CloudTrail सह)
  • मोफत — पूर्ण न वापरण्याला सबब नाही

❌ तोटे

  • policy JSON पटकन गुंतागुंतीचे होते (ARNs, conditions)
  • "AccessDenied" debug करण्यात दुपार जाऊ शकते
  • वैतागून जास्त परवानगी देणे सोपे (Admin*)

👍 वापरा जेव्हा

  • नेहमी — AWS वरच्या तुमच्या पहिल्या दिवसापासून
  • एकट्याच्या खात्यातही वेगळ्या ओळखी (तुम्ही + CI)

👎 दोनदा विचार करा जेव्हा

  • …कधीच नाही. पण टाळा: रोज root वापर, सामायिक users, आणि सगळ्यासाठी एक महा-policy

आकृती ↗

🎩 Roles (तात्पुरती credentials) विरुद्ध दीर्घकालीन access keys (धडे 04–05)

⏮️ roles & STS च्या आधी

मशीन AKIA… access keys ने ओळख पटवत — config फाइल्स, CI settings आणि (दुर्दैवाने अनेकदा) git रेपोंमध्ये चिकटवलेले कायमचे पासवर्ड. key गळणे हे अजूनही AWS खाते हॅक होण्याचे #1 कारण आहे; माफीआधी crypto-mining चे बिल येते. Roles ने मॉडेल उलटे केले: ओळखी ज्या तुम्ही थोडा वेळ घालता, credentials जी तासाभरात संपतात.

✅ फायदे (roles)

  • credentials संपतात — गळतीचा परिणाम 1 तासापुरता
  • साठवायला काही नाही: EC2/EKS ना त्यांची metadata मधून मिळतात
  • OIDC ने CI: pipeline settings मध्ये शून्य secrets
  • audit व्यक्ती आणि घातलेली टोपी दोन्ही दाखवते

❌ तोटे

  • trust policies म्हणजे विचार करायचा आणखी एक दस्तऐवज
  • role-chaining/debugging ला सराव लागतो
  • स्थानिक लॅपटॉपना अजूनही SSO किंवा (काळजीपूर्वक) keys लागतात

👍 Roles, जेव्हा

  • प्रत्येक मशीन: EC2, EKS, Lambda, CI — अपवाद नाही
  • माणसे IAM Identity Center (SSO) सत्रांद्वारे

👎 Keys फक्त जेव्हा

  • तृतीय-पक्ष साधन खरोखर roles घेऊ शकत नाही
  • …मग: किमान policy, rotation, आणि पश्चात्ताप 😄

आकृत्या ↗

🖥️ EC2 — भाड्याचे संगणक (धडे 07–12)

⏮️ EC2 च्या आधी (2006)

सर्व्हर विकत घेणे. वर्षभर आधी क्षमता-नियोजन, purchase orders, delivery साठी आठवडे वाट, हार्डवेअर rack मध्ये लावणे, आणि वापरले किंवा नाही तरी पैसे भरणे. startup चा पहिला खर्च म्हणजे सर्व्हर रूम. EC2 ची क्रांतिकारी कल्पना: मिनिटांत संगणक, तासाने, कधीही परत द्या — compute ही विजेसारखी सुविधा.

✅ फायदे

  • मिळायला मिनिटे, सेकंदांवर बिलिंग
  • स्कूटरपासून ट्रकपर्यंत प्रत्येक आकार, GPU सह
  • पूर्ण नियंत्रण: तुमचे OS, तुमचे सॉफ्टवेअर, तुमचा kernel
  • बाकी सगळे (EKS!) ज्यावर चालते तो पाया

❌ तोटे

  • तुम्ही OS patch, सुरक्षित आणि सांभाळता
  • रिकामे instances गुपचूप बिल लावतात (क्लासिक बिल-धक्का)
  • cattle शिस्त पाळली नाही तर pets साचतात

👍 वापरा जेव्हा

  • तुम्हाला पूर्ण OS नियंत्रण किंवा खास सॉफ्टवेअर हवे
  • स्थिर, अंदाजे workloads (savings plans सह)
  • managed-सेवेचा पाया म्हणून (EKS nodes) — बहुतेक अदृश्य

👎 दोनदा विचार करा जेव्हा

  • event-driven स्क्रिप्ट → Lambda (सर्व्हरच नाही)
  • containerized web ॲप → Fargate/Cloud Run शैली
  • तुम्हाला पुन्हा कधीच SSH करायचे नाही → सगळे managed

आकृती ↗

🎟️ Spot instances (धडा 08)

⏮️ spot च्या आधी

AWS चे रिकामे बाक रिकामेच बसत; तुमचे batch jobs पूर्ण किंमत देत. Spot (2009) रिकाम्या जागांचा लिलाव करते: ~90% पर्यंत स्वस्त, एका अटीवर — पूर्ण भाडे देणारा ग्राहक आला की AWS दोन मिनिटांच्या सूचनेने जागा परत घेऊ शकते.

✅ फायदे

  • on-demand पेक्षा ~60–90% स्वस्त
  • k8s साठी उत्तम: pods फक्त पुन्हा schedule होतात (☸️ चा धडा 03)
  • झटक्यांत प्रचंड प्रमाण उपलब्ध

❌ तोटे

  • 2 मिनिटांच्या सूचनेने गायब होऊ शकते
  • क्षमता type/AZ/वेळेनुसार बदलते
  • व्यत्यय सहन करणारी रचना लागते (checkpoints, queues)

👍 वापरा जेव्हा

  • batch jobs, CI runners, rendering, big data
  • on-demand पायासोबत मिसळलेले stateless k8s workers

👎 दोनदा विचार करा जेव्हा

  • डेटाबेस किंवा stateful-आणि-एकमेव काहीही
  • हलू न शकणारे latency-critical singletons

आकृती ↗

🛗 SSM Session Manager विरुद्ध SSH (धडा 09)

⏮️ SSM च्या आधी

सगळे SSH करत: port 22 ऑफिसच्या IP साठी (किंवा वाईट, जगासाठी) उघडा, लोक येताना-जाताना key फाइल्स हातोहात, सांभाळायला bastion hosts, आणि कोणी काय टाइप केले याची शून्य नोंद. Session Manager (2018) shell AWS च्या API मधून नेतो — उघडा port नाही, सामायिक keys नाहीत, प्रत्येक सत्र log करता येणारे.

✅ SSM चे फायदे

  • आत येणारा port अजिबात नाही — scan करायला काही नाही
  • IAM द्वारे प्रवेश (key फाइल नव्हे, व्यक्ती रद्द करा)
  • सत्रे audit/record करता येणारी
  • public IP किंवा bastion शिवाय चालते

❌ SSM चे तोटे

  • agent + instance role setup लागते
  • किंचित हळू; फाइल हस्तांतरण अवघड
  • शिकायला आणखी एक AWS-विशिष्ट गोष्ट

👍 SSH अजूनही ठीक जेव्हा

  • झटपट वैयक्तिक प्रयोग (या कोर्ससारखे — फक्त तुमच्या IP वरून)
  • rsync/scp-भरपूर workflows
  • AWS नसलेली मशीन (SSM AWS-आकाराचे आहे)

👎 पूर्ण टाळा

  • port 22 0.0.0.0/0 साठी उघडा — क्लासिक honeypot
  • टीमने वाटून घेतलेल्या खाजगी key फाइल्स
  • कोणीही patch न करणारे दीर्घकालीन bastions

आकृती ↗

🗃️ RDS — managed डेटाबेस विरुद्ध स्वतः चालवणे (धडा 17)

⏮️ managed डेटाबेसच्या आधी

प्रत्येक टीम स्वतःच्या मशीनवर Postgres/MySQL चालवत असे: DBA (किंवा दुर्दैवी डेव्हलपर) backups, patches, replication आणि पहाटे 3 च्या failovers चा मालक. RDS (2009) तुम्हाला कारकुनासह डेटाबेस भाड्याने देते — कौशल्याचे भाग तपासलेले आणि कंटाळवाणे येतात.

✅ फायदे

  • खरोखर restore होणारे backups (point-in-time)
  • ~एका मिनिटात Multi-AZ failover, नाट्य नाही
  • patching, metrics, read replicas — समाविष्ट

❌ तोटे

  • तासाने बिल, रिकामे असो वा नसो (धडा 20!)
  • OS प्रवेश नाही; extension यादी निवडक
  • engine आधी पाकीट संपणे सोपे

👍 वापरा जेव्हा

  • टिकलीच पाहिजे अशी state — जवळपास नेहमी
  • छोट्या टीम: कंटाळवाणे विकत घ्या, खास बनवा
  • k8s ॲप्ससाठीही: cluster मध्ये stateless, state RDS मध्ये

👎 दोनदा विचार करा जेव्हा

  • RDS देत नाही असे खास engines/extensions
  • प्रत्येक tenant साठी DB चे ताफे जिथे खर्च फुटतो
  • तुमच्याकडे ते चालवायला खरोखर टीम आहे (दुर्मीळ)

आकृती ↗

⚡ Lambda — serverless विरुद्ध बाक भाड्याने घेणे (धडा 19)

⏮️ serverless च्या आधी

दिवसातून एकदाच्या कामासाठीही 24/7 चालणारा बाक लागे — patched, monitored, आणि रिकामा असतानाही बिल. Lambda (2014) ने compute चे एकक "एक मशीन" वरून "एक काम" केले: कोड बोलावल्यावर येतो, नंतर नाहीसा होतो, आणि रिकामेपणाचा खर्च शून्य.

✅ फायदे

  • रिकामे = $0 · महिन्याला दहा लाख कामे मोफत
  • scaling अंगभूत: प्रत्येक कामाला एक मदतनीस
  • patch करायला OS नाही, सांभाळायला ताफा नाही

❌ तोटे

  • cold starts (~100ms–2s) latency-critical API ना टोचतात
  • 15 मिनिटांची मर्यादा; स्थिर जड load बाकांपेक्षा जास्त महाग
  • स्थानिक dev/debug अवघड; vendor-आकाराचे

👍 वापरा जेव्हा

  • event glue: uploads, webhooks, queues, वेळापत्रके
  • तुरळक किंवा दुर्मीळ workloads (दिवसातून एकदाचा अहवाल)
  • ops automation — धडा 12 च्या स्क्रिप्ट, serverless

👎 दोनदा विचार करा जेव्हा

  • सतत जास्त traffic (खर्चात बाक/k8s जिंकतात)
  • दीर्घकाळ चालणारी jobs, तासन्‌तास धरलेले websockets
  • खास हार्डवेअर (GPU) किंवा प्रचंड memory

आकृती ↗

🛡️ WAF — फक्त security groups विरुद्ध web firewall (धडा 24)

⏮️ web firewalls च्या आधी

सीमा म्हणजे port ची यादी: 443 वर कोण ठोठावू शकते हे SG ठरवत, आणि 443 वर आलेले सगळे ॲपपर्यंत पोहोचे — injections, scanners, पूर सगळे. Application-थरातले हल्ले ही ॲपची समस्या होती; प्रत्येक टीम स्वतःचे (अर्धवट) बचाव लिहीत असे.

✅ फायदे

  • स्वतःहून update होणारी managed नियमपुस्तके
  • rate limits रिसेप्शनआधी पूर थांबवतात
  • logs "आमच्यावर हल्ला झाला" चे graph मध्ये रूपांतर करतात

❌ तोटे

  • खोटे positives — पहिल्या दिवशी block, एखादा फॉर्म मोडतो
  • प्रत्येक ACL, नियम, विनंतीचे पैसे
  • auth bugs किंवा business-logic गैरवापर दुरुस्त करू शकत नाही

👍 वापरा जेव्हा

  • ALB/API Gateway/CloudFront वरचे सार्वजनिक काहीही
  • तुमची एकदाही चाचपणी किंवा पूर झाला असेल
  • compliance विचारते "तुमचा WAF कुठे आहे?"

👎 दोनदा विचार करा जेव्हा

  • VPN मागच्या फक्त-अंतर्गत सेवा
  • तुम्ही आधी count mode मध्ये एक दिवस घालवू शकत नाही
  • WAF वाचू शकत नाही असे प्रोटोकॉल (NLB मागचे कच्चे TCP)

आकृती ↗

🎟️ API Gateway विरुद्ध तुमच्या API समोरचा ALB (धडा 25)

⏮️ API gateways च्या आधी

Auth, throttling, API keys, staging आणि metering हा प्रत्येक सेवेच्या आतला कोड होता — किंवा मध्यरात्री कोणीतरी patch करणारा हाताने चालवलेला nginx/Kong बॉक्स. API Gateway (2015) ने फ्रंट डेस्कला configuration बनवले, प्रत्येक विनंतीला बिल.

✅ API Gateway चे फायदे

  • auth, throttling, keys, stages config म्हणून — कोड नाही
  • रिकामे = $0; Lambda सोबत नैसर्गिक जोडी
  • प्रत्येक route चे metrics, logs, transformations

❌ तोटे

  • स्थिर जास्त volume वर प्रत्येक-विनंती किंमत दुखते
  • 29 सेकंदांचा integration timeout, 10 MB payloads
  • incidents मध्ये विचार करायचा आणखी एक थर

👍 API Gateway जेव्हा

  • serverless backends, partner APIs, webhooks
  • तुम्हाला JWT/keys/quotas लिहिल्याशिवाय हवेत
  • तुरळक किंवा कमी traffic (रिकामे मोफत असावे)

👎 त्याऐवजी ALB जेव्हा

  • बाकांकडे स्थिर जड traffic — तासाने प्रत्येक-विनंतीला हरवते
  • तासन्‌तास धरलेले WebSockets, मोठे uploads, लांब jobs
  • तुमच्याकडे आधीच ॲपमध्ये auth असलेले ingress आहे

आकृती ↗