Beispiele der Lebenszykluskonfiguration - Amazon Simple Storage Service

Sofern wir eine Übersetzung der englischsprachigen Version des Handbuchs bereitstellen, gilt im Fall von Widersprüchen die englischsprachige Version des Handbuchs. Bei der Übersetzung handelt es sich um eine maschinelle Übersetzung.

Beispiele der Lebenszykluskonfiguration

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

Beispiel 1 Festlegen eines Filters

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

  • In dieser Lebenszykluskonfigurationregel spezifiziert der Filter ein Schlüsselpräfix (tax/). Daher gilt die Regel für Objekte mit Key-Name-Präfix tax/, wie z. B. 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 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>S3 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 jedoch nicht beides verwenden Date und Days in derselben Regel.

  • Wenn Sie wollen, dass die Lebenszyklusregel für alle Objekte im Bucket gilt, geben Sie ein leeres Präfix an. In der folgenden Konfiguration gibt die Regel eine Transition Handlungsweisen Amazon S3 um Objekte auf die S3 Glacier Speicherklasse 0 Tage nach Erstellung, in der Fallobjekte für Archiv berechtigt sind Amazon S3 Glacier um Mitternacht UTC nach Erstellung.

    <LifecycleConfiguration> <Rule> <ID>Archive all object same-day upon creation</ID> <Filter> <Prefix></Prefix> </Filter> <Status>Enabled</Status> <Transition> <Days>0</Days> <StorageClass>S3 Glacier</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
  • Sie können null oder mehrere Schlüsselnamenpräfixe und null oder mehr Objekt-Tags in einem Filter angeben. Der folgende Beispiel-Code wendet die Lebenszyklusregel auf eine Untermenge von Objekten mit dem Schüsselpräfix tax/ an, ebenso wie auf Objekte mit zwei Tags mit spezifischem Schüssel und Wert. Beachten Sie, dass Sie bei der Angabe von mehr als einem Filter eine UND-Verknüpfung verwenden müssen, wie gezeigt (Amazon S3 wendet ein logisches UND an und kombiniert die spezifizierten Filterbedingungen).

    ... <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 Tags basierend filtern. Die folgende Lebenszyklusregel beispielsweise wird auf Objekte angewendet, die die beiden spezifizierten Tags 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 Lebenszyklusaktionen zulässig werden. 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 für beide S3 Glacier und S3 Standard-IA (oder S3 One Zone-IA) Übergang, Amazon S3 wählt die S3 Glacier Übergang.

Beispiele für finden Sie unter Beispiel 5 Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen und was Amazon S3 tut .

Beispiel 2 Deaktivieren einer Lifecycle-Regel

Lebenszyklusregeln können vorübergehend deaktiviert werden. Die folgende Lebenszykluskonfiguration spezifiziert zwei Regeln:

  • Regel 1 steuert Amazon S3 Objekte mit dem logs/ Präfix der S3 Glacier Speicherklasse bald nach Erstellung.

  • Regel 2 steuert Amazon S3 Objekte mit dem documents/ Präfix der S3 Glacier Speicherklasse bald nach Erstellung.

In der Richtlinie ist die Regel 1 aktiviert und die Regel 2 deaktiviert. Amazon S3 führt keine Aktionen für deaktivierte Regeln aus.

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

Beispiel 3 Ablagerung der Speicherklasse über das gesamte Objekt hinweg

In diesem Beispiel nutzen Sie die 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 Preisgestaltung.

Folgendes S3-Lebenszyklus Konfiguration gibt eine Regel an, die auf Objekte mit Key-Name-Präfix angewendet wird logs/. Die Regel gibt die folgenden Aktionen an:

  • Zwei Übergangsaktionen:

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

    • Übergang von Objekten in die Speicherklasse S3 Glacier 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 Lebenszyklusaktionen 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.

Beispiel 4 Festlegen mehrerer Regeln

