All Products
Search
Document Center

Object Storage Service:Ikhtisar siklus hidup

Last Updated:Apr 01, 2026

Frekuensi akses terhadap data yang disimpan di OSS umumnya menurun seiring waktu. Menyimpan data dingin dalam kelas penyimpanan Standard yang berbiaya tinggi tidak ekonomis, sementara pembersihan manual sejumlah besar file log atau backup juga tidak efisien. Manajemen siklus hidup memungkinkan Anda membuat aturan otomatis untuk memindahkan objek ke kelas penyimpanan berbiaya lebih rendah—seperti Infrequent Access atau Archive—setelah periode tertentu (misalnya, 30 hari), atau bahkan menghapus objek tersebut. Hal ini membantu Anda mengelola seluruh siklus hidup data secara cerdas dan hemat biaya.

Cara kerja

Manajemen siklus hidup menggunakan aturan yang ditentukan pengguna untuk melakukan operasi otomatis pada objek dalam bucket. OSS memuat aturan siklus hidup dalam waktu 24 jam setelah aturan tersebut dibuat. Setelah dimuat, OSS memindai dan mengeksekusi aturan yang sesuai pada waktu tetap setiap hari, biasanya setelah pukul 00:00 UTC (atau pukul 08:00 UTC+8).

Sebuah aturan siklus hidup terdiri dari tiga bagian utama:

  1. Objek yang dikelola: Tentukan objek mana yang dikenai aturan tersebut. Anda dapat menyaring objek target berdasarkan awalan objek (Prefix), tag objek (Tag), atau ukuran objek (ObjectSize).

    Aturan siklus hidup tidak mendukung karakter wildcard, pencocokan akhiran, atau ekspresi reguler.
  2. Aksi yang dilakukan: Tentukan tindakan yang akan dilakukan terhadap objek yang telah difilter. Aksi utama meliputi hal-hal berikut:

    • Transisi kelas penyimpanan (Transition): Memindahkan objek ke kelas penyimpanan berbiaya lebih rendah seperti Infrequent Access, Archive, atau Cold Archive.

    • Kedaluwarsa dan penghapusan (Expiration): Menghapus objek setelah mencapai periode siklus hidup tertentu.

    • Pembersihan fragmen (AbortMultipartUpload): Secara otomatis menghapus bagian-bagian dari unggah multi-bagian yang tidak lengkap setelah jangka waktu tertentu.

  3. Kebijakan pemicu: Tentukan kondisi yang memicu aksi terhadap objek yang telah difilter:

    • Waktu modifikasi terakhir (Last-Modified-Time): Memindahkan atau menghapus objek berdasarkan waktu modifikasi terakhirnya. Ini cocok untuk data dengan siklus hidup yang jelas, seperti log dan backup. Anda dapat secara otomatis memindahkan kelas penyimpanan atau menghapus objek untuk menghemat biaya.

    • Waktu akses terakhir (Last-Access-Time): Setelah Anda mengaktifkan fitur access tracking, Anda dapat secara cerdas mengganti kelas penyimpanan berdasarkan waktu akses terakhir suatu objek. Ini berguna untuk skenario dengan pola akses yang tidak dapat diprediksi, seperti perpustakaan materi. Kelas penyimpanan dapat diturunkan ketika data menjadi dingin dan secara otomatis dipulihkan saat data tersebut diakses.

Untuk informasi lebih lanjut tentang cara mengonfigurasi kebijakan siklus hidup, lihat Elemen konfigurasi siklus hidup.

Jika sebuah bucket memiliki ObjectWorm yang diaktifkan, operasi transisi kelas penyimpanan (Transition) dalam aturan siklus hidup tidak terpengaruh, tetapi objek yang masih dalam periode retensi tidak akan dihapus secara otomatis (Expiration) oleh aturan siklus hidup.

Skenario konfigurasi

Membersihkan file log yang kedaluwarsa secara otomatis

Server menghasilkan banyak log setiap hari dan mengunggahnya ke direktori tertentu. Anda dapat mengonfigurasi aturan siklus hidup berdasarkan waktu modifikasi terakhir untuk menghapus semua objek dalam bucket setelah jumlah hari tertentu. Hal ini melepaskan ruang penyimpanan dan mengurangi biaya penyimpanan.

Menggunakan tiering penyimpanan otomatis untuk data panas dan dingin

