Contoh konfigurasi Siklus Hidup S3 - Amazon Simple Storage Service

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Contoh konfigurasi Siklus Hidup S3

Bagian ini memberikan contoh konfigurasi Siklus Hidup S3. Setiap contoh menunjukkan bagaimana Anda dapat menentukan XML dalam setiap skenario contoh.

Contoh 1: Menentukan filter

Setiap aturan Siklus Hidup S3 mencakup filter yang dapat Anda gunakan untuk mengidentifikasi bagian objek dalam bucket Anda yang berlaku aturan Siklus Hidup S3. Konfigurasi Siklus Hidup S3 berikut menunjukkan contoh cara menentukan filter.

  • Dalam aturan konfigurasi Siklus Hidup S3 ini, filter menentukan awalan kunci (tax/). Oleh karena itu, aturan berlaku untuk objek dengan awalan nama kunci tax/, seperti tax/doc1.txt dan tax/doc2.txt.

    Aturan tersebut menetapkan dua tindakan yang mengarahkan Amazon S3 untuk melakukan hal berikut:

    • Transisi objek ke kelas penyimpanan S3 Glacier Flexible Retrieval 365 hari (satu tahun) setelah pembuatan.

    • Menghapus objek (tindakan Expiration) 3.650 hari (10 tahun) setelah pembuatan.

    <LifecycleConfiguration> <Rule> <ID>Transition and Expiration Rule</ID> <Filter> <Prefix>tax/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> <Expiration> <Days>3650</Days> </Expiration> </Rule> </LifecycleConfiguration>

    Alih-alih menentukan usia objek dalam hal hari setelah pembuatan, Anda dapat menentukan tanggal untuk setiap tindakan. Namun, Anda tidak dapat menggunakan Date dan Days dalam aturan yang sama.

  • Jika Anda ingin aturan Siklus Hidup S3 berlaku pada semua objek dalam bucket, tentukan awalan kosong. Dalam konfigurasi berikut, aturan menentukan tindakan Transition yang mengarahkan Amazon S3 untuk melakukan transisi objek ke kelas penyimpanan S3 Glacier Flexible Retrieval 0 hari setelah pembuatan. Aturan ini berarti bahwa objek memenuhi syarat untuk arsip ke S3 Glacier Flexible Retrieval pada tengah malam setelah pembuatan. UTC Untuk informasi selengkapnya tentang batasan siklus hidup, lihat Kendala dan pertimbangan untuk transisi.

    <LifecycleConfiguration> <Rule> <ID>Archive all object same-day upon creation</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
  • Anda dapat menentukan nol atau satu awalan nama kunci dan nol atau lebih tag objek pada suatu filter. Kode contoh berikut ini menerapkan aturan Siklus Hidup S3 pada subset objek dengan awalan kunci tax/ dan untuk objek yang memiliki dua tag dengan kunci dan nilai spesifik. Saat Anda menentukan lebih dari satu filter, Anda harus menyertakan elemen <And> seperti yang ditunjukkan (Amazon S3 menerapkan AND logis untuk menggabungkan kondisi filter yang ditentukan).

    ... <Filter> <And> <Prefix>tax/</Prefix> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...

  • Anda dapat memfilter objek berdasarkan tag saja. Misalnya, aturan Siklus Hidup S3 berikut berlaku untuk objek yang memiliki dua label yang ditentukan (tidak menyebutkan awalan apa pun).

    ... <Filter> <And> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...

penting

Jika Anda memiliki beberapa aturan dalam konfigurasi Siklus Hidup S3, objek dapat memenuhi syarat untuk beberapa tindakan Siklus Hidup S3 pada hari yang sama. Dalam kasus tersebut, Amazon S3 mengikuti aturan umum ini:

  • Penghapusan permanen lebih diutamakan daripada transisi.

  • Transisi lebih diutamakan daripada pembuatan penanda hapus.

  • Saat objek memenuhi syarat untuk transisi S3 Glacier Flexible Retrieval dan S3 Standard-IA (atau S3 One Zone-IA), Amazon S3 memilih transisi Pengambilan Fleksibel S3 Glacier.

Sebagai contoh, lihat Contoh 5: Filter yang tumpang tindih, tindakan siklus hidup yang bertentangan, dan apa yang dilakukan Amazon S3 dengan bucket tanpa versi.

Contoh 2: Menonaktifkan aturan Siklus Hidup

