Beispiele für S3-Lifecycle-Konfigurationen

Dieser Abschnitt enthält Beispiele für S3-Lebenszyklus-Konfigurationen. Jedes Beispiel zeigt, wie Sie das XML in den einzelnen Beispielszenarien spezifizieren können.

Archivierung aller Objekte innerhalb eines Tages nach der Erstellung

Jede S3-Lebenszyklusregel enthält einen Filter, mit dem Sie eine Untermenge der Objekte in Ihrem Bucket identifizieren können, auf die sich die S3-Lebenszyklusregel bezieht. Das folgenden S3 Lifecycle-Konfigurationen zeigen Beispiele dafür, wie Sie einen Filter spezifizieren können.

• In dieser S3-Lebenszyklus-Konfigurationregel spezifiziert der Filter ein Schlüsselpräfix (tax/). Aus diesem Grund gilt die Regel für Objekte mit dem Schlüsselnamenpräfix tax/, wie beispielsweise tax/doc1.txt und tax/doc2.txt.

  Die Regel spezifiziert zwei Aktionen, die Amazon S3 zu Folgendem anweisen:

  • Übergang von Objekten in die Speicherklasse S3 Glacier Flexible Retrieval 365 Tage (ein Jahr) nach der Erstellung.

  • Objekte 3.650 Tage (10 Jahre) nach der Erstellung löschen (die Expiration-Aktion).

  <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>

  Anstatt das Objektalter in Tagen nach der Erstellung anzugeben, können Sie für jede Aktion ein Datum angeben. Sie können Date und Days nicht in derselben Regel kombinieren.

• Wenn Sie wollen, dass die S3-Lebenszyklusregel für alle Objekte im Bucket gilt, geben Sie ein leeres Präfix an. In der folgenden Konfiguration gibt die Regel eine Transition-Aktion an, die Amazon S3 anweist, Objekte 0 Tage nach der Erstellung in die S3 Glacier Flexible Retrieval-Speicherklasse zu überführen. Diese Regel bedeutet, dass die Objekte um Mitternacht UTC nach der Erstellung in S3 Glacier Flexible Retrieval archiviert werden können. Weitere Informationen zu Lebenszykluseinschränkungen finden Sie unter Einschränkungen und Überlegungen für Übergänge.

  <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>

• Sie können null oder mehrere Schlüsselnamenpräfixe und null oder mehr Objekt-Markierungen in einem Filter angeben. Der folgende Beispiel-Code wendet die S3-Lebenszyklusregel auf eine Untermenge von Objekten mit dem Schüsselpräfix tax/ an, ebenso wie auf Objekte mit zwei Markierungen mit spezifischem Schüssel und Wert. Wenn Sie mehr als einen Filter angeben, müssen Sie das <And>-Element wie gezeigt einschließen (Amazon S3 wendet ein logisches AND an, um die angegebenen Filterbedingungen zu kombinieren).

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

• Sie können Objekte nur auf Markierungen basierend filtern. Die folgende S3-Lebenszyklusregel beispielsweise wird auf Objekte angewendet, die die beiden spezifizierten Markierungen aufweisen (es wird kein Präfix angegeben).

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

Wichtig

Wenn Sie mehrere Regeln in einer S3 Lifecycle-Konfiguration haben, kann ein Objekt am selben Tag für mehrere S3 Lifecycle-Aktionen in Frage kommen. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

• Das permanente Löschen hat Vorrang vor einem Übergang.

• Der Übergang hat Vorrang vor der Erstellung von Löschmarkierungen.

• Wenn ein Objekt sowohl für eine Umstellung auf S3 Glacier Flexible Retrieval als auch für eine Umstellung auf S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, entscheidet sich Amazon S3 für die Umstellung auf S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiele für sich überschneidende Filter und widersprüchliche Lebenszyklusaktionen.

Lebenszyklusregeln vorübergehend deaktivieren

Sie können eine S3-Lebenszyklusregel mithilfe des status Elements vorübergehend deaktivieren. Dies kann nützlich sein, wenn Sie neue Regeln testen oder Probleme mit Ihrer Konfiguration beheben möchten, ohne Ihre vorhandenen Regeln zu überschreiben. Die folgende S3-Lebenszyklus-Konfiguration spezifiziert zwei Regeln:

