كيفية خفض تكاليف تخزين AWS S3 بنسبة 40% باستخدام سياسات Lifecycle: دليل عملي

إذا كانت فاتورة AWS الخاصة بك ترتفع شهرًا بعد شهر دون أن تتمكن من تحديد السبب، فعادةً ما تكون حاويات S3 هي نقطة البداية في التحقيق. معظم فرق الهندسة تقوم بإعداد التخزين في المراحل الأولى من المشروع ثم تنتقل إلى مهام أخرى دون إعداد أي Lifecycle Rule. مع مرور الوقت، تتراكم سجلات التطبيقات، وتتزايد ملفات النسخ الاحتياطي، وتبقى الوسائط المعالجة مخزنة في S3 Standard بنفس التكلفة التي تدفعها مقابل بيانات الإنتاج النشطة.

بالنسبة لمهندسي السحابة ومعماريي الحلول، فهذه ليست مجرد مشكلة فواتير، بل فجوة في الحوكمة. بدون استراتيجية واضحة لتقسيم طبقات التخزين، فإن فريقك يدفع أسعار تخزين مرتفعة مقابل بيانات لم يتم الوصول إليها منذ أشهر.

تُعد سياسات S3 Lifecycle الطريقة الأكثر مباشرة لحل هذه المشكلة. فهي تسمح لك بأتمتة انتقال البيانات بين فئات التخزين المختلفة مع تقدم عمر البيانات، بحيث تتم عملية تحسين التكلفة بشكل مستمر دون الحاجة إلى إدارة يدوية من فريقك.

للشركات التي ترغب في مراجعة بنيتها السحابية بالكامل وليس التخزين فقط، فإن AWS Well-Architected Review الخاص بنا يغطي كفاءة التكلفة، والأمان، والاعتمادية، وفرص تحسين الأداء عبر جميع الأحمال التشغيلية.

تتيح لك Amazon S3 Lifecycle Policies نقل البيانات تلقائيًا بين طبقات التخزين بناءً على أنماط الوصول ومتطلبات الاحتفاظ بالبيانات. وعند دمجها مع S3 Intelligent-Tiering وS3 Glacier، تحقق معظم المؤسسات تخفيضًا في تكاليف التخزين يتراوح بين 30% و40% دون التأثير على إمكانية الوصول أو متطلبات الامتثال.

يقدم هذا الدليل شرحًا عمليًا متكاملًا يشمل اختيار فئات التخزين، إعداد Lifecycle Rules، استراتيجيات Versioning، إدارة Delete Markers، التنفيذ باستخدام CLI، الإعداد عبر AWS Console، وأفضل الممارسات التي تميز بيئة تخزين مُدارة بكفاءة عن بيئة تستمر تكاليفها بالارتفاع.

لماذا تستمر تكاليف تخزين AWS في الارتفاع دون إنذار

نادراً ما تقفز تكاليف التخزين في AWS بشكل مفاجئ، بل ترتفع تدريجيًا نتيجة قرارات لم تُتخذ وعمليات لم يتم وضعها. وعند تدقيق بيئات AWS الخاصة بالمؤسسات، تتكرر نفس الأنماط بغض النظر عن القطاع.

عادةً ما تكون سجلات التطبيقات هي المساهم الأكبر. يقوم الفريق بتفعيل التسجيل التفصيلي أثناء مرحلة تصحيح الأخطاء ثم ينسى تحديد تاريخ انتهاء لها. وبعد عامين، تجد جيجابايتات من السجلات مخزنة في S3 Standard بنفس تكلفة ملفات قاعدة بيانات الإنتاج التي يتم الوصول إليها يوميًا.

تمثل ملفات النسخ الاحتياطي مشكلة مشابهة. يتم إنشاؤها تلقائيًا وفق جدول زمني وتُحتفظ بها إلى أجل غير مسمى لأن حذفها دون سياسة رسمية يبدو محفوفًا بالمخاطر. أما سجلات الامتثال، فغالبًا ما تبقى في طبقات التخزين مرتفعة التكلفة لفترات أطول من اللازم بسبب غياب الأرشفة الآلية.

المشكلة الأساسية ثابتة: بدون أتمتة دورة الحياة، يتم التعامل مع جميع الملفات في الحاوية بنفس الطريقة بغض النظر عن عمرها أو معدل الوصول إليها. ملف سجل عمره سنتان يكلف نفس تكلفة ملف يقرأه التطبيق مئات المرات يوميًا.

فيما يلي الشكل الفعلي لأنماط الوصول لمعظم بيانات المؤسسات:

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

بمجرد فهم هذه الأنماط لبياناتك، يصبح بناء استراتيجية Lifecycle المناسبة أمرًا مباشرًا.

اختيار فئة التخزين المناسبة في S3 لكل نوع من البيانات

قبل أن تكتب حتى قاعدة Lifecycle واحدة، تحتاج إلى فهم التكلفة الفعلية لكل فئة تخزين وما التنازلات المرتبطة بها. اختيار الطبقة الخاطئة لنوع معين من البيانات هو أحد الأسباب الرئيسية التي تجعل إعدادات Lifecycle تفشل في تحقيق وفورات حقيقية.

