Bir medya şirketi, günlük video dosyalarını Azure Blob Storage'a alır. Videolar 7 gün boyunca yoğun bir şekilde okunur, sonraki 3 ay boyunca ara sıra okunur ve ardından en düşük maliyetle 5 yıl boyunca saklanması gerekir. Yalnızca 'critical' kapsayıcısının ikincil bir bölgeye çoğaltılması gerekir. İkincil kopyanın birincilden daha uzun bir saklama politikası olacaktır. Ne tasarlamalısınız?

Doğru cevap, Blob nesne çoğaltmasını ve yaşam döngüsü yönetimini birleştirerek gereksinimleri karşılar. "Critical" kapsayıcısının ikincil bir bölgeye çoğaltılması için Blob nesne çoğaltması en uygun çözümdür ve ikincil kopyanın farklı bir saklama politikasına sahip olmasına olanak tanır. Her iki depolama hesabında da yaşam döngüsü yönetim kuralları tanımlamak, verilerin zamanla Hot, Cool, Cold ve Archive katmanları arasında otomatik olarak geçişini sağlayarak maliyetleri optimize eder ve belirtilen erişim desenlerine (7 gün yoğun, 3 ay ara sıra, 5 yıl arşiv) uyum sağlar. GZRS tüm depolama hesabını çoğaltır ve ikincil bölge için farklı bir saklama politikasına izin vermez. Doğrudan Archive katmanında depolamak, ilk 7 gün boyunca yoğun okuma gereksinimini karşılamaz ve hidrasyon maliyeti/gecikmesi yaratır. Azure Data Factory ile kopyalama, karmaşık ve manuel bir çözüm olup, yerleşik çoğaltma ve yaşam döngüsü yönetiminin otomasyonunu sağlamaz. Azure Files, blok bloblar için değil, dosya paylaşımları için tasarlanmıştır.