• Regel 1 weist Amazon S3 an, Objekte mit dem Präfix logs/ bald nach der Erstellung in die Speicherklasse S3 Glacier Flexible Retrieval zu übertragen.

• Regel 2 weist Amazon S3 an, Objekte mit dem Präfix documents/ bald nach der Erstellung in die Speicherklasse S3 Glacier Flexible Retrieval zu übertragen.

In der Konfiguration ist Regel 1 aktiviert und Regel 2 ist deaktiviert. Amazon S3 ignoriert die deaktivierte Regel.

<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>

Verkleinerung der Speicherklasse im Laufe der Lebensdauer eines Objekts

In diesem Beispiel nutzen Sie die S3-Lebenszyklus-Konfiguration, um die Speicherklasse von Objekten über ihre Lebensdauer stufenweise zu reduzieren. Diese schichtweise Reduzierung kann dazu beitragen, Speicherkosten zu reduzieren. Weitere Informationen zu Preisen finden Sie unter Amazon-S3-Preise.

Die folgende S3-Lebenszyklus-Konfiguration spezifiziert eine Regel, die auf Objekte mit Schlüsselnamenpräfix logs/ angewendet wird. Die Regel definiert die folgenden Aktionen:

• Zwei Übergangsaktionen:

  • Übergang von Objekten in die Speicherklasse S3 Standard-IA 30 Tage nach der Erstellung.

  • Übergang von Objekten in die Speicherklasse S3 Glacier Flexible Retrieval 90 Tage nach der Erstellung.

• Eine Ablaufaktion, die Amazon S3 anweist, Objekte ein Jahr nach ihrer Erstellung zu löschen.

<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>

Anmerkung

Sie können eine Regel verwenden, um alle S3-Lebenszyklus-Aktionen zu beschreiben, die für dieselbe Objektmenge angewendet werden (identifiziert durch den Filter). Andernfalls können Sie mehrere Regeln hinzufügen, die jeweils einen unterschiedlichen Filter angeben.

Wichtig

Wenn Sie mehrere Regeln in einer S3 Lifecycle-Konfiguration haben, kann ein Objekt für mehrere S3 Lifecycle-Aktionen am selben Tag in Frage kommen. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

• Das permanente Löschen hat Vorrang vor einem Übergang.

• Der Übergang hat Vorrang vor der Erstellung von Löschmarkierungen.

• Wenn ein Objekt sowohl für eine Umstellung auf S3 Glacier Flexible Retrieval als auch für eine Umstellung auf S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, entscheidet sich Amazon S3 für die Umstellung auf S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiele für sich überschneidende Filter und widersprüchliche Lebenszyklusaktionen.

Angabe mehrerer Regeln

Sie können mehrere Regeln angeben, wenn Sie unterschiedliche S3-Lebenszyklus-Aktionen auf unterschiedliche Objekte anwenden wollen. Die folgende S3-Lebenszyklus-Konfiguration spezifiziert zwei Regeln:

• Regel 1 gilt für Objekte mit dem Schlüsselnamenpräfix classA/. Sie weist Amazon S3 an, Objekte ein Jahr nach der Erstellung in die Speicherklasse S3 Glacier Flexible Retrieval zu übertragen, und diese Objekte 10 Jahre nach dem Erstellen ablaufen zu lassen.

• Regel 2 gilt für Objekte mit dem Schlüsselnamenpräfix classB/. Sie weist Amazon S3 an, Objekte 90 Tage nach der Erstellung in die Speicherklasse S3 Standard-IA zu übertragen, und sie ein Jahr nach dem zu löschen.

<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>

Wichtig

Wenn Sie mehrere Regeln in einer S3 Lifecycle-Konfiguration haben, kann ein Objekt am selben Tag für mehrere S3 Lifecycle-Aktionen in Frage kommen. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

• Das permanente Löschen hat Vorrang vor einem Übergang.

• Der Übergang hat Vorrang vor der Erstellung von Löschmarkierungen.

• Wenn ein Objekt sowohl für eine Umstellung auf S3 Glacier Flexible Retrieval als auch für eine Umstellung auf S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, entscheidet sich Amazon S3 für die Umstellung auf S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiele für sich überschneidende Filter und widersprüchliche Lebenszyklusaktionen.

Angabe einer Lebenszyklusregel für einen Bucket mit aktivierter Versionierung

