🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

📸 धडा 12 — Backup, patching आणि lifecycle: रात्रीची photocopy आणि सोनेरी साचा

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 — शेवटचा धडा! · मागील: lesson-11-monitoring

📦 या ब्रँचमध्ये काय आहे

संपूर्ण कोर्स, आणि fleet वर्षानुवर्षे जिवंत ठेवणारी कामे: retention सह ठरलेल्या वेळचे snapshots (Data Lifecycle Manager / AWS Backup), golden AMI तयार करून आणि instance refresh ने डेस्क बदलून केलेले patching, आणि stop, hibernate आणि terminate नेमके काय ठेवतात. संपूर्ण check suite, ec2/test_ec2.py, 12/12 पास व्हायला हवा.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दर रात्री 3 वाजता एक कारकून प्रत्येक ड्रॉवरची photocopy 📸 काढतो आणि त्या प्रती फाईल करतो. भिंतीवरचा नियम सांगतो "शेवटच्या 7 ठेवा" — म्हणून रोज सकाळी सर्वात जुनी प्रत shredder मध्ये जाते. कोणालाच लक्षात ठेवावे लागत नाही; नियमच ते करतो.

डेस्कच्या साच्यात सुरक्षेचा बदल (patch) आला की शाळा प्रत्येक डेस्कवर screwdriver घेऊन कोणाला पाठवत नाही. ती एक नवा, तपासलेला सोनेरी साचा 🏅 बनवते, recipe card अद्ययावत करते, आणि पाहुणे काम करत असतानाच काळजीवाहक डेस्क थोडे-थोडे करून बदलतो — हे म्हणजे instance refresh.

आणि डेस्क सोडण्याचे तीन प्रकार आहेत:

Stop ⏸️ — तुम्ही घरी जाता; ड्रॉवर तसेच राहतात, डेस्कवर जे काही होते (RAM) ते साफ होते.
Hibernate 😴 — तुम्ही घरी जाता, पण आधी डेस्कवरचे सगळे काळजीपूर्वक ड्रॉवरमध्ये भरून ठेवता, म्हणजे उद्या जिथे होता तिथूनच पुढे सुरू करता.
Terminate 🗑️ — डेस्क टाकून दिला जातो; मुख्य ड्रॉवरही त्याच्यासोबत जातो (तुम्ही तो ठेवायला सांगितले नसेल तर).

🗺️ आकृती

flowchart LR
    policy["🗓️ snapshot policy<br/>daily 03:00 · keep 7"]
    snaps["📸 2026-09-21 … 2026-09-27 kept<br/>🗑️ 2026-09-20 and older deleted"]
    policy -->|"1"| snaps
    patch["🩹 new patches"]
    golden["🏅 golden AMI<br/>built, patched, tested"]
    lt["📇 launch template v2"]
    refresh["👯 instance refresh<br/>replace desks a few at a time"]
    patch -->|"2 bake"| golden -->|"3"| lt -->|"4 roll out"| refresh
    life["⏸️ stop: RAM lost · 😴 hibernate: RAM saved to root EBS · 🗑️ terminate: root deleted"]
    refresh -.-> life

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l12

❓ काय

