الخلاصة

  • يمنع السلوك الافتراضي الحالي في S3 Lifecycle انتقال الكائنات الأصغر من 128 كيلوبايت إلى أي فئة تخزين. قبل سبتمبر 2024، كان يسمح لها بالانتقال افتراضياً إلى S3 Glacier Flexible Retrieval أو Deep Archive فقط.
  • تحتفظ الإعدادات المنشأة قبل ذلك بالسلوك القديم إلى أن تُعدّل. إنشاء قاعدة أو تحريرها أو حذفها يجلب السلوك الجديد، ما لم يُحدّد المشغّل السلوك السابق أو مرشحاً مخصصاً لحجم الكائن.

تغيرت القاعدة، فتغيرت بوابة الأرشيف

يفتح المسؤول إعداد Lifecycle قديماً ليصحح موعد انتقال أو بادئة ملفات. يقبل النظام الحفظ، وتظل القاعدة مفعّلة. لكن وثائق AWS تصف نتيجة أوسع: تعديل قواعد إعداد أُنشئ قبل سبتمبر 2024 يجعله يتبنى الحد الافتراضي الجديد للكائنات الصغيرة. ما كان مؤهلاً للانتقال إلى فئتي Glacier المذكورتين قد يبقى في فئته الحالية ما لم توجد تعليمات حجم صريحة.

الحديث عن أهلية الانتقال، لا عن حذف الكائن. في السلوك القديم أيضاً لم يكن الحجم وحده كافياً؛ كان على الكائن استيفاء بقية شروط القاعدة. الفارق أن فريق التخزين قد يعتمد خطة مالية تفترض استمرار انتقال المجموعة الصغيرة، ثم يقرأ إشعار «تم تحديث الإعداد» من دون أن يفحص الافتراض الذي تغير.

اختارت AWS الحد لسبب مالي واضح. كل كائن ينتقل يُحتسب له طلب انتقال، وقد تكلف الطلبات على الملفات الصغيرة أكثر مما توفره أجرة التخزين الأرخص. وفي S3 Glacier Flexible Retrieval وDeep Archive، تضيف المنصة 40 كيلوبايت من البيانات الوصفية المدفوعة لكل كائن: 8 كيلوبايت بسعر S3 Standard و32 كيلوبايت بسعر فئة الأرشيف. هذا يبرر الحذر الافتراضي، لكنه لا يحسب فاتورة مجموعة بيانات بعينها.

يمكن للعميل تغيير النتيجة. تقدم AWS مثالاً لمرشح حجم يسمح بانتقال الكائنات الصغيرة، ويعلو المرشح المخصص على الحد الافتراضي. وتتيح واجهة الإعدادات للدلاء العامة اختيار السلوك القديم بحسب فئة الوجهة أو حد 128 كيلوبايت العام. القرار الصحيح يتطلب عدد الكائنات وأحجامها ومدة بقائها وكلفة الطلبات والاستعادة. لا توجد في هذه المصادر فاتورة عميل أو وفر محقق.

المصادر