Beispiele der S3-Lebenszyklus-Konfiguration

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

Beispiel 1: Festlegen eines Filters

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>

  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 für die Archivierung in S3 Glacier Flexible Retrieval berechtigt sind. Weitere Informationen zu Lebenszykluseinschränkungen finden Sie unter Beschränkungen.

  <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-Lebenszyklus-Konfiguration haben, kann es sein, dass für ein Objekt mehrere S3-Lebenszyklus-Aktionen auszuführen sind. 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 einen Übergang von S3 Glacier Flexible Retrieval als auch von S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, wählt Amazon S3 den Übergang von S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiel 5: Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen, und was Amazon S3 mit nichtversionierten Buckets macht.

Beispiel 2: Deaktivieren einer Lebenszyklusregel

Sie können eine S3-Lebenszyklusregel vorübergehend deaktivieren. 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 deaktivierte Regeln.

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

Beispiel 3: Schichtweise Reduzierung der Speicherklasse über die Lebensdauer des 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-Lebenszyklus-Konfiguration haben, kann es sein, dass für ein Objekt mehrere S3-Lebenszyklus-Aktionen auszuführen sind. 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 einen Übergang von S3 Glacier Flexible Retrieval als auch von S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, wählt Amazon S3 den Übergang von S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiel 5: Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen, und was Amazon S3 mit nichtversionierten Buckets macht.

Beispiel 4: Festlegen 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-Lebenszyklus-Konfiguration haben, kann es sein, dass für ein Objekt mehrere S3-Lebenszyklus-Aktionen auszuführen sind. 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 einen Übergang von S3 Glacier Flexible Retrieval als auch von S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, wählt Amazon S3 den Übergang von S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiel 5: Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen, und was Amazon S3 mit nichtversionierten Buckets macht.

Beispiel 5: Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen, und was Amazon S3 mit nichtversionierten Buckets macht

Sie könnten eine S3-Lebenszyklus-Konfiguration angeben, in der Sie überlappende Präfixe oder Aktionen spezifizieren.

Im Allgemeinen gibt S3-Lebenszyklus Kostenoptimierung Vorrang. Wenn sich z. B. zwei Ablaufrichtlinien überschneiden, wird die Ablaufrichtlinie mit der kürzeren Frist durchgesetzt, sodass die Daten nicht länger als erwartet gespeichert werden. Wenn sich zwei Übergangsrichtlinien überschneiden, überführt S3 Lifecycle Ihre Objekte in die Speicherklasse mit geringeren Kosten.

In beiden Fällen versucht S3 Lifecycle den für Sie kostengünstigsten Pfad auszuwählen. Die Speicherklasse S3 Intelligent-Tiering ist von dieser Regel ausgenommen. S3 Intelligent-Tiering wird von S3 Lifecycle gegenüber jeder Speicherklasse bevorzugt, abgesehen von den Speicherklassen S3 Glacier Flexible Retrieval und S3 Glacier Deep Archive.

Die folgenden Beispiele zeigen, wie Amazon S3 potenzielle Konflikte löst.

Beispiel 1: Überlappende Präfixe (kein Konflikt)

Die folgende Beispielkonfiguration weist zwei Regeln auf, die überlappenden Präfixe spezifizieren, wie folgt:

• Die erste Regel spezifiziert einen leeren Filter, d. h. alle Objekte in dem Bucket werden angesprochen.

• Die zweite Regel spezifiziert ein Schlüsselnamenpräfix (logs/), d. h. nur eine Untermenge von Objekten.

Regel 1 fordert Amazon S3 auf, alle Objekte ein Jahr nach der Erstellung zu löschen. Regel 2 fordert Amazon S3 auf, 30 Tage nach der Erstellung eine Teilmenge von Objekten in die S3-Standard-IA-Speicherklasse zu überführen.

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

Da in diesem Fall kein Konflikt besteht, überführt Amazon S3 die Objekte mit dem Präfix logs/ 30 Tage nach der Erstellung in die Speicherklasse S3 Standard-IA. Wenn ein Objekt ein Jahr nach der Erstellung erreicht, wird es gelöscht.

Beispiel 2: Widersprüchliche Lebenszyklus-Aktionen

In dieser Beispielkonfiguration gibt es zwei Regeln, die Amazon S3 anweisen, zwei unterschiedliche Aktionen für dieselbe Objektmenge zur selben Zeit in der Lebensdauer des Objekts auszuführen:

• Beide Regeln geben dasselbe Schlüsselnamenpräfix an, deshalb gelten beide Regeln für dieselbe Objektmenge.