1. S3 Standard

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

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

2. S3 Standard-Infrequent Access (Standard-IA)

   تُعد Standard-IA من أكثر فئات التخزين غير المستغلة في معظم حسابات AWS. فهي تقلل تكاليف التخزين بحوالي 46 بالمئة مقارنة بـ Standard مع الحفاظ على سرعة استرجاع بزمن ميلي ثانية عند الحاجة، لكنها تفرض رسوم استرجاع لكل جيجابايت، مما يجعلها اقتصادية فقط للبيانات التي يتم الوصول إليها أقل من مرة أو مرتين شهريًا.

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

3. S3 Intelligent-Tiering

   تُعتبر Intelligent-Tiering الخيار المناسب عندما لا يمكنك التنبؤ بشكل موثوق بعدد مرات الوصول إلى مجموعة بيانات معينة. وبدلًا من مطالبتك بتحديد جداول الانتقال مسبقًا، تقوم بمراقبة كل ملف بشكل منفصل وتنقله تلقائيًا بين الطبقات بناءً على أنماط الاستخدام الفعلية، دون فرض رسوم استرجاع عندما يتم نقل الملف مرة أخرى إلى طبقة أعلى.

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

4. S3 Glacier Flexible Retrieval / Deep Archive

تم تصميم طبقات Glacier خصيصًا للبيانات التي يجب الاحتفاظ بها ولكن نادرًا ما يتم استرجاعها. وبجزء بسيط من تكلفة S3 Standard، فهي مناسبة جدًا لسجلات الامتثال، وسجلات التدقيق، والمستندات القانونية، وأرشيفات النسخ الاحتياطي طويلة الأجل.

   الفرق بين طبقتي Glacier يعود إلى سرعة الاسترجاع والتكلفة. تقوم Glacier Flexible Retrieval باستعادة الملفات خلال 3 إلى 5 ساعات عند طلب الاسترجاع القياسي. أما Glacier Deep Archive فقد يستغرق حتى 12 ساعة لكنه يكلف أقل من 0.001 دولار لكل جيجابايت شهريًا، مما يجعله أرخص خيار تخزين في AWS. كما أن لكلتا الطبقتين حدًا أدنى لمدة التخزين يؤثر على توقيت الانتقال: 90 يومًا لـ Glacier Flexible و180 يومًا لـ Deep Archive. وبالنسبة لبيانات الامتثال التي قد تتطلب وصولًا طارئًا، فإن Glacier Flexible Retrieval يعتبر الخيار الأكثر أمانًا.

كيف تعمل إجراءات S3 Lifecycle

   تعتمد كل Lifecycle Policy على نوع أو كلا النوعين من الإجراءات التالية. فهم طريقة عمل كل نوع قبل البدء في كتابة القواعد يساعدك على تجنب أخطاء الإعداد التي قد تقلل من حجم التوفير أو تسبب رسوم استرجاع غير متوقعة.

Transition Actions

تقوم Transition Actions بنقل الملفات تلقائيًا من فئة تخزين إلى أخرى بعد عدد محدد من الأيام. ولا يتطلب الأمر أي تدخل يدوي بعد تفعيل القاعدة. يمكنك التفكير فيها كعملية مجدولة تنقل البيانات من التخزين مرتفع التكلفة إلى التخزين الأرخص مع تقدم عمر البيانات، وتعمل بشكل مستمر في الخلفية دون أي جهد إضافي من فريقك.

   هناك نقطة مهمة يجب فهمها منذ البداية: عمليات الانتقال تنقل البيانات فقط إلى طبقات أبرد. لا يمكن لـ Lifecycle Rule إعادة الملف إلى S3 Standard. وإذا احتجت في أي وقت إلى إعادة البيانات إلى طبقة أعلى تكلفة لحالة استخدام معينة، فسيتطلب ذلك عملية نسخ يدوية أو منطقًا مخصصًا داخل التطبيق. وهذا يعني أن جداول الانتقال يجب أن تعتمد على بيانات وصول فعلية وليس على افتراضات حول كيفية استخدام البيانات.

سلسلة انتقال نموذجية لبيانات المؤسسات:

• من اليوم 0 إلى 30: يبقى الملف في S3 Standard بتكلفة تقريبية 0.023 دولار لكل جيجابايت شهريًا
•    اليوم 30: ينتقل إلى Standard-IA بتكلفة تقريبية 0.0125 دولار لكل جيجابايت شهريًا، أي أقل بحوالي 46 بالمئة
•    اليوم 90: ينتقل إلى Glacier Deep Archive بتكلفة أقل من 0.001 دولار لكل جيجابايت شهريًا، وهو ما يمثل أكثر من 95 بالمئة توفير مقارنة بـ Standard

Expiration Actions

تمثل Expiration Actions جانب التنظيف في إدارة دورة الحياة. فبينما تقلل Transition Rules التكلفة من خلال نقل البيانات إلى طبقات تخزين أرخص، تقوم Expiration Rules بإزالة التكلفة بالكامل عبر حذف الملفات نهائيًا عندما لا يعود هناك حاجة للاحتفاظ بها.