Anda dapat menonaktifkan sementara aturan Siklus Hidup S3. Konfigurasi Siklus Hidup S3 berikut menetapkan dua aturan:

  • Aturan 1 mengarahkan Amazon S3 untuk melakukan transisi objek dengan awalan logs/ ke kelas penyimpanan S3 Glacier Flexible Retrieval segera setelah pembuatan.

  • Aturan 2 mengarahkan Amazon S3 untuk melakukan transisi objek dengan awalan documents/ ke kelas penyimpanan S3 Glacier Flexible Retrieval segera setelah pembuatan.

Dalam konfigurasi, Aturan 1 diaktifkan dan Aturan 2 dinonaktifkan. Amazon S3 mengabaikan aturan yang dinonaktifkan.

<LifecycleConfiguration> <Rule> <ID>Rule1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> <Rule> <ID>Rule2</ID> <Filter> <Prefix>documents/</Prefix> </Filter> <Status>Disabled</Status> <Transition> <Days>0</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>

Contoh 3: Mengurangi kelas penyimpanan selama masa pakai objek

Dalam contoh ini, Anda menggunakan konfigurasi Siklus Hidup S3 untuk menurunkan kelas penyimpanan objek selama masa aktifnya. Penurunan tingkat dapat membantu mengurangi biaya penyimpanan. Untuk informasi selengkapnya tentang harga, lihat Harga Amazon S3.

Konfigurasi Siklus Hidup S3 berikut ini menentukan aturan yang berlaku untuk objek dengan awalan nama kunci logs/. Aturan menetapkan tindakan berikut ini:

  • Dua tindakan transisi:

    • Transisi objek ke kelas penyimpanan S3 Standard-IA 30 hari setelah pembuatan.

    • Transisi objek ke kelas penyimpanan S3 Glacier Flexible Retrieval 90 hari setelah pembuatan.

  • Satu tindakan kedaluwarsa yang mengarahkan Amazon S3 untuk menghapus objek setahun setelah pembuatan.

<LifecycleConfiguration> <Rule> <ID>example-id</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>30</Days> <StorageClass>STANDARD_IA</StorageClass> </Transition> <Transition> <Days>90</Days> <StorageClass>GLACIER</StorageClass> </Transition> <Expiration> <Days>365</Days> </Expiration> </Rule> </LifecycleConfiguration>
catatan

Anda dapat menggunakan satu aturan untuk menjelaskan semua tindakan Siklus Hidup S3 jika semua tindakan berlaku pada set objek yang sama (diidentifikasi oleh filter). Jika tidak, Anda dapat menambahkan beberapa aturan dengan masing-masing menetapkan filter yang berbeda.

penting

Jika Anda memiliki beberapa aturan dalam konfigurasi Siklus Hidup S3, objek dapat memenuhi syarat untuk beberapa tindakan Siklus Hidup S3 pada hari yang sama. Dalam kasus tersebut, Amazon S3 mengikuti aturan umum ini:

  • Penghapusan permanen lebih diutamakan daripada transisi.

  • Transisi lebih diutamakan daripada pembuatan penanda hapus.

  • Saat objek memenuhi syarat untuk transisi S3 Glacier Flexible Retrieval dan S3 Standard-IA (atau S3 One Zone-IA), Amazon S3 memilih transisi Pengambilan Fleksibel S3 Glacier.

Sebagai contoh, lihat Contoh 5: Filter yang tumpang tindih, tindakan siklus hidup yang bertentangan, dan apa yang dilakukan Amazon S3 dengan bucket tanpa versi.

Contoh 4: Menentukan beberapa aturan

Anda dapat menentukan beberapa aturan jika Anda menginginkan tindakan Siklus Hidup S3 yang berbeda dari objek yang berbeda. Konfigurasi Siklus Hidup S3 berikut memiliki dua aturan:

  • Aturan 1 berlaku untuk objek dengan awalan nama kunci classA/. Aturan ini mengarahkan Amazon S3 untuk melakukan transisi objek ke kelas penyimpanan S3 Glacier Flexible Retrieval satu tahun setelah pembuatan dan mengakhiri objek ini 10 tahun setelah pembuatan.

  • Aturan 2 berlaku untuk objek dengan awalan nama kunci classB/. Aturan ini mengarahkan Amazon S3 untuk melakukan transisi objek ke kelas penyimpanan S3 Standard-IA 90 hari setelah pembuatan dan menghapusnya satu tahun setelah pembuatan.