ठरलेल्या वेळचे snapshots — Amazon Data Lifecycle Manager (DLM) दिलेला tag असलेल्या volumes/instances साठी वेळापत्रकानुसार EBS snapshots किंवा AMIs बनवतो, आणि संख्या किंवा वयानुसार ते delete करतो. AWS Backup हेच अनेक services साठी करतो, backup vaults, cross-Region / cross-account copies आणि vault lock सह. कोणताही मार्ग घ्या: ठरलेल्या वेळी restore करून तपासा.
Backups म्हणून AMIs — create-image instance चे volumes snapshots म्हणून आणि सोबत launch metadata टिपतो. Default ने तो सुसंगत file system साठी instance reboot करतो; --no-reboot reboot टाळतो पण प्रत विसंगत असण्याचा धोका असतो.
जागीच patching — patch baselines आणि maintenance windows सह Systems Manager Patch Manager. काही मोजक्या दीर्घकाळ चालणाऱ्या instances साठी योग्य.
बदलीने patching — एक golden AMI बनवा (EC2 Image Builder build, patch आणि test आपोआप करू शकतो), तो नव्या launch-template version मध्ये ठेवा, मग ASG चा instance refresh करा: तो minimum healthy percentage राखत instances टप्प्याटप्प्याने बदलतो, ऐच्छिक checkpoints आणि आपोआप rollback सह. प्रत्येक डेस्क शेवटी एकसारखा होतो — drift नाही.
Stop — RAM जाते, EBS राहतो, instance store पुसला जातो, public IPv4 address बदलतो (Elastic IP तसाच राहतो), instance सहसा नव्या host वर जातो. Compute चा खर्च नाही; EBS चे बिल मात्र लागते.
Hibernate — RAM encrypted root EBS volume वर लिहिली जाते आणि start वर परत आणली जाते. हे launch च्या वेळीच चालू करावे लागते, RAM मावेल इतका मोठा root volume लागतो, आणि instance types, RAM चा आकार आणि instance किती काळ hibernated राहू शकतो यावर मर्यादा आहेत.
Terminate — instance गेला; DeleteOnTermination = true असलेले volumes delete होतात. Termination protection (--disable-api-termination) अपघातांपासून वाचवते.

🤔 का

कारण बहुतेक EC2 कथा वाईट रीतीने संपवणाऱ्या तीन गोष्टी म्हणजे: backup नाही (किंवा असलेला कधीच कोणी restore केला नाही), patch करायला कोणी धजत नाही असा fleet, आणि एखाद्या गोष्टीची एकुलती एक प्रत घेऊन गेलेला terminate. एक policy, एक pipeline आणि एक checklist तिन्ही सोडवतात — आणि त्यापैकी कोणतेही कोणाच्या लक्षात ठेवण्यावर अवलंबून नाही.

🔧 कसे (या repo मध्ये)

ec2/demo.py मधील lifecycle() 2026-09-27 पर्यंतच्या दहा दिवसांना "रोज 03:00 ला, 7 ठेवा" policy लावते आणि कोणते snapshots टिकतात ते छापते, मग stop, hibernate आणि terminate काय ठेवतात याचे table. ec2/costs.py मधील snapshot_cost() (धडा 04) retention period ची किंमत काढते. ec2/test_ec2.py प्रत्येक धड्याच्या वचनासाठी एक check चालवते.

🧪 करून पाहा

python3 ec2/demo.py lifecycle
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import costs
from datetime import date, timedelta
# a weekly policy that keeps 4: which Sundays survive on 2026-09-27?
today = date(2026, 9, 27)
sundays = [today - timedelta(weeks=i) for i in range(6)]
for i, d in enumerate(sundays):
    print(d, "📸 kept" if i < 4 else "🗑️ deleted")
print("daily × 7 on a 20 GB disk, 1 GB/day changes:", costs.snapshot_cost(1, 7, 20), "(GB, $/month)")
EOF
python3 ec2/test_ec2.py
# capstone: write a launch template for a web tier that check_template.py passes (L07),
# price it for three AZs with a Savings Plan base and spot extras (L08), run fleet.asg()
# with your own day of traffic (L09), and write down its snapshot and golden-AMI plan (L12).

खऱ्या account वर (AWS credentials लागतात; तुम्ही deregister आणि delete करेपर्यंत AMIs आणि snapshots चे बिल लागते — तुमचे स्वतःचे IDs आणि नावे वापरा):

aws ec2 create-image --instance-id i-0123456789abcdef0 --name "school-web-2026-09-27" \
    --description "golden AMI, patched 2026-09-27"
aws ec2 create-launch-template-version --launch-template-name school-web --source-version 1 \
    --launch-template-data '{"ImageId":"ami-0fedcba9876543210"}'
aws autoscaling start-instance-refresh --auto-scaling-group-name school-web \
    --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":120}'
