सेकंदाच्या हिशोबाने भाड्याने घेतलेले संगणक, शाळेच्या अभ्यासिकेच्या रूपात शिकवलेले: बाक, इमारती, ड्रॉवर, पाहुण्यांच्या याद्या आणि एक स्वागतकक्ष. प्रत्येक धडा म्हणजे चित्र आणि lab असलेली एक शाळेची गोष्ट — आणि अभ्यासिका repo मध्येच आहे: छोटे Python programs (कोणतीही dependency नाही, AWS account नाही) जे पाहुण्यांच्या याद्या तपासतात, CPU credits जाळतात, fleet वाढवतात, traffic वाटतात आणि bill ची किंमत काढतात.
🏫 regions & AZs🛵 instance types🖼️ AMIs💾 EBS🧍 security groups🔑 Session Manager💳 spot & Savings Plans👯 Auto Scaling🛎️ load balancers
🪑 भाग 1 — बाक भाड्याने घेणे (1–6)
सेकंदाने बाक, वेगवेगळ्या इमारती 🖥️
योग्य वाहन, इंधनाची टाकी 🛵
साचा, ड्रॉवर, photocopy 🖼️💾
पाहुण्यांची यादी आणि आत येण्याचा मार्ग 🧍🔑
🏫 भाग 2 — fleet चालवणे (7–12)
चाव्यांऐवजी ओळखपत्र 🪪
bill, पैसे भरण्याचे तीन मार्ग 💳
गर्दी असताना जास्त बाक, एकच स्वागतकक्ष 👯🛎️
status checks, snapshots, सोनेरी साचे 📈📸
# the 60-second wow — every lesson, live:
git clone https://github.com/BaluRaut/learn-ec2-school.git && cd learn-ec2-school
python3 ec2/demo.py # 12 lessons: guest lists, credits, a fleet, a reception, the bill
python3 ec2/test_ec2.py # 12 checks, one per lesson
तुम्हाला काय दिसायला हवे (छाटलेले — यश असे दिसते):
═══ regions ═══
── a region is a district; each Availability Zone is separate buildings with their own power and network
🏫 all in AZ-a AZ-a loses power → 0 of 3 desks still serving 💥 site down
🏫 spread a/b/c AZ-a loses power → 2 of 3 desks still serving ✅
a desk (instance) is rented by the second; stopped = no compute bill, the disk (EBS) still bills
═══ types ═══
── the letter is the family, the number the generation, g = Graviton (ARM), then the size
t3.micro 2 vCPU 1 GiB burstable 🛵 ~$0.0104/h
t4g.small 2 vCPU 2 GiB burstable 🛵 ~$0.0168/h
m7i.large 2 vCPU 8 GiB general 🚗 ~$0.1008/h
m7g.large 2 vCPU 8 GiB general 🚗 ~$0.0816/h
c7i.xlarge 4 vCPU 8 GiB compute 🏎️ ~$0.1785/h
c7g.xlarge 4 vCPU 8 GiB compute 🏎️ ~$0.1450/h
r7i.large 2 vCPU 16 GiB memory 🚚 ~$0.1323/h
r7g.large 2 vCPU 16 GiB memory 🚚 ~$0.1071/h
── t3.micro is a scooter with a fuel tank: CPU credits (earn 12/h, hold up to 288; 1 credit = 1 vCPU·minute at 100%)
hour 1: balance 36.0 credits · you get 100% CPU
hour 2: balance 0.0 credits · you get 10% CPU ← tank empty: throttled to the 10% baseline
hour 3: balance 0.0 credits · you get 10% CPU ← tank empty: throttled to the 10% baseline
═══ launch ═══
── a launch template = the desk's recipe card: image (AMI) + type + disk + badge + guest list + first-boot script
ImageId "ami-0abc1234example"
InstanceType "t4g.small"
IamInstanceProfile {"Name": "school-web"}
SecurityGroupIds ["sg-0web"]
UserData (runs once, as root, on first boot):
# Runs ONCE, as root, on the desk's first boot (cloud-init). Everything a new desk needs, written down.
dnf install -y nginx
echo "<h1>school web desk $(hostname)</h1>" > /usr/share/nginx/html/index.html
systemctl enable --now nginx
every desk from this card is identical — a broken desk is replaced, never repaired by hand
═══ storage ═══
── what survives what (root volume with DeleteOnTermination = true, one extra data volume, one instance store)
root EBS data EBS instance store
reboot ✅ ✅ ✅
stop / start ✅ ✅ ❌ wiped
terminate ❌ deleted ✅ kept ❌ wiped
── snapshots are incremental: 6 GB first copy + 0.5 GB changed/day × 6 more days = 9.0 GB stored ≈ $0.45/month
a snapshot lives in S3-backed storage and restores into ANY AZ in the region — the volume itself lives in one AZ
═══ network ═══
── the security group (guest list at the desk, stateful)
✅ 198.51.100.9 → :443 sg-web: inbound rule '443 from anywhere'
🚫 198.51.100.9 → :22 sg-web: no inbound rule matches — dropped (the sender sees a timeout)
✅ 203.0.113.5 → :22 sg-web: inbound rule '22 from the office laptop'
✅ reply 443 → 198.51.100.9:51000 sg-web: reply to a remembered conversation — stateful, no rule needed
── the network ACL (the wing door, stateless — the reply needs its own rule)
without an ephemeral-port rule request in: ✅ (acl-public inbound rule 100: ALLOW) · reply out: 🚫 (acl-public outbound: no rule matches → the final * DENY)
with 1024–65535 out request in: ✅ (acl-public inbound rule 100: ALLOW) · reply out: ✅ (acl-public outbound rule 110: ALLOW)
═══ connect ═══
── three ways to get a shell on the desk
SSH with a key pair port: 22 open (to your IP) key: a .pem you must guard audit: only the OS log
EC2 Instance Connect port: 22 open (to AWS's range) key: a one-minute key pushed by IAM audit: CloudTrail
Session Manager port: none — the agent calls out key: none — IAM decides audit: CloudTrail + session logs
for anything real: Session Manager, and a security group with no port 22 at all
═══ metadata ═══
── every desk can ask 'who am I?' at the metadata address; a launch template decides how safely
📄 risky.json: 6 finding(s)
⚠️ metadata service v2 not required → set "MetadataOptions": {"HttpTokens": "required"} — session-token mode only
⚠️ metadata hop limit above 2 → keep HttpPutResponseHopLimit at 1 (2 if containers on the host need it)
⚠️ root volume not encrypted → set "Encrypted": true on every EBS volume (or turn on EBS encryption by default for the account)
⚠️ no instance profile (the desk has no badge) → attach an instance profile with a narrow role instead of putting keys on the desk
⚠️ a key pair for SSH → prefer Session Manager: no key to lose and no port 22 to open
⚠️ gp2 instead of gp3 → gp3 is cheaper per GB and lets you set IOPS separately
📄 web.json: ✅ nothing risky
the badge (instance profile → role) is how the desk gets short-lived credentials — never paste keys onto it
═══ pricing ═══
── one m7g.large for a month (approximate us-east-1 prices — check the pricing page before trusting them)
on-demand compute $ 59.57 + 20 GB gp3 $1.6
1-yr Compute Savings Plan compute $ 42.89 + 20 GB gp3 $1.6
3-yr Compute Savings Plan compute $ 29.78 + 20 GB gp3 $1.6
spot (typical) compute $ 17.87 + 20 GB gp3 $1.6
office hours only (8 h × 22 days) on-demand: compute $14.36 + disk $1.6 — a stopped desk still pays for its disk
Graviton vs Intel, same size: m7g $0.0816/h vs m7i $0.1008/h
═══ scaling ═══
── an Auto Scaling group: min 2, max 6, target 50% average CPU, new desks warm up for 2 minutes
min 1 demand 90 · desks 2 (2 serving) · CPU 45%
min 2 demand 100 · desks 2 (2 serving) · CPU 50%
min 3 demand 160 · desks 4 (2 serving) · CPU 80% 📈 CPU 80% > target 50% → launch 2 (warming up 2 min)
min 4 demand 240 · desks 4 (2 serving) · CPU 100%
min 5 demand 300 · desks 6 (4 serving) · CPU 75% 📈 CPU 75% > target 50% → launch 2 (warming up 2 min)
min 6 demand 320 · desks 6 (4 serving) · CPU 80%
min 7 demand 300 · desks 6 (6 serving) · CPU 50%
min 8 demand 200 · desks 5 (5 serving) · CPU 33% 📉 quiet → scale in ONE desk (then wait 3 min — slowly, on purpose)
min 9 demand 120 · desks 5 (4 serving) · CPU 30% 💥 a desk fails its health check → terminated; a fresh one launches and warms up
min 10 demand 100 · desks 5 (4 serving) · CPU 25%
min 11 demand 80 · desks 4 (4 serving) · CPU 16% 📉 quiet → scale in ONE desk (then wait 3 min — slowly, on purpose)
min 12 demand 80 · desks 4 (4 serving) · CPU 20%
min 13 demand 80 · desks 4 (4 serving) · CPU 20%
min 14 demand 80 · desks 3 (3 serving) · CPU 20% 📉 quiet → scale in ONE desk (then wait 3 min — slowly, on purpose)
min 15 demand 80 · desks 3 (3 serving) · CPU 27%
═══ balancing ═══
── a load balancer checks every 10 s; 2 failures → unhealthy, 3 passes → healthy again; traffic only to healthy desks
t=10s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4
t=20s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4
t=30s web-a:✅ 6 web-b:🚫 0 web-c:✅ 6
t=40s web-a:✅ 6 web-b:🚫 0 web-c:✅ 6
t=50s web-a:✅ 6 web-b:🚫 0 web-c:✅ 6
t=60s web-a:✅ 6 web-b:🚫 0 web-c:✅ 6
t=70s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4
t=80s web-a:✅ 4 web-b:✅ 4 web-c:✅ 4
═══ monitoring ═══
── two status checks, two different fixes
❌ system status check → AWS's hardware or network under your desk → stop + start (moves to a new host)
❌ instance status check → YOUR operating system (full disk, bad config, kernel) → reboot, read the console log, fix
── metrics: CPU, network and disk I/O come free every 5 min (1 min with detailed monitoring);
memory and disk-space-used need the CloudWatch agent — the hypervisor cannot see inside your OS
🔔 alarm idea: CPUCreditBalance < 20 → in the busy run above it fires from hour 2
═══ lifecycle ═══
── a daily snapshot policy at 03:00 that keeps 7 (Data Lifecycle Manager / AWS Backup)
2026-09-27 📸 kept
2026-09-26 📸 kept
2026-09-25 📸 kept
2026-09-24 📸 kept
2026-09-23 📸 kept
2026-09-22 📸 kept
2026-09-21 📸 kept
2026-09-20 🗑️ deleted by the policy
2026-09-19 🗑️ deleted by the policy
2026-09-18 🗑️ deleted by the policy
── stop · hibernate · terminate — what each keeps
stop RAM lost root EBS kept public IP changes
hibernate RAM saved to the root volume root EBS kept public IP changes
terminate RAM lost root EBS deleted (DeleteOnTermination) gone
bake a golden AMI (patched, tested), roll it out with an instance refresh — patch by replacing desks
✅ done — the study hall ran every lesson
🎒 धडा 01 पूर्वी: तुम्हाला फक्त Python 3 हवे — दुसरे काही नाही; AWS account नाही. simulations ही शिकवण्याची मॉडेल्स आहेत आणि किमती अंदाजे आहेत (एखाद्या आकड्यावर विश्वास ठेवण्यापूर्वी EC2 pricing page तपासा). प्रत्येक धडा खऱ्या account साठी खूण केलेल्या खऱ्या AWS CLI commands सुद्धा दाखवतो. चांगले शेजारी: IAM शाळा (हे बाक घालतात ती ओळखपत्रे) आणि AWS शाळा (संपूर्ण campus).
एक git branch = एक कल्पना; branch 04 मध्ये धडे 01–04 आहेत. Labs साध्या Python 3 वर चालतात — AWS account लागत नाही.
1
🖥️ EC2 का — regions आणि AZs
सेकंदाच्या हिशोबाने बाक भाड्याने घ्या — वेगवेगळ्या इमारतींच्या जिल्ह्यात, म्हणजे एका इमारतीची वीज गेली तरी शाळा कधीच बंद होत नाही.lesson-01-why-ec2धडा वाचा →आकृती पहा ↗
2
🛵 Instance प्रकार
कामासाठी योग्य वाहन निवडा — families, sizes, Graviton, आणि CPU credits ची burstable इंधन टाकी.lesson-02-instance-typesधडा वाचा →आकृती पहा ↗
3
🖼️ AMIs आणि launch templates
बाकाचा साचा आणि पाककृती कार्ड — प्रत्येक बाक एकसारखा, पहिल्या boot च्या script ने तयार केलेला.lesson-03-amis-launchधडा वाचा →आकृती पहा ↗
4
💾 साठवण — EBS आणि snapshots
ड्रॉवर, कच्ची वही आणि photocopy — reboot, stop आणि terminate नंतर काय टिकते.lesson-04-storageधडा वाचा →आकृती पहा ↗
5
🧍 Networking — security groups आणि NACLs
बाकावरची पाहुण्यांची यादी (stateful) आणि विंगच्या दारावरचे नियम (stateless).lesson-05-networkingधडा वाचा →आकृती पहा ↗
6
🔑 जोडणी
दारासाठी चावी, एक मिनिटाचा पास, किंवा दारच नाही — SSH, Instance Connect, Session Manager.lesson-06-connectingधडा वाचा →आकृती पहा ↗
🏫 भाग 2 — बाकांची fleet चालवणे (धडे 7–12)
Production EC2 ला काय लागते: roles, खर्च नियंत्रण, Auto Scaling, load balancing, monitoring आणि lifecycle योजना.
7
🪪 Metadata आणि roles
प्रत्येक बाक विचारू शकतो 'मी कोण?' — IMDSv2, hop limit, आणि चाव्यांची जागा घेणारे ओळखपत्र.lesson-07-metadata-rolesधडा वाचा →आकृती पहा ↗
8
💳 किंमत
तासाने पैसे भरा, वर्षाचे वचन द्या, किंवा रिकामी जागा घ्या — on-demand, Savings Plans आणि spot.lesson-08-pricingधडा वाचा →आकृती पहा ↗
9
👯 Auto Scaling
बाकांची योग्य संख्या ठेवा — min, max, target tracking, warm-up आणि बदली.lesson-09-auto-scalingधडा वाचा →आकृती पहा ↗
10
🛎️ Load balancing
अनेक बाकांसाठी एक स्वागतकक्ष — target groups, health checks, फक्त निरोगी बाकांनाच पाहुणे मिळतात.lesson-10-load-balancingधडा वाचा →आकृती पहा ↗
11
📈 Monitoring आणि अडचणी सोडवणे
दोन status checks, दोन उपाय — आणि hypervisor ला न दिसणारे आकडे.lesson-11-monitoringधडा वाचा →आकृती पहा ↗
12
📸 Backup, patching आणि lifecycle
रात्रीची photocopy, सोनेरी साचा, आणि stop, hibernate आणि terminate काय ठेवतात.lesson-12-lifecycleधडा वाचा →आकृती पहा ↗
🗣️ मोठ्याने समजावून सांगा — धडा 12 नंतर: (1) बाक तीन AZs मध्ये का पसरवायचे? (2) पूर्ण load च्या एका तासानंतर t3.micro हळू होतो — का? (3) stop नंतर काय टिकते, आणि terminate नंतर काय टिकते? (4) NACL ला उत्तरासाठी नियम का लागतो पण security group ला का नाही? (5) स्थिर web server साठी काय स्वस्त: on-demand, Savings Plan की spot — आणि spot का नाही? (6) System status check की instance status check — कोणता stop/start ने दुरुस्त होतो?
🎓 त्याच शाळेतून:IAM · AWS · Docker · Kubernetes — तेच उपमा-विश्व, तीच branch-दर-branch पद्धत.
📐 धड्यांच्या आकृत्या — क्रमांक अनुसरा
प्रत्येक धडा एका क्रमांकित बॉक्स-आणि-बाण आकृतीत — स्वतंत्र पानावरही.
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 — बाक काय जपतो?