Sie können mehrere Regeln angeben, wenn Sie unterschiedliche Lebenszyklusaktionen auf unterschiedliche Objekte anwenden wollen. Die folgende Lebenszykluskonfiguration spezifiziert zwei Regeln:

  • Regel 1 gilt für Objekte mit dem Key-Name-Präfix classA/. Es leitet Amazon S3 um Objekte auf die S3 Glacier Speicherklasse ein Jahr nach Erstellung und Ablauf dieser Objekte 10 Jahre nach Erstellung.

  • Regel 2 gilt für Objekte mit Key-Name-Präfix classB/. Es leitet Amazon S3 um Objekte auf die S3 Standard-IA-Speicherklasse 90 Tage nach Erstellung und Löschen eines Jahres nach Erstellung.

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

Beispiel 5 Überlappende Filter, widersprüchliche Lebenszyklus-Aktionen und was Amazon S3 tut

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

Im Allgemeinen gibt Amazon S3 Lifecycle 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-Lebenszyklus Ihre Objekte in die Speicherklasse mit geringeren Kosten. In beiden Fällen versucht S3-Lebenszyklus, den Pfad auszuwählen, der für Sie am kostengünstigsten ist. Eine Ausnahme dieser allgemeinen Regel ist mit der S3 Intelligent-Tiering Speicherklasse. S3 Intelligent-Tiering wird von S3-Lebenszyklus über jede Speicherklasse, abgesehen von S3 Glacier und S3 Glacier Deep Archive Speicherklassen.

Die folgenden Beispiele zeigen, wie Amazon S3 potenzielle Konflikte auflö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. Anforderungen der Regel 2 Amazon S3 um eine Teilmenge an Objekten an das S3 Standard-IA-Speicherklasse 30 Tage nach Erstellung.

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

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 Regelführung Amazon S3 um Objekte in die S3-Standard-IA-Speicherklasse zu übertragen, und eine andere Regel möchte Amazon S3 um die Objekte gleichzeitig zu ablaufen.

<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 (entfernt werden), 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 Lebenszyklusaktionen aus beiden Regeln angewendet. Eine Regel Amazon S3 um Objekte 10 Tage nach Erstellung und eine andere Regel zu übertragen Amazon S3 um Objekte 365 Tage nach Erstellung zu verschieben.

<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-basierte Filterung und daraus resultierende Lebenszyklus-Aktionen

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

  • Regel 1 spezifiziert einen Tag-basierten Filter (tag1/value1). Diese Regel lenkt Amazon S3 um Objekte auf die S3 Glacier Speicherklasse 365 Tage nach Erstellung.

  • 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 Lebenszykluskonfiguration 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>value1</Value> </Tag> </Filter> <Status>Enabled</Status> <Expiration> <Days>14</Days> </Expiration> </Rule> </LifecycleConfiguration>

Die Richtlinie ist in Ordnung, aber wenn es ein Objekt mit beiden Tags gibt, muss S3 entscheiden, was zu tun ist. Das bedeutet, beide Regeln gelten für eine Objekt, und letztlich weisen Sie Amazon S3 an, widersprüchliche Aktionen auszuführen. In diesem Fall lässt Amazon S3 das Objekt 14 Tage nach der Erstellung ablaufen. Das Objekt wird entfernt, deshalb kommt die Übergangsaktion nicht ins Spiel.

Beispiel 6 Festlegen einer Lifecycle-Regel für einen versioning-aktivierten Bucket

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. Sie wollen, dass ein Verlauf von einem Jahr beibehalten wird. Anschließend sollen die nicht aktuellen Versionen gelöscht werden. Weitere Informationen zu S3-Versioning finden Sie unter ()Objekt-Versioning.