aws autoscaling describe-instance-refreshes --auto-scaling-group-name school-web
aws ec2 stop-instances --instance-ids i-0123456789abcdef0 --hibernate
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --disable-api-termination

✅ तपासा — तुम्हाला काय दिसायला हवे

lifecycle 2026-09-27 ते 2026-09-21 यांना 📸 kept म्हणून, आणि 2026-09-20, 2026-09-19, 2026-09-18 यांना 🗑️ deleted by the policy म्हणून दाखवते, मग 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. तुमचा snippet 2026-09-27, 2026-09-20, 2026-09-13, 2026-09-06 ठेवतो आणि 2026-08-30 व 2026-08-23 delete करतो, मग छापतो daily × 7 on a 20 GB disk, 1 GB/day changes: (26, 1.3) (GB, $/month). Test suite बारा ✅ ओळी आणि 12/12 passed छापतो.

🏁 तुम्ही आत्ताच काय सिद्ध केले

आपोआप कालबाह्य होणारे backups, screwdriver ऐवजी नव्या साच्याच्या रूपात येणारे patches, आणि "हे बटण दाबले तर मी काय गमावेन?" याचे स्पष्ट उत्तर — आणि बाराही धड्यांची वचने आपापले checks पास करतात.

⚠️ नेहमीच्या चुका

कोणीही कधीच restore न केलेले snapshots — restore सराव झाल्यावरच backup खरा backup ठरतो
retention नियम नाही, त्यामुळे snapshots साचत राहतात आणि वर्षानुवर्षे बिल लागते (किंवा नियम इतका छोटा की हवी असलेली प्रतच गेलेली)
production ला SSH वरून हाताने patch करणे, त्यामुळे प्रत्येक डेस्क हळूहळू वेगळाच बनतो
चालू service वर MinHealthyPercentage 0 ठेवून instance refresh करणे
आधी DeleteOnTermination आणि termination protection न तपासता "साफसफाई" साठी terminate करणे
hibernate चालू ठेवून launch न केलेल्या instance वर hibernate चालेल अशी अपेक्षा करणे

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: EC2 service live होण्याआधी reviewer हीच checklist तपासतो: snapshot policy खाली असलेले tagged volumes, cross-Region copy आणि restore ची तारीख, दरमहा refresh होणारी golden-AMI pipeline, stateful असलेल्या प्रत्येक गोष्टीवर termination protection, आणि कोणते बटण काय करते हे सांगणारे runbook.

🎓 अभ्यासिका आता तुमची आहे

वेगवेगळ्या इमारतींमधले डेस्क → योग्य वाहन → साचा आणि recipe card → ड्रॉवर आणि photocopy → पाहुण्यांची यादी आणि विंगचे दार → दारच नाही → चाव्यांऐवजी badge → पैसे भरण्याचे तीन मार्ग → काळजीवाहक → reception → दोन निरीक्षक → रात्रीची photocopy आणि सोनेरी साचा. तुम्ही फक्त EC2 शिकला नाहीत — तुम्ही त्यावर fleet चालवू शकता. 🖥️🎓

शाळेतली पुढची दारे: IAM school हे डेस्क घालतात त्या badges बद्दल खोलवर शिकवते; Docker school डेस्कवर जे चालते ते पॅक करते; AWS school संपूर्ण परिसर फिरवते; आणि School portal मध्ये बाकी सगळे आहे.

git checkout main
python3 ec2/demo.py     # one last run, for fun

📸 Lesson 12 — Backup, patching & lifecycle: the nightly photocopy and the golden template

📍 You are here: Lesson 12 of 12 — the final lesson! · Previous: lesson-11-monitoring

📦 What's in this branch

The whole course, plus the operations that keep a fleet alive for years: scheduled snapshots with retention (Data Lifecycle Manager / AWS Backup), patching by baking a golden AMI and replacing desks with an instance refresh, and exactly what stop, hibernate and terminate keep. The full check suite, ec2/test_ec2.py, should pass 12/12.

