कई टीमें AMI को ऐसी चीज़ मानती हैं जो एक बार बनाई और भुला दी जाती है। समस्या महीनों बाद दिखती है: दर्जनों बिना टैग वाली इमेज, ऐसे EBS स्नैपशॉट जिनके बारे में किसी को नहीं पता कि हटाए जा सकते हैं या नहीं, और बिना स्पष्टीकरण बढ़ता बिल। AMI का जीवनचक्र संभालने का मतलब है उसे एक सॉफ़्टवेयर आर्टिफ़ैक्ट की तरह देखना — जन्म, संस्करण, परिपक्वता, डेप्रिकेशन और विदाई के साथ।
अच्छी इमेज गवर्नेंस लागत घटाती है, सुरक्षा सुधारती है —कोई ग़लती से साल भर पुरानी बिना पैच वाली इमेज नहीं चलाता— और अनुपालन ऑडिट आसान बनाती है।
चरण 1 — अर्थपूर्ण संस्करण
संस्करण रीढ़ की हड्डी है। इसके बिना «आख़िरी अच्छी AMI» गलियारे की बातचीत है, आँकड़ा नहीं। हम एक पठनीय और सुसंगत योजना की सलाह देते हैं।
- संस्करण सहित नाम: जैसे
imaxe-ubuntu22-nginx-2026.07.1, जिसमें उत्पाद, आधार और कैलेंडर संस्करण हों। - अनिवार्य टैग:
Version,GitCommit,BuildDate,Owner,Environment,CISLevel,Status। - अपरिवर्तनीय: एक संस्करण, एक आर्टिफ़ैक्ट। प्रकाशित AMI को कभी न बदलें; नया संस्करण बनाएँ।
- केंद्रीय रजिस्ट्री: «मौजूदा प्रोडक्शन AMI» का ID रखने के लिए AWS Systems Manager Parameter Store इस्तेमाल करें, ताकि आपके Launch Template उसे संदर्भ से पढ़ें।
चरण 2 — छोर से छोर तक एन्क्रिप्शन
AMI का डेटा EBS स्नैपशॉट में रहता है। अगर वे एन्क्रिप्ट नहीं हैं, तो कोई भी बेतरतीब प्रति संभावित रिसाव है। एन्क्रिप्शन नियम होना चाहिए, अपवाद नहीं।
- डिफ़ॉल्ट एन्क्रिप्शन: खाते और रीजन स्तर पर EBS encryption by default चालू करें।
- आपकी प्रबंधित कुंजियाँ (CMK): अनुमतियाँ और रोटेशन नियंत्रित करने के लिए AWS की डिफ़ॉल्ट कुंजी के बजाय अपनी KMS कुंजी इस्तेमाल करें।
- कॉपी यानी दोबारा एन्क्रिप्शन: AMI को दूसरे रीजन या खाते में कॉपी करते समय उसे गंतव्य कुंजी से दोबारा एन्क्रिप्ट कर लें।
- KMS grants से साझा करें: दूसरे खातों को AMI बाँटते समय न्यूनतम नीतियों के साथ कुंजी तक पहुँच दें।
चरण 3 — डेप्रिकेशन: हटाने से पहले चेतावनी
AWS किसी AMI को तारीख़ के साथ अप्रचलित (deprecated) चिह्नित करने देता है। उस क्षण से वह खोजों में डिफ़ॉल्ट रूप से दिखना बंद हो जाती है, पर जो उसे स्पष्ट रूप से संदर्भित करता है उसके लिए काम करती रहती है। यह «चालू» और «हटाई हुई» के बीच का सभ्य क़दम है: आप चेतावनी देते हैं, माइग्रेशन का समय देते हैं और तैनातियाँ नहीं तोड़ते।
चरण 4 — स्वचालित सफ़ाई (और स्नैपशॉट की छिपी लागत)
पैसा यहीं है। जब आप कोई AMI हटाते हैं, तो उससे जुड़े EBS स्नैपशॉट अपने आप नहीं हटते। रहस्यमय ढंग से बढ़ते स्टोरेज बिलों का यही नंबर एक कारण है। विदाई की नीति को AMI डीरजिस्टर करना चाहिए और उसके बाद अनाथ स्नैपशॉट हटाने चाहिए।
- रिटेंशन नीति: N हालिया संस्करण रखें (जैसे आख़िरी तीन) और बाक़ी विदा करें।
- क्लाउड से स्वचालित करें: Amazon Data Lifecycle Manager (DLM) नीति के आधार पर इमेज बनाना और हटाना संभाल सकता है।
- अनाथ स्नैपशॉट खोजें: बिना जुड़ी AMI वाले स्नैपशॉट का समय-समय पर ऑडिट कर उन्हें हटाएँ।
- कभी आँख मूँदकर न हटाएँ: विदा करने से पहले जाँचें कि कोई सक्रिय इंस्टेंस या Launch Template उस AMI पर निर्भर तो नहीं।
जीवनचक्र सारांश तालिका
| चरण | मुख्य क्रिया | उपकरण या सेवा |
|---|---|---|
| निर्माण | पुनरुत्पाद्य बिल्ड और टैगिंग | Packer / EC2 Image Builder |
| एन्क्रिप्शन | CMK से एन्क्रिप्टेड स्नैपशॉट | AWS KMS + EBS default encryption |
| वितरण | मल्टी-रीजन या मल्टी-अकाउंट कॉपी व पुनः एन्क्रिप्शन | AMI copy / AWS RAM |
| प्रचलन | मौजूदा ID की रजिस्ट्री | SSM Parameter Store |
| डेप्रिकेशन | तारीख़ के साथ अप्रचलित चिह्नित करना | ec2 enable-image-deprecation |
| विदाई | डीरजिस्टर और स्नैपशॉट हटाना | DLM / निर्धारित स्क्रिप्ट |
AMI गवर्नेंस के छह चरण और उन्हें स्वचालित करने का तरीक़ा।
जिन मीट्रिक पर नज़र रखें
- उपयोग में मौजूद AMI की औसत आयु: जितनी कम, उतने बेहतर पैच।
- अनाथ स्नैपशॉट की संख्या और उनकी मासिक लागत।
- एन्क्रिप्टेड AMI का प्रतिशत, लक्ष्य 100 %।
- गंभीर CVE से नई इमेज प्रकाशन तक का समय, यानी पैच का MTTR।
अक्सर पूछे जाने वाले सवाल
AMI हटा देने के बाद भी मेरा EBS बिल क्यों बढ़ रहा है?
क्योंकि AMI डीरजिस्टर करने से उसके स्नैपशॉट नहीं हटते। उन्हें स्पष्ट रूप से हटाना होगा। अनाथ स्नैपशॉट का नियमित ऑडिट करें; आम तौर पर यही सबसे बड़ी छिपी लागत होती है।
क्या एन्क्रिप्टेड AMI दूसरे खाते से साझा करना सुरक्षित है?
हाँ, बशर्ते आप KMS कुंजी तक पहुँच किसी विशिष्ट grant और न्यूनतम अनुमतियों से दें। उस पहुँच के बिना गंतव्य खाता इमेज लॉन्च नहीं कर पाएगा।
AMI के कितने संस्करण रखने चाहिए?
यह आपकी रोलबैक और अनुपालन ज़रूरतों पर निर्भर है, पर दो से चार हालिया संस्करण रखना आम तौर पर रोलबैक सुरक्षा और लागत के बीच अच्छा संतुलन होता है।
imaxe.cloud में हम अपनी इमेज शुरू से ही संस्करण और एन्क्रिप्शन के साथ डिज़ाइन करते हैं, ताकि उनका जीवनचक्र पूर्वानुमेय और ऑडिट योग्य रहे।