Angenommen, Sie haben einen Versioning-fähigen Bucket, d. h. Sie haben für jedes Objekt eine aktuelle Version und keine oder mehr nicht aktuelle Versionen. (Weitere Informationen über das S3-Versioning finden Sie unter Beibehaltung mehrerer Versionen von Objekten mit S3 Versioning.) In diesem Beispiel möchten Sie den Verlauf eines Jahres verwalten und die nicht aktuellen Versionen löschen. S3-Lebenszykluskonfigurationen unterstützen die Aufbewahrung von 1 bis 100 Versionen eines beliebigen Objekts.

Um Speicherkosten zu sparen, sollten Sie nicht aktuelle Versionen 30 Tage, nachdem sie nicht mehr aktuell werden, auf S3 Glacier Flexible Retrieval verschieben (vorausgesetzt, diese nicht aktuellen Objekte sind kalte Daten, für die Sie keinen Echtzeitzugriff benötigen). Darüber hinaus gehen Sie davon aus, dass die Zugriffshäufigkeit der aktuellen Versionen 90 Tage nach der Erstellung abnehmen wird. Sie könnten sich also dafür entscheiden, diese Objekte in die Speicherklasse S3 Standard-IA zu verschieben.

<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>

Löschen von Markierungen für das Löschen abgelaufener Objekte in einem Bucket mit aktivierter Versionierung

Ein Bucket mit Versioning enthält eine aktuelle Version und null oder mehr nicht aktuelle Versionen für jedes Objekt. Beachten Sie beim Löschen eines Objekts Folgendes:

• Wenn Sie keine Versions-ID in Ihrer Löschanfrage angeben, fügt Amazon S3 eine Löschmarkierung hinzu, statt das Objekt zu löschen. Das aktuelle Version wird nicht aktuell, und die Löschmarkierung wird zur aktuellen Version.

• Wenn Sie eine Versions-ID in Ihrer Löschanfrage angeben, löscht Amazon S3 die Objektversion permanent (es wird keine Löschmarkierung erstellt).

• Eine Löschmarkierung mit null nicht aktuellen Versionen wird als Löschmarkierung für das abgelaufene Objekt bezeichnet.

Dieses Beispiel zeigt ein Szenario, das Löschmarkierungen für abgelaufene Objekte in Ihrem Bucket erstellen kann, und demonstriert, wie Sie mit einer S3-Lebenszyklus-Konfiguration Amazon S3 anweisen können, die Löschmarkierungen für abgelaufene Objekte zu löschen.

Angenommen, Sie schreiben eine S3-Lifecycle-Konfiguration, die die NoncurrentVersionExpiration Aktion verwendet, um die nicht aktuellen Versionen 30 Tage, nachdem sie veraltet sind, zu entfernen und maximal 10 nicht aktuelle Versionen beizubehalten, wie im folgenden Beispiel gezeigt.

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

Die Aktion NoncurrentVersionExpiration gilt nicht für die aktuellen Objektversionen. Sie entfernt nur nicht aktuelle Versionen.

Für aktuelle Objektversionen haben Sie die folgenden Optionen, ihre Lebensdauer zu verwalten, abhängig davon, ob die aktuellen Objektversionen einen definieren Lebenszyklus haben:

• Aktuelle Objektversionen folgen einem gut definierten Lebenszyklus.

  In diesem Fall können Sie eine S3-Lebenszykluskonfiguration mit der Aktion Expiration verwenden, um Amazon S3 anzuweisen, die aktuellen Versionen zu entfernen, wie im folgenden Beispiel gezeigt.

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

  In diesem Beispiel entfernt Amazon S3 aktuelle Versionen 60 Tage nach ihrer Erstellung, indem für jede der aktuellen Objektversionen eine Löschmarkierung hinzugefügt wird. Durch diesen Vorgang wird die aktuelle Version nicht mehr aktuell und die Löschmarkierung wird zur aktuellen Version. Weitere Informationen finden Sie unter Beibehaltung mehrerer Versionen von Objekten mit S3 Versioning.

  Anmerkung

  Sie können nicht sowohl ein Days als auch ExpiredObjectDeleteMarker-Tag für dieselbe Regel angeben. Wenn Sie das Days-Tag angeben, führt Amazon S3 automatisch eine ExpiredObjectDeleteMarker-Bereinigung durch, wenn die Löschmarkierungen alt genug sind, um die Alterskriterien zu erfüllen. Um Löschmarkierungen zu bereinigen, sobald sie die einzige Version werden, erstellen Sie eine separate Regel nur mit dem ExpiredObjectDeleteMarker-Tag.

  Die NoncurrentVersionExpiration-Aktion in derselben S3-Lebenszyklus-Konfiguration entfernt nicht aktuelle Objekte 30 Tage, nachdem sie nicht aktuell wurden. Somit werden in diesem Beispiel 90 Tage nach der Objekterstellung alle Objektversionen dauerhaft entfernt. Obwohl während dieses Vorgangs Löschmarkierungen für abgelaufene Objekte erstellt werden, erkennt und entfernt Amazon S3 die Löschmarkierungen für abgelaufene Objekte für Sie.

