भाग 1: बाक भाड्याने घेणे (नारिंगी, 1–6) · भाग 2: ताफा चालवणे (निळा, 7–12). प्रत्येक आकृती खऱ्या lab मधून काढली आहे — ec2/demo.py छापतो ते credit balances, packet निर्णय, fleet table आणि किमती — आणि प्रत्येकीखाली स्वतः करून पाहण्यासाठी एक lab आहे. वर्तुळातील क्रमांकांप्रमाणे जा 1 → 2 → 3.
1 🖥️ EC2 का — regions आणि AZs
सेकंदाच्या हिशोबाने बाक भाड्याने घ्या — वेगवेगळ्या इमारतींच्या जिल्ह्यात, म्हणजे एका इमारतीची वीज गेली तरी शाळा कधीच बंद होत नाही.
🧒 सोप्या शब्दांत
परीक्षेचा आठवडा जवळ आला आहे आणि शाळेला चाळीस गृहपाठाचे डेस्क हवे आहेत, पण फक्त एका महिन्यासाठी. ते विकत घेण्याऐवजी शाळा एका अभ्यासिका कंपनीकडून डेस्क भाड्याने घेते आणि मुले बसतील तेवढ्याच वेळेचे पैसे भरते. कंपनीच्या प्रत्येक जिल्ह्यात वेगवेगळ्या इमारती आहेत, प्रत्येकीची स्वतःची वीज, म्हणून शाळा प्रत्येक इमारतीत एक डेस्क ठेवते: एका इमारतीतील वीज गेली तरी बाकीचे चालू राहतात.
📖 नवे शब्दEC2 — cloud मध्ये computers भाड्याने घेणे आणि वापरलेल्या सेकंदांचेच पैसे भरणेinstance — भाड्याने घेतलेला एक computer, अभ्यासिकेतील एका भाड्याच्या डेस्कसारखाRegion — AWS च्या इमारती असलेला जिल्हा, जसे मुंबई (ap-south-1)Availability Zone — Region मधली एक वेगळी इमारत, जिची स्वतःची वीज आणि network असते
⏪ आधी
स्वतःचे servers घेतले की वर्षभर सर्वात गर्दीच्या दिवसाचा खर्च भरावा लागे, आणि एका इमारतीतील वीज गेली की संपूर्ण site बंद पडे.
💡 काय
EC2 म्हणजे सेकंदाच्या हिशोबाने भाड्याने मिळणारे virtual servers (instances), वेगवेगळ्या Availability Zones असलेल्या Regions मध्ये.
⚙️ कसे
तिन्ही डेस्क AZ-a मध्ये असतील तर वीज गेल्यावर 3 पैकी 0 चालू राहतात; AZ-a, b आणि c मध्ये पसरवले तर 3 पैकी 2 चालू राहतात.
🎯 का
डेस्क अनेक AZs मध्ये पसरवणे हा AWS मधील सर्वात स्वस्त विश्वासार्हतेचा निर्णय आहे, आणि डेस्क stop केल्यावर compute चे बिल थांबते.
🚀 पुढे
पुढचा धडा कामासाठी योग्य डेस्क निवडतो: instance families, sizes, Graviton आणि burstable CPU credits.
🧪 Try it here — तीन बाक ठेवा, मग एका इमारतीची वीज कापा
कामासाठी योग्य वाहन निवडा — families, sizes, Graviton, आणि CPU credits ची burstable इंधन टाकी.
🧒 सोप्या शब्दांत
पत्र टाकायला स्कूटर घेतो; वाचनालय हलवायला ट्रक. अभ्यासिकेतील डेस्कही families मध्ये येतात: हलक्या कामासाठी लहान, जड कामासाठी मोठे. सर्वात लहान डेस्कना CPU credits ची छोटी इंधन टाकी असते: हळू काम केले तर ती भरते, पूर्ण ताकदीने केले तर रिकामी होते, आणि मग डेस्क रांगत चालतो.
📖 नवे शब्दinstance type — डेस्कचा आकार आणि प्रकार, m7g.large सारखा लिहिलेलाvCPU — computer मधला एक कामगार thread; जास्त vCPU म्हणजे एकाच वेळी जास्त कामGraviton — AWS ची स्वतःची chip, नावात g ने दाखवलेली, त्याच size ला सहसा स्वस्तCPU credits — लहान t डेस्कची इंधन टाकी: पूर्ण वेग ती संपवतो, मग डेस्क मंद होतो
⏪ आधी
अंदाजाने type निवडला तर दर तासाला पैसे वाया जातात, किंवा एखादा t3.micro दुपारनंतर अचानक मंद होतो.
💡 काय
m7g.large सारख्या नावाचा अर्थ: family m, generation 7, g म्हणजे Graviton (ARM), आणि size large: 2 vCPU आणि 8 GiB.
⚙️ कसे
t3.micro तासाला 12 credits कमावतो आणि 288 पर्यंत साठवतो; 100% वर पहिल्या तासानंतर 36 उरतात, मग (standard mode मध्ये) तो 10% baseline वर येतो.
🎯 का
Type म्हणजेच बिलाचा मोठा भाग: m7g.large सुमारे $0.0816/h, तर m7i.large $0.1008/h, म्हणजे जवळपास 19% कमी.
🚀 पुढे
पुढे, कोणी बसण्याआधी प्रत्येक डेस्कवर काहीतरी हवे: AMIs, launch templates आणि user data.
🧪 Try it here — t3.micro चा CPU जाळा आणि इंधन टाकी पहा (12/h कमाई, कमाल 288, 2 vCPU)
बाकाचा साचा आणि पाककृती कार्ड — प्रत्येक बाक एकसारखा, पहिल्या boot च्या script ने तयार केलेला.
🧒 सोप्या शब्दांत
नवीन डेस्क आला की तो शून्यातून कोणालाच मांडायचा नसतो. अभ्यासिका नक्कल करण्यासाठी एक परिपूर्ण नमुना डेस्क ठेवते, आणि भिंतीवर एक recipe card: कोणत्या size चा डेस्क, कोणता ड्रॉवर, कोणता badge, आणि पहिल्या सकाळी एकदाच करायच्या कामांची छोटी यादी. प्रत्येक नवा डेस्क सारखाच बनतो, म्हणून बिघडलेला सरळ बदलला जातो.
📖 नवे शब्दAMI — ज्याची नक्कल करून प्रत्येक नवा डेस्क बनतो तो नमुना: operating system आणि softwarelaunch template — recipe card: कोणता AMI, कोणता size, कोणता disk, badge आणि पाहुण्यांची यादीuser data — पहिल्या सकाळच्या कामांची यादी, डेस्क पहिल्यांदा सुरू होताना एकदाच चालते
⏪ आधी
हाताने तयार केलेला server पुन्हा कोणालाच तसाच बनवता येत नाही, त्यामुळे दहावा डेस्क पहिल्यासारखा कधीच नसतो.
💡 काय
AMI म्हणजे डेस्कचा साचा; launch template म्हणजे AMI, type, disk, badge आणि security group लिहिलेले recipe card.
⚙️ कसे
web template मध्ये t4g.small वर ami-0abc1234example आणि sg-0web आहे, आणि user data पहिल्या boot ला एकदाच root म्हणून nginx install करते.
🎯 का
Card वरून बनलेला प्रत्येक डेस्क सारखाच असतो, म्हणून बिघडलेला डेस्क हाताने दुरुस्त न करता बदलला जातो, रात्री 3 वाजताही.
🚀 पुढे
पुढे, डेस्कचे ड्रॉवर: EBS volumes, instance store ची खरडवही, snapshots, आणि कशानंतर काय टिकते.
🧪 Try it here — पाककृती कार्डवरून बाक launch करा, मग एक बिघडवा
ड्रॉवर, कच्ची वही आणि photocopy — reboot, stop आणि terminate नंतर काय टिकते.
🧒 सोप्या शब्दांत
तुमच्या डेस्कला कुलूप लावता येणारा ड्रॉवर, एक खरडवही आणि व्हरांड्यात झेरॉक्स मशीन आहे. घरी गेल्यावरही ड्रॉवर तुमचे काम ठेवतो, खरडवही दर संध्याकाळी पुसली जाते, आणि झेरॉक्स प्रत संग्रहात सुरक्षित राहते. EC2 मध्ये असेच: EBS म्हणजे ड्रॉवर, instance store म्हणजे खरडवही, आणि snapshot म्हणजे अशी झेरॉक्स जी कोणत्याही इमारतीत पुन्हा ड्रॉवर बनवता येते.
📖 नवे शब्दEBS volume — डेस्कचा ड्रॉवर: डेस्क stop केला तरी files ठेवणारा diskinstance store — खरडवही: खूप वेगवान, पण डेस्क stop झाल्यावर पुसली जातेsnapshot — ड्रॉवरची झेरॉक्स प्रत; पहिल्यानंतर फक्त बदललेली पाने copy होतातterminate — डेस्क कायमचा टाकून देणे; मुख्य ड्रॉवर सहसा त्याच्यासोबत जातो
⏪ आधी
चुकीच्या disk वरचा data सरळ नाहीसा होतो: stop केल्यावर instance store पुसला जातो, आणि terminate वर root EBS delete होतो.
💡 काय
EBS म्हणजे एकाच AZ मधला network drive, instance store म्हणजे host मधला वेगवान NVMe, आणि snapshot म्हणजे त्याची प्रत.
⚙️ कसे
Snapshots incremental असतात: पहिले 6 GB, मग 6 दिवस रोज 0.5 GB बदल, एकूण 9.0 GB साठवण, सुमारे $0.45/महिना.
🎯 का
Terminate root volume delete करतो पण data volume ठेवतो, आणि snapshot Region मधील कोणत्याही AZ मध्ये restore होतो.
🚀 पुढे
पुढे, डेस्कजवळ कोण येऊ शकतो: security group ची पाहुण्यांची यादी आणि विंगच्या दारावरचा network ACL.
🧪 Try it here — तिन्ही disks वर लिहा, मग बाक reboot, stop किंवा terminate करा
🧪 Try it here — incremental snapshots च्या एका आठवड्याची किंमत काढा (≈ $0.05 प्रति GB-महिना)
बाकावरची पाहुण्यांची यादी (stateful) आणि विंगच्या दारावरचे नियम (stateless).
🧒 सोप्या शब्दांत
विंगच्या दारावर एक नियम-फलक आत येणाऱ्या आणि बाहेर जाणाऱ्या प्रत्येकाला तपासतो, आणि तो चेहरे लगेच विसरतो. प्रत्येक डेस्कवर एक monitor आत कोण येऊ शकतो याची पाहुण्यांची यादी ठेवतो, आणि प्रत्येक पाहुणा लक्षात ठेवतो, म्हणून त्यांचे उत्तर नेहमी बाहेर जाऊ शकते. यादीत नसलेल्या अनोळखी व्यक्तीकडे दुर्लक्ष होते, ती कंटाळून जाईपर्यंत.
📖 नवे शब्दsecurity group — डेस्कवरची पाहुण्यांची यादी; ती फक्त परवानगी देते, आणि संभाषणे लक्षात ठेवतेnetwork ACL — विंगच्या दारावरचा नियम-फलक; दोन्ही बाजूंनी तपासतो आणि काहीच लक्षात ठेवत नाहीsubnet — इमारतीची एक विंग, जिथे डेस्कचा एक गट बसतोport — डेस्कवरचे क्रमांक असलेले दार, जसे web pages साठी 443 किंवा SSH साठी 22
⏪ आधी
नियोजन नसेल तर port 22 सगळ्या जगासाठी (0.0.0.0/0) उघडा राहतो, आणि reply चा नियम नसल्याने pages कोणत्याही error शिवाय अडकतात.
💡 काय
Security group म्हणजे डेस्कच्या network card वरची stateful allow-list; NACL म्हणजे subnet वरची stateless नियमांची यादी.
⚙️ कसे
sg-web 198.51.100.9 ला 443 वर येऊ देतो पण त्याचा :22 timeout म्हणून सोडून देतो, आणि SG ला आठवते म्हणून reply बाहेर जातो.
🎯 का
NACL ला आठवत नाही: outbound 1024–65535 (rule 110) नसेल तर शेवटचा * DENY reply अडवतो आणि page अडकते.
🚀 पुढे
पुढे, तुम्ही स्वतः डेस्कपर्यंत कसे पोहोचता: SSH key, एका मिनिटाची Instance Connect key, किंवा Session Manager.
🧪 Try it here — web बाकाकडे packet पाठवा — विंगचे दार (NACL) आणि पाहुण्यांची यादी (SG) ओलांडून, मग उत्तर परत बाहेर
दारासाठी चावी, एक मिनिटाचा पास, किंवा दारच नाही — SSH, Instance Connect, Session Manager.
🧒 सोप्या शब्दांत
काहीतरी बदलायला तुम्हाला डेस्कपर्यंत जायचे आहे. तुम्ही धातूची चावी वापरू शकता, पण ती कोणी copy केली तर तोही आत येतो. तुम्ही office कडून एका मिनिटासाठी चालणारा pass मागू शकता. किंवा डेस्कवर असा phone असू शकतो जो office ला call करतो, office तुमचा badge तपासून तुम्हाला जोडून देते, कोणतेही दार न उघडता.
📖 नवे शब्दSSH key pair — .pem file मध्ये ठेवलेली चावी; तिच्यासाठी port 22 उघडा ठेवावा लागतोEC2 Instance Connect — तुम्ही कोण ते तपासून AWS डेस्कवर फक्त 60 सेकंदांसाठी ठेवलेली चावीSession Manager — दार न उघडता आत जाण्याचा मार्ग: डेस्क बाहेर call करतो आणि कोण जोडले जाईल ते IAM ठरवतोCloudTrail — कोण कधी जोडले गेले ते लिहून ठेवणारी office ची नोंदवही
⏪ आधी
उघडा port 22 दिवसभर scan होत राहतो, आणि सगळ्यांनी वाटून घेतलेल्या .pem file मुळे कोण login झाले ते कोणीच सांगू शकत नाही.
💡 काय
आत जाण्याचे तीन मार्ग: key pair सह SSH, 60 सेकंदांच्या key सह EC2 Instance Connect, आणि port न उघडता Session Manager.
⚙️ कसे
SSM Agent 443 वर बाहेर call करतो, session कोण सुरू करू शकतो ते IAM ठरवतो, आणि CloudTrail व session logs नोंद ठेवतात.
🎯 का
एकही inbound नियम नसलेला डेस्कही पूर्णपणे सांभाळता येतो, म्हणजे scan करायला दार नाही आणि फुटायला key नाही.
🚀 पुढे
पुढे, भाग 2 सुरू: प्रत्येक डेस्क 'मी कोण?' विचारू शकतो आणि keys ऐवजी badge, म्हणजे instance profile, घालतो.
🧪 Try it here — बाकावर तीन प्रकारे shell मिळवा — switches बदला आणि काय बिघडते ते पहा
प्रत्येक बाक विचारू शकतो 'मी कोण?' — IMDSv2, hop limit, आणि चाव्यांची जागा घेणारे ओळखपत्र.
🧒 सोप्या शब्दांत
प्रत्येक डेस्कच्या भिंतीवर एक छोटा मदत-केंद्र असतो, जिथे फक्त तोच डेस्क पोहोचू शकतो. तो उत्तर देतो: 'मी कोणता डेस्क, कोणत्या इमारतीत?' नवा मदत-केंद्र आधी ticket साठी sign in करायला सांगतो, मग प्रत्येक प्रश्नासोबत ते ticket मागतो, आणि ते ticket डेस्कपासून दूर जाऊ शकत नाही. डेस्कखाली चिकटवलेल्या keys ऐवजी डेस्कवर badge असतो.
📖 नवे शब्दinstance metadata — डेस्क स्वतःबद्दल विचारू शकतो ती माहिती, जसे त्याचा ID आणि इमारतIMDSv2 — अधिक सुरक्षित मदत-केंद्र: आधी session token घ्या, मग प्रत्येक प्रश्नासोबत दाखवाhop limit — token चे उत्तर किती दूर जाऊ शकते; 1 म्हणजे ते डेस्कवरच राहतेinstance profile — डेस्कला role देणारा badge, म्हणजे त्यावर कोणालाही keys ठेवाव्या लागत नाहीत
⏪ आधी
Servers वर चिकटवलेल्या keys फुटतात, आणि जुनी metadata service, IMDSv1, कोणत्याही साध्या request ला उत्तर देत असे, फसवलेल्यालाही.
💡 काय
169.254.169.254 वरची metadata service डेस्कला तो कोण आहे ते सांगते; instance profile डेस्कला त्याचा IAM role जोडतो.
⚙️ कसे
HttpTokens required असेल तर program आधी session token मागतो (6 तासांपर्यंत), मग प्रत्येक प्रश्नासोबत तो दाखवतो.
🎯 का
IMDSv2, hop limit 1 आणि मर्यादित role मुळे web bug फक्त web bug राहतो; reviewer ला risky.json मध्ये असे 6 धोके सापडले.
🚀 पुढे
पुढे, डेस्क सुरक्षित झाले, मग त्यांचा खर्च किती, आणि तोच डेस्क अर्ध्या किमतीत कसा मिळू शकतो?
🧪 Try it here — metadata खिडकीला विचारा "मी कोण?" (IMDSv1 विरुद्ध v2, आणि hop limit)
1
🧪 Try it here — launch template बदला आणि त्यावर check_template.py चालवा
तासाने पैसे भरा, वर्षाचे वचन द्या, किंवा रिकामी जागा घ्या — on-demand, Savings Plans आणि spot.
🧒 सोप्या शब्दांत
अभ्यासिका कंपनी एकाच डेस्कसाठी तीन योजना देते. बसाल तेवढे भरा, आणि हवे तेव्हा निघा. वर्षभर येण्याचे वचन द्या आणि मोठी सूट मिळवा. किंवा कोणी book न केलेली रिकामी जागा घ्या, खूप स्वस्त, पण पैसे भरणाऱ्या ग्राहकाला हवी असेल तर दोन मिनिटांच्या सूचनेवर उठावे लागते.
📖 नवे शब्दon-demand — कोणतेही वचन न देता सेकंदानुसार पैसे; सर्वात जास्त स्वातंत्र्य आणि सर्वात जास्त किंमतSavings Plan — सूट मिळवण्यासाठी 1 किंवा 3 वर्षे दर तासाला ठरलेली रक्कम खर्च करण्याचे वचनspot — मोठ्या सवलतीतले रिकामे डेस्क, जे AWS 2 मिनिटांच्या सूचनेवर परत घेऊ शकतो
⏪ आधी
बिल महिन्यानंतर येते, तोपर्यंत purchase option, processor आणि चालू तासांचा निर्णय इतिहास झालेला असतो.
💡 काय
एका डेस्कसाठी पैसे भरण्याचे तीन मार्ग: सेकंदानुसार on-demand, 1 किंवा 3 वर्षांचे Savings Plan वचन, किंवा रिकाम्या spot जागा.
⚙️ कसे
एक m7g.large एका महिन्यासाठी: on-demand $59.57, 1-yr plan $42.89, 3-yr $29.78, spot ~$17.87, आणि gp3 disk चे $1.60.
🎯 का
उपाय एकत्र चालतात: फक्त office hours चालवल्यास compute $14.36 वर येते, आणि त्याच size ला Graviton Intel पेक्षा सुमारे 19% स्वस्त.
🚀 पुढे
पुढे, Auto Scaling आत्ता लागणारेच डेस्क ठेवते, आणि सर्वात स्वस्त डेस्क म्हणजे जो चालूच नाही.
🧪 Try it here — बाक, plan आणि तास निवडा — महिन्याचे bill (अंदाजे us-east-1 Linux किमती)
बाकांची योग्य संख्या ठेवा — min, max, target tracking, warm-up आणि बदली.
🧒 सोप्या शब्दांत
अभ्यासिकेच्या काळजीवाहकाकडे एक clipboard आहे: कधीही 2 पेक्षा कमी डेस्क नाहीत, 6 पेक्षा जास्त नाहीत, प्रत्येक साधारण अर्धा व्यस्त ठेवा. गर्दी आली की तो आणखी डेस्क आणतो आणि ते तयार होईपर्यंत दोन मिनिटे थांबतो. गर्दी गेली की तो एकेक करून, हळूहळू डेस्क काढतो. बिघडलेला डेस्क बाहेर नेला जातो आणि नवा त्याची जागा घेतो.
📖 नवे शब्दAuto Scaling group — डेस्कची संख्या किमान आणि कमाल यांच्या दरम्यान ठेवणारा काळजीवाहकtarget tracking — 'सरासरी CPU सुमारे 50% ठेवा' सारखा thermostat नियमwarm-up — नवा डेस्क मोजला जाण्याआधी तयार होण्यासाठी लागणारी मिनिटेscale in — गर्दी गेल्यावर डेस्क कमी करणे, एकेक करून
अनेक बाकांसाठी एक स्वागतकक्ष — target groups, health checks, फक्त निरोगी बाकांनाच पाहुणे मिळतात.
🧒 सोप्या शब्दांत
कोणता डेस्क मोकळा आहे याचा अंदाज पाहुण्यांना लावावा लागू नये, म्हणून अभ्यासिकेच्या प्रवेशद्वारावर एकच reception आहे. Receptionist प्रत्येक पाहुण्याला क्रमाने पुढच्या डेस्ककडे पाठवतो, आणि दर 10 सेकंदांनी प्रत्येक डेस्कला विचारतो: 'सगळे ठीक?' दोनदा उत्तर न देणाऱ्या डेस्कला पाहुणे मिळत नाहीत, आणि सलग तीनदा उत्तर दिल्यावरच तो परत येतो.
📖 नवे शब्दload balancer — एकाच पत्त्यामागे अनेक डेस्कवर पाहुणे वाटणारे receptiontarget group — reception ज्या डेस्ककडे पाहुणे पाठवू शकते त्यांची यादीhealth check — नियमितपणे 'सगळे ठीक?' विचारणे; नापास डेस्कना पाहुणे मिळत नाहीत
⏪ आधी
कोणता डेस्क चालू आहे ते पाहुण्यांना कळत नाही, म्हणून बिघडलेल्या डेस्कलाही एक तृतीयांश traffic जाते आणि errors दिसतात.
💡 काय
Load balancer मध्ये listeners, rules आणि target groups असतात, आणि health checks ठरवतात की कोणत्या डेस्कला पाहुणे मिळतील.
⚙️ कसे
दर 10 s ला check: web-b दोनदा नापास झाला आणि t=30s पासून 0 requests; 3 वेळा पास झाल्यावर t=70s ला 4 requests सह परत आला.
🎯 का
डेस्क येत-जात राहिले तरी clients साठी एकच स्थिर DNS नाव राहते, आणि एखादा बिघडलेला डेस्क पाहुण्यांच्या लक्षातही येत नाही.
🚀 पुढे
पुढे, काही विचित्र घडले तर: दोन status checks, दोन वेगळे उपाय, आणि hypervisor ला न दिसणारे metrics.
🧪 Try it here — कोणते बाक /health ला उत्तर देतात ते निवडा, मग 10 s एकावेळी तपासण्या चालवा (2 अपयश → बाहेर, 3 यश → परत)
दोन status checks, दोन उपाय — आणि hypervisor ला न दिसणारे आकडे.
🧒 सोप्या शब्दांत
दोन तपासनीस दर मिनिटाला प्रत्येक डेस्क तपासतात. इमारत तपासनीस खाली फरशी, वीज आणि cables पाहतो, जे कंपनीचे आहेत; ते नापास झाले तर तुम्ही दुसऱ्या जागी जाता. डेस्क तपासनीस तुमचा स्वतःचा डेस्क पाहतो, जसे अडकलेला ड्रॉवर किंवा बिघडलेली settings, आणि ते तुम्हालाच दुरुस्त करायचे. डेस्कवरचा एक छोटा reporter ड्रॉवर किती भरला आहे ते सांगतो.
📖 नवे शब्दsystem status check — डेस्कखालचा AWS चा hardware तपासतो; उपाय म्हणजे stop आणि startinstance status check — तुमची स्वतःची operating system तपासतो; उपाय तुमचा, जसे rebootCloudWatch agent — memory आणि disk space चे आकडे पाठवणारा डेस्कवरचा छोटा reporteralarm — एखादा आकडा रेषा ओलांडतो तेव्हा वाजणारी घंटा, जसे credits 20 च्या खाली जाणे
⏪ आधी
Incident मध्ये पहिली काही मिनिटे हा प्रश्न कोणाचा याचा अंदाज लावण्यात जातात, आणि memory किंवा disk space कोणी गोळाच केलेले नसते.
💡 काय
System status check AWS चा host तपासतो, instance status check तुमची OS तपासतो, आणि CloudWatch metrics ठेवते.
⚙️ कसे
System check नापास: stop आणि start केल्याने डेस्क नव्या host वर जातो. Instance check नापास: reboot करा आणि console log वाचा.
🎯 का
Memory आणि disk space साठी CloudWatch agent लागतो, आणि busy run मध्ये CPUCreditBalance < 20 चा alarm तास 2 पासून वाजतो.
🚀 पुढे
शेवटचा धडा: रात्रीचे snapshots, golden AMI, आणि stop, hibernate आणि terminate नेमके काय ठेवतात.
🧪 Try it here — बाकात काहीतरी बिघडले आहे — कोणता check अपयशी होतो, आणि उपाय काय?
🧪 Try it here — CPUCreditBalance alarm लावा आणि t3.micro busy चालवा (सुरुवातीचा balance 144)
रात्रीची photocopy, सोनेरी साचा, आणि stop, hibernate आणि terminate काय ठेवतात.
🧒 सोप्या शब्दांत
दररोज रात्री 3 वाजता एक कारकून प्रत्येक ड्रॉवरची झेरॉक्स काढतो, आणि भिंतीवरचा नियम सांगतो शेवटच्या 7 ठेवा, म्हणून रोज सकाळी सर्वात जुनी प्रत फाडली जाते. नमुना डेस्कला सुरक्षा दुरुस्ती मिळाली की शाळा नवा तपासलेला नमुना बनवते आणि काही-काही डेस्क टप्प्याने बदलते. आणि डेस्क सोडणे म्हणजे stop, hibernate किंवा कायमचा टाकून देणे.
📖 नवे शब्दretention — किती प्रती ठेवायच्या याचा नियम, जसे 'शेवटच्या 7 ठेवा'golden AMI — नवे डेस्क ज्याची नक्कल करून बनतात असा ताजा, patched आणि तपासलेला नमुना डेस्कinstance refresh — पाहुणे काम करत असतानाच जुने डेस्क काही-काही करून नव्यांनी बदलणेhibernate — डेस्कवरचे सगळे ड्रॉवरमध्ये भरून ठेवणे, म्हणजे उद्या तिथूनच पुढे सुरू करता येते
⏪ आधी
Backup नाही, patch करायला कोणी धजत नाही असा fleet, आणि एकुलती एक प्रत घेऊन गेलेला terminate, यांनी अनेक EC2 कथा संपतात.
💡 काय
Lifecycle म्हणजे retention सह ठरलेल्या वेळचे snapshots, golden AMI ने patching, आणि प्रत्येक बटण काय ठेवते हे माहीत असणे.
⚙️ कसे
रोज 03:00 ची, 7 ठेवणारी policy 2026-09-21 ते 09-27 ठेवते आणि 09-18 ते 09-20 delete करते, कोणी लक्षात न ठेवता.
🎯 का
Instance refresh डेस्क टप्प्याटप्प्याने patched golden AMI वर बदलतो, आणि hibernate RAM root volume मध्ये साठवतो.
🚀 पुढे
Production मध्ये: cross-Region snapshot copies, दरमहा golden-AMI refresh, restore सराव आणि termination protection.
🧪 Try it here — रोज 03:00 ची snapshot policy — किती ठेवायचे ते निवडा
710
🧪 Try it here — stop, hibernate की terminate — बाक काय जपतो?