AMI کا دورانِ حیات: ورژن، خفیہ کاری اور خودکار صفائی

بہت سی ٹیمیں AMI کو ایسی چیز سمجھتی ہیں جو ایک بار بنا کر بھلا دی جاتی ہے۔ مسئلہ مہینوں بعد سامنے آتا ہے: درجنوں بغیر ٹیگ امیجز، ایسے EBS اسنیپ شاٹس جن کے بارے میں کسی کو معلوم نہیں کہ مٹائے جا سکتے ہیں یا نہیں، اور ایک بل جو بغیر وضاحت بڑھتا جاتا ہے۔ AMI کے دورانِ حیات کو سنبھالنے کا مطلب ہے اسے ایک سافٹ ویئر مصنوعہ سمجھنا جس کی پیدائش، ورژن، پختگی، متروکی اور سبکدوشی ہوتی ہے۔

اچھی امیج گورننس لاگت گھٹاتی ہے، سلامتی بہتر کرتی ہے —کوئی غلطی سے ایک سال پرانی، بغیر پیچ امیج نہیں چلاتا— اور تعمیل کے آڈٹ آسان بناتی ہے۔

مرحلہ 1 — بامعنی ورژن بندی

ورژن بندی ریڑھ کی ہڈی ہے۔ اس کے بغیر «آخری اچھی AMI» راہداری کی گفتگو ہے، کوئی حقیقت نہیں۔ ہم ایک قابلِ مطالعہ اور ہم آہنگ خاکہ تجویز کرتے ہیں۔

• ورژن والا نام: مثلاً imaxe-ubuntu22-nginx-2026.07.1، مصنوعے، بنیاد اور تقویمی ورژن کے ساتھ۔
• لازمی ٹیگ: Version، GitCommit، BuildDate، Owner، Environment، CISLevel، Status۔
• ناقابلِ تبدیل: ایک ورژن، ایک مصنوعہ۔ شائع شدہ AMI کو کبھی نہ بدلیں؛ نیا ورژن بنائیں۔
• مرکزی رجسٹری: «موجودہ پروڈکشن AMI» کی شناخت رکھنے کے لیے AWS Systems Manager Parameter Store استعمال کریں تاکہ آپ کے Launch Templates اسے حوالے سے پڑھیں۔

مرحلہ 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 پر منحصر تو نہیں۔

دورانِ حیات کا خلاصہ

AMI گورننس کے چھ مراحل اور انہیں خودکار بنانے کا طریقہ۔

جن پیمانوں پر نظر رکھیں

• زیرِ استعمال AMIs کی اوسط عمر: جتنی کم، اتنی بہتر پیچنگ۔
• یتیم اسنیپ شاٹس کی تعداد اور ان کی ماہانہ لاگت۔
• خفیہ AMIs کا تناسب، ہدف 100 %۔
• اہم CVE سے نئی امیج کی اشاعت تک وقت، یعنی پیچ کا MTTR۔

اکثر پوچھے جانے والے سوالات

AMIs مٹانے کے باوجود میرا EBS بل کیوں بڑھ رہا ہے؟

کیونکہ AMI کی رجسٹریشن ختم کرنے سے اس کے اسنیپ شاٹس نہیں مٹتے۔ انہیں صراحتاً حذف کرنا ہوگا۔ یتیم اسنیپ شاٹس کا باقاعدہ آڈٹ کریں؛ عموماً یہی سب سے بڑی پوشیدہ لاگت ہوتی ہے۔

کیا خفیہ AMI کسی دوسرے اکاؤنٹ کے ساتھ شریک کرنا محفوظ ہے؟

جی ہاں، بشرطیکہ آپ KMS کلید تک رسائی ایک مخصوص grant اور کم سے کم اجازتوں کے ساتھ دیں۔ اس رسائی کے بغیر منزل کا اکاؤنٹ امیج چلا ہی نہیں سکے گا۔

AMI کے کتنے ورژن رکھنے چاہئیں؟

یہ آپ کی واپسی اور تعمیل کی ضرورت پر منحصر ہے، مگر دو سے چار حالیہ ورژن رکھنا عموماً واپسی کی حفاظت اور لاگت کے درمیان اچھا توازن ہوتا ہے۔

imaxe.cloud میں ہم اپنی امیجز کو شروع ہی سے ورژن بندی اور خفیہ کاری کے ساتھ ڈیزائن کرتے ہیں، تاکہ ان کا دورانِ حیات قابلِ پیش بینی اور قابلِ آڈٹ رہے۔