개요
2022.04.24-[S3] 수명 주기(Life Cycle) 적용/확인에서 S3 비용 및 데이터 수명 주기 최적화를 위해 S3 수명 주기 규칙을 적용했었다. S3는 버킷 당 최대 1000개의 수명 주기 규칙을 적용할 수 있는데, 이번 글에서는 규칙의 대상이 서로 겹치는 등의 경우에 어떻게 처리되는지를 적어두려고 한다.
기본 적용 규칙
일반적으로 S3 수명 주기는 비용을 최적화하는 방향으로 적용된다. 예로 들어 두 개의 객체 만료 정책이 서로 겹치는 경우 더 짧은 만료 정책을 적용하며, 두 개의 스토리지 클래스 전환 정책이 서로 겹치는 경우 더 저렴한 스토리지 클래스로 전환하는 규칙을 적용한다.
다만, S3 Intelligent-Tiering 전환 정책은 S3 Glacier Flexible Retrieval 및 S3 Glacier Deep Archive을 제외하고는 모든 스토리지클래스 전환 정책에 대해 높은 우선순위를 가진다.
예시
각 경우의 수에 대해 정리해 보자.
1. 중복 접두사
| 대상 | 작업 | |
| 규칙 1 | 버킷 내 전체 객체 | Objects uploaded -> Day 365 : Objects expire |
| 규칙 2 | /logs | Objects uploaded -> Day 30 : STANDARD_IA |
규칙이 다음과 같이 구성되어 있는 경우, /logs 하위에 위치한 객체는 Objects uploaded -> Day 30 : STANDARD_IA -> Day 365 : Objects expire으로 처리된다.
2. 서로 충돌하는 작업
| 대상 | 작업 | |
| 규칙 1 | /logs | Objects uploaded -> Day 365 : Objects expire |
| 규칙 2 | /logs | Objects uploaded -> Day 365 : STANDARD_IA |
두 규칙은 서로 동일한 대상에 대해 다른 작업을 하게끔 구성되어 있다. 이 경우, 객체를 STANDARD_IA로 전환하는 것은 무의미하기 때문에 객체는 만료된다.
3. 서로 충돌하는 중복 접두사
| 대상 | 작업 | |
| 규칙 1 | 버킷 내 전체 객체 | Objects uploaded -> Day 10 : STANDARD_IA |
| 규칙 2 | /logs | Objects uploaded -> Day 365 : STANDARD_IA |
이 경우는 버킷 내 전체 객체를 대상으로 하는 규칙보다 /logs 하위 객체 대상의 규칙의 스토리지클래스 전환 시점이 더 늦게 구성된 모습이다. 이때는 /logs 하위도 규칙 1에 따라 Objects uploaded -> Day 10 : STANDARD_IA로 작업이 이루어진다.
결과적으로 버킷 내 전체 객체 대상 규칙은 다른 특정 객체 대상 규칙보다 항상 전환일/만료일이 길게 지정해야 한다.
실제 사례
다음과 같이 구성된 S3 수명주기 규칙이 어떻게 동작하는지 적어둔다.
| 대상 | 작업 | |
| 규칙 1 | 버킷 내 전체 객체 | Objects uploaded -> Day 0 : Intelligent-Tiering -> Day 150 : Glacier Flexible Retrieval |
| 규칙 2 | /logs | Objects uploaded -> Day 100 : Glacier Flexible Retrieval |
이 때 /logs 하위 객체는 Objects uploaded -> Day 0 : Intelligent-Tiering -> Day 100 : Glacier Flexible Retrieval로 전환된다.
참고 문서