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

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

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

💳 On-demand विरुद्ध Savings Plans विरुद्ध spot — धडा 08

⏮️ cloud pricing models आधी

शाळा वर्षातील सर्वात गर्दीच्या दिवसासाठी servers विकत घेत आणि प्रत्येक शांत दिवशीही त्यांचे पैसे भरत.

✅ फायदे

  • on-demand: कोणतेही वचन नाही, कधीही बंद करा
  • Savings Plans: 1–3 वर्षांच्या खर्चाच्या वचनासाठी साधारण एक चतुर्थांश ते अर्धी सूट
  • spot: रिकाम्या क्षमतेसाठी अनेकदा 60–90% सूट

❌ तोटे

  • on-demand प्रति तास सर्वात महाग
  • तुम्ही वापरणे थांबवले तरी Savings Plan चे bill येते
  • spot 2 मिनिटांच्या सूचनेवर परत घेतला जाऊ शकतो

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

  • स्थिर मूळ load: Savings Plan · चढउतार: on-demand + Auto Scaling · batch, CI, stateless workers: spot

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

  • तुमच्या एकमेव database साठी spot
  • पुढच्या वर्षी संपू शकणाऱ्या project साठी 3 वर्षांचे वचन

💾 EBS विरुद्ध instance store — धडा 04

⏮️ network disks आधी

data server च्या स्वतःच्या disk वर राहायचा; server मेला की data पण गेला.

✅ फायदे

  • EBS: stop आणि (अतिरिक्त volumes साठी) terminate नंतरही टिकतो, snapshots, चालू असतानाच resize
  • instance store: खूप जलद स्थानिक disk, instance सोबत मोफत

❌ तोटे

  • EBS एकाच AZ मध्ये राहतो आणि एक network hop दूर असतो
  • stop किंवा hardware बिघाडावर instance store पुसला जातो

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

  • जपून ठेवायलाच हवे अशा सगळ्यासाठी EBS
  • caches आणि कच्च्या कामाच्या जागेसाठी instance store

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

  • replication शिवाय instance store वर database
  • root volume वरचे DeleteOnTermination विसरणे

🧍 Security groups विरुद्ध network ACLs — धडा 05

⏮️ दोन्हीपैकी काहीही येण्याआधी

संपूर्ण network च्या काठावर एकच firewall; आत प्रत्येक server प्रत्येक दुसऱ्यापर्यंत पोहोचू शकत असे.

✅ फायदे

  • security group: प्रत्येक network card साठी, फक्त allow, stateful — सोपे आणि अचूक
  • NACL: प्रत्येक subnet साठी, क्रमांकित allow/deny, दुसरी भिंत

❌ तोटे

  • security groups DENY म्हणू शकत नाहीत
  • NACLs stateless आहेत — reply ports विसरलात तर सगळे अडकते

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

  • जवळजवळ सगळ्यासाठी security groups; groups चा उल्लेख ID ने करा
  • संपूर्ण subnet भर मोठ्या बंदीसाठी NACLs

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

  • port 22 वर 0.0.0.0/0
  • कोणी जोडले हे कोणालाच आठवत नाही असे NACL rules

🔑 SSH keys विरुद्ध Session Manager — धडा 06

⏮️ Session Manager आधी

Port 22 जगासाठी उघडा, एकच सामायिक .pem फाइल लोकांमध्ये email ने फिरणारी.

✅ फायदे

  • Session Manager: inbound port नाही, keys नाहीत, IAM ठरवतो, प्रत्येक session ची नोंद
  • SSH: सार्वत्रिक, सगळीकडे चालतो, झटपट labs साठी ठीक

❌ तोटे

  • SSM ला instance वर agent आणि role लागतो
  • SSH keys बदलणे आणि तपासणे अवघड

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

  • खऱ्या कामासाठी Session Manager
  • labs साठी तुमच्या स्वतःच्या IP वरून SSH

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

  • port 22 0.0.0.0/0 साठी उघडा
  • एकच key अनेक लोकांमध्ये वाटणे

👯 मोठा बाक विरुद्ध अधिक बाक — धडा 09

⏮️ Auto Scaling आधी

site मंद झाली की कोणीतरी server बंद करून मोठ्या server वर हलवायचे — बंद राहण्याच्या वेळेसह.

✅ फायदे

  • अधिक बाक: एकच बिघाड-बिंदू नाही, मागणीप्रमाणे वाढतात आणि कमी होतात
  • मोठा बाक: app मध्ये काहीच बदलायला नको

❌ तोटे

  • अधिक बाकांसाठी stateless app आणि load balancer लागतो
  • मोठ्या बाकाला छत असते आणि तो तरीही एकच बाक असतो

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

  • web आणि API tiers: load balancer मागे अधिक बाक
  • एकच database: मोठा बाक (किंवा managed service)

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

  • बाकावरच sessions ठेवणाऱ्या app ला Auto Scaling
  • अडथळा database मध्ये असताना CPU वर scaling

⚙️ Graviton (ARM) विरुद्ध x86 — धडा 02

⏮️ Graviton आधी

प्रत्येक EC2 बाक Intel किंवा AMD चा होता.

✅ फायदे

  • Graviton: या lab च्या किमतींमध्ये सारख्याच आकारासाठी प्रति तास सुमारे 20% स्वस्त, अनेकदा प्रति डॉलर चांगली कामगिरी
  • x86: जुन्या binaries सह सगळे काही चालवतो

❌ तोटे

  • ARM ला तुमच्या software आणि images चे ARM builds लागतात
  • काही व्यावसायिक software फक्त x86 साठीच असते

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

  • नवीन services, multi-arch images असलेले containers, Java, Python, Go, Node सारख्या भाषा

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

  • ARM build नसलेले जुने फक्त-binary tool

📸 जागीच patch विरुद्ध बाक बदलणे — धडा 12

⏮️ immutable infrastructure आधी

Admins login करून हाताने updates चालवत; प्रत्येक server हळूहळू वेगळा, एकमेवाद्वितीय हिमकण बनत असे.

✅ फायदे

  • बदलणे: golden AMI तयार करा, instance refresh ने पसरवा — प्रत्येक बाक एकसारखा
  • जागीच patch (Patch Manager): नवीन AMI ची गरज नाही

❌ तोटे

  • बदलण्यासाठी automation आणि stateless बाक लागतात
  • जागीच patching मुळे बाक कालांतराने एकमेकांपासून वेगळे होत जातात

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

  • load balancer मागचे ताफे: बदला
  • काही दीर्घकाळ चालणारे लाडके pets: maintenance windows सह Patch Manager

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

  • production ला हाताने patch करण्यासाठी SSH ने आत जाणे
  • वर्षभर कोणी पुन्हा build न केलेले AMI