• Beide Regeln spezifizieren dieselben 365 Tage nach der Erstellung des Objekts, wann die Regeln angewendet werden sollen.

• Eine Regel weist Amazon S3 an, Objekte zur S3 Standard-IA-Speicherklasse zu überführen. Eine andere Regel weist Amazon S3 an, die Objekte zur gleichen Zeit ablaufen zu lassen.

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

In diesem Fall wollen Sie, dass Objekte ablaufen (zu entfernen), deshalb macht es keinen Sinn, die Speicherklasse zu ändern, und Amazon S3 wählt einfach die Ablaufaktion für diese Objekte aus.

Beispiel 3: Überlappende Präfixe, die zu widersprüchlichen Lebenszyklus-Aktionen führen

In diesem Beispiel besitzt die Konfiguration zwei Regeln, die überlappende Präfixe angeben, wie folgt:

• Regel 1 legt ein leeres Präfix fest (was für alle Objekte gilt).

• Regel 2 spezifiziert ein Schlüsselnamenpräfix (logs/), das eine Untermenge aller Objekte angibt.

Für die Untermenge der Objekte mit dem Schlüsselnamenpräfix logs/ werden die S3-Lebenszyklus-Aktionen aus beiden Regeln angewendet. Eine Regel weist Amazon S3 an, Objekte 10 Tage nach der Erstellung zu übertragen, und eine andere Regel weist Amazon S3 an, Objekte 365 Tage nach dem Erstellen zu übertragen.

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

In diesem Fall entscheidet Amazon S3 den Übergang 10 Tage nach der Erstellung auszuführen.

Beispiel 4: Tag-basiertes Filtern, das zu widersprüchlichen Lebenszyklus-Aktionen führt

Angenommen, Sie haben die folgende S3-Lebenszykluskonfiguration, die zwei Regeln enthält, die beide einen Tag-Filter spezifizieren:

• Regel 1 spezifiziert einen Tag-basierten Filter (tag1/value1). Diese Regel weist Amazon S3 an, Objekte 365 Tage nach der Erstellung in die Speicherklasse S3 Glacier Flexible Retrieval zu übertragen.

• Regel 2 spezifiziert einen Tag-basierten Filter (tag2/value2). Diese Regel weist Amazon S3 an, Objekte 14 Tage nach der Erstellung ablaufen zu lassen.

Die S3-Lebenszyklus-Konfiguration wird im Folgenden angezeigt.

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

Wenn ein Objekt beide Tags hat, muss Amazon S3 entscheiden, welche Regel befolgt werden soll. In diesem Fall lässt Amazon S3 das Objekt 14 Tage nach der Erstellung ablaufen. Das Objekt wird entfernt und die Übergangsaktion wird daher nicht angewendet.

Wichtig

Wenn Sie mehrere Regeln in einer S3-Lebenszyklus-Konfiguration haben, kann es sein, dass für ein Objekt mehrere S3-Lebenszyklus-Aktionen auszuführen sind. 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 einen Übergang von S3 Glacier Flexible Retrieval als auch von S3 Standard-IA (oder S3 One Zone-IA) in Frage kommt, wählt Amazon S3 den Übergang von S3 Glacier Flexible Retrieval.

Beispiele finden Sie unter Beispiel 5: Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen, und was Amazon S3 mit nichtversionierten Buckets macht.

Beispiel 6: Spezifikation 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 Verwenden der Versioning in S3-Buckets.) In diesem Beispiel möchten Sie den Verlauf eines Jahres verwalten und die nicht aktuellen Versionen löschen. S3-Lebenszyklus-Konfigurationen unterstützen die Beibehaltung 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 erwarten Sie, dass der häufige Zugriff auf die aktuellen Versionen 90 Tage nach der Erstellung abläuft, Sie könnten entscheiden, diese Objekte in die Speicherklasse S3 Standard-IA überzuführen.

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

Beispiel 7: Löschen abgelaufener Löschmarkierungen für Objekte

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-Lebenszykluskonfiguration, die die -NoncurrentVersionExpirationAktion verwendet, um die nicht aktuellen Versionen 30 Tage, nachdem sie nicht aktuell geworden sind, zu entfernen und höchstens 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 Verwenden der Versioning in S3-Buckets.

  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.

Beispiel 8: 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.

Mit Hilfe der S3-Lebenszyklus-Konfiguration 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-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>

Beispiel 9: Lebenszykluskonfiguration mit größenbasierten Regeln

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 64000 Byte angeben.

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