S3 수명 주기 구성의 예제
이 섹션에서는 S3 수명 주기 구성의 예를 제공합니다. 각 예제에서는 예제 시나리오별로 XML을 지정하는 방법을 보여줍니다.
주제
예 1: 필터 지정
각 S3 수명 주기 규칙에는 S3 수명 주기 규칙이 적용되는 버킷 내 객체의 하위 집합을 식별하는 데 사용할 수 있는 필터가 포함되어 있습니다. 다음 S3 수명 주기 구성은 필터를 지정하는 방법에 대한 예제입니다.
-
이 S3 수명 주기 구성 규칙에서 필터는 키 접두사(
tax/
)를 지정합니다. 따라서 이 규칙은tax/doc1.txt
및tax/doc2.txt
와 같은 키 이름 접두사tax/
가 있는 객체에 적용됩니다.이 규칙은 Amazon S3에 다음을 수행하도록 지시하는 두 가지 작업을 지정합니다.
-
생성 후 365일(1년)이 지난 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환합니다.
-
생성 후 3,650일(10년)이 지난 객체를 삭제합니다(
Expiration
작업).
<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>
생성 후 객체 기간을 일수로 지정하는 대신 각 작업에 날짜를 지정할 수 있습니다. 하지만 동일한 규칙에서
Date
와Days
를 모두 사용할 수는 없습니다. -
-
S3 수명 주기 규칙을 버킷의 모든 객체에 적용하려면 빈 접두사를 지정합니다. 다음 구성에서 규칙은 생성 후 0일이 지나면 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시하는
Transition
작업을 지정합니다. 이 규칙은 객체를 생성한 후 UTC 자정에 S3 Glacier Flexible Retrieval에 아카이브할 수 있음을 의미합니다. 수명 주기 제한 사항에 대한 자세한 내용은 전환에 대한 제약 조건 및 고려 사항 섹션을 참조하세요.<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>
-
0개 이상의 키 이름 접두사, 0개 이상의 객체 태그를 필터에 지정할 수 있습니다. 다음 예제 코드에서는 키 접두사
tax/
가 있는 객체의 하위 집합과 특정 키 및 값을 가진 태그 두 개가 있는 객체에 S3 수명 주기 규칙을 적용합니다. 둘 이상의 필터를 지정하는 경우 예시와 같이<And>
요소를 포함해야 합니다(Amazon S3가 논리적AND
를 적용하여 지정된 필터 조건을 결합함).... <Filter> <And> <Prefix>tax/</Prefix> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...
-
태그에만 기반을 두어 객체를 필터링할 수 있습니다. 예를 들어, 다음 S3 수명 주기 규칙은 지정된 태그가 두 개인 객체에 적용됩니다(접두사는 지정하지 않음).
... <Filter> <And> <Tag> <Key>key1</Key> <Value>value1</Value> </Tag> <Tag> <Key>key2</Key> <Value>value2</Value> </Tag> </And> </Filter> ...
중요
S3 수명 주기 구성에 규칙이 여러 개인 경우 객체는 같은 날에 여러 가지 S3 수명 주기 작업을 수행할 수 있습니다. 이러한 경우 Amazon S3은 다음과 같은 일반 규칙을 따릅니다.
-
영구 삭제는 전환에 우선합니다.
-
이전은 삭제 마커 생성에 우선합니다.
-
객체에서 S3 Glacier Flexible Retrieval 및 S3 Standard-IA(또는 S3 One Zone-IA) 전환을 모두 사용할 수 있는 경우 Amazon S3가 S3 Glacier 전환을 선택합니다.
예제는 예 5: 중복 필터, 서로 충돌하는 수명 주기 작업 및 Amazon S3가 버전이 지정되지 않은 버킷으로 수행하는 작업을 참조하세요.
예 2: 수명 주기 규칙 사용 중지
S3 수명 주기 규칙을 일시적으로 사용 중지할 수 있습니다. 다음 S3 수명 주기 구성에는 두 가지 규칙을 지정합니다.
-
규칙 1은 객체 생성 직후
logs/
접두사가 있는 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시합니다. -
규칙 2는 객체 생성 직후
documents/
접두사가 있는 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시합니다.
구성에서 규칙 1은 활성화되어 있고 규칙 2는 비활성화되어 있습니다. Amazon S3는 사용 중지된 규칙을 무시합니다.
<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>
예 3: 객체의 수명 주기 동안 스토리지 클래스 티어 다운
이 예제에서는 S3 수명 주기 구성을 사용하여 수명 주기 동안 객체의 스토리지 클래스를 계층 다운합니다. 티어 다운을 사용하면 스토리지 비용을 줄일 수 있습니다. 요금에 대한 자세한 내용은 Amazon S3 요금
다음 S3 수명 주기 구성에서는 키 이름 접두사가 logs/
인 객체에 적용되는 규칙을 지정합니다. 이 규칙은 다음 작업을 지정합니다.
-
두 전환 작업:
-
생성 후 30일이 지난 객체를 S3 Standard-IA 스토리지 클래스로 전환합니다.
-
생성 후 90일이 지난 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환합니다.
-
-
생성 후 1년이 지난 객체를 삭제하도록 Amazon S3에 지시하는 만료 작업 1개
<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>
참고
모든 작업이 필터로 식별된 동일한 객체 집합에 적용되는 경우 한 개의 규칙으로 모든 S3 수명 주기 작업을 설명할 수 있습니다. 또는 각각 다른 필터를 지정하는 여러 규칙을 추가할 수 있습니다.
중요
S3 수명 주기 구성에 규칙이 여러 개인 경우 객체는 같은 날에 여러 가지 S3 수명 주기 작업을 수행할 수 있습니다. 이러한 경우 Amazon S3은 다음과 같은 일반 규칙을 따릅니다.
-
영구 삭제는 전환에 우선합니다.
-
이전은 삭제 마커 생성에 우선합니다.
-
객체에서 S3 Glacier Flexible Retrieval 및 S3 Standard-IA(또는 S3 One Zone-IA) 전환을 모두 사용할 수 있는 경우 Amazon S3가 S3 Glacier 전환을 선택합니다.
예시는 예 5: 중복 필터, 서로 충돌하는 수명 주기 작업 및 Amazon S3가 버전이 지정되지 않은 버킷으로 수행하는 작업 섹션을 참조하세요.
예 4: 여러 규칙 지정
객체마다 다른 S3 수명 주기 작업을 원할 경우 여러 규칙을 지정할 수 있습니다. 다음 S3 수명 주기 구성에는 두 가지 규칙이 있습니다.
-
규칙 1은 키 이름 접두사가
classA/
인 객체에 적용되며, 생성 후 1년이 지난 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하고 10년이 지난 객체를 만료 처리하도록 Amazon S3에 지시합니다. -
규칙 2는 키 이름 접두사가
classB/
인 객체에 적용되며, 생성 후 90일이 지난 객체를 S3 Standard-IA 스토리지 클래스로 전환하고 1년이 지난 객체를 삭제하도록 Amazon S3에 지시합니다.
<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>
중요
S3 수명 주기 구성에 규칙이 여러 개인 경우 객체는 같은 날에 여러 가지 S3 수명 주기 작업을 수행할 수 있습니다. 이러한 경우 Amazon S3은 다음과 같은 일반 규칙을 따릅니다.
-
영구 삭제는 전환에 우선합니다.
-
이전은 삭제 마커 생성에 우선합니다.
-
객체에서 S3 Glacier Flexible Retrieval 및 S3 Standard-IA(또는 S3 One Zone-IA) 전환을 모두 사용할 수 있는 경우 Amazon S3가 S3 Glacier 전환을 선택합니다.
예시는 예 5: 중복 필터, 서로 충돌하는 수명 주기 작업 및 Amazon S3가 버전이 지정되지 않은 버킷으로 수행하는 작업 섹션을 참조하세요.
예 5: 중복 필터, 서로 충돌하는 수명 주기 작업 및 Amazon S3가 버전이 지정되지 않은 버킷으로 수행하는 작업
S3 수명 주기 구성을 지정하여 중복 접두사 또는 작업을 지정할 수 있습니다.
일반적으로 S3 수명 주기는 비용을 최적화합니다. 예를 들어, 두 만료 정책이 겹치는 경우 데이터가 예상보다 오래 저장되지 않도록 더 짧은 만료 정책이 적용됩니다. 마찬가지로, 두 전환 정책이 겹치는 경우 S3 수명 주기는 객체를 더 저렴한 비용의 스토리지 클래스로 전환합니다.
두 경우 모두 S3 수명 주기는 가장 비용이 적게 드는 경로를 선택하려고 시도합니다. 이 일반 규칙의 예외는 S3 Intelligent-Tiering 스토리지 클래스입니다. S3 Intelligent-Tiering은 S3 Glacier Flexible Retrieval 및 S3 Glacier Deep Archive 스토리지 클래스를 제외한 모든 스토리지 클래스보다 S3 수명 주기에서 우선 적용됩니다.
다음 예에서는 Amazon S3가 어떻게 잠재적인 충돌을 해결하는지 보여줍니다.
예 1: 중복 접두사(충돌 없음)
다음에서 예로 든 구성에는 중복 접두사를 지정하는 규칙이 두 개 있습니다.
-
첫 번째 규칙은 버킷의 모든 객체를 의미하는 빈 필터를 지정합니다.
-
두 번째 규칙은 버킷에서 객체의 하위 집합만을 의미하는 키 이름 접두사(
logs/
)를 지정합니다.
규칙 1은 생성 후 1년이 지난 모든 객체를 삭제하도록 Amazon S3에 요청합니다. 규칙 2는 생성 후 30일이 지난 객체의 하위 집합을 S3 Standard-IA 스토리지 클래스로 전환하도록 Amazon S3에 요청합니다.
<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>
이 경우 충돌이 없으므로 Amazon S3는 logs/
접두사가 있는 객체를 생성 후 30일이 지나면 S3 Standard-IA 스토리지 클래스로 전환합니다. 생성 후 1년이 지나면 객체가 삭제됩니다.
예 2: 서로 충돌하는 수명 주기 작업
이 구성 예에는 객체 수명 주기 중 같은 시각에 동일한 객체 집합에 대해 두 가지 작업을 수행하도록 Amazon S3에 지시하는 규칙이 두 개 있습니다.
-
두 규칙은 동일한 키 이름 접두사를 지정하므로, 두 규칙은 동일한 객체 집합에 적용됩니다.
-
두 규칙은, 규칙이 적용될 때 생성 후 365일이 지난 동일한 객체를 지정합니다.
-
한 규칙은 객체를 S3 Standard-IA 스토리지 클래스로 전환하도록 Amazon S3에 지시하고, 이와 동시에 다른 규칙은 객체를 만료 처리하도록 Amazon S3에 지시합니다.
<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>
이 경우 객체가 만료(제거)되기를 원하는 것이므로 스토리지 클래스를 변경하는 것은 의미가 없습니다. 따라서 Amazon S3가 이 객체들에 대해 만료 작업을 선택합니다.
예 3: 중복 접두사로 인해 서로 충돌하는 수명 주기 작업
이 예제에서 구성에는 다음과 같이 중복 접두사를 지정하는 두 가지 규칙이 있습니다.
-
규칙 1은 빈 접두사(모든 객체를 의미)를 지정합니다.
-
규칙 2는 모든 객체의 하위 집합을 식별하는 키 이름 접두사(
logs/
)를 지정합니다.
키 이름 접두사가 logs/
인 객체의 하위 집합에는 두 규칙의 S3 수명 주기 작업이 적용됩니다. 한 규칙은 생성 후 10일이 지난 객체를 전환하도록 Amazon S3에 지시하고, 다른 규칙은 생성 후 365일이 지난 객체를 전환하도록 Amazon S3에 지시합니다.
<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>
이 경우, Amazon S3은 생성 후 10일 지난 객체를 전환하는 쪽을 선택합니다.
예 4: 태그 기반 필터링과 그로 인해 서로 충돌하는 수명 주기 작업
다음과 같이 각각 태그 필터를 지정하는 두 가지 규칙이 있는 S3 수명 주기 구성이 있다고 가정해 보겠습니다.
-
규칙 1은 태그 기반 필터(
tag1/value1
)를 지정합니다. 이 규칙은 생성 후 365일이 지난 객체를 S3 Glacier Flexible Retrieval 스토리지 클래스로 전환하도록 Amazon S3에 지시합니다. -
규칙 2는 태그 기반 필터(
tag2/value2
)를 지정합니다. 이 규칙은 생성 후 14일이 지난 객체를 만료 처리하도록 Amazon S3에 지시합니다.
S3 수명 주기 구성은 다음 예에 나와 있습니다.
<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>
객체에 두 태그가 모두 있는 경우 Amazon S3는 따라야 할 규칙을 결정해야 합니다. 이 경우, Amazon S3은 생성 후 14일 지난 객체를 만료 처리합니다. 객체가 제거되므로 전환 작업이 적용되지 않습니다.
중요
S3 수명 주기 구성에 규칙이 여러 개인 경우 객체는 같은 날에 여러 가지 S3 수명 주기 작업을 수행할 수 있습니다. 이러한 경우 Amazon S3은 다음과 같은 일반 규칙을 따릅니다.
-
영구 삭제는 전환에 우선합니다.
-
이전은 삭제 마커 생성에 우선합니다.
-
객체에서 S3 Glacier Flexible Retrieval 및 S3 Standard-IA(또는 S3 One Zone-IA) 전환을 모두 사용할 수 있는 경우 Amazon S3가 S3 Glacier 전환을 선택합니다.
예시는 예 5: 중복 필터, 서로 충돌하는 수명 주기 작업 및 Amazon S3가 버전이 지정되지 않은 버킷으로 수행하는 작업 섹션을 참조하세요.
예 6: 버전 관리를 사용하는 버킷에 대한 수명 주기 규칙 지정
버전 관리를 사용하는 버킷이 있다고 가정합니다. 즉, 각 객체에 대해 현재 버전과 0 버전 이상의 여러 버전이 있음을 의미합니다. S3 버전 관리에 대한 자세한 내용은 S3 버킷에서 버전 관리 사용 섹션을 참조하세요. 이 예에서는 기록을 1년 동안 유지하고 최신이 아닌 버전을 삭제하려고 합니다. S3 수명 주기 구성은 모든 객체의 1~100개 버전을 유지할 수 있도록 지원합니다.
스토리지 비용을 절약하기 위해 최신이 아닌 버전이 된 후 30일 후에 S3 Glacier Flexible Retrieval로 이전 버전을 이동하려고 합니다(이러한 최신이 아닌 객체가 실시간 액세스가 필요 없는 콜드 데이터라고 가정). 뿐만 아니라 생성 후 90일이 지나면 최신 버전에 대한 액세스 빈도가 감소할 것을 예상하여 해당 객체를 S3 Standard-IA 스토리지 클래스로 이동하는 쪽을 선택할 수 있습니다.
<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>
예제 7: 만료된 객체 삭제 마커의 제거
버전 관리를 사용하는 버킷에는 최신 버전의 객체 1개와 각 객체에 대한 0개 이상의 비 최신 버전이 존재합니다. 객체를 삭제할 때는 다음 사항에 유의하세요.
-
삭제 요청에서 버전 ID를 지정하지 않는 경우, Amazon S3에서는 그 객체를 삭제하는 대신 삭제 마커를 추가합니다. 최신 객체 버전이 최신이 아닌 버전이 되고 삭제 마커가 최신 버전이 됩니다.
-
삭제 요청에서 버전 ID를 지정하는 경우, Amazon S3에서는 그 객체 버전을 영구적으로 삭제합니다(삭제 마커는 생성되지 않음).
-
최신이 아닌 버전이 없는 삭제 마커는 만료된 객체 삭제 마커라고 부릅니다.
이 예제에서는 버킷에 만료된 객체 삭제 마커를 생성할 수 있는 시나리오와 S3 수명 주기 구성을 사용해 만료된 객체 삭제 마커를 제거하도록 Amazon S3에 지시하는 방법을 보여줍니다.
다음 예와 같이 NoncurrentVersionExpiration
작업을 사용하여 최신이 아닌 버전이 된 후 30일이 지나면 제거하고 최대 10개의 최신이 아닌 버전을 유지하는 S3 수명 주기 구성을 작성한다고 가정합니다.
<LifecycleConfiguration> <Rule> ... <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
NoncurrentVersionExpiration
작업은 현재 객체 버전에는 적용되지 않습니다. 최신이 아닌 버전만 제거합니다.
최신 객체 버전의 경우 최신 객체 버전이 잘 정의된 수명 주기를 따르는지 여부에 따라 수명 주기를 관리할 수 있는 옵션이 다음과 같이 제공됩니다.
-
최신 객체 버전은 잘 정의된 수명 주기를 따릅니다.
이 경우 다음 예시와 같이 Amazon S3에 최신 버전을 제거하도록 지시하는
Expiration
작업과 함께 S3 수명 주기 구성을 사용할 수 있습니다.<LifecycleConfiguration> <Rule> ... <Expiration> <Days>60</Days> </Expiration> <NoncurrentVersionExpiration> <NewerNoncurrentVersions>10</NewerNoncurrentVersions> <NoncurrentDays>30</NoncurrentDays> </NoncurrentVersionExpiration> </Rule> </LifecycleConfiguration>
이 예에서 Amazon S3가 최신 버전의 객체 각각에 삭제 마커를 추가함으로써 생성된 후 60일이 지난 최신 버전을 제거합니다. 이 프로세스를 통해 최신 버전이 최신이 아닌 버전이 되고 삭제 마커가 최신 버전이 됩니다. 자세한 내용은 S3 버킷에서 버전 관리 사용 단원을 참조하십시오.
참고
동일한 규칙에
Days
및ExpiredObjectDeleteMarker
태그를 모두 지정할 수는 없습니다.Days
태그를 지정하면 삭제 마커의 기간이 사용 기간 기준을 충족할 때 Amazon S3가 자동으로ExpiredObjectDeleteMarker
정리를 수행합니다. 삭제 마커가 유일한 버전이 되는 즉시 정리하려면ExpiredObjectDeleteMarker
태그만 있는 별도의 규칙을 생성합니다.동일한 S3 수명 주기 구성의
NoncurrentVersionExpiration
작업은 최신 버전이 아닌 30일이 지난 객체를 제거합니다. 따라서 이 예제에서는 객체 생성 후 90일이 지나면 모든 객체 버전이 영구적으로 제거됩니다. 만료된 객체 삭제 마커는 이 과정에서 생성되지만 Amazon S3에서 만료된 객체 삭제 마커를 자동 감지하여 제거합니다. -
객체의 최신 버전은 잘 정의된 수명 주기를 따르지 않습니다.
이 경우 객체가 필요 없는 경우 1개 이상의 최신이 아닌 버전에 삭제 마커를 생성하여 수동으로 객체를 제거할 수 있습니다. S3 수명 주기 구성에
NoncurrentVersionExpiration
작업을 사용하여 최신이 아닌 버전을 모두 제거하면 만료된 객체 삭제 마커가 생깁니다.특히 이 시나리오의 경우 S3 수명 주기 구성은 만료된 객체 삭제 마커를 제거하는 데 사용할 수 있는
Expiration
작업을 제공합니다.<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>
Expiration
작업에서 ExpiredObjectDeleteMarker
요소를 true
로 설정하여 Amazon S3에 만료된 객체 삭제 마커를 제거하도록 지시합니다.
참고
ExpiredObjectDeleteMarker
S3 수명 주기 작업을 사용하면 이 규칙은 태그 기반 필터를 지정할 수 없습니다.
예 8: 멀티파트 업로드 중단을 위한 수명 주기 구성
Amazon S3 멀티파트 업로드 REST API 작업을 사용하여 대형 객체를 여러 부분으로 나누어 업로드할 수 있습니다. 멀티파트 업로드에 대한 자세한 내용은 멀티파트 업로드를 사용한 객체 업로드 및 복사 섹션을 참조하십시오.
멀티파트 업로드가 시작된 후 지정된 일수 내에 완료되지 않은 경우 S3 수명 주기 구성을 사용하여 미완료 멀티파트 업로드(규칙에 지정된 키 이름 접두사로 식별)를 중단하도록 Amazon S3에 지시할 수 있습니다. Amazon S3가 멀티파트 업로드를 중단할 때 멀티파트 업로드와 관련된 모든 부분을 삭제합니다. 이 프로세스는 Amazon S3에 저장된 부분으로 불완전한 멀티파트 업로드가 없도록 하여 스토리지 비용을 조정하는 데 도움이 됩니다.
참고
AbortIncompleteMultipartUpload
S3 수명 주기 작업을 사용하면 이 규칙은 태그 기반 필터를 지정할 수 없습니다.
다음은 AbortIncompleteMultipartUpload
작업으로 규칙을 지정하는 S3 수명 주기 구성의 예시입니다. 이 작업은 시작 후 7일이 지나면 미완료된 멀티파트 업로드를 중단하도록 Amazon S3에 지시합니다.
<LifecycleConfiguration> <Rule> <ID>sample-rule</ID> <Filter> <Prefix>
SomeKeyPrefix
/</Prefix> </Filter> <Status>rule-status
</Status> <AbortIncompleteMultipartUpload> <DaysAfterInitiation>7</DaysAfterInitiation> </AbortIncompleteMultipartUpload> </Rule> </LifecycleConfiguration>
예 9: 크기 기반 규칙을 사용한 수명 주기 구성
크기만 기준으로 객체를 전환하는 규칙을 생성할 수 있습니다. 최소 크기(ObjectSizeGreaterThan
) 또는 최대 크기(ObjectSizeLessThan
)를 지정하거나 객체 크기 범위를 바이트 단위로 지정할 수 있습니다. 접두사 및 크기 규칙과 같은 필터를 여러 개 사용하는 경우 <And>
요소로 필터를 묶어야 합니다.
<LifecycleConfiguration> <Rule> <ID>Transition with a prefix and based on size</ID> <Filter> <And> <Prefix>tax/</Prefix> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> </And> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
ObjectSizeGreaterThan
요소와 ObjectSizeLessThan
요소를 둘 다 사용하여 범위를 지정하는 경우 최대 객체 크기가 최소 객체 크기보다 커야 합니다. 둘 이상의 필터를 사용하는 경우 <And>
요소로 필터를 묶어야 합니다. 다음 예에서는 500~64,000바이트 범위의 객체를 지정하는 방법을 보여 줍니다. 범위를 지정하는 경우 ObjectSizeGreaterThan
및 ObjectSizeLessThan
필터는 지정된 값을 제외합니다. 자세한 내용은 필터 요소 단원을 참조하십시오.
<LifecycleConfiguration> <Rule> ... <And> <ObjectSizeGreaterThan>500</ObjectSizeGreaterThan> <ObjectSizeLessThan>64000</ObjectSizeLessThan> </And> </Rule> </LifecycleConfiguration>
버전 관리를 사용하는 버킷에서 만든 비최신 삭제 마커 객체를 포함하여 데이터가 없는 비최신 객체를 특별히 만료시키는 규칙을 만들 수도 있습니다. 다음 예시에서는 NoncurrentVersionExpiration
작업을 사용하여 비최신 버전이 된 후 30일이 지나면 제거하고 객체의 비최신 버전을 최대 10개까지 보존합니다. 또한 ObjectSizeLessThan
요소를 사용하여 데이터가 없는 객체만 필터링합니다.
<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>
예제: 128KB 미만의 객체 전환 허용
Amazon S3는 128KB 미만의 객체가 스토리지 클래스로 전환되지 않도록 하는 기본 동작을 수명 주기 구성에 적용합니다. 구성에 더 작은 크기를 지정하는 최소 크기(ObjectSizeGreaterThan
) 또는 최대 크기(ObjectSizeLessThan
) 필터를 추가하여 더 작은 객체가 전환되도록 할 수 있습니다. 다음 예제에서는 128KB보다 작은 객체의 S3 Glacier Instant Retrieval 스토리지 클래스 전환을 허용합니다.
<LifecycleConfiguration> <Rule> <ID>Allow small object transitions</ID> <Filter> <ObjectSizeGreaterThan>1</ObjectSizeGreaterThan> </Filter> <Status>Enabled</Status> <Transition> <Days>365</Days> <StorageClass>GLACIER_IR</StorageClass> </Transition> </Rule> </LifecycleConfiguration>
참고
2024년 9월 Amazon S3는 소형 객체의 기본 전환 동작을 다음과 같이 업데이트했습니다.
기본 전환 동작 업데이트 - 2024년 9월부터 기본 동작은 128KB 미만의 객체가 스토리지 클래스로 전환되는 것을 금지합니다.
이전의 기본 전환 동작 - 2024년 9월 이전에는 128KB 미만의 객체를 S3 Glacier 및 S3 Glacier Deep Archive 스토리지 클래스로는 전환할 수 있었습니다.
2024년 9월 이전에 생성된 구성은 수정하지 않는 한 이전 전환 동작을 유지합니다. 즉, 규칙을 생성, 편집 또는 삭제하면 구성의 기본 전환 동작이 업데이트된 동작으로 변경됩니다. 사용 사례에 필요한 경우 128KB 미만의 객체가 S3 Glacier 및 S3 Glacier Deep Archive로 전환되도록 기본 전환 동작을 변경할 수 있습니다. 이렇게 하려면 PutBucketLifecycleConfiguration 요청에서 선택적 x-amz-transition-object-size-minimum-default
헤더를 사용하세요.
다음 예제는 PutBucketLifecycleConfiguration 요청에서 x-amz-transition-object-size-minimum-default
헤더를 사용하여 수명 주기 구성에 varies_by_storage_class
기본 전환 동작을 적용하는 방법을 보여줍니다. 이 동작을 통해 128KB보다 작은 객체를 S3 Glacier 또는 S3 Glacier Deep Archive 스토리지 클래스로 전환할 수 있습니다. 기본적으로 다른 모든 스토리지 클래스는 128KB 미만의 전환을 허용하지 않습니다. 그래도 사용자 지정 필터를 사용하여 모든 스토리지 클래스의 최소 전환 크기를 변경할 수 있습니다. 사용자 지정 필터는 항상 기본 전환 동작보다 우선합니다.
HTTP/1.1 200 x-amz-transition-object-size-minimum-default: varies_by_storage_class <?xml version="1.0" encoding="UTF-8"?> ...