Beispiele für S3-Lebenszykluskonfigurationen - Amazon Simple Storage Service
Archivieren aller Objekte innerhalb eines Tages nach der ErstellungVorübergehendes Deaktivieren von LebenszyklusregelnStufenweise Reduzierung der Speicherklasse über die Lebensdauer des Objekts Festlegen mehrerer Aktionen oder RegelnFestlegen einer Lebenszyklus-Konfigurationsregel für einen Bucket mit VersioningEntfernen von Löschmarkierungen für abgelaufene Objekte in einem Bucket mit aktivierter VersionsverwaltungLebenszyklus-Konfigurationsregel für das Abbrechen mehrteiliger UploadsAblauf von Objekten, die keine Daten enthaltenBeispiel: Zulassen der Übertragung von Objekten, die kleiner als 128 KB sind

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beispiele für S3-Lebenszykluskonfigurationen

Dieser Abschnitt enthält Beispiele für S3-Lebenszykluskonfigurationen. Jedes Beispiel zeigt, wie Sie in jedem der Beispielszenarien das XML spezifizieren können.

Archivieren 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. Die folgenden S3-Lebenszykluskonfigurationen zeigen Beispiele dafür, wie Sie einen Filter spezifizieren können.

  • In dieser S3-Lebenszyklus-Konfigurationsregel 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>

    Statt das Objektalter in Tagen nach der Erstellung zu spezifizieren, können Sie für jede Aktion ein Datum festlegen. 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 nach der Erstellung um Mitternacht UTC zur Archivierung in S3 Glacier Flexible Retrieval berechtigt sind. Weitere Informationen zu Lebenszykluseinschränkungen finden Sie unter Einschränkungen und Überlegungen hinsichtlich Übertragungen.

    <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 in einer S3-Lebenszykluskonfiguration mehrere Regeln vorhanden sind, kann es sein, dass für ein Objekt am gleichen Tag mehrere S3-Lebenszyklusaktionen auszuführen sind. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

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

  • Die Übertragung hat Vorrang vor der Erstellung von Löschmarkierungen.

  • Wenn ein Objekt sowohl für einen S3 Glacier Flexible Retrieval als auch für einen S3 Standard-IA (oder S3 One Zone-IA)-Übergang in Frage kommt, entscheidet sich Amazon S3 für den Übergang zu S3 Glacier Flexible Retrieval.

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

Vorübergehendes Deaktivieren von Lebenszyklusregeln

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

Stufenweise Reduzierung der Speicherklasse über die Lebensdauer des Objekts

In diesem Beispiel nutzen Sie die S3-Lebenszykluskonfiguration, 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 in einer S3-Lebenszykluskonfiguration mehrere Regeln vorhanden sind, kann es sein, dass für ein Objekt am gleichen Tag mehrere S3-Lebenszyklusaktionen auszuführen sind. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

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

  • Die Übertragung hat Vorrang vor der Erstellung von Löschmarkierungen.

  • Wenn ein Objekt sowohl für einen S3 Glacier Flexible Retrieval als auch für einen S3 Standard-IA (oder S3 One Zone-IA)-Übergang in Frage kommt, entscheidet sich Amazon S3 für den Übergang zu S3 Glacier Flexible Retrieval.

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

Festlegen mehrerer Aktionen oder Regeln

Sie können mehrere Regeln angeben, wenn Sie unterschiedliche S3-Lebenszyklusaktionen 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 in einer S3-Lebenszykluskonfiguration mehrere Regeln vorhanden sind, kann es sein, dass für ein Objekt am gleichen Tag mehrere S3-Lebenszyklusaktionen auszuführen sind. In solchen Fällen folgt Amazon S3 diesen allgemeinen Regeln:

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

  • Die Übertragung hat Vorrang vor der Erstellung von Löschmarkierungen.

  • Wenn ein Objekt sowohl für einen S3 Glacier Flexible Retrieval als auch für einen S3 Standard-IA (oder S3 One Zone-IA)-Übergang in Frage kommt, entscheidet sich Amazon S3 für den Übergang zu S3 Glacier Flexible Retrieval.

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

Festlegen einer Lebenszyklus-Konfigurationsregel für einen Bucket mit Versioning

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 Beibehalten mehrerer Versionen von Objekten mit der S3-Versionsverwaltung.)

Im folgenden Beispiel möchten Sie die Historie von einem Jahr beibehalten und fünf nicht aktuelle Versionen beibehalten. S3-Lebenszykluskonfigurationen unterstützen die Beibehaltung von 1 bis 100 Versionen eines beliebigen Objekts. Beachten Sie, dass mehr als 5 neuere, nicht aktuelle Versionen existieren müssen, bevor Amazon S3 eine bestimmte Version ablaufen lassen kann. Amazon S3 löscht alle zusätzlichen nicht aktuellen Versionen dauerhaft, die über die angegebene Anzahl hinaus beibehalten werden sollen. Damit der Löschvorgang durchgeführt werden kann, müssen NoncurrentDays sowohl der als auch der NewerNoncurrentVersions Wert überschritten werden.

