AWS S3 Lifecycle 규칙, 어떤 기준으로 적용될까?
S3 Lifecycle은 객체 자동 정리 및 스토리지 클래스 전환을 통해 비용 효율화(Cost Efficiency)를 달성하는 기능임
객체 상태(Object State), 필터 조건(Filter), 규칙 선택 원칙 세 가지 핵심 개념을 통해 Lifecycle 동작 방식 설명
동일 객체에 여러 규칙 적용 시, 스토리지 비용 절감(Storage Cost Reduction)에 유리한 규칙 우선 적용
운영 팁: 필터 조건 중복 방지, 버저닝 버킷 분리 관리, 삭제 마커 명시적 관리 등을 통해 정책 일관성(Policy Consistency) 확보
S3 Lifecycle 규칙 선택의 핵심 원리
본문에 따르면 S3 Lifecycle 규칙 선택의 핵심은 비용 절감(Cost Reduction)에 있다. 규칙의 순서, 이름, 콘솔 표시 위치는 전혀 고려되지 않으며, 동일 객체에 여러 규칙이 적용될 경우 스토리지 비용을 더 빠르게 줄일 수 있는 동작을 선택한다.
객체 상태(Object State): 현재 버전, 이전 버전, 삭제 마커 등 객체 상태별(Object State)로 규칙 적용
필터 조건(Filter): 접두사(Prefix), 객체 태그(Tag), 접두사 + 태그 조합으로 적용 대상 제한
예시: logs/app.log는 Rule 1(logs/), data/file.csv는 Rule 2(data/), backup/db.bak는 Rule 3(*, 모든 객체)에 적용
필터 조건 중복 시 규칙 적용 방식
글에서는 필터 조건이 겹치는 경우, 가장 구체적인 필터(Specific Filter)를 가진 규칙이 우선 적용된다고 설명한다. 예를 들어, logs/ 접두사를 가진 객체는 Rule 1(logs/)이 Rule 3(*)보다 먼저 적용된다.
Rule 1 (logs/): 90일 후 이전 버전
Rule 3 (*): 60일 후 이전 버전
객체 경로(Object Path) 일치: 객체 경로와 가장 정확히 일치하는 규칙이 먼저 선택
기간(Expiration Period) 무관: 기간이 짧은 규칙이 항상 우선되는 것은 아님
결과적으로, 필터 조건 설계(Filter Condition Design) 시 중복을 최소화하여 예상치 못한 동작을 방지해야 한다.
동일 조건, 다른 기간 규칙의 제약
본문에서는 동일한 상태와 필터 조건을 가진 규칙은 AWS 콘솔 및 CLI에서 생성 자체가 불가능하다고 언급한다. 즉, 중복된 규칙은 S3 Lifecycle에서 허용되지 않는다.
생성 불가 예시: Rule 4(data/, 90일), Rule 5(data/, 180일)
AWS의 설계 의도: 불필요한 혼란을 방지하고, 규칙 관리(Rule Management)의 효율성을 높임
운영 팁: 규칙 설계 시, 중복되는 조건이 없는지 꼼꼼히 검토
결론적으로, S3 Lifecycle 규칙은 명확하고 일관된 정책(Consistent Policy)을 유지하도록 설계되어야 한다.
운영 환경에서의 S3 Lifecycle 설계 팁
글에서는 S3 Lifecycle 규칙 설계 시, 운영 경험을 바탕으로 한 몇 가지 팁을 제시한다.
필터 조건 중복 방지: 규칙 간의 충돌을 최소화하여 예상치 못한 동작 방지
버저닝 버킷 분리 관리: 현재 버전, 이전 버전, 삭제 마커를 별도로 관리하여 데이터 관리(Data Management)의 유연성 확보
삭제 마커 명시적 관리: 삭제 마커에 대한 별도의 규칙을 설정하여 데이터 삭제(Data Deletion) 정책 명확화
규칙 추가 전 검토: 기존 규칙과의 중복 여부를 사전에 검토하여 정책 일관성(Policy Consistency) 유지
결과적으로, S3 Lifecycle은 비용 효율적인 스토리지 관리(Cost-Effective Storage Management)를 위한 강력한 도구이지만, 신중한 설계와 관리가 필요하다.