<LifecycleConfiguration> <Rule> <ID>ClassADocRule</ID> <Filter> <Prefix>classA/</Prefix> </Filter> <Status>Enabled</Status> <Transition>       <Days>365</Days>       <StorageClass>GLACIER</StorageClass>     </Transition> <Expiration> <Days>3650</Days> </Expiration> </Rule> <Rule> <ID>ClassBDocRule</ID> <Filter> <Prefix>classB/</Prefix> </Filter> <Status>Enabled</Status> <Transition>       <Days>90</Days>       <StorageClass>STANDARD_IA</StorageClass>     </Transition> <Expiration> <Days>365</Days> </Expiration> </Rule> </LifecycleConfiguration>
penting

Jika Anda memiliki beberapa aturan dalam konfigurasi Siklus Hidup S3, objek dapat memenuhi syarat untuk beberapa tindakan Siklus Hidup S3 pada hari yang sama. Dalam kasus tersebut, Amazon S3 mengikuti aturan umum ini:

  • Penghapusan permanen lebih diutamakan daripada transisi.

  • Transisi lebih diutamakan daripada pembuatan penanda hapus.

  • Saat objek memenuhi syarat untuk transisi S3 Glacier Flexible Retrieval dan S3 Standard-IA (atau S3 One Zone-IA), Amazon S3 memilih transisi Pengambilan Fleksibel S3 Glacier.

Sebagai contoh, lihat Contoh 5: Filter yang tumpang tindih, tindakan siklus hidup yang bertentangan, dan apa yang dilakukan Amazon S3 dengan bucket tanpa versi.

Contoh 5: Filter yang tumpang tindih, tindakan siklus hidup yang bertentangan, dan apa yang dilakukan Amazon S3 dengan bucket tanpa versi

Anda dapat menentukan konfigurasi Siklus Hidup S3 yang kemudian Anda menentukan tindakan, atau awalan yang tumpang tindih.

Umumnya, Siklus Hidup S3 mengoptimalkan biaya. Misalnya, jika dua kebijakan kedaluwarsa tumpang tindih, kebijakan kedaluwarsa yang lebih pendek akan dipenuhi sehingga data tidak disimpan lebih lama dari yang diharapkan. Demikian pula, jika dua kebijakan transisi tumpang tindih, Siklus Hidup S3 mentransisi objek Anda ke kelas penyimpanan berbiaya rendah.

Dalam kedua kasus tersebut, Siklus Hidup S3 mencoba memilih jalur yang paling murah bagi Anda. Pengecualian untuk aturan umum ini adalah dengan kelas penyimpanan S3 Intelligent-Tiering. S3 Intelligent-Tiering lebih disukai oleh Siklus Hidup S3 daripada kelas penyimpanan mana pun, selain kelas penyimpanan S3 Glacier Flexible Retrieval dan S3 Glacier Deep Archive.

Contoh berikut menunjukkan cara Amazon S3 menyelesaikan potensi konflik.

contoh 1: Awalan tumpang-tindih (tidak ada konflik)

Konfigurasi contoh berikut memiliki dua aturan yang menetapkan awalan yang tumpang tindih sebagai berikut:

  • Aturan pertama menetapkan filter kosong, yang menunjukkan semua objek dalam bucket.

  • Aturan kedua menetapkan awalan nama kunci (logs/), yang hanya menunjukkan subset objek.

Aturan 1 meminta Amazon S3 menghapus semua objek satu tahun setelah pembuatan. Aturan 2 meminta Amazon S3 mentransisikan subset objek ke kelas penyimpanan S3 Standard-IA 30 hari setelah pembuatan.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>30</Days> </Transition> </Rule> </LifecycleConfiguration>

Karena tidak ada konflik dalam kasus ini, Amazon S3 akan mentransisikan objek dengan awalan logs/ ke kelas penyimpanan S3 Standard-IA 30 hari setelah pembuatan. Ketika objek apa pun mencapai satu tahun setelah pembuatan, itu akan dihapus.

contoh 2: Tindakan siklus hidup yang bertentangan