يقوم Current Version Expiration بتحديد تاريخ حذف نهائي للملفات الحالية. ويكون هذا مفيدًا جدًا للملفات المؤقتة مثل مخرجات المعالجة الوسيطة، وبيانات الجلسات، أو أي محتوى له نهاية عمر محددة بوضوح.

تصبح Noncurrent Version Expiration ضرورية عندما يكون Versioning مفعّلًا. ففي كل مرة يتم فيها استبدال ملف أو حذفه داخل Bucket مفعّل عليه Versioning، يتم الاحتفاظ بالإصدار السابق ويتم احتساب تكلفته بالكامل. ويمكن لحاوية تعمل مع Versioning لمدة عام أن تحتوي بسهولة على بيانات أكبر بثلاث إلى خمس مرات مما توحي به لوحات المتابعة، ويكون معظمها عبارة عن إصدارات قديمة لن يتم الوصول إليها مرة أخرى. وتوفر Lifecycle Rule تقوم بحذف الإصدارات القديمة بعد 60 يومًا مع الاحتفاظ بآخر ثلاث نسخ فقط قدرة استرجاع مفيدة دون تكلفة الاحتفاظ بكل شيء.

يُعد تنظيف Multipart Uploads غير المكتملة من أكثر فرص التوفير التي يتم تجاهلها في بيئات AWS. فعندما يفشل رفع ملف كبير قبل اكتماله، يحتفظ S3 بجميع الأجزاء التي تم رفعها ويستمر في احتساب تكلفتها إلى أجل غير مسمى. وتقوم Lifecycle Rule التي تلغي عمليات Multipart Upload غير المكتملة بعد ثلاثة إلى سبعة أيام بحل هذه المشكلة بالكامل، وفي البيئات التي تعتمد بكثرة على رفع الملفات الكبيرة تكون الوفورات الناتجة أكبر مما تتوقعه معظم الفرق.

مثال حقيقي من مؤسسة: خفض تكاليف التخزين بنسبة 43% خلال 90 يومًا

أحد عملائنا، وهي منصة متوسطة الحجم لتحليلات الوسائط تقوم بمعالجة محتوى الفيديو لعلامات التجارة الإلكترونية، جاء إلينا بمشكلة تظهر بشكل أو بآخر في معظم بيئات AWS الخاصة بالمؤسسات التي نقوم بمراجعتها. كانت فاتورة S3 الخاصة بهم ترتفع بنسبة 25 بالمئة شهريًا لمدة ستة أشهر متتالية، ولم يتمكن أي شخص في الفريق من تحديد مصدر هذا الارتفاع. وعندما قمنا بتدقيق بيئتهم، تجاوز إجمالي التخزين 400 تيرابايت بينما كانت ملفات الإنتاج النشطة تمثل أقل من 15 بالمئة فقط من هذا الحجم.
استغرق التشخيص حوالي ساعة واحدة. كل شيء كان موجودًا في S3 Standard. الفيديوهات الخام المرفوعة، ومخرجات التحويل، وسجلات التطبيقات، وسجلات الامتثال الخاصة بسبع سنوات، كانت جميعها مخزنة في نفس فئة التخزين وبنفس التكلفة دون أي قواعد انتهاء صلاحية أو انتقال مطبقة في أي مكان.

إليك ما قمنا بتنفيذه:

• الاحتفاظ بـ S3 Standard لملفات الوسائط النشطة والسجلات الخاصة بآخر 30 يومًا
• استخدام Standard-IA لمخرجات المعالجة والسجلات التي يتراوح عمرها بين 30 و90 يومًا
• استخدام Glacier Flexible Retrieval لسجلات الامتثال الأقدم من 90 يومًا
• استخدام Glacier Deep Archive لأي بيانات أقدم من 365 يومًا دون الحاجة إلى استرجاع سريع
• حذف الإصدارات القديمة Noncurrent Versions بعد 60 يومًا لمنع تضخم التخزين الناتج عن Versioning
• إلغاء عمليات Multipart Upload غير المكتملة بعد 7 أيام للتخلص من أجزاء الرفع المهجورة

النتائج بعد 90 يومًا:

• انخفض الإنفاق الشهري على S3 من حوالي 38,000 دولار إلى 21,500 دولار، أي انخفاض بنسبة 43 بالمئة
• تم نقل أكثر من 280 تيرابايت تلقائيًا إلى طبقات Glacier دون أي تدخل يدوي
• تحسن وضع الامتثال مع تخزين جميع السجلات داخل Glacier غير القابل للتعديل مع نوافذ احتفاظ موثقة

تبدأ العديد من المؤسسات هذا النوع من العمل خلال مبادرات أوسع للانتقال إلى السحابة أو تحديث البنية التقنية. تساعد خدمات Cloud Migration Services الخاصة بنا الفرق على تصميم بيئات AWS تكون فيها كفاءة التكلفة جزءًا من البنية منذ البداية بدلًا من معالجتها لاحقًا عندما تصبح الفواتير صعبة التبرير.