Außerdem wollen Sie Speicherkosten sparen, indem Sie nicht aktuelle Versionen 30 Tage, nachdem sie nicht aktuell geworden sind, in S3 Glacier verschieben (vorausgesetzt, es handelt sich um kalte Daten, für die Sie keinen Speicherzugriff in Echtzeit 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 also entscheiden, diese Objekte in die S3 Standard-IA-Speicherklasse zu überfü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>S3 Glacier</StorageClass> </NoncurrentVersionTransition> <NoncurrentVersionExpiration> <NoncurrentDays>365</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>

Beispiel 7: Löschen abgelaufener Objektlöschmarkierungen

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öschanforderung 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öschanforderung angeben, löscht Amazon S3 die Objektversion permanent (es wird keine Löschmarkierung erstellt).

  • Ein Löschmarker mit null-aktuellen Versionen wird als die abgelaufener Objektlöschmarker.

Dieses Beispiel zeigt ein Szenario, das ein abgelaufenes Objekt zum Löschen von Markierungen in Ihrem Bucket erstellt und wie Sie können S3-Lebenszyklus Konfiguration zur direkten Amazon S3 um die abgelaufenen Objektlöschen-Markierungen zu entfernen.

Angenommen, Sie schreiben eine Lebenszyklusrichtlinie, die die NoncurrentVersionExpiration-Aktion angibt, um die nicht aktuellen Versionen 30 Tage, nachdem sie nicht aktuell geworden sind, zu löschen, wie nachfolgend gezeigt.

<LifecycleConfiguration> <Rule> ... <NoncurrentVersionExpiration> <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 Lifecycle Policy mit dem Expiration Handlungsaufforderung Amazon S3 um aktuelle Versionen wie im folgenden Beispiel gezeigt zu entfernen.

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

    Amazon S3 entfernt aktuelle Versionen 60 Tage, nachdem sie erstellt wurden, indem eine Löschmarkierung für jede der aktuellen Objektversionen hinzugefügt wird. Damit wird die aktuelle Version wird nicht aktuell, und die Löschmarkierung wird zur aktuellen Version. Weitere Informationen finden Sie im Verwenden von Versioning.

    Anmerkung

    Diese Regel wird automatisch ausgeführt ExpiredObjectDeleteMarker in einer versionierten Schaufel, die Notwendigkeit umfasst, eine ExpiredObjectDeleteMarker Tag unnötig.

    Die NoncurrentVersionExpiration-Aktion in derselben Lebenszykluskonfiguration 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. Sie erhalten Löschmarkierungen für abgelaufene Obekte, aber Amazon S3 erkennt und entfernt 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 die Lebenszykluskonfiguration mit der NoncurrentVersionExpiration-Aktion alle nicht aktuellen Versionen löscht, haben Sie jetzt Löschmarkierungen für abgelaufene Objekte.

    Speziell für dieses Szenario Amazon S3 Lifecycle-Konfiguration bietet eine Expiration Aktion, die Sie anfordern können Amazon S3 um die abgelaufenen Objektlöschen-Markierungen zu entfernen.

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

Indem Sie die ExpiredObjectDeleteMarker Element in das Feld Expiration Aktion, Sie direkt Amazon S3 um abgelaufene Objektlöschmarkierungen zu entfernen.

Anmerkung

Bei Angabe der ExpiredObjectDeleteMarker-Lebenszyklusaktion kann die Regel keinen Tag-basierten Filter angeben.

Beispiel: = 8 Lifecycle-Konfiguration zum Abbrechen mehrerer Upload-Uploads

Sie können die API für mehrteilige Uploads verwenden, um große Objekte in Teilen hochzuladen. Weitere Informationen über mehrteilige Uploads finden Sie unter Überblick über mehrteiligen Upload.

Verwendung S3-Lebenszyklus Konfiguration können Sie direkt Amazon S3 um unvollständige Multipart-Uploads zu stoppen (identifiziert durch das in der Regel angegebene Key Name Präfix), wenn sie nicht innerhalb einer festgelegten Anzahl von Tagen nach Beginn abgeschlossen sind. Wenn Amazon S3 einen mehrteiligen Upload abbricht, werden alle diesem mehrteiligen Upload zugeordneten Teile gelöscht. Damit wird sichergestellt, dass Sie keine unvollständigen mehrteiligen Uploads mit Teilen haben, die in Amazon S3 gespeichert sind, sodass Sie keine Speicherkosten für diese Teile zahlen müssen.

Anmerkung

Bei Angabe der AbortIncompleteMultipartUpload-Lebenszyklusaktion kann die Regel keinen Tag-basierten Filter angeben.

Folgendes Beispiel ist ein Beispiel S3-Lebenszyklus Konfiguration, die eine Regel mit dem AbortIncompleteMultipartUpload Aktion. Diese Aktionsanfragen Amazon S3 um unvollständige Mehrteilige Uploads nach Beginn von sieben Tagen zu beenden.

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