Dalam konfigurasi contoh ini, ada dua aturan yang mengarahkan Amazon S3 untuk melakukan dua tindakan berbeda pada set objek yang sama dalam masa aktif objek:

  • Kedua aturan menentukan awalan nama kunci yang sama, sehingga kedua aturan berlaku pada objek yang sama.

  • Kedua aturan menentukan 365 hari yang sama setelah pembuatan objek saat aturan berlaku.

  • Satu aturan mengarahkan Amazon S3 untuk mentransisi objek ke kelas penyimpanan S3 Standard-IA dan aturan lain ingin Amazon S3 mengakhiri objek pada saat yang sama.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <Days>365</Days> </Expiration> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

Dalam kasus ini, karena Anda ingin objek kedaluwarsa (dihapus), tidak ada artinya mengubah kelas penyimpanan, jadi Amazon S3 memilih tindakan kedaluwarsa pada objek tersebut.

contoh 3: Awalan tumpang-tindih yang mengakibatkan tindakan siklus hidup yang bertentangan

Dalam contoh ini, konfigurasi memiliki dua aturan, yang menetapkan awalan tumpang tindih sebagai berikut:

  • Aturan 1 menetapkan awalan kosong (menunjukkan semua objek).

  • Aturan 2 menetapkan awalan nama kunci (logs/) yang mengidentifikasi bagian dari semua objek.

Untuk subset objek dengan awalan nama kunci logs/, tindakan Siklus Hidup S3 dalam kedua aturan berlaku. Satu aturan mengarahkan Amazon S3 transisi objek 10 hari setelah pembuatan, dan aturan lain mengarahkan Amazon S3 mentransisi objek 365 hari setelah pembuatan.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>10</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>STANDARD_IA<StorageClass> <Days>365</Days> </Transition> </Rule> </LifecycleConfiguration>

Dalam kasus ini, Amazon S3 memilih untuk melakukan transisi 10 hari setelah pembuatan.

contoh 4: Pemfilteran berbasis tag dan tindakan siklus hidup bertentangan yang diakibatkan

Anggaplah Anda memiliki konfigurasi Siklus Hidup S3 berikut yang memiliki dua aturan, masing-masing menetapkan filter tag:

  • Aturan 1 menetapkan filter berbasis tag (tag1/value1). Aturan ini mengarahkan Amazon S3 mentransisi objek ke kelas penyimpanan S3 Glacier Flexible Retrieval 365 hari setelah pembuatan.

  • Aturan 2 menetapkan filter berbasis tag (tag2/value2). Aturan ini mengarahkan Amazon S3 untuk mengakhiri objek 14 hari setelah pembuatan.

Konfigurasi Siklus Hidup S3 ditampilkan dalam contoh berikut.

<LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Tag> <Key>tag1</Key> <Value>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Transition> <StorageClass>GLACIER<StorageClass> <Days>365</Days> </Transition> </Rule> <Rule> <ID>Rule 2</ID> <Filter> <Tag> <Key>tag2</Key> <Value>value2</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

Jika suatu objek memiliki kedua tag, Amazon S3 harus memutuskan aturan mana yang harus diikuti. Dalam kasus ini, Amazon S3 mengakhiri objek 14 hari setelah pembuatan. Objek dihapus, dan oleh karena itu tindakan transisi tidak berlaku.

penting

Jika Anda memiliki beberapa aturan dalam konfigurasi Siklus Hidup S3, objek dapat memenuhi syarat untuk beberapa tindakan Siklus Hidup S3 pada hari yang sama. Dalam kasus tersebut, Amazon S3 mengikuti aturan umum ini:

  • Penghapusan permanen lebih diutamakan daripada transisi.

  • Transisi lebih diutamakan daripada pembuatan penanda hapus.

  • Saat objek memenuhi syarat untuk transisi S3 Glacier Flexible Retrieval dan S3 Standard-IA (atau S3 One Zone-IA), Amazon S3 memilih transisi Pengambilan Fleksibel S3 Glacier.

Sebagai contoh, lihat Contoh 5: Filter yang tumpang tindih, tindakan siklus hidup yang bertentangan, dan apa yang dilakukan Amazon S3 dengan bucket tanpa versi.

Contoh 6: Menentukan aturan siklus hidup untuk bucket dengan dukungan Penentuan Versi

Misalkan Anda memiliki bucket dengan dukungan Penentuan Versi, yang berarti untuk setiap objek Anda memiliki versi saat ini dan nol atau lebih versi lama. (Untuk informasi selengkapnya tentang Penentuan Versi S3, lihat Menggunakan Penentuan Versi dalam bucket S3.) Dalam contoh ini, Anda ingin mempertahankan nilai historis satu tahun, dan menghapus versi lama. Konfigurasi Siklus Hidup S3 mendukung penyimpanan 1 hingga 100 versi objek apa pun.