Untuk data dengan frekuensi akses yang tidak pasti, seperti gambar website, video online, dan dokumen, Anda dapat mengaktifkan fitur access tracking. Kemudian, Anda dapat menggunakan aturan siklus hidup berdasarkan waktu akses terakhir untuk menerapkan tiering data cerdas. Sistem secara otomatis memindahkan data dingin ke kelas penyimpanan Infrequent Access, Archive, atau Cold Archive berdasarkan pola akses aktual. Hal ini mencapai tiering cerdas dan optimalisasi biaya.

Membersihkan versi sebelumnya secara otomatis

Setelah Anda mengaktifkan versioning, operasi overwrite dan penghapusan pada data disimpan sebagai versi sebelumnya. Ketika sebuah bucket mengumpulkan banyak versi sebelumnya atau penanda hapus yang kedaluwarsa, Anda dapat menggunakan aturan siklus hidup berdasarkan waktu modifikasi terakhir bersamaan dengan versioning untuk mengurangi biaya penyimpanan. Objek dihapus secara otomatis setelah jangka waktu tertentu. Hal ini mengurangi biaya penyimpanan dan meningkatkan performa daftar objek.

Membersihkan fragmen dari unggah multi-bagian secara otomatis

Jika unggah multi-bagian file besar terputus, sistem menyimpan bagian-bagian yang belum digabung, yang tetap dikenai biaya. Anda dapat mengonfigurasi aturan siklus hidup untuk secara otomatis membersihkan bagian yang tidak lengkap setelah jangka waktu tertentu guna menghindari penggunaan resource yang tidak perlu.

Selain skenario di atas, Anda dapat menerapkan kebijakan manajemen data yang lebih detail halus. Untuk informasi lebih lanjut, lihat Contoh konfigurasi siklus hidup. Anda dapat menggabungkan berbagai aturan untuk mencapai manajemen data detail halus dalam bucket sesuai kebutuhan.

Beberapa aturan siklus hidup

Untuk memastikan beberapa aturan siklus hidup berjalan sesuai harapan, Anda perlu memahami dua mekanisme inti: Prioritas eksekusi aturan dan mekanisme timpa konfigurasi.

Prioritas eksekusi aturan

Anda dapat mengonfigurasi beberapa aturan siklus hidup untuk bucket yang sama. Aturan-aturan tersebut bersifat independen, sehingga objek yang sama mungkin sesuai dengan beberapa aturan. Aksi akhir ditentukan berdasarkan hasil semua aturan yang sesuai.

Ketika beberapa aturan sesuai dengan objek yang sama pada waktu yang sama, aturan tersebut dieksekusi sesuai urutan prioritas berikut: Hapus Objek > Transisi ke Deep Cold Archive > Transisi ke Cold Archive > Transisi ke Archive > Transisi ke Infrequent Access > Transisi ke Standard.

Penting

Aksi hapus selalu memiliki prioritas lebih tinggi daripada transisi kelas penyimpanan. Atur waktu aturan hapus agar lebih lama daripada waktu aturan transisi. Hal ini mencegah objek dihapus sebelum transisi selesai.

Contoh eksekusi

Asumsikan Anda menentukan dua aturan siklus hidup berikut, dan kedua aturan tersebut sesuai dengan objek yang sama.

  • Aturan 1: Menentukan bahwa objek yang terakhir dimodifikasi lebih dari 365 hari lalu dipindahkan ke kelas penyimpanan Infrequent Access.

  • Aturan 2: Menentukan bahwa objek yang terakhir dimodifikasi lebih dari 365 hari lalu dihapus.

Hasil: Objek yang sesuai dengan aturan tersebut akan dihapus lebih dari 365 hari setelah waktu modifikasi terakhirnya.

Mekanisme timpa konfigurasi

Saat menggunakan Konsol, Anda tidak perlu khawatir tentang penimpaan konfigurasi. Setiap kali Anda menambahkan atau mengubah aturan, Konsol secara otomatis membaca konfigurasi saat ini, menggabungkan perubahan, lalu mengirimkan hasilnya. Hal ini mencegah hilangnya aturan yang sudah ada secara tidak sengaja. Namun, berhati-hatilah saat mengonfigurasi aturan siklus hidup menggunakan ossutil, SDK, atau dengan langsung memanggil API. Setiap panggilan PutBucketLifecycle sepenuhnya menimpa semua konfigurasi siklus hidup yang ada untuk bucket tersebut. Jika Anda mengirimkan aturan baru tanpa menyertakan aturan yang sudah ada, aturan yang sudah ada akan dihapus dan tidak lagi berlaku.