نظرة عامة على البنية المعمارية: كيف يعمل تدفق البيانات

تم تصميم بنية Lifecycle حول الطريقة الفعلية التي تتغير بها أنماط الوصول إلى البيانات مع مرور الوقت. بالنسبة لمعظم أنواع بيانات المؤسسات، يكون الوصول مرتفعًا خلال الأسابيع الأولى، ثم ينخفض بشكل حاد بعد 30 يومًا، ويصل إلى ما يقارب الصفر بعد ثلاثة أشهر. ويعكس هيكل طبقات التخزين هذا المنحنى بشكل مباشر.

التخزين النشط إلى التخزين الدافئ إلى التخزين البارد إلى الأرشيف إلى الحذف

إليك كيف يرتبط كل انتقال بمنطق أعمال محدد ولماذا تعتبر هذه الحدود الزمنية منطقية:

1- تصل الملفات الجديدة إلى S3 Standard حيث تكون متاحة فورًا لعمليات قراءة التطبيقات، والتقارير النشطة، وعمليات تصحيح الأخطاء

2- بعد 30 يومًا، تنتقل الملفات إلى Standard-IA. يتوافق هذا التوقيت مع نهاية معظم دورات تصحيح الأخطاء النشطة وفترات التقارير الشهرية التي لا تزال البيانات خلالها مطلوبة أحيانًا ولكن لم تعد تُستخدم يوميًا
3- بعد 90 يومًا، تنتقل الملفات إلى Glacier. يغطي هذا دورات التقارير الفصلية مع الحفاظ على إمكانية استعادة البيانات عند طلبات التدقيق. معظم البيانات التشغيلية التي لم يتم الوصول إليها خلال ثلاثة أشهر لن تكون مطلوبة مرة أخرى إلا في ظروف استثنائية
4- يتم حذف الإصدارات القديمة Noncurrent Versions التي يزيد عمرها عن 60 يومًا. يمنح هذا فريقك نافذة مدتها شهران لاستعادة البيانات بعد التعديلات أو عمليات الاستبدال غير المقصودة، مع منع الإصدارات القديمة من التراكم وتحولها إلى تكلفة كبيرة ومتزايدة
5- تتم إزالة Delete Markers المنتهية الصلاحية تلقائيًا. بدون هذه القاعدة، تتراكم العلامات المهجورة وتخفي الحجم والبنية الحقيقية للحاوية الخاصة بك
6- تنتهي صلاحية الملفات بعد 365 يومًا، وهو ما يتوافق مع الحد الأدنى القياسي لفترات الاحتفاظ بالبيانات التشغيلية التي لا تخضع لمتطلبات امتثال أطول

النتيجة هي بيئة تخزين تُدير نفسها بنفسها. لا توجد مهام تنظيف شهرية، ولا قوائم أرشفة يدوية، ولا جداول بيانات لتتبع أي الحاويات تحتاج إلى اهتمام خلال هذا الربع. بمجرد كتابة القواعد واختبارها، تستمر وفورات التكلفة في التحقق بشكل متواصل.

التنفيذ العملي باستخدام AWS Console وCLI

الخطوة 1: إنشاء S3 Bucket

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

AWS CLI

aws s3api create-bucket 
  --bucket your-company-storage-lifecycle 
  --region ap-south-1 
  --create-bucket-configuration LocationConstraint=ap-south-1

AWS Console Path

AWS Console إلى Amazon S3 إلى Buckets إلى Create bucket

عند إعداد الـ Bucket، اترك خيار Block Public Access مفعّلًا. هذا هو الإعداد الافتراضي ويعمل كطبقة حماية إضافية حتى لو تم إعداد Bucket Policies بشكل خاطئ لاحقًا. اترك Versioning معطلًا في هذه المرحلة. سنقوم بتفعيله في الخطوة 4 بعد فهم واضح لكيفية تفاعله مع Lifecycle Rules الخاصة بك.

الخطوة 2: رفع وتنظيم البيانات

قبل رفع البيانات، قم بتنظيمها داخل Prefixes تعكس أنواع البيانات المختلفة. هذا مهم لأن Lifecycle Rules يمكن ربطها بـ Prefixes محددة، مما يسمح لك بتطبيق جداول انتقال مختلفة على أنواع البيانات المختلفة. القاعدة التي تستهدف Prefix باسم logs/ لن تؤثر على الملفات الموجودة داخل مجلد compliance/.

هيكل Prefix مناسب لمعظم بيئات المؤسسات:

• logs/ لسجلات التطبيقات وسجلات الوصول التي تنتهي صلاحيتها بسرعة
• reports/ لمخرجات الأعمال الشهرية والفصلية
• media/ للصور والفيديوهات الخام أو المعالجة
• backups/ لنسخ قواعد البيانات ولقطات البنية التحتية
• compliance/ لسجلات التدقيق والمستندات القانونية التي تتطلب أطول فترة احتفاظ

AWS CLI

aws s3 cp your-local-data/ s3://your-company-storage-lifecycle/ --recursive

AWS Console