Untuk menghemat biaya penyimpanan, Anda ingin memindahkan versi lama ke S3 Glacier Flexible Retrieval 30 hari setelah menjadi versi lama (dengan asumsi objek lama ini adalah data dingin yang tidak memerlukan akses waktu nyata). Selain itu, Anda mengharapkan frekuensi akses versi saat ini berkurang 90 hari setelah pembuatan, jadi Anda dapat memilih untuk memindahkan objek ini ke kelas penyimpanan IA Standar S3.

<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>90</Days> <StorageClass>STANDARD_IA</StorageClass> </Transition> <NoncurrentVersionTransition> <NoncurrentDays>30</NoncurrentDays> <StorageClass>GLACIER</StorageClass> </NoncurrentVersionTransition> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>5</NewerNoncurrentVersions> <NoncurrentDays>365</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Contoh 7: Menghapus penanda hapus objek kedaluwarsa

Bucket dengan dukungan Penentuan Versi memiliki satu versi saat ini dan nol atau lebih versi lama untuk setiap objek. Ketika Anda menghapus sebuah objek, perhatikan hal berikut ini:

  • Jika Anda tidak menentukan ID versi dalam permintaan penghapusan Anda, Amazon S3 menambahkan penanda hapus alih-alih menghapus objek. Versi objek saat ini menjadi versi lama, dan penanda hapus menjadi versi saat ini.

  • Jika Anda menentukan ID versi dalam permintaan penghapusan Anda, Amazon S3 menghapus versi objek secara permanen (penanda hapus tidak dibuat).

  • Penanda hapus dengan nol versi lama disebut sebagai penanda hapus objek kedaluwarsa.

Contoh ini menunjukkan skenario yang dapat membuat penanda hapus objek kedaluwarsa dalam bucket Anda, dan cara Anda dapat menggunakan konfigurasi Siklus Hidup S3 untuk mengarahkan Amazon S3 untuk menghapus penanda hapus objek kedaluwarsa.

Misalkan Anda menulis konfigurasi Siklus Hidup S3 yang menggunakan NoncurrentVersionExpiration tindakan untuk menghapus versi noncurrent 30 hari setelah menjadi noncurrent dan mempertahankan paling banyak 10 versi noncurrent, seperti yang ditunjukkan pada contoh berikut.

<LifecycleConfiguration> <Rule> ... <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Tindakan NoncurrentVersionExpiration tidak berlaku untuk versi objek saat ini. Ini hanya menghapus versi lama.

Untuk versi objek saat ini, Anda memiliki opsi berikut untuk mengelola masa aktifnya, tergantung pada apakah versi objek saat ini mengikuti siklus hidup yang ditetapkan dengan baik:

  • Versi objek saat ini mengikuti siklus hidup yang ditentukan dengan baik.

    Dalam kasus ini, Anda dapat menggunakan konfigurasi Siklus Hidup S3 dengan tindakan Expiration guna mengarahkan Amazon S3 untuk menghapus versi saat ini, seperti yang ditunjukkan pada contoh berikut.

    <LifecycleConfiguration> <Rule> ... <Expiration> <Days>60</Days> </Expiration> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

    Dalam contoh ini, Amazon S3 menghapus versi saat ini 60 hari setelah dibuat dengan menambahkan penanda hapus untuk setiap versi objek saat ini. Proses ini membuat versi saat ini menjadi lama, dan penanda hapus menjadi versi saat ini. Untuk informasi selengkapnya, lihat Menggunakan Penentuan Versi dalam bucket S3.

    catatan

    Anda tidak dapat menentukan tag Days dan ExpiredObjectDeleteMarker pada aturan yang sama. Saat menentukan tag Days, Amazon S3 secara otomatis melakukan pembersihan ExpiredObjectDeleteMarker saat penanda hapus sudah cukup tua untuk memenuhi kriteria usia. Untuk membersihkan penanda hapus segera setelah menjadi satu-satunya versi, buat aturan terpisah hanya dengan tag ExpiredObjectDeleteMarker.

    Tindakan NoncurrentVersionExpiration dalam konfigurasi Siklus Hidup S3 yang sama akan menghapus objek lama 30 hari setelah menjadi lama. Dengan demikian, dalam contoh ini, semua versi objek dihapus secara permanen 90 hari setelah pembuatan objek. Meskipun penanda hapus objek kedaluwarsa dibuat selama proses ini, Amazon S3 mendeteksi dan menghapus penanda hapus objek kedaluwarsa untuk Anda.

  • Versi objek saat ini tidak memiliki siklus hidup yang didefinisikan dengan baik.

    Dalam kasus ini, Anda dapat menghapus objek secara manual ketika Anda tidak memerlukannya, membuat penanda hapus dengan satu atau lebih versi lama. Jika konfigurasi Siklus Hidup S3 dengan tindakan NoncurrentVersionExpiration menghapus semua versi lama, sekarang Anda memiliki penanda hapus objek kedaluwarsa.

    Khusus untuk skenario ini, konfigurasi Siklus Hidup S3 menyediakan tindakan Expiration yang dapat Anda gunakan untuk menghapus penanda hapus objek kedaluwarsa.

    <LifecycleConfiguration> <Rule> <ID>Rule 1</ID> <Filter> <Prefix>logs/</Prefix> </Filter> <Status>Enabled</Status> <Expiration> <ExpiredObjectDeleteMarker>true</ExpiredObjectDeleteMarker> </Expiration> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Dengan mengatur elemen ExpiredObjectDeleteMarker ke true dalam tindakan Expiration, Anda mengarahkan Amazon S3 untuk menghapus penanda hapus objek kedaluwarsa.