🧒 Explain like I'm 5

Every night at 3 o'clock, a clerk photocopies every drawer 📸 and files the copies. The rule on the wall says "keep the last 7" — so each morning the oldest copy goes in the shredder. Nobody has to remember; the rule does it.

When the desk template gets a safety fix (a patch), the school does not send someone round with a screwdriver to every desk. It makes a new, tested golden template 🏅, updates the recipe card, and the caretaker swaps the desks a few at a time while visitors keep working — an instance refresh.

And leaving a desk comes in three kinds:

Stop ⏸️ — you go home; the drawers stay, whatever was on the desk top (RAM) is cleared.
Hibernate 😴 — you go home, but first everything on the desk top is carefully packed into the drawer, so tomorrow you carry on where you were.
Terminate 🗑️ — the desk is thrown away; the main drawer goes with it (unless you said to keep it).

🗺️ Diagram

flowchart LR
    policy["🗓️ snapshot policy<br/>daily 03:00 · keep 7"]
    snaps["📸 2026-09-21 … 2026-09-27 kept<br/>🗑️ 2026-09-20 and older deleted"]
    policy -->|"1"| snaps
    patch["🩹 new patches"]
    golden["🏅 golden AMI<br/>built, patched, tested"]
    lt["📇 launch template v2"]
    refresh["👯 instance refresh<br/>replace desks a few at a time"]
    patch -->|"2 bake"| golden -->|"3"| lt -->|"4 roll out"| refresh
    life["⏸️ stop: RAM lost · 😴 hibernate: RAM saved to root EBS · 🗑️ terminate: root deleted"]
    refresh -.-> life

🗺️ Drawn version + a lab: https://school-edh.pages.dev/ec2/lesson-diagrams.html#l12

❓ What

Scheduled snapshots — Amazon Data Lifecycle Manager (DLM) creates EBS snapshots or AMIs on a schedule for volumes/instances with a given tag, and deletes them by count or age. AWS Backup does the same across many services, with backup vaults, cross-Region / cross-account copies and vault lock. Either way: test a restore, on a schedule.
AMIs as backups — create-image captures the instance's volumes as snapshots plus launch metadata. By default it reboots the instance for a consistent file system; --no-reboot avoids the reboot but risks an inconsistent copy.
Patching in place — Systems Manager Patch Manager with patch baselines and maintenance windows. Right for a few long-lived instances.
Patching by replacement — build a golden AMI (EC2 Image Builder can automate build, patch and test), put it in a new launch-template version, then instance refresh the ASG: it replaces instances in batches while keeping a minimum healthy percentage, with optional checkpoints and automatic rollback. Every desk ends up identical — no drift.
Stop — RAM lost, EBS kept, instance store wiped, the public IPv4 address changes (an Elastic IP stays), the instance usually lands on a new host. No compute charge; EBS still bills.
Hibernate — RAM is written to the encrypted root EBS volume and restored on start. Must be enabled at launch, needs a root volume big enough for the RAM, and has limits on instance types, RAM size and how long an instance may stay hibernated.
Terminate — the instance is gone; volumes with DeleteOnTermination = true are deleted. Termination protection (--disable-api-termination) guards against accidents.

🤔 Why

Because the three things that end most EC2 stories badly are: no backup (or one nobody ever restored), a fleet nobody dares to patch, and a terminate that took the only copy of something. A policy, a pipeline and a checklist fix all three — and none of them depends on someone remembering.

🔧 How (in this repo)

lifecycle() in ec2/demo.py applies a "daily at 03:00, keep 7" policy to the ten days up to 2026-09-27 and prints which snapshots survive, then a table of what stop, hibernate and terminate keep. snapshot_cost() in ec2/costs.py (lesson 04) prices a retention period. ec2/test_ec2.py runs one check per lesson's promise.

🧪 Try it