Contoh

Jika Anda ingin menambahkan aturan baru ke aturan yang sudah ada, lakukan langkah-langkah berikut:

  1. Ambil semua aturan siklus hidup yang sedang berlaku (misalnya, Aturan 1).

  2. Tambahkan aturan baru (misalnya, Aturan 2).

  3. Kirim ulang konfigurasi lengkap yang mencakup semua aturan (Aturan 1 + Aturan 2).

Catatan: Jika Anda hanya mengirimkan konfigurasi yang berisi aturan baru (Aturan 2) tanpa menyertakan aturan yang sudah ada (Aturan 1), Aturan 1 akan dihapus dan tidak lagi berlaku.

Penerapan di lingkungan produksi

Untuk menggunakan manajemen siklus hidup secara aman dan efisien di lingkungan produksi, kami merekomendasikan hal-hal berikut:

  • Uji sebelum menerapkan: Buat aturan terlebih dahulu di bucket uji. Verifikasi bahwa perilakunya sesuai harapan sebelum menerapkannya ke bucket produksi.

  • Gunakan aturan hapus dengan hati-hati: Untuk aturan yang dikonfigurasi dengan kedaluwarsa dan penghapusan, atur awalan secara tepat. Hal ini mencegah cakupan aturan meluas dan secara tidak sengaja menghapus data penting.

  • Aktifkan versioning sebagai perlindungan: Untuk data bisnis kritis, aktifkan fitur versioning untuk bucket tersebut. Dengan demikian, meskipun versi saat ini dari objek secara tidak sengaja dihapus oleh aturan siklus hidup, Anda tetap dapat memulihkan data dari versi sebelumnya.

  • Gunakan transisi bertingkat untuk menghindari biaya tambahan: Saat merancang kebijakan transisi kelas penyimpanan, pastikan waktu pemicu tahap berikutnya berada setelah jumlah waktu pemicu tahap sebelumnya dan durasi penyimpanan minimum kelas penyimpanan tersebut. Hal ini menghindari biaya akibat transisi prematur.

    • Contoh salah: Standard 30 hari -> Infrequent Access 40 hari -> Archive Storage. Konfigurasi ini menyebabkan objek hanya disimpan dalam kelas penyimpanan IA selama 10 hari (< 30 hari) sebelum ditransisikan lagi. Hal ini menimbulkan biaya.

    • Contoh benar: Standard 30 hari -> Infrequent Access 90 hari -> Archive Storage. (Objek ditransisikan ke kelas penyimpanan IA setelah 30 hari. Objek tetap berada di kelas penyimpanan IA selama 60 hari sebelum ditransisikan ke Archive Storage, total 90 hari).

Penagihan

Mengonfigurasi aturan siklus hidup tidak dikenai biaya. Biaya dikenakan saat aturan dieksekusi dan saat status penyimpanan berubah sebagai akibatnya.

  1. Biaya permintaan: Saat aturan siklus hidup melakukan transisi kelas penyimpanan, menghapus objek, atau menghapus bagian, sistem memulai permintaan jenis Put. Biaya permintaan dikenakan berdasarkan jumlah permintaan. Untuk informasi lebih lanjut tentang aturan penagihan, lihat Deskripsi biaya siklus hidup.

    Untuk bucket yang berisi banyak file kecil, biaya ini bisa signifikan. Evaluasi hal ini sebelum mengonfigurasi aturan.
  2. Biaya penyimpanan: Setelah objek ditransisikan ke kelas penyimpanan baru, objek tersebut ditagih berdasarkan harga satuan kelas baru tersebut.

    Penting

    Kelas penyimpanan seperti Infrequent Access, Archive, dan Cold Archive memiliki persyaratan durasi penyimpanan minimum (misalnya, 30 hari untuk Infrequent Access dan 60 hari untuk Archive). Jika aturan siklus hidup menghapus atau mentransisikan objek sebelum durasi penyimpanan minimum terpenuhi, Anda harus membayar durasi penyimpanan yang tersisa. Untuk menghindari biaya kapasitas kondisional untuk penyimpanan lebih pendek dari durasi yang ditentukan akibat transisi atau penghapusan, lihat Bagaimana cara menghindari biaya kapasitas untuk penyimpanan lebih pendek dari durasi yang ditentukan?. Pastikan durasi penyimpanan minimum terpenuhi sebelum mentransisikan atau menghapus.

  3. Biaya pengambilan data: Aturan siklus hidup itu sendiri tidak menimbulkan biaya pengambilan data. Namun, saat Anda mengakses objek yang telah ditransisikan ke kelas penyimpanan seperti Infrequent Access atau Archive, biaya pengambilan data yang sesuai akan dikenakan.

    • Membaca objek Infrequent Access (IA) secara langsung menimbulkan biaya pengambilan data.

    • Membaca objek Archive secara langsung menimbulkan biaya kapasitas pengambilan data untuk akses real-time.

    • Memulihkan objek Archive menimbulkan biaya permintaan jenis Put dan biaya kapasitas pengambilan data.

    • Memulihkan objek Cold Archive atau Deep Cold Archive menimbulkan biaya permintaan pengambilan, biaya kapasitas pengambilan, dan biaya kapasitas pemulihan sementara.

    Penting

    Untuk objek Cold Archive dan Deep Cold Archive, biayanya bervariasi tergantung pada prioritas pengambilan yang Anda pilih. Prioritas yang lebih tinggi menghasilkan biaya yang lebih tinggi.