catatan

Saat Anda menggunakan tindakan Siklus Hidup S3 ExpiredObjectDeleteMarker, aturan tidak dapat menentukan filter berbasis tag.

Contoh 8: Konfigurasi siklus hidup untuk membatalkan unggahan multibagian

Anda dapat menggunakan REST API operasi unggahan multipart Amazon S3 untuk mengunggah objek besar menjadi beberapa bagian. Untuk informasi lebih lanjut tentang unggahan multibagian, lihat Mengunggah dan menyalin objek menggunakan unggahan multibagian.

Dengan menggunakan konfigurasi Siklus Hidup S3, Anda dapat mengarahkan Amazon S3 untuk menghentikan unggahan multibagian yang tidak lengkap (diidentifikasi dengan awalan nama kunci yang ditentukan dalam aturan) jika tidak selesai dalam jumlah hari tertentu setelah inisiasi. Saat Amazon S3 membatalkan unggahan multibagian, Amazon S3 menghapus semua bagian yang terkait dengan unggahan multibagian. Proses ini membantu mengontrol biaya penyimpanan dengan memastikan bahwa Anda tidak memiliki unggahan multibagian yang belum selesai dengan bagian-bagian yang disimpan di Amazon S3.

catatan

Saat Anda menggunakan tindakan Siklus Hidup S3 AbortIncompleteMultipartUpload, aturan tidak dapat menentukan filter berbasis tag.

Berikut ini adalah contoh konfigurasi Siklus Hidup S3 yang menentukan aturan dengan tinndakan AbortIncompleteMultipartUpload. Tindakan ini mengarahkan Amazon S3 untuk menghentikan pengunggahan multibagian yang tidak selesai tujuh hari setelah inisiasi.

<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix>SomeKeyPrefix/</Prefix> </Filter> <Status>rule-status</Status> <AbortIncompleteMultipartUpload> <DaysAfterInitiation>7</DaysAfterInitiation> </AbortIncompleteMultipartUpload> </Rule> </LifecycleConfiguration>

Contoh 9: Konfigurasi siklus hidup menggunakan aturan berbasis ukuran

Anda dapat membuat aturan yang mentransisikan objek hanya berdasarkan ukurannya. Anda dapat menentukan ukuran minimum (ObjectSizeGreaterThan) atau ukuran maksimum (ObjectSizeLessThan), atau Anda dapat menentukan rentang ukuran objek dalam bita. Saat menggunakan lebih dari satu filter, seperti awalan dan aturan ukuran, Anda harus membungkus filter dalam elemen <And>.

<LifecycleConfiguration> <Rule> <ID>Transition with a prefix and based on size</ID> <Filter> <And> <Prefix>tax/</Prefix> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> </And> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>