• Aktuelle Objektversionen folgen keinem gut definierten Lebenszyklus.

  In diesem Fall müssen Sie die Objekte möglicherweise manuell entfernen, wenn Sie sie nicht mehr brauchen, und eine Löschmarkierungen mit einer oder mehreren nicht aktuellen Versionen erstellen. Wenn Ihre S3-Lebenszyklus-Konfiguration mit der NoncurrentVersionExpiration-Aktion alle nicht aktuellen Versionen löscht, haben Sie jetzt Löschmarkierungen für abgelaufene Objekte.

  Speziell für dieses Szenario stellt die S3-Lebenszykluskonfiguration die Expiration-Aktion bereit, mit der Sie die Löschmarkierungen für abgelaufene Objekte entfernen können.

  <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>

Setzen Sie das ExpiredObjectDeleteMarker-Element in der Expiration-Aktion auf true, um Amazon S3 anzuweisen, Löschmarkierungen für abgelaufene Objekte zu entfernen.

Anmerkung

Bei Verwendung der ExpiredObjectDeleteMarker-S3-Lebenszyklus-Aktion kann die Regel keinen Tag-basierten Filter angeben.

Lifecycle-Konfiguration zum Abbrechen mehrteiliger Uploads

Sie können die mehrteiligen REST API Upload-Operationen von Amazon S3 verwenden, um große Objekte in Teilen hochzuladen. Weitere Informationen über mehrteilige Uploads finden Sie unter Hochladen und Kopieren von Objekten mit mehrteiligen Uploads.

Mithilfe einer S3-Lifecycle-Konfiguration können Sie Amazon S3 anweisen, unvollständige mehrteilige Uploads (identifiziert durch das in der Regel angegebene Schlüsselnamenpräfix) zu beenden, wenn sie nicht innerhalb einer bestimmten Anzahl von Tagen nach der Initiierung abgeschlossen werden. Wenn Amazon S3 einen mehrteiligen Upload abbricht, werden alle diesem mehrteiligen Upload zugeordneten Teile gelöscht. Dieser Prozess hilft, Ihre Speicherkosten zu kontrollieren, indem Sie sicherstellen, dass Sie keine unvollständigen mehrteiligen Uploads mit Teilen haben, die in Amazon S3 gespeichert sind.

Anmerkung

Bei Verwendung der AbortIncompleteMultipartUpload-S3-Lebenszyklus-Aktion kann die Regel keinen Tag-basierten Filter angeben.

Das folgende Beispiel zeigt eine S3-Lebenszyklus-Konfiguration, die eine Regel mit der Aktion AbortIncompleteMultipartUpload spezifiziert. Diese Aktion leitet Amazon S3 dazu, unvollständige mehrteilige Uploads sieben Tage nach der Initiierung abzubrechen.

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

Ablaufende, nicht aktuelle Objekte, die keine Daten enthalten

Sie können Regeln erstellen, die Objekte nur basierend auf ihrer Größe übergehen. Sie können eine Mindestgröße (ObjectSizeGreaterThan) oder eine Maximalgröße (ObjectSizeLessThan) angeben, oder Sie können einen Bereich von Objektgrößen in Bytes angeben. Wenn Sie mehr als einen Filter verwenden, z. B. ein Präfix und eine Größenregel, müssen Sie die Filter in ein <And>-Element umfassen.

<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>