FAQ

Apa perbedaan antara aturan siklus hidup berdasarkan waktu modifikasi terakhir dan waktu akses terakhir?

Perbedaan antara kebijakan berdasarkan waktu modifikasi terakhir dan waktu akses terakhir adalah sebagai berikut:

Kebijakan

Berdasarkan waktu modifikasi terakhir

Berdasarkan waktu akses terakhir

Scenarios

Cocok untuk skenario data dengan pola akses tetap atau dapat diprediksi.

Cocok untuk skenario data dengan pola akses tidak tetap atau tidak dapat diprediksi.

Supports Object Deletion

Didukung.

No.

Object Recovery After Deletion

  • Jika versioning tidak diaktifkan, objek yang dihapus tidak dapat dipulihkan.

  • Jika versioning diaktifkan, saat aturan siklus hidup menghapus objek versi saat ini, objek tersebut menjadi versi sebelumnya dan dapat dipulihkan. Namun, saat aturan siklus hidup menghapus objek versi sebelumnya, objek tersebut tidak dapat dipulihkan.

Kebijakan berdasarkan waktu akses terakhir tidak melibatkan pemulihan objek setelah penghapusan.

Reversibility Of Storage Class Transition

Tidak dapat dibalik. Misalnya, setelah objek ditransisikan dari kelas penyimpanan Standard ke kelas penyimpanan Infrequent Access, objek tersebut tidak dapat secara otomatis ditransisikan kembali ke kelas penyimpanan Standard. Untuk informasi lebih lanjut, lihat Transisi kelas penyimpanan.

Saat objek ditransisikan ke kelas penyimpanan Infrequent Access, Archive, Cold Archive, atau Deep Cold Archive, isu-isu seperti ukuran tagihan minimum, durasi penyimpanan minimum, dan biaya pengambilan data ikut terlibat. Untuk informasi lebih lanjut, lihat Transisi kelas penyimpanan.

Dapat dibalik. Saat objek secara otomatis ditransisikan dari kelas penyimpanan Standard ke kelas penyimpanan Infrequent Access, Anda juga dapat memilih agar objek tersebut kembali ke kelas penyimpanan Standard saat diakses.

Penting

Objek dianggap "diakses" hanya jika diakses melalui panggilan API GetObject. Panggilan API lainnya tidak termasuk.

Skenario ini juga melibatkan isu-isu seperti ukuran tagihan minimum, durasi penyimpanan minimum, dan biaya pengambilan data. Untuk informasi lebih lanjut, lihat Aturan siklus hidup berdasarkan waktu akses terakhir.

Mengapa aturan siklus hidup saya tidak berfungsi?

Periksa hal-hal berikut:

  1. Waktu berlaku: Apakah aturan telah dibuat lebih dari 24 jam? Aturan baru memerlukan waktu untuk dimuat.

  2. Pencocokan awalan: Apakah awalan dalam aturan diatur dengan benar? Misalnya, folder harus berupa logs/ dan bukan logs.

  3. Kondisi waktu: Apakah waktu modifikasi terakhir atau waktu akses terakhir objek benar-benar memenuhi jumlah hari yang ditentukan?

  4. Fitur prasyarat: Jika Anda menggunakan aturan berdasarkan waktu akses terakhir, apakah Anda telah mengaktifkan fitur access tracking untuk bucket tersebut?

Setelah mengaktifkan versioning, saya menghapus objek. Mengapa penggunaan penyimpanan saya tidak berkurang?

Karena versioning diaktifkan, operasi penghapusan hanya membuat penanda hapus. Objek asli menjadi versi sebelumnya dan tetap menempati ruang penyimpanan. Anda harus membuat aturan siklus hidup tambahan untuk membersihkan versi sebelumnya.

Apakah objek yang telah ditransisikan akan dipulihkan jika saya menghapus aturan siklus hidup?

Tidak, tidak akan. Menghapus aturan tidak memengaruhi hasil aksi yang telah dieksekusi. Anda harus secara manual memulihkan objek yang telah ditransisikan ke kelas penyimpanan aslinya.

Mengapa objek yang dihapus masih menempati ruang setelah versioning diaktifkan?

Setelah versioning diaktifkan, operasi penghapusan membuat penanda hapus. Objek asli menjadi versi sebelumnya dan tetap menempati ruang. Anda perlu mengonfigurasi aturan untuk menghapus versi sebelumnya.

Apa yang harus saya lakukan jika menerima error Set bucket lifecycle error, InvalidArgument, Days in the Transition action for StorageClass Archive must be more than the Transition action for StorageClass IA?

Error ini terjadi karena waktu transisi untuk kelas penyimpanan berbeda tidak memenuhi persyaratan. Periode transisi yang dikonfigurasi untuk bucket harus memenuhi: Infrequent Access < Archive < Cold Archive < Deep Cold Archive.

Apakah fitur siklus hidup OSS dapat melakukan tiering data atau aksi penghapusan dengan mencocokkan akhiran file?

Apakah aturan siklus hidup berlaku untuk objek yang sudah ada di bucket?

Aturan siklus hidup berlaku untuk semua objek, termasuk yang disimpan sebelum aturan dikonfigurasi maupun yang diunggah setelahnya. Misalnya, jika aturan dikonfigurasi pada 7 Oktober untuk menghapus objek setelah 30 hari, objek yang diunggah pada 5 Oktober dihapus pada 6 November, dan objek yang diunggah pada 8 Oktober dihapus pada 9 November.

Bagaimana cara mengubah satu atau beberapa konfigurasi aturan siklus hidup?

Asumsikan bucket Anda dikonfigurasi dengan dua aturan siklus hidup, Aturan1 dan Aturan2, dan Anda ingin mengubah item konfigurasi dalam Aturan1. Lakukan operasi berikut.

  1. Panggil API GetBucketLifecycle untuk mengambil semua aturan siklus hidup yang saat ini dikonfigurasi untuk bucket tersebut, yaitu Aturan1 dan Aturan2.

  2. Ubah item konfigurasi aturan siklus hidup Aturan1.

  3. Panggil API PutBucketLifecycle untuk memperbarui aturan siklus hidup menjadi Aturan1+Aturan2.

Apakah ada catatan log untuk transisi jenis dan penghapusan kedaluwarsa yang dilakukan oleh aturan siklus hidup?

Ya. Semua transisi jenis dan penghapusan kedaluwarsa yang berhasil dilakukan oleh aturan siklus hidup dicatat. Field log-nya adalah sebagai berikut:

  • Operasi

    • CommitTransition: Melakukan transisi kelas penyimpanan.

    • ExpireObject: Menghapus objek yang kedaluwarsa.

  • Permintaan Sinkron

    lifecycle: Operasi transisi dan penghapusan yang dipicu.

Untuk informasi lebih lanjut tentang field log OSS, lihat Detail field log. Untuk informasi tentang penagihan kueri log, lihat Penagihan.

Dapatkah saya membuat satu aturan siklus hidup untuk membersihkan penanda hapus objek dan objek versi saat ini secara bersamaan?

Tidak, tidak bisa. Anda harus membuat satu aturan untuk membersihkan penanda hapus objek dan aturan lain untuk menghapus objek versi saat ini.

Bagaimana cara membersihkan semua file dalam bucket secara cepat menggunakan aturan siklus hidup

Bucket dengan versioning dinonaktifkan

Untuk bucket dengan versioning dinonaktifkan, Anda hanya perlu mengonfigurasi satu aturan siklus hidup untuk secara otomatis dan cepat membersihkan semua file dan bagian dari unggah multi-bagian yang tidak lengkap.

  1. Masuk ke Konsol OSS, buka halaman Daftar Bucket, lalu temukan bucket target.

  2. Di panel navigasi kiri, pilih Data Security > Versioning, dan pastikan versioning dinonaktifkan untuk bucket tersebut.

    未开启版本控制

  3. Di panel navigasi kiri, pilih Data Management > Lifecycle. Atur aturan siklus hidup untuk secara otomatis menghapus semua file dalam bucket 1 hari setelah modifikasi terakhirnya. Juga, secara otomatis membersihkan bagian dari unggah multi-bagian yang tidak lengkap yang dibuat lebih dari 1 hari lalu.

    screenshot_2025-07-01_17-59-32

Bucket dengan versioning diaktifkan

Setelah versioning diaktifkan untuk bucket, bucket tersebut menghasilkan objek versi saat ini, objek versi sebelumnya, bagian dari unggah multi-bagian yang tidak lengkap, dan penanda hapus. Anda hanya perlu mengonfigurasi satu aturan siklus hidup untuk secara otomatis dan cepat membersihkan semua elemen tersebut.

  1. Masuk ke Konsol OSS, buka halaman Daftar Bucket, lalu temukan bucket target.

  2. Di panel navigasi kiri, pilih Data Security > Versioning, dan pastikan versioning diaktifkan untuk bucket tersebut.

    screenshot_2025-07-02_10-58-23

  3. Di panel navigasi kiri, pilih Data Management > Lifecycle. Atur aturan siklus hidup untuk secara otomatis menghapus semua objek versi saat ini dan versi sebelumnya dalam bucket 1 hari setelah modifikasi terakhirnya. Juga, secara otomatis membersihkan bagian dari unggah multi-bagian yang tidak lengkap yang dibuat lebih dari 1 hari lalu. Aturan ini juga membersihkan penanda hapus.

    screenshot_2025-07-02_10-58-23

Jika saya membuat dua aturan siklus hidup untuk objek dengan awalan yang sama, satu berdasarkan waktu modifikasi terakhir dan yang lain berdasarkan waktu akses terakhir, aturan mana yang diterapkan?

Misalnya, Anda membuat dua aturan siklus hidup untuk bucket target examplebucket. Aturan 1 menentukan bahwa semua objek dengan awalan doc dalam bucket dihapus 30 hari setelah waktu modifikasi terakhirnya. Aturan 2 menentukan bahwa semua objek dengan awalan doc dalam bucket ditransisikan ke kelas penyimpanan Infrequent Access 30 hari setelah waktu akses terakhirnya.

OSS mengeksekusi aturan siklus hidup berdasarkan prinsip meminimalkan biaya pengguna. Oleh karena itu, hanya Aturan 1 yang berlaku. Hal ini karena Aturan 1 menghapus objek setelah 30 hari, yang menghentikan semua biaya yang timbul. Sebaliknya, Aturan 2, yang mentransisikan objek ke kelas penyimpanan Infrequent Access, masih akan menimbulkan biaya penyimpanan atau pengambilan data terkait.

Kapan perubahan pada aturan siklus hidup yang telah dikonfigurasi mulai berlaku, dan bagaimana data yang sesuai dengan aturan asli ditangani?

Misalnya, Anda mengonfigurasi aturan siklus hidup untuk objek dengan awalan er. Aturan ini mentransisikan objek ke kelas penyimpanan Infrequent Access 30 hari setelah waktu akses terakhirnya, lalu mentransisikannya kembali ke kelas penyimpanan Standard jika objek tersebut diakses lagi setelah tambahan 30 hari. Namun, 35 hari setelah waktu akses terakhir objek, Anda mengubah awalan dalam aturan siklus hidup dari er menjadi re. Akibatnya, objek ditransisikan ke kelas penyimpanan Infrequent Access, tetapi aksi untuk mentransisikannya kembali ke kelas penyimpanan Standard tidak berlaku. Untuk objek yang sesuai dengan aturan yang diperbarui, waktu akses terakhirnya dihitung sejak fitur access tracking diaktifkan untuk bucket tersebut.

Dalam bucket dengan versioning diaktifkan, bagaimana tiering cerdas memengaruhi kelas penyimpanan versi objek yang berbeda?

Dalam bucket dengan versioning diaktifkan, setiap versi objek memiliki ID versi unik dan diperlakukan sebagai objek independen. Oleh karena itu, versi sebelumnya dari suatu objek mungkin berada dalam kelas penyimpanan Infrequent Access, sedangkan versi saat ini dari objek yang sama berada dalam kelas penyimpanan Standard.