Jika Anda menentukan rentang dengan menggunakan kedua elemen ObjectSizeGreaterThan dan ObjectSizeLessThan, ukuran objek maksimum harus lebih besar dari ukuran objek minimum. Saat menggunakan lebih dari satu filter, Anda harus membungkus filter dalam elemen <And>. Contoh berikut menunjukkan bagaimana menentukan objek dalam kisaran antara 500 byte dan 64.000 byte. Saat Anda menentukan rentang, ObjectSizeLessThan filter ObjectSizeGreaterThan dan mengecualikan nilai yang ditentukan. Untuk informasi selengkapnya, lihat Elemen filter.

<LifecycleConfiguration> <Rule> ... <And> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> <ObjectSizeLessThan>64000</ObjectSizeLessThan> </And> </Rule> </LifecycleConfiguration>

Anda juga dapat membuat aturan untuk secara khusus menghapus objek noncurrent yang tidak memiliki data, termasuk objek penanda hapus noncurrent yang dibuat dalam bucket berkemampuan versi. Contoh berikut menggunakan NoncurrentVersionExpiration tindakan untuk menghapus versi noncurrent 30 hari setelah menjadi noncurrent dan mempertahankan paling banyak 10 versi noncurrent objek. Ini juga menggunakan ObjectSizeLessThan elemen untuk memfilter hanya objek tanpa data.

<LifecycleConfiguration> <Rule> <ID>Expire noncurrent with size less than 1 byte</ID> <Filter> <ObjectSizeLessThan>1</ObjectSizeLessThan> </Filter> <Status>Enabled</Status> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Contoh: Mengizinkan objek yang lebih kecil dari 128 KB untuk dialihkan

Amazon S3 menerapkan perilaku default ke konfigurasi Siklus Hidup Anda yang mencegah objek yang lebih kecil dari 128 KB dialihkan ke kelas penyimpanan apa pun. Anda dapat mengizinkan objek yang lebih kecil untuk bertransisi dengan menambahkan filter ukuran minimum (ObjectSizeGreaterThan) atau ukuran maksimum (ObjectSizeLessThan) yang menentukan ukuran yang lebih kecil ke konfigurasi. Contoh berikut memungkinkan objek yang lebih kecil dari 128 KB untuk transisi ke kelas penyimpanan S3 Glacier Instant Retrieval:

<LifecycleConfiguration> <Rule> <ID>Allow small object transitions</ID> <Filter> <ObjectSizeGreaterThan>1</ObjectSizeGreaterThan> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER_IR</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
catatan

Pada bulan September 2024 Amazon S3 memperbarui perilaku transisi default untuk objek kecil, sebagai berikut:

  • Perilaku transisi default yang diperbarui — Mulai September 2024, perilaku default mencegah objek yang lebih kecil dari 128 KB dialihkan ke kelas penyimpanan apa pun.

  • Perilaku transisi default sebelumnya — Sebelum September 2024, perilaku default memungkinkan objek yang lebih kecil dari 128 KB untuk dialihkan hanya ke kelas penyimpanan S3 Glacier dan S3 Glacier Deep Archive.

Konfigurasi yang dibuat sebelum September 2024 mempertahankan perilaku transisi sebelumnya kecuali Anda memodifikasinya. Artinya, jika Anda membuat, mengedit, atau menghapus aturan, perilaku transisi default untuk konfigurasi Anda berubah ke perilaku yang diperbarui. Jika kasus penggunaan diperlukan, Anda dapat mengubah perilaku transisi default sehingga objek yang lebih kecil dari 128KB akan bertransisi ke S3 Glacier dan S3 Glacier Deep Archive. Untuk melakukan ini, gunakan x-amz-transition-object-size-minimum-default header opsional dalam PutBucketLifecycleConfigurationpermintaan.

Contoh berikut menunjukkan cara menggunakan x-amz-transition-object-size-minimum-default header dalam PutBucketLifecycleConfigurationpermintaan untuk menerapkan perilaku transisi varies_by_storage_class default ke konfigurasi Siklus Hidup. Perilaku ini memungkinkan objek yang lebih kecil dari 128 KB untuk beralih ke kelas penyimpanan S3 Glacier atau S3 Glacier Deep Archive. Secara default, semua kelas penyimpanan lainnya akan mencegah transisi yang lebih kecil dari 128 KB. Anda masih dapat menggunakan filter khusus untuk mengubah ukuran transisi minimum untuk kelas penyimpanan apa pun. Filter khusus selalu diutamakan daripada perilaku transisi default:

HTTP/1.1 200 x-amz-transition-object-size-minimum-default: varies_by_storage_class <?xml version="1.0" encoding="UTF-8"?> ...