افتح الـ Bucket ثم Upload ثم Add files and folders. استخدم هيكل الـ Prefixes المذكور أعلاه كأسماء للمجلدات أثناء رفع الملفات.

الخطوة 3: تطبيق Lifecycle Policy

هذه هي الخطوة التي تحقق وفورات التكلفة الفعلية. قبل تطبيق الإعدادات، هناك نقطتان مهمتان يجب فهمهما.

القيمة الفارغة لـ Prefix داخل Filter تطبق القاعدة على جميع الملفات داخل الـ Bucket. هذا مناسب لبيئة اختبار لكنه واسع جدًا لبيئات الإنتاج. في بيئات الإنتاج، قم بإنشاء قواعد منفصلة مرتبطة بـ Prefixes محددة. كذلك تذكر أن S3 يفرض حدًا أدنى مدته 30 يومًا داخل Standard قبل أن يتمكن الملف من الانتقال إلى Standard-IA، و30 يومًا إضافية داخل Standard-IA قبل الانتقال إلى Glacier.

Create lifecycle.json

{
  "Rules": [
    {
      "ID": "StorageOptimizationPolicy",
      "Filter": { "Prefix": "" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" }
      ],
      "Expiration": { "Days": 365 },
      "NoncurrentVersionExpiration": { "NoncurrentDays": 60 }
    }
  ]
}

Apply the configuration:

aws s3api put-bucket-lifecycle-configuration 
  --bucket your-company-storage-lifecycle 
  --lifecycle-configuration file://lifecycle.json

AWS Console Path

Bucket إلى تبويب Management إلى Lifecycle rules إلى Create lifecycle rule. قم بتحديد الانتقال بعد 30 يومًا إلى Standard-IA وبعد 90 يومًا إلى Glacier، مع انتهاء صلاحية الملفات بعد 365 يومًا.

الخطوة 4: تفعيل Versioning

يحمي Versioning من الحذف غير المقصود وعمليات الاستبدال، لكنه يأتي مع تأثير على التكلفة يسهل التقليل من أهميته. في كل مرة يتم فيها تعديل ملف أو حذفه داخل Bucket مفعّل عليه Versioning، يتم الاحتفاظ بالإصدار السابق ويتم احتساب تكلفته بالكامل. وفي البيئات النشطة، يمكن أن يؤدي ذلك إلى تضخم كبير في حجم البيانات المخزنة خلال أسابيع إذا لم تقم بربط Versioning بقواعد حذف الإصدارات القديمة.

قم بتفعيل Versioning مع العلم أن إعداد NoncurrentVersionExpiration الذي أضفته في الخطوة 3 سيتولى عملية التنظيف تلقائيًا. سيتم حذف الإصدارات القديمة وفق الجدول المحدد بينما يبقى الإصدار الحالي متاحًا بالكامل.

AWS CLI

aws s3api put-bucket-versioning 
  --bucket your-company-storage-lifecycle 
  --versioning-configuration Status=Enabled

AWS Console Path

Bucket إلى Properties إلى Bucket Versioning إلى Edit إلى Enable

إدارة Versioning باستخدام Lifecycle Policies

يعمل كل من Versioning وLifecycle Rules بأفضل شكل عندما يتم إعدادهما معًا، لكن التفاعل بينهما ليس دائمًا واضحًا. وأكثر نقطة تسبب الالتباس عادة تتعلق بـ Delete Markers، وأي خطأ في التعامل معها قد يؤدي بصمت إلى تقليل وفورات التكلفة التي تحققها Lifecycle Rules في أماكن أخرى.

ما الذي يحدث فعليًا عند حذف ملف داخل Bucket مفعّل عليه Versioning

عندما تقوم بحذف ملف داخل Bucket مفعّل عليه Versioning، فإن S3 لا يقوم بإزالته فعليًا. بل يقوم بإنشاء Delete Marker، وهو عنصر بحجم صفر بايت يجعل الملف يبدو وكأنه محذوف بالنسبة لطلبات القراءة العادية. أما الإصدارات السابقة لذلك الملف فتظل موجودة داخل التخزين خلف هذا الـ Marker، وتستمر AWS في احتساب تكلفتها بالكامل.

الحاويات التي تعمل مع Versioning لفترة تتجاوز عدة أشهر غالبًا ما تحتوي على بيانات مخزنة أكبر بكثير مما تبدو عليه فعليًا. تتراكم Delete Markers نتيجة عمليات الحذف الاعتيادية، بينما تتجمع الإصدارات القديمة أسفلها دون أي وضوح داخل تقارير الاستخدام التقليدية. وبدون Lifecycle Rules تستهدف هذه المشكلة تحديدًا، يستمر الفرق بين ما يبدو أن الـ Bucket يحتويه وما تدفع مقابله فعليًا في الاتساع مع مرور الوقت.

كيفية إزالة Delete Markers والإصدارات القديمة تلقائيًا

توفر Lifecycle Rules عدة خيارات للتحكم في التكاليف داخل الـ Buckets المفعّل عليها Versioning:

• قم بإعداد NoncurrentVersionExpiration مع قيمة NoncurrentDays لحذف الإصدارات القديمة بعد عدد محدد من الأيام من استبدالها بإصدار أحدث
• استخدم NoncurrentVersionTransition لنقل الإصدارات القديمة إلى Glacier قبل حذفها إذا كنت تريد نافذة استرجاع منخفضة التكلفة قبل الإزالة النهائية
• قم بتفعيل ExpiredObjectDeleteMarker لتنظيف Delete Markers تلقائيًا بمجرد حذف جميع الإصدارات المرتبطة بها
• استخدم NewerNoncurrentVersions للاحتفاظ بعدد محدد فقط من أحدث الإصدارات القديمة وحذف أي شيء أقدم، بحيث تحافظ على قدرة الاسترجاع دون تضخم تكاليف التخزين

أهم إعدادات Lifecycle للـ Buckets المفعّل عليها Versioning

Days After Noncurrent

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

Newer Versions to Retain

يحدد هذا الإعداد عدد أحدث الإصدارات القديمة التي يجب على S3 الاحتفاظ بها قبل تطبيق قواعد الحذف. تعيين القيمة إلى 3 يعني أنك ستحتفظ دائمًا بآخر ثلاث إصدارات سابقة للاسترجاع بينما يتم حذف أي إصدار أقدم وفق الجدول المحدد.

الـ Bucket المهيأ بشكل صحيح مع Versioning يمنحك قدرة كاملة على استرجاع التغييرات الحديثة مع منع الإصدارات التاريخية وDelete Markers المهجورة من التحول إلى تكلفة تخزين كبيرة ومتزايدة.

الخطوة 5: مراقبة وفورات التكلفة مع مرور الوقت

لا تحتاج Lifecycle Rules إلى إدارة مستمرة بعد إعدادها، لكنها تستفيد من المراقبة الدورية للتأكد من أنها تعمل بالشكل المتوقع واكتشاف الحالات غير المتوقعة التي لم تكن في الحسبان عند كتابة القواعد لأول مرة.

يوفر S3 Storage Lens عرضًا لتوزيع فئات التخزين عبر الحساب بالكامل. خلال 30 يومًا من تفعيل Lifecycle Rules، من المفترض أن يبدأ حجم طبقة Standard بالانخفاض بينما تزداد طبقة Standard-IA. وإذا لم ينخفض حجم Standard، فإن أكثر الأسباب شيوعًا تكون إما وجود Prefix Filter غير صحيح أو أن القاعدة مضبوطة على Disabled بدلًا من Enabled.

يعرض AWS Cost Explorer بعد تصفيته على S3 وتجميعه حسب فئات التخزين تكلفة كل طبقة شهريًا. مقارنة هذه البيانات شهرًا بعد شهر تمنحك صورة واضحة وقابلة للقياس عن تقدم وفورات التكلفة.

تكون مقاييس طلبات S3 داخل CloudWatch مفيدة عندما ترتفع تكاليف الاسترجاع بشكل غير متوقع. ارتفاع طلبات GetObject أو RestoreObject من Prefix معين يعني غالبًا أن جدول الانتقال الخاص بهذا النوع من البيانات عدواني أكثر من اللازم وأن الملفات يتم الوصول إليها بعد انتقالها بالفعل إلى طبقة تفرض رسوم استرجاع.

تُعد المراجعة الفصلية لـ Lifecycle Rules الحد الأدنى المناسب للصيانة داخل معظم بيئات المؤسسات. تتغير أنماط الوصول مع تطور التطبيقات، وقد تحتاج القواعد التي كانت دقيقة قبل ستة أشهر إلى تعديل مع إضافة أنواع بيانات وPrefixes جديدة داخل الـ Buckets.

قبل وبعد: ما الذي يتغير عند تفعيل Lifecycle Rules

قبل

• جميع الملفات تبقى داخل S3 Standard بغض النظر عن عمرها أو معدل الوصول إليها أو ما إذا كان سيتم قراءتها مرة أخرى أم لا
• تستمر فواتير التخزين بالارتفاع شهرًا بعد شهر دون وجود تفسير واضح لهذا الارتفاع
• تتراكم سجلات الامتثال، والسجلات القديمة، والنسخ الاحتياطية المنتهية دون أي عملية تنظيف تلقائية
• تتم قرارات الأرشفة يدويًا عندما يتذكر أحدهم تنفيذها، وهو ما يعني عمليًا أنها نادرًا ما تتم في الوقت المناسب
• لا توجد رؤية واضحة لأي Prefixes تستهلك أكبر مساحة تخزين أو أي بيانات لم يتم الوصول إليها منذ أشهر

بعد

• تنتقل البيانات تلقائيًا من Standard إلى Standard-IA ثم إلى Glacier مع تقدم عمرها، بينما تعمل العملية بالكامل دون أي تدخل يدوي
• تنخفض تكاليف التخزين الشهرية بشكل متوقع مع زيادة نسبة البيانات الموجودة داخل الطبقات منخفضة التكلفة بمرور الوقت
• يتم نقل سجلات الامتثال تلقائيًا إلى Glacier غير القابل للتعديل مع نوافذ احتفاظ محددة وقابلة للتدقيق
• يتم تنظيف الإصدارات القديمة Noncurrent Versions وDelete Markers المهجورة وMultipart Uploads غير المكتملة وفق جدول زمني قبل أن تتحول إلى تكاليف كبيرة
• توفر لوحات Storage Lens وCost Explorer لفريقك رؤية واضحة لتوزيع فئات التخزين واتجاهات التكلفة وما إذا كانت Lifecycle Rules تعمل كما هو مخطط لها

