أتمتة تنظيف S3 Lifecycle: قلل فاتورة التخزين بدون حذف خطر
لو عندك bucket بيخزن exports وbackups يومية، المقال ده هيوفرلك طريقة عملية تقلل فاتورة التخزين بدون سكربت حذف عشوائي.
المشكلة باختصار
اللي بيحصل فعلاً إن الفريق بيبدأ بـ S3 bucket بسيط: صور، logs، exports، ونسخ احتياطية. بعد 6 شهور تلاقي 1.8TB ملفات قديمة، منها 70% لا يتم فتحه تقريبًا. الطريقة الشائعة الغلط هي إن حد يشغل aws s3 rm --recursive كل فترة. الطريقة دي بتفشل لأنها تمسح بناءً على إحساسك، مش بناءً على سياسة واضحة.
الافتراض إن عندك bucket عام للمشروع، وفيه prefixes واضحة مثل exports/ وbackups/ وtmp/. لو عندك 50K زائر يوميًا وبتطلع 2GB logs يوميًا، هتوصل تقريبًا إلى 60GB شهريًا من logs فقط. الرقم صغير في البداية، لكنه بيتراكم بصمت.
الفكرة: Lifecycle بدل سكربت حذف يدوي
ركز: S3 Lifecycle مش cron بيحذف ملفات. هو policy داخل S3 بتقول: الملفات تحت prefix معين تنتقل بعد عدد أيام إلى storage class أرخص، أو تتحذف بعد مدة محددة. حسب توثيق AWS CLI، أمر put-bucket-lifecycle-configuration يستبدل إعدادات Lifecycle الحالية للـ bucket، ويدعم قواعد تعتمد على prefix أو tags أو حجم object. لذلك لازم تحفظ القديم قبل ما تطبق الجديد.
مثال بسيط: ملفات exports/ يحتاجها العميل خلال أول شهر. بعد 30 يوم نقدر ننقلها إلى STANDARD_IA. بعد 180 يوم نحذفها. الـ trade-off هنا واضح: بتكسب تكلفة أقل وتنظيف تلقائي، لكن بتخسر سرعة وبساطة الوصول لو الملف رجع مطلوب بعد مدة طويلة.
إعداد عملي قابل للنسخ
أفضل طريقة تبدأ بيها هي قاعدة واحدة على prefix واحد. لا تبدأ بكل الـ bucket. جرّب على exports/ لأن تأثيره عادة واضح وخطره أقل من uploads/.
{
"Rules": [
{
"ID": "exports-transition-and-expire",
"Status": "Enabled",
"Filter": {
"Prefix": "exports/"
},
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
}
],
"Expiration": {
"Days": 180
},
"AbortIncompleteMultipartUpload": {
"DaysAfterInitiation": 7
}
}
]
}احفظ الملف باسم lifecycle.json، وبعدها نفذ الأوامر دي: