object storage class और lifecycle rule आप कैसे तय करते हैं?

class को access pattern और यह कि retrieval में कितनी देर बर्दाश्त है, उसके हिसाब से मिलाएं। बार बार पढ़े जाने वाला डेटा standard में रहे; जिन पैटर्न का अंदाजा न हो उनके लिए intelligent tiering ठीक है, जो एक छोटी monitoring फीस पर object खुद खिसकाती है। infrequent access वाली class में रखना सस्ता है पर retrieval पर चार्ज लगता है और न्यूनतम अवधि होती है, और archive class सबसे सस्ती हैं पर retrieval में देरी होती है। transition और expiry के लिए lifecycle rule इस्तेमाल करें, पुराने version समेत, और पहले object की गिनती देख लें।

मैं देखता हूं कि डेटा कितनी बार पढ़ा जाता है और पढ़ने वाला कितना इंतजार कर सकता है। गर्म डेटा standard में रहता है। अगर कोई मुझे access pattern बता ही नहीं सकता, तो intelligent tiering ईमानदार जवाब है, क्योंकि वह object खुद खिसकाती है और गलत अंदाजा लगाने के मुकाबले monitoring फीस छोटी है। जो डेटा मुझे पता है कि कम ही पढ़ा जाता है वह infrequent access class में जाता है, पर तभी जब वह न्यूनतम अवधि से आगे जिएगा, वरना जल्दी delete करने का चार्ज बचत खा जाता है। archive class compliance वाले retention के लिए हैं जहां मिनटों या घंटों की retrieval देरी चल जाती है। कोई भी lifecycle rule लिखने से पहले मैं जिस जाल की जांच करता हूं वह object की गिनती है, क्योंकि transition प्रति object चार्ज होते हैं, तो बीस करोड़ छोटी log फाइलों वाले bucket को खिसकाना बचत से ज्यादा महंगा पड़ सकता है; उन्हें इसके बजाय जोड़कर बड़ा करना चाहिए। और सबसे बड़ी जीत आमतौर पर class होती ही नहीं। किसी versioned bucket में non current version की expiry चालू करना, और एक हफ्ते बाद अधूरे multipart upload रद्द करना, इन दोनों ने मेरे लिए एक भी जिंदा object को छुए बिना bucket का बिल आधा किया है।