أفضل الممارسات المتقدمة لتحسين S3 على مستوى المؤسسات

تفعيل التشفير

يجب أن يكون التشفير هو الإعداد الافتراضي لكل S3 Bucket يحتوي على بيانات مؤسسات. منذ بداية عام 2023، أصبحت AWS تطبق تلقائيًا تشفير SSE-S3 على جميع الملفات الجديدة، لذلك تمتلك معظم أحمال العمل بالفعل مستوى أساسيًا من الحماية دون أي إعدادات إضافية.

لكن المؤسسات العاملة ضمن قطاعات منظمة تحتاج غالبًا إلى مستوى أعلى من ذلك. بيئات الرعاية الصحية والخدمات المالية والجهات الحكومية التي تعمل وفق أطر مثل HIPAA أو PCI-DSS أو SOC 2 تتطلب عادة مفاتيح تشفير مُدارة من العميل لأغراض تتبع التدقيق، والتحكم في تدوير المفاتيح، وقيود الوصول بين الحسابات. توفر AWS Key Management Service هذا المستوى من التحكم مع تكلفة بسيطة لكل طلب، وهي تكلفة تكون مبررة تقريبًا دائمًا بسبب متطلبات الامتثال.

تطبيق ضوابط وصول قوية

تستحق ضوابط الوصول الخاصة بـ S3 Buckets التي تحتوي على بيانات مُدارة عبر Lifecycle نفس مستوى الانضباط الذي تطبقه على أي مورد حساس داخل بيئة AWS الخاصة بك.

قم بتفعيل جميع إعدادات Block Public Access الأربعة على مستوى الـ Bucket بغض النظر عن إعدادات Bucket Policy. هذه الإعدادات تتجاوز أخطاء إعداد السياسات وتعمل كشبكة أمان دائمة. استبدل ACLs بسياسات Bucket وسياسات IAM المعتمدة على الأدوار إذا لم تكن قد قمت بذلك بالفعل. فـ ACLs أصعب في التدقيق على نطاق واسع وتخلق فرصًا أكبر للوصول غير المقصود.

بالنسبة للحاويات التي تحتوي على سجلات امتثال أو أرشيفات نسخ احتياطي، قم بتفعيل MFA Delete. يتطلب هذا مصادقة متعددة العوامل قبل تعديل أو إزالة أي إعدادات Versioning أو Lifecycle Rules، مما يحمي من التغييرات غير المقصودة أو الوصول غير المصرح به.

قم بتقييد صلاحية s3:PutLifecycleConfiguration على دور محدد ضمن فرق Cloud Engineering أو DevOps. تتحكم Lifecycle Rules في مدة الاحتفاظ بالبيانات ووقت حذفها نهائيًا، ولا يجب أن تكون هذه الصلاحية متاحة لجميع المطورين بشكل افتراضي.

ستخدام Intelligent-Tiering لأحمال العمل الديناميكية

بالنسبة للمؤسسات التي تدير بحيرات بيانات مشتركة أو مكتبات ضخمة من المحتوى الذي ينشئه المستخدمون أو أي مجموعات بيانات تختلف فيها معدلات الوصول بشكل كبير بين الملفات المختلفة، فإن Intelligent-Tiering يستحق دراسة جدية كفئة التخزين الافتراضية.
الميزة العملية هنا هي أنك لا تحتاج إلى تحليل سجلات الوصول أو ضبط جداول الانتقال يدويًا. يقوم S3 بمراقبة استخدام كل ملف على حدة وينقله تلقائيًا بناءً على ما يحدث فعليًا بدلًا من الاعتماد على توقعاتك المسبقة. المقابل لذلك هو رسوم مراقبة لكل ملف تبلغ حوالي 0.0025 دولار لكل 1000 ملف شهريًا، وتصبح هذه الرسوم مؤثرة فقط في الحاويات التي تحتوي على ملايين الملفات الصغيرة أقل من 128 كيلوبايت. أما بالنسبة للملفات الكبيرة ذات أنماط الوصول غير المتوقعة، فتظل رسوم المراقبة ضئيلة مقارنة بحجم التوفير.

مراجعة تقارير التخزين بشكل منتظم

لا تبقى Lifecycle Rules محسّنة من تلقاء نفسها. تنمو التطبيقات، وتتغير أنواع البيانات، ويتم إضافة Prefixes جديدة إلى الـ Buckets لم تكن القواعد الأصلية مصممة للتعامل معها.