Um Speicherkosten zu sparen, sollten Sie nicht aktuelle Versionen 30 Tage, nachdem sie ihre Aktualität verlieren, in S3 Glacier Flexible Retrieval verschieben (vorausgesetzt, diese nicht aktuellen Objekte sind kalte Daten, für die Sie keinen Echtzeitzugriff benötigen). Darüber hinaus erwarten Sie, dass die Häufigkeit der Zugriffe auf die aktuellen Versionen 90 Tage nach der Erstellung nachlässt. So könnten Sie sich dazu 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>

Entfernen von Löschmarkierungen für abgelaufene Objekte in einem Bucket mit aktivierter Versionsverwaltung

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 in Ihrer Löschanfrage eine Versions-ID angeben, löscht Amazon S3 die Objektversion dauerhaft (eine Löschmarkierung wird nicht 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 ältere Versionen 30 Tage, nachdem sie veraltet sind, zu entfernen und 10 nicht aktuelle Versionen beizubehalten, wie im folgenden Beispiel gezeigt. Beachten Sie, dass mehr als 10 neuere, nicht aktuelle Versionen existieren müssen, bevor Amazon S3 eine bestimmte Version ablaufen lassen kann. Amazon S3 löscht alle zusätzlichen nicht aktuellen Versionen dauerhaft, die über die angegebene Anzahl hinaus beibehalten werden sollen. Damit der Löschvorgang durchgeführt werden kann, müssen NoncurrentDays sowohl der als auch der NewerNoncurrentVersions Wert überschritten werden.

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

Die NoncurrentVersionExpiration Aktion 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 Beibehalten mehrerer Versionen von Objekten mit der S3-Versionsverwaltung.

    Anmerkung

    Sie können nicht Days sowohl ein Tag als auch ein 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. Beachten Sie, dass in diesem Beispiel mehr als 10 neuere, nicht aktuelle Versionen existieren müssen, bevor Amazon S3 eine bestimmte Version ablaufen lassen kann. Amazon S3 löscht alle zusätzlichen nicht aktuellen Versionen dauerhaft, die über die angegebene Anzahl hinaus beibehalten werden sollen. Damit der Löschvorgang durchgeführt werden kann, müssen NoncurrentDays sowohl der als auch der NewerNoncurrentVersions Wert überschritten werden.

    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-Lebenszyklusaktion kann die Regel keinen Tag-basierten Filter angeben.

Lebenszyklus-Konfigurationsregel für das Abbrechen mehrteiliger Uploads

Sie können die mehrteiligen Upload-REST-API-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 in Amazon S3.

Mit Hilfe der S3-Lebenszykluskonfiguration können Sie Amazon S3 anweisen, unvollständige mehrteilige Uploads abzubrechen (identifiziert durch das Schlüsselnamenpräfix in der Regel), die nicht innerhalb einer bestimmten Anzahl an Tagen nach der Initiierung abgeschlossen wurden. 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-Lebenszykluskonfiguration, 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>

Ablauf von Objekten, 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. Im folgenden Beispiel wird gezeigt, wie Sie Objekte in einem Bereich zwischen 500 und 64.000 Byte angeben. Wenn Sie einen Bereich angeben, schließen die Filter ObjectSizeGreaterThan und ObjectSizeLessThan die festgelegten 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. Im folgenden Beispiel wird die NoncurrentVersionExpiration Aktion verwendet, um nicht aktuelle Versionen 30 Tage, nachdem sie veraltet sind, zu entfernen und 10 nicht aktuelle Versionen beizubehalten. In diesem Beispiel wird das ObjectSizeLessThan Element auch verwendet, um nur Objekte ohne Daten zu filtern.

Beachten Sie, dass mehr als 10 neuere, nicht aktuelle Versionen existieren müssen, bevor Amazon S3 eine bestimmte Version ablaufen lassen kann. Amazon S3 löscht alle zusätzlichen nicht aktuellen Versionen dauerhaft, die über die angegebene Anzahl hinaus beibehalten werden sollen. Damit der Löschvorgang durchgeführt werden kann, müssen NoncurrentDays sowohl der als auch der NewerNoncurrentVersions Wert überschritten werden. 

<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: Zulassen der Übertragung von Objekten, die kleiner als 128 KB sind

Amazon S3 wendet ein Standardverhalten auf Ihre Lebenszykluskonfiguration an, das verhindert, dass Objekte, die kleiner als 128 KB sind, in eine beliebige Speicherklasse übertragen werden. Sie können die Übertragung 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 festlegt. Im folgenden Beispiel wird für jedes Objekt, das kleiner als 128 KB ist, eine Übertragung auf die Speicherklasse S3 Glacier Instant Retrieval zugelassen:

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

  • Neues Standard-Übertragungsverhalten – Seit 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 ließ das Standardverhalten für Objekte, die kleiner als 128 KB waren, nur eine Übertragung in die Speicherklassen S3 Glacier und S3 Glacier Deep Archive zu.

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

Das folgende Beispiel zeigt, wie der x-amz-transition-object-size-minimum-default Header in einem verwendet wird PutBucketLifecycleConfigurationAnfrage, das varies_by_storage_class standardmäßige Übergangsverhalten auf eine S3-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 Übertragungen von Objekten, die kleiner als 128 KB sind. Sie können weiterhin benutzerdefinierte Filter verwenden, um die minimale Übertragungsgröße für jede Speicherklasse zu ändern. Benutzerdefinierte Filter haben immer Vorrang vor dem standardmäßigen Übertragungsverhalten:

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