python3 ec2/demo.py lifecycle
python3 - <<'EOF'
import sys; sys.path.insert(0, "ec2"); import costs
from datetime import date, timedelta
# a weekly policy that keeps 4: which Sundays survive on 2026-09-27?
today = date(2026, 9, 27)
sundays = [today - timedelta(weeks=i) for i in range(6)]
for i, d in enumerate(sundays):
    print(d, "📸 kept" if i < 4 else "🗑️ deleted")
print("daily × 7 on a 20 GB disk, 1 GB/day changes:", costs.snapshot_cost(1, 7, 20), "(GB, $/month)")
EOF
python3 ec2/test_ec2.py
# capstone: write a launch template for a web tier that check_template.py passes (L07),
# price it for three AZs with a Savings Plan base and spot extras (L08), run fleet.asg()
# with your own day of traffic (L09), and write down its snapshot and golden-AMI plan (L12).

On a real account (needs AWS credentials; AMIs and snapshots bill until you deregister and delete them — use your own IDs and names):

aws ec2 create-image --instance-id i-0123456789abcdef0 --name "school-web-2026-09-27" \
    --description "golden AMI, patched 2026-09-27"
aws ec2 create-launch-template-version --launch-template-name school-web --source-version 1 \
    --launch-template-data '{"ImageId":"ami-0fedcba9876543210"}'
aws autoscaling start-instance-refresh --auto-scaling-group-name school-web \
    --preferences '{"MinHealthyPercentage":90,"InstanceWarmup":120}'
aws autoscaling describe-instance-refreshes --auto-scaling-group-name school-web
aws ec2 stop-instances --instance-ids i-0123456789abcdef0 --hibernate
aws ec2 modify-instance-attribute --instance-id i-0123456789abcdef0 --disable-api-termination

✅ Verify — what you should see

lifecycle lists 2026-09-27 to 2026-09-21 as 📸 kept and 2026-09-20, 2026-09-19, 2026-09-18 as 🗑️ deleted by the policy, then stop RAM lost … root EBS kept … public IP changes, hibernate RAM saved to the root volume … root EBS kept … public IP changes and terminate RAM lost … root EBS deleted (DeleteOnTermination) gone, ending with bake a golden AMI (patched, tested), roll it out with an instance refresh — patch by replacing desks. Your snippet keeps 2026-09-27, 2026-09-20, 2026-09-13, 2026-09-06 and deletes 2026-08-30 and 2026-08-23, then prints daily × 7 on a 20 GB disk, 1 GB/day changes: (26, 1.3) (GB, $/month). The test suite prints twelve ✅ lines and 12/12 passed.

🏁 What you just proved

Backups that expire on their own, patches that arrive as a new template instead of a screwdriver, and a clear answer to "what do I lose if I press this button?" — and all twelve lessons' promises pass their checks.

⚠️ Common mistakes

snapshots that nobody has ever restored — a backup is only a backup after a restore drill
no retention rule, so snapshots pile up and bill for years (or a rule so short the copy you need is gone)
patching production manually over SSH, so every desk drifts into a one-off
an instance refresh with MinHealthyPercentage at 0 on a live service
terminating to "clean up" without checking DeleteOnTermination and termination protection first
expecting hibernate to work on an instance that was not launched with it enabled

🏭 Why this matters in production: this is the checklist a reviewer walks before an EC2 service goes live: tagged volumes under a snapshot policy with a cross-Region copy and a restore date, a golden-AMI pipeline with a monthly refresh, termination protection on anything stateful, and a runbook that says which button does what.

🎓 The study hall is yours

Desks in separate buildings → the right vehicle → the template and the recipe card → the drawer and the photocopy → the guest list and the wing door → no door at all → the badge instead of keys → three ways to pay → the caretaker → the reception → two inspectors → the nightly photocopy and the golden template. You didn't just learn EC2 — you can run a fleet on it. 🖥️🎓

Next doors in the school: the IAM school goes deep on the badges these desks wear; the Docker school packs what runs on the desks; the AWS school walks the whole campus; and the School portal has the rest.

git checkout main
python3 ec2/demo.py     # one last run, for fun

← Previousmonitoring Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-lifecycle branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.