أتمتة تنظيف 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، وبعدها نفذ الأوامر دي:

# 1) راجع الإعداد الحالي قبل أي تغيير
aws s3api get-bucket-lifecycle-configuration \
  --bucket my-company-assets \
  --output json > lifecycle-current.json

# 2) طبّق الإعداد الجديد
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-company-assets \
  --lifecycle-configuration file://lifecycle.json

# 3) اتأكد إن القاعدة اتحفظت
aws s3api get-bucket-lifecycle-configuration \
  --bucket my-company-assets \
  --query 'Rules[].{ID:ID,Status:Status}'

لو عندك ملفات multipart upload فشلت بسبب انقطاع شبكة أو deploy، السطر الخاص بـ AbortIncompleteMultipartUpload هينظفها بعد 7 أيام. دي من الحاجات اللي بتقلل تكلفة من غير ما تلمس ملفات المستخدم النهائية.

الأرقام: قبل وبعد بشكل واقعي

خلينا نحسب سيناريو محافظ. عندك 1TB exports قديمة في S3 Standard، و60% منها أقدم من 30 يوم. لو نقلت 600GB إلى Standard-IA، هتدفع أقل على التخزين الشهري، لكن لازم تحسب رسوم retrieval لو رجعت تقرأ الملفات بكثافة. AWS بتوضح في صفحة تسعير S3 إن التكلفة تعتمد على storage class، مدة التخزين، الطلبات، ورسوم الاسترجاع، وإن Standard-IA له حد أدنى 30 يوم وحجم billable أدنى 128KB.

بالظبط، مش كل ملف قديم يستحق النقل. ملف حجمه 20KB غالبًا مش هيوفر حاجة مفيدة بسبب حد 128KB. لكن export حجمه 300MB ومحدش بيفتحه بعد شهر مناسب جدًا. في مشروع متوسط، نقل 600GB بارد ممكن يقلل بند التخزين لهذا الجزء بنسبة ملحوظة، لكن لو فريق الدعم بيرجع يفتح نفس الملفات يوميًا، رسوم القراءة هتاكل جزء من المكسب.

الـ trade-offs وما يجب الانتباه له

• بتكسب: تنظيف تلقائي، تكلفة أقل، وقاعدة موحدة بدل قرارات يدوية.
• بتخسر: مرونة أقل لو احتجت ملف قديم بسرعة، واحتمال تكلفة retrieval أعلى مع Standard-IA أو Glacier.
• الخطر الحقيقي: أمر put-bucket-lifecycle-configuration يستبدل الإعداد الحالي. لو عندك قواعد موجودة، ادمجها في الملف الجديد بدل ما تمسحها بالغلط.
• القياس: راقب S3 Storage Lens أو Cost Explorer لمدة 14 يوم بعد التطبيق. لو الطلبات على الملفات القديمة أعلى من المتوقع، غير مدة النقل من 30 إلى 60 أو 90 يوم.

متى لا تستخدم هذه الطريقة

لا تستخدم Lifecycle للحذف لو الملفات جزء من التزام قانوني أو مالي، إلا بعد موافقة واضحة من الفريق المسؤول. لا تستخدم Standard-IA لملفات صغيرة جدًا أو ملفات تُقرأ يوميًا. ولا تطبق القاعدة على uploads/ كلها مرة واحدة؛ استخدم prefix محدد أو tag مثل retention=temporary.

مصادر اعتمدت عليها

• AWS CLI: put-bucket-lifecycle-configuration
• AWS S3 Pricing

الخطوة التالية

افتح bucket واحد عندك، اختار prefix مؤقت مثل exports/، وطبّق القاعدة على 30 يوم transition و180 يوم expiration. بعد 14 يوم راجع التكلفة والقراءات قبل ما توسعها لباقي الملفات.