تُعتبر المراجعة الفصلية هي الوتيرة المناسبة لمعظم بيئات المؤسسات. وفي كل مراجعة، تحقق مما إذا كان أي Prefix قد نما بشكل غير متوقع، أو إذا كانت طلبات استرجاع Glacier ترتفع لنوع بيانات معين مما قد يشير إلى أن جدول الانتقال عدواني أكثر من اللازم، أو إذا كانت هناك Prefixes جديدة لا تغطيها Lifecycle Rules، أو إذا تغيرت متطلبات الاحتفاظ الخاصة بالامتثال منذ آخر تحديث للقواعد.

يوفر S3 Storage Lens لوحة تحكم على مستوى المؤسسة تسمح لك بمراجعة توزيع فئات التخزين وأنماط الوصول واتجاهات التكلفة عبر جميع الـ Buckets في حسابك من مكان واحد. وهذا يجعل المراجعات الفصلية أسرع وأكثر فاعلية مقارنة بمراجعة كل Bucket بشكل منفصل.

أهم النقاط

تُعتبر S3 Lifecycle Policies من أعلى عمليات التحسين عائدًا داخل AWS، ليس لأنها معقدة تقنيًا، بل لأن معظم المؤسسات ببساطة لم تقم بتطبيقها بعد. البيانات موجودة بالفعل. والتكاليف تتراكم بالفعل. وما ينقص فقط هو الأتمتة التي تدير البيانات خلال دورة حياتها الطبيعية.

أهم الوفورات تأتي باستمرار من المناطق التي تتجاهلها الفرق عادة. تتراكم الإصدارات القديمة Noncurrent Versions بصمت داخل الـ Buckets المفعّل عليها Versioning. تتكدس Multipart Uploads غير المكتملة الناتجة عن العمليات الفاشلة دون أي مؤشر واضح. وتتراكم Delete Markers المنتهية بعد عمليات الحذف الجماعية وتزيد من حجم التخزين بطرق لا تظهر بوضوح داخل التقارير التقليدية. ولا يتم التعامل مع أي من هذه المشكلات دون Lifecycle Rules مخصصة لها بشكل صريح.

ابدأ بـ Bucket واحد. اكتب جداول الانتقال بناءً على بيانات وصول فعلية من Storage Lens بدلًا من الافتراضات. أضف قواعد انتهاء صلاحية للبيانات المؤقتة وللإصدارات القديمة. ثم قم بقياس النتائج بعد 30 يومًا. ما ستجده سيمنحك على الأرجح النموذج الذي تحتاجه لتطبيق نفس النهج على جميع الـ Buckets داخل حسابك.

تحسين تكاليف S3 على نطاق واسع ليس مشروعًا له تاريخ انتهاء. بل هو ممارسة مستمرة تتضاعف قيمتها مع نمو حجم بياناتك. المؤسسات التي تبني Lifecycle Governance داخل بنية التخزين منذ البداية تنتهي بتكاليف تخزين تنمو بشكل متناسب مع الاستخدام الفعلي بدلًا من النمو بشكل متسارع لأن لا أحد كان يدير البيانات.

ابدأ بخفض تكاليف تخزين AWS هذا الأسبوع

إذا كانت فاتورة S3 الخاصة بك ترتفع دون تفسير واضح، فأنت الآن تمتلك كل ما تحتاجه لتحديد السبب وحل المشكلة. Lifecycle Rules وأوامر CLI وملفات JSON الموجودة في هذا الدليل جاهزة للاستخدام الإنتاجي. اختر Bucket واحدًا، وطبق القاعدة، ثم راقب لوحة Storage Lens بعد 30 يومًا لمعرفة التأثير.

إذا كنت تفضل إجراء مراجعة شاملة لبيئة التخزين الحالية قبل تنفيذ أي تغييرات، فإن AWS Well-Architected Review الخاصة بنا هي نقطة البداية المناسبة. نقوم بتقييم توزيع فئات التخزين، والفجوات في Lifecycle، وإعدادات Versioning، وأنماط الوصول عبر الحساب بالكامل، ثم نقدم خطة عمل مرتبة حسب الأولوية مع تقدير وفورات التكلفة لكل توصية.

المؤسسات التي نعمل معها تحقق عادة انخفاضًا في تكاليف التخزين يتراوح بين 30 و45 بالمئة خلال 90 يومًا من تطبيق Lifecycle Governance. هذه الوفورات لا تتطلب إعادة تصميم للبنية بالكامل، بل تتطلب تطبيق القواعد الصحيحة على البيانات الصحيحة.
في SUDO، نساعد المؤسسات على بناء بيئات AWS فعالة من حيث التكلفة وآمنة وقابلة للتوسع من خلال خدمات Cloud Consulting Services وAWS Well-Architected Reviews وCloud Migration Solutions.

إذا كنت ترغب في تقليل إنفاق S3، أو تحسين سياسات الاحتفاظ بالبيانات، أو رفع بنية التخزين لديك إلى معايير المؤسسات، تواصل مع فريق AWS لدينا وسنوضح لك بالضبط أين توجد فرص التحسين داخل بيئتك.

Maryam Mairaj

Marketing Tech at SUDO Consultants, focused on brand communication and digital campaigns that highlight cloud and AI capabilities in the MENA region.