Wenn Sie einen Bereich mit den ObjectSizeGreaterThan- und ObjectSizeLessThan-Elementen angeben, muss die maximale Objektgröße größer als die minimale Objektgröße sein. Wenn Sie mehr als einen Filter verwenden, müssen Sie die Filter in ein <And>-Element packen. Das folgende Beispiel zeigt, wie Objekte in einem Bereich zwischen 500 Byte und 64.000 Byte angegeben werden. Wenn Sie einen Bereich angeben, schließen die ObjectSizeLessThan Filter ObjectSizeGreaterThan und die angegebenen Werte aus. Weitere Informationen finden Sie unter Filterelement.

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

Sie können auch Regeln erstellen, um nicht aktuelle Objekte, die keine Daten enthalten, ausdrücklich ablaufen zu lassen, einschließlich nicht aktueller Löschmarkierungsobjekte, die in einem Bucket mit aktivierter Versionsverwaltung erstellt wurden. Das folgende Beispiel verwendet die NoncurrentVersionExpiration-Aktion angibt, um nicht aktuelle Versionen 30 Tage, nachdem sie nicht mehr aktuell sind, zu entfernen und höchstens 10 nicht aktuelle Versionen beizubehalten, wie im folgenden Beispiel gezeigt. Außerdem wird das ObjectSizeLessThan-Element verwendet, um nur Objekte ohne Daten zu filtern.

<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>

Beispiel: Ermöglicht die Übertragung von Objekten, die kleiner als 128 KB sind

Amazon S3 wendet auf Ihre Lifecycle-Konfiguration ein Standardverhalten an, das verhindert, dass Objekte, die kleiner als 128 KB sind, in eine beliebige Speicherklasse übertragen werden. Sie können den Übergang kleinerer Objekte zulassen, indem Sie der Konfiguration einen Filter für die Mindestgröße (ObjectSizeGreaterThan) oder die maximale Größe (ObjectSizeLessThan) hinzufügen, der eine kleinere Größe angibt. Das folgende Beispiel ermöglicht jedem Objekt, das kleiner als 128 KB ist, den Übergang zur S3 Glacier Instant Retrieval-Speicherklasse:

<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>

Anmerkung

Im September 2024 hat Amazon S3 das standardmäßige Übergangsverhalten für kleine Objekte wie folgt aktualisiert:

• Aktualisiertes Standard-Übergangsverhalten — Ab September 2024 verhindert das Standardverhalten, dass Objekte, die kleiner als 128 KB sind, in eine beliebige Speicherklasse übertragen werden.

• Bisheriges Standard-Übergangsverhalten — Vor September 2024 erlaubte das Standardverhalten, dass Objekte, die kleiner als 128 KB waren, nur in die Speicherklassen S3 Glacier und S3 Glacier Deep Archive übertragen wurden.

Konfigurationen, die vor September 2024 erstellt wurden, behalten das vorherige Übergangsverhalten bei, sofern Sie sie nicht ändern. Das heißt, wenn Sie Regeln erstellen, bearbeiten oder löschen, ändert sich das standardmäßige Übergangsverhalten für Ihre Konfiguration in das aktualisierte Verhalten. Falls es Ihr Anwendungsfall erfordert, können Sie das standardmäßige Übergangsverhalten so ändern, dass Objekte, die kleiner als 128 KB sind, auf S3 Glacier und S3 Glacier Deep Archive umgestellt werden. Verwenden Sie dazu den optionalen x-amz-transition-object-size-minimum-default Header in einer PutBucketLifecycleConfigurationAnfrage.

Das folgende Beispiel zeigt, wie der x-amz-transition-object-size-minimum-default Header in einer PutBucketLifecycleConfigurationAnfrage verwendet wird, um das varies_by_storage_class standardmäßige Übergangsverhalten auf eine Lifecycle-Konfiguration anzuwenden. Dieses Verhalten ermöglicht Objekten, die kleiner als 128 KB sind, den Übergang zu den Speicherklassen S3 Glacier oder S3 Glacier Deep Archive. Standardmäßig verhindern alle anderen Speicherklassen Übergänge, die kleiner als 128 KB sind. Sie können weiterhin benutzerdefinierte Filter verwenden, um die minimale Übergangsgröße für jede Speicherklasse zu ändern. Benutzerdefinierte Filter haben immer Vorrang vor dem standardmäßigen Übergangsverhalten:

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