라이프사이클 한눈 정리 — S3 자동 관리 5편

이 글은 Amazon S3 심화 정리 시리즈의 다섯 번째 편이고, 주제는 라이프사이클입니다. 1편에서 객체 스토리지의 기본기를 잡았고, 2편 보안, 3편 성능, 4편 복제까지 지나왔다면 이번 라이프사이클 편은 — 데이터 자체의 시간 관리 차원이에요. 객체가 처음 만들어진 순간부터, 자주 쓰이다가 점점 식어가고, 결국 아카이브로 옮겨지거나 삭제되는 그 흐름 전체를 자동화하는 단원입니다.

핵심 키워드 한 줄 — 라이프사이클은 "자료 보관 자동 관리 위탁" 입니다. 30일 후 창고로 옮겨라, 1년 후 폐기해라, 같은 규칙을 미리 걸어 두면 사람이 손대지 않아도 S3가 알아서 객체를 이동시키고 지웁니다. 공식 문서는 S3 사용자 가이드 의 Lifecycle 섹션이 가장 정확하니 한 번 옆에 띄워 놓고 읽으면 좋아요.

라이프사이클이 처음엔 왜 어렵게 느껴질까요

이유는 세 가지예요.

첫째, "규칙"이 너무 여러 갈래로 갈라집니다. 전환 규칙, 만료 규칙, 현재 버전 규칙, 이전 버전 규칙, 삭제 마커 정리 규칙, 미완료 멀티파트 정리 규칙 — 한 라이프사이클 정책 안에 이 모든 게 동시에 들어갈 수 있어서, 처음 JSON을 보면 "어디서 어디까지가 한 규칙이지?" 싶어집니다.

둘째, Intelligent-Tiering과 헷갈립니다. 둘 다 "오래된 객체를 저렴한 계층으로 옮기는" 일을 하는데, 자동 관찰형(IT) vs 정해진 시점에 옮기는 라이프사이클 형 차이가 직관에 안 옵니다.

셋째, 최소 저장 기간 함정이 깔려 있습니다. 라이프사이클로 부지런히 Glacier로 옮겼는데, 정작 더 비싸지는 경우가 생기거든요.

해결법은 한 가지예요. 라이프사이클을 "자료 보관 자동 관리 위탁"이라는 비유로 잡고, 전환은 "책상 → 캐비닛 → 외부 창고", 만료는 "정해진 날짜에 폐기", Intelligent-Tiering은 "관찰자가 알아서 옮김" — 이렇게 그림으로 잡으면 갑자기 깔끔해집니다. 이 글은 그 비유를 끝까지 따라갑니다.

라이프사이클 정책이 도대체 뭔가요

라이프사이클 정책(Lifecycle Policy) 은 S3 버킷 안 객체를 자동으로 관리하기 위한 규칙 모음이에요. 한 줄로 풀면 — "이런 조건에 들어맞는 객체는, 며칠 뒤 이렇게 처리해라" 라는 명령서를 버킷에 미리 붙여 놓는 거예요.

회사 비유로 풀면 — 자료실 운영을 외부 업체에 위탁한다고 생각해 보세요. 위탁 계약서에 이렇게 적습니다.

• "신규 자료는 30일 동안 책상 옆 칸에 둔다"
• "30일이 지나면 사무실 캐비닛으로 옮긴다"
• "90일이 지나면 외부 창고로 옮긴다"
• "1년이 지나면 폐기한다"

이렇게 한 번 적어 두면, 직원이 매번 자료를 옮기거나 버릴 필요가 없어요. 위탁 업체가 날짜 보고 알아서 처리합니다. S3 라이프사이클이 정확히 그 역할이에요.

라이프사이클이 할 수 있는 작업은 크게 두 가지로 갈립니다.

작업 종류	비유	기능
전환(Transition)	책상 → 캐비닛 → 창고 자동 이동	객체를 더 저렴한 스토리지 클래스로 이동
만료(Expiration)	정해진 날 폐기	객체 자동 삭제 또는 버전 만료 처리

이 둘이 라이프사이클의 양대 기둥입니다. 그리고 각 기둥 아래에 "현재 버전 / 이전 버전 / 삭제 마커 / 미완료 멀티파트" 같은 세부 가지가 붙어요.

라이프사이클 정책 자체는 무료입니다. 정책을 거는 비용은 없고, 정책이 작동하면서 발생하는 전환 요청 비용·저장 비용 변화만 있어요.

> 한 줄 정리 — 라이프사이클 = 객체 수명 자동 관리 위탁 계약서. 전환(이동)과 만료(삭제) 두 갈래.

전환 규칙 — 책상에서 창고로 자동 이동

전환 규칙은 객체를 더 저렴한 스토리지 클래스로 자동 이동시키는 규칙이에요. 책상 옆 자료(Standard)를 시간이 지나면 캐비닛(Standard-IA)으로, 또 시간이 지나면 외부 창고(Glacier)로 옮기는 식입니다.

전환 경로 — 한 방향으로만 흐른다

라이프사이클 전환은 냉수가 흐르는 방향처럼 한쪽으로만 흘러요. 자주 접근(따뜻한) 클래스에서 거의 안 보는(차가운) 클래스로만 자동 이동합니다.

S3 Standard
    ↓ (30일 이후)
S3 Standard-IA 또는 S3 One Zone-IA
    ↓ (추가 60일 이후)
S3 Glacier Instant Retrieval
    ↓ (추가 기간 이후)
S3 Glacier Flexible Retrieval
    ↓ (추가 기간 이후)
S3 Glacier Deep Archive

여기서 시험 함정이 하나 있어요. 역방향 전환(차가운 → 따뜻한)은 라이프사이클로 자동 처리되지 않습니다. 예를 들어 "Glacier에 있던 객체를 Standard로 다시 올려라"는 라이프사이클 규칙으로는 안 돼요. 이건 수동으로 복사(또는 복원 후 재업로드) 만 가능합니다.

이게 직관에 살짝 어긋나는 부분인데, 이유는 단순해요. 라이프사이클의 본래 목적이 "오래된 데이터를 자동으로 더 저렴하게 보관" 이라서, 비싼 곳으로 거꾸로 올리는 자동화는 제공하지 않는 겁니다.

전환 최소 기간 요건

여기가 시험에 자주 나오는 함정이에요. 클래스 간 전환에는 최소 기간 요건이 있습니다.

전환 대상	최소 기간 요건
Standard → Standard-IA	30일 이상
Standard → One Zone-IA	30일 이상
Standard → Intelligent-Tiering	30일 이상
Standard → Glacier Instant	90일 이상
Any → Glacier Flexible	제한 없음
Any → Glacier Deep Archive	제한 없음

여기서 시험 함정이 하나 있어요. Standard에서 Glacier Instant로 가려면 90일을 채워야 합니다. "어 30일 만에 바로 Glacier Instant로 보내자" 같은 규칙은 만들 수 없어요. 반면 Glacier Flexible과 Deep Archive는 곧장 보낼 수 있습니다 — 0일짜리 규칙도 가능해요.

전환 규칙 JSON 예시

실제 JSON으로 어떻게 생겼는지 한 번 보고 가요. logs/ 접두사로 들어오는 모든 객체에 대해 30일 → IA, 90일 → Glacier, 180일 → Deep Archive로 단계별로 옮기는 규칙입니다.

{
    "Rules": [
        {
            "ID": "TransitionToIA",
            "Status": "Enabled",
            "Filter": {"Prefix": "logs/"},
            "Transitions": [
                {
                    "Days": 30,
                    "StorageClass": "STANDARD_IA"
                },
                {
                    "Days": 90,
                    "StorageClass": "GLACIER"
                },
                {
                    "Days": 180,
                    "StorageClass": "DEEP_ARCHIVE"
                }
            ]
        }
    ]
}

읽는 법 — Rules 안에 규칙 여러 개가 들어가고, 각 규칙은 ID(규칙 이름), Status(켜짐/꺼짐), Filter(어떤 객체에 적용), Transitions(언제 어디로 옮길지) 로 구성돼요. Days는 객체가 만들어진 날부터 며칠 뒤 입니다.

만료 규칙 — 정해진 날 자료 폐기

만료 규칙은 객체를 자동으로 삭제하는 규칙이에요. 전환이 "이동"이라면 만료는 "폐기"입니다. 회사 비유로 — 1년 지난 회의록은 자동 폐기, 7일 지난 임시 자료는 자동 폐기, 같은 규정이에요.

만료 규칙은 적용 대상에 따라 네 갈래로 갈라집니다. 처음엔 헷갈리지만 한 번 정리하면 단순해요.

1. 현재 버전 만료 (Current Version Expiration)

활성 버전(가장 최신 버전) 의 객체를 지정 기간 후 영구 삭제합니다. 가장 흔히 쓰는 만료 규칙이에요.

{
    "ID": "ExpireOldObjects",
    "Status": "Enabled",
    "Filter": {"Prefix": "temp/"},
    "Expiration": {
        "Days": 30
    }
}

temp/ 접두사로 들어온 객체는 30일 뒤 자동 삭제하는 규칙입니다.

2. 이전 버전 만료 (Noncurrent Version Expiration)

버전 관리가 켜진 버킷에서 — 이전 버전(noncurrent) 만 삭제합니다. 최신 버전은 그대로 두고 옛날 버전들을 정리하는 거예요.

{
    "ID": "CleanOldVersions",
    "Status": "Enabled",
    "Filter": {"Prefix": ""},
    "NoncurrentVersionExpiration": {
        "NoncurrentDays": 90,
        "NewerNoncurrentVersions": 3
    }
}

이게 시험에 자주 나와요. 두 옵션이 같이 들어가는데 — NoncurrentDays는 "이전 버전이 된 후 며칠 지나면 삭제", NewerNoncurrentVersions는 "최신 N개 이전 버전은 무조건 보존" 입니다. 위 예시는 "이전 버전이 된 후 90일이 지나면 삭제하되, 최신 3개 이전 버전은 그래도 살려둬라" 라는 뜻이에요.

여기서 시험 함정이 하나 있어요. 1편에서 봤던 버전 관리 비용 폭탄을 통제하는 핵심 도구가 바로 이 규칙입니다. 버전 관리만 켜고 라이프사이클을 안 걸면, 이전 버전이 무한히 쌓이면서 저장 비용이 무서워져요.

3. 삭제 마커 만료 (Expired Object Delete Markers)

버전 관리 버킷에서 객체를 삭제하면 — 1편에서 봤듯 — 데이터가 사라지는 게 아니라 "삭제 마커"가 새 버전으로 추가돼요. 그런데 이전 버전들이 라이프사이클로 다 정리되고 나면, 삭제 마커만 외롭게 남는 상황이 생깁니다. 이걸 자동으로 청소해 주는 규칙이에요.

{
    "ID": "CleanDeleteMarkers",
    "Status": "Enabled",
    "Filter": {"Prefix": ""},
    "Expiration": {
        "ExpiredObjectDeleteMarker": true
    }
}

여기서 시험 함정이 하나 있어요. "만료된 삭제 마커"의 정의가 "다른 버전 없이 혼자 남은 삭제 마커" 입니다. 다른 버전이 같이 있으면 이 규칙에 안 걸려요. 이전 버전 만료 규칙과 짝으로 걸어 둬야 효과가 제대로 납니다.

4. 미완료 멀티파트 업로드 정리

이게 의외로 많은 사람이 놓치는 함정 자리예요. 3편(성능)에서 봤던 멀티파트 업로드는 — 큰 파일을 여러 조각으로 쪼개 보내고, 마지막에 "complete" 호출로 합치는 방식이에요. 그런데 complete 호출이 안 되고 중간에 끊긴 멀티파트 업로드는, 그 조각들(parts)이 버킷 안에 그대로 남아 있으면서 저장 비용을 발생시킵니다.

회사 비유로 — 이사 중간에 떨어뜨린 박스가 창고 한쪽에 계속 쌓이는 식이에요. 누가 청소하지 않으면 점점 자리를 차지합니다. 이걸 자동으로 청소하는 규칙입니다.

{
    "ID": "CleanIncompleteUploads",
    "Status": "Enabled",
    "Filter": {"Prefix": ""},
    "AbortIncompleteMultipartUpload": {
        "DaysAfterInitiation": 7
    }
}

DaysAfterInitiation은 "멀티파트 업로드가 시작된 후 며칠이 지나도 완료되지 않으면 버려라" 입니다. 모든 버킷에 7일 정도로 거의 무조건 걸어 두는 게 정석이에요. 안 걸어 두면 보이지 않는 곳에서 비용이 새고 있을 수 있습니다.

> 한 줄 정리 — 만료 규칙은 네 갈래. 현재 버전 / 이전 버전 / 외로운 삭제 마커 / 미완료 멀티파트. 마지막 미완료 멀티파트 정리는 모든 버킷에 거는 게 좋다.

라이프사이클 필터 — 어떤 객체에 적용할지

라이프사이클 규칙은 그냥 버킷 전체에 무차별로 거는 게 아니라, 필터(Filter) 로 적용 대상을 좁힐 수 있어요. 회사 비유로 — "마케팅 부서 자료만 30일 뒤 창고로", "기밀 라벨 붙은 자료만 1년 뒤 폐기" 같은 세부 규정 만드는 거랑 비슷합니다.

필터는 네 가지 기준을 쓸 수 있어요.

접두사 기반 필터 (Prefix)

{"Filter": {"Prefix": "archive/2023/"}}

archive/2023/로 시작하는 객체에만 적용. 가장 자주 쓰는 필터예요. 1편에서 본 것처럼 S3는 평면 구조라 사실 폴더는 없지만, 접두사로 폴더처럼 묶여 있는 객체들을 한꺼번에 처리할 수 있어요.

태그 기반 필터 (Tag)

{
    "Filter": {
        "Tag": {
            "Key": "Status",
            "Value": "Archived"
        }
    }
}

Status=Archived 태그가 붙은 객체에만 적용. 1편에서 객체 태그 다룰 때 "수명 주기 정책 적용에 쓴다"고 했던 게 바로 이 자리예요.

크기 기반 필터 (Object Size)

{
    "Filter": {
        "ObjectSizeGreaterThan": 1048576,
        "ObjectSizeLessThan": 1073741824
    }
}

객체 크기가 1MB(1,048,576바이트) 이상이고 1GB(1,073,741,824바이트) 이하인 것에만 적용. 자잘한 파일은 전환하면 오히려 비용이 늘 수 있어서, 일정 크기 이상만 옮길 때 씁니다.

복합 필터 (And 조건)

여러 조건을 모두 만족해야 할 때는 And로 묶어요.

{
    "Filter": {
        "And": {
            "Prefix": "data/",
            "Tags": [
                {"Key": "Archive", "Value": "true"}
            ],
            "ObjectSizeGreaterThan": 1024
        }
    }
}

data/ 접두사 + Archive=true 태그 + 1KB 초과 — 이 세 조건을 동시에 만족하는 객체만 적용. 여기서 시험 함정이 하나 있어요. 여러 조건을 그냥 나란히 쓰면 안 되고 반드시 And 안에 넣어야 합니다. And가 없으면 단일 조건 필터로 인식돼요.

통합 예시 — 한 규칙 안에 다 넣기

이제 한 규칙 안에 전환·만료·이전 버전 처리·미완료 멀티파트 정리를 모두 묶은 진짜 실전 예시를 봅니다. logs/ 접두사 객체 전체에 대해 다음을 한꺼번에 처리하는 정책이에요.

• 30일 후 Standard-IA로 전환
• 90일 후 Glacier로 전환
• 365일 후 영구 삭제
• 이전 버전은 30일 후 Glacier로 전환
• 이전 버전은 90일 후 영구 삭제
• 7일 넘은 미완료 멀티파트 자동 정리

{
    "Rules": [
        {
            "ID": "LogsLifecycle",
            "Status": "Enabled",
            "Filter": {"Prefix": "logs/"},
            "Transitions": [
                {"Days": 30, "StorageClass": "STANDARD_IA"},
                {"Days": 90, "StorageClass": "GLACIER"}
            ],
            "Expiration": {
                "Days": 365
            },
            "NoncurrentVersionTransitions": [
                {"NoncurrentDays": 30, "StorageClass": "GLACIER"}
            ],
            "NoncurrentVersionExpiration": {
                "NoncurrentDays": 90
            },
            "AbortIncompleteMultipartUpload": {
                "DaysAfterInitiation": 7
            }
        }
    ]
}

규칙 한 개 안에 여섯 개 종류의 처리가 다 들어 있어요. 이게 라이프사이클의 강점입니다. 한 객체 그룹에 대한 수명 전체를 한 규칙으로 표현할 수 있어요.

CLI로 거는 법은 다음과 같습니다.

# JSON 파일로 정책 저장 후 적용
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration file://lifecycle-policy.json

# 라이프사이클 정책 조회
aws s3api get-bucket-lifecycle-configuration --bucket my-bucket

# 라이프사이클 정책 삭제
aws s3api delete-bucket-lifecycle --bucket my-bucket

날짜 기반 규칙 — 며칠 뒤가 아니라 정해진 날에

지금까지 본 규칙은 다 "객체 생성 후 며칠" 기준이었어요. 그런데 가끔 — 특정 날짜를 못 박아 두고 처리하고 싶을 때가 있습니다. 예를 들어 "2024년 12월 31일까지 모든 자료를 Glacier로 옮기고, 2025년 12월 31일에 모두 폐기" 같은 규정이요.

이럴 땐 Date 키를 씁니다.

{
    "Rules": [
        {
            "ID": "ArchiveByDate",
            "Status": "Enabled",
            "Filter": {"Prefix": ""},
            "Transitions": [
                {
                    "Date": "2024-12-31T00:00:00.000Z",
                    "StorageClass": "GLACIER"
                }
            ],
            "Expiration": {
                "Date": "2025-12-31T00:00:00.000Z"
            }
        }
    ]
}

여기서 시험 함정이 하나 있어요. Days와 Date는 한 규칙 안에서 동시에 못 씁니다. 둘 중 하나만 골라야 해요. 그리고 Date는 한 번 지나면 그 규칙은 그날 이후로 작동을 안 해요. 그래서 보통 — 정기적인 데이터 관리는 Days, 일회성 마이그레이션·법적 보존 만료일 같은 건 Date로 갈라 씁니다.

Intelligent-Tiering — 자동 관찰 후 이동

여기가 4편(스토리지 클래스)과 약간 겹치면서도 다른 자리예요. 1편·4편에서 Intelligent-Tiering(IT)을 "접근 패턴에 따라 자동으로 등급 조정해 주는 클래스"라고 봤었죠. 그럼 라이프사이클이랑 뭐가 다르냐 — 이게 시험 단골 질문이에요.

라이프사이클 vs Intelligent-Tiering

비교 항목	라이프사이클	Intelligent-Tiering
결정 기준	정해진 시점(N일 후)	실제 접근 패턴(미접근 기간)
작동 방식	규칙 기반 자동 이동	AWS가 관찰 후 자동 이동
추가 비용	정책 자체 무료	객체당 월 $0.0025 모니터링비
양방향 이동	한 방향만	자주 쓰면 다시 위로 올라감
예측 가능성	매우 명확	패턴에 따라 다름

회사 비유로 풀면 — 라이프사이클은 "30일 지난 자료는 무조건 창고로 옮긴다" 라는 정해진 규정이고, Intelligent-Tiering은 "한 달 동안 아무도 안 본 자료는 창고로, 갑자기 다시 보면 책상으로" 라는 살아있는 관찰자가 일하는 시스템이에요.

여기서 시험 함정이 하나 있어요. 접근 패턴이 예측 불가능하면 IT, 패턴이 일정하면 라이프사이클이 정답입니다. 그리고 IT는 자주 접근하면 다시 Frequent 계층으로 자동 승격되지만, 라이프사이클로 Glacier에 떨어진 객체는 자주 쓰여도 자동으로 다시 안 올라와요. 이게 둘의 본질적인 차이입니다.

Intelligent-Tiering 계층 구조

IT 안에 5개 계층이 있어요. 처음 두 개는 기본 활성, 나머지 세 개는 선택 활성화입니다.

Frequent Access Tier (기본, Standard 요금)
    ↕ (30일 미접근)
Infrequent Access Tier (Standard-IA 요금)
    ↕ (90일 미접근, 선택 활성화)
Archive Instant Access Tier (Glacier Instant 요금)
    ↕ (90~730일 미접근, 선택 활성화)
Archive Access Tier (Glacier Flexible 요금)
    ↕ (180~730일 미접근, 선택 활성화)
Deep Archive Access Tier (Glacier Deep Archive 요금)

위쪽 두 개(Frequent / Infrequent)는 화살표가 양방향(↕)이에요. 자주 쓰면 다시 Frequent로 자동 복귀합니다. 아래쪽 Archive 계층들은 한 번 가면 다시 올라오려면 복원 요청이 필요해요.

특징을 정리하면:

• 모니터링 비용 — 객체당 월 $0.0025 (단, 128KB 미만 객체는 모니터링·자동화 대상 제외)
• 검색 비용 없음 — Frequent / Infrequent 계층 한정
• Archive 계층은 검색 시간 발생 — 활성화한 경우
• 최소 저장 기간 없음 — IA·Glacier와 다른 점

# Intelligent-Tiering으로 업로드
aws s3 cp file.txt s3://my-bucket/ \
  --storage-class INTELLIGENT_TIERING

# Archive 계층 활성화
aws s3api put-bucket-intelligent-tiering-configuration \
  --bucket my-bucket \
  --id MyTieringConfig \
  --intelligent-tiering-configuration '{
    "Id": "MyTieringConfig",
    "Status": "Enabled",
    "Tierings": [
      {"Days": 90, "AccessTier": "ARCHIVE_ACCESS"},
      {"Days": 180, "AccessTier": "DEEP_ARCHIVE_ACCESS"}
    ]
  }'

여기서 시험 함정이 하나 있어요. 128KB 미만 작은 객체가 매우 많으면 IT가 손해일 수 있습니다. 모니터링비는 객체 수 기준으로 붙는데, 작은 객체들은 어차피 가장 비싼 계층(Frequent)에 머물러서 절약 효과는 없고 모니터링비만 늘어나요. 작은 객체 다발은 라이프사이클로 처리하는 게 더 깔끔합니다.

Glacier 복원 — 외부 창고에서 잠시 가져오기

라이프사이클로 Glacier·Deep Archive로 보낸 객체는 그 상태로는 직접 못 읽어요. 회사 비유로 — 외부 창고에 보낸 자료는 책상에서 바로 꺼내볼 수 없고, "꺼내 와 주세요"라고 신청해야 잠시 책상으로 가져올 수 있는 식이에요. 이게 Glacier 복원(Restore) 입니다.

복원 옵션 — Glacier Flexible Retrieval

복원에는 세 가지 속도 옵션이 있어요. 비싸고 빠른 것부터 싸고 느린 것까지.

옵션	복원 시간	비용
Expedited (긴급)	1~5분	가장 비쌈
Standard (표준)	3~5시간	중간
Bulk (대량)	5~12시간	가장 저렴

복원 옵션 — Glacier Deep Archive

Deep Archive는 더 차가운 클래스라 복원이 더 오래 걸려요.

옵션	복원 시간
Standard	12시간
Bulk	48시간

여기서 시험 함정이 하나 있어요. Deep Archive에는 Expedited 옵션이 없습니다. 1~5분에 꺼낼 방법 자체가 없어요. 그래서 진짜 긴급하게 자주 꺼낼 수도 있는 자료라면 Deep Archive에 두면 안 됩니다.

복원 후 임시 접근 기간

복원 요청에는 또 하나 중요한 항목이 있어요 — Days(반환 기간) 입니다.

# Glacier 객체 복원 요청
aws s3api restore-object \
  --bucket my-bucket \
  --key archived-file.zip \
  --restore-request '{
    "Days": 7,
    "GlacierJobParameters": {
      "Tier": "Standard"
    }
  }'

# 복원 상태 확인
aws s3api head-object \
  --bucket my-bucket \
  --key archived-file.zip

# 응답 예시:
# "Restore": "ongoing-request=\"false\", expiry-date=\"Wed, 01 Jan 2025 00:00:00 GMT\""

# 긴급 복원 요청
aws s3api restore-object \
  --bucket my-bucket \
  --key urgent-file.zip \
  --restore-request '{
    "Days": 3,
    "GlacierJobParameters": {
      "Tier": "Expedited"
    }
  }'

여기가 처음 보면 헷갈리는 부분이에요. Glacier 객체를 복원해도 영구히 일반 객체가 되는 게 아닙니다. Days로 지정한 기간(예: 7일) 동안만 임시로 Standard처럼 접근 가능한 사본을 만드는 거예요. 그 기간이 지나면 사본이 사라지고, 다시 복원 요청해야 접근 가능합니다. 원본은 계속 Glacier에 남아 있어요 — 복원했다고 자동으로 Standard로 옮겨지는 게 아닙니다.

회사 비유로 — 외부 창고에서 자료를 잠시 책상으로 가져왔는데 7일 후에는 사본을 다시 폐기. 원본은 창고에 그대로. 또 보고 싶으면 다시 신청. 이런 식이에요.

여기서 시험 함정이 하나 있어요. 복원해도 스토리지 클래스 자체는 Glacier 그대로입니다. 영구히 Standard로 옮기고 싶으면 복원된 사본을 별도로 다시 PUT으로 업로드(또는 copy)해야 해요.

비용 최적화 패턴 — 실전 정책 모음

이제 실무에서 거의 그대로 쓸 수 있는 패턴 세 가지를 모아 봅니다.

1. 로그 파일 관리 — 가장 흔한 패턴

로그는 처음 30일은 자주 보다가, 그 이후는 거의 안 보고, 1년 지나면 폐기해도 되는 전형적인 데이터예요.

{
    "Rules": [
        {
            "ID": "LogsOptimization",
            "Status": "Enabled",
            "Filter": {"Prefix": "logs/"},
            "Transitions": [
                {"Days": 30, "StorageClass": "STANDARD_IA"},
                {"Days": 90, "StorageClass": "GLACIER"}
            ],
            "Expiration": {"Days": 365}
        }
    ]
}

2. 데이터 백업 관리 — 더 공격적인 정책

백업은 거의 안 꺼내는 자료라 더 빨리 차가운 계층으로 보낼 수 있어요. 이전 버전도 활발히 정리합니다.

{
    "Rules": [
        {
            "ID": "BackupManagement",
            "Status": "Enabled",
            "Filter": {"Prefix": "backups/"},
            "Transitions": [
                {"Days": 7, "StorageClass": "STANDARD_IA"},
                {"Days": 30, "StorageClass": "GLACIER"},
                {"Days": 90, "StorageClass": "DEEP_ARCHIVE"}
            ],
            "NoncurrentVersionExpiration": {
                "NoncurrentDays": 30,
                "NewerNoncurrentVersions": 5
            }
        }
    ]
}

여기서 시험 함정이 하나 있어요. 위 정책은 7일에 IA로 보낸다고 적었는데, IA의 최소 저장 기간은 30일이에요. 그래서 7일짜리는 IA 최소 기간 요건에 위배되지 않냐 싶은데 — 라이프사이클 전환 자체는 30일 미만에서는 막혀요. 즉, 위 JSON처럼 적어도 실제로는 30일이 안 되면 적용이 안 되거나 검증 단계에서 거부됩니다. 백업이라는 이유로 7일 같은 짧은 값을 쓰려면 클래스를 바꾸거나 최소 기간을 다시 확인해야 해요.

3. 임시 파일 정리 — 태그 결합

특정 태그가 붙은 임시 파일만 빠르게 폐기하는 정책. 복합 필터를 활용합니다.

{
    "Rules": [
        {
            "ID": "TempCleanup",
            "Status": "Enabled",
            "Filter": {
                "And": {
                    "Prefix": "temp/",
                    "Tags": [{"Key": "AutoDelete", "Value": "true"}]
                }
            },
            "Expiration": {"Days": 1}
        }
    ]
}

4. 미완료 멀티파트 정리 — 모든 버킷에 기본 권장

이건 그냥 모든 버킷에 거의 무조건 거는 게 좋아요.

{
    "Rules": [
        {
            "ID": "CleanIncompleteUploads",
            "Status": "Enabled",
            "Filter": {"Prefix": ""},
            "AbortIncompleteMultipartUpload": {
                "DaysAfterInitiation": 7
            }
        }
    ]
}

버전 관리와 라이프사이클 결합 — 실전 종합

1편에서 본 버전 관리와 이번 편 라이프사이클을 결합한 실전 종합 예시입니다. 버전 관리가 켜진 버킷에서 — 현재 버전·이전 버전·삭제 마커를 모두 자동으로 관리하는 정석 정책이에요.

aws s3api put-bucket-lifecycle-configuration \
  --bucket versioned-bucket \
  --lifecycle-configuration '{
    "Rules": [
      {
        "ID": "VersionManagement",
        "Status": "Enabled",
        "Filter": {"Prefix": ""},
        "Transitions": [
          {"Days": 30, "StorageClass": "STANDARD_IA"}
        ],
        "NoncurrentVersionTransitions": [
          {"NoncurrentDays": 7, "StorageClass": "GLACIER"}
        ],
        "NoncurrentVersionExpiration": {
          "NoncurrentDays": 30,
          "NewerNoncurrentVersions": 3
        },
        "Expiration": {
          "ExpiredObjectDeleteMarker": true
        }
      }
    ]
  }'

규칙 한 개에 다음을 다 담았어요.

• 현재 버전은 30일 후 IA로 전환
• 이전 버전은 7일 후 Glacier로 전환
• 이전 버전은 30일 후 영구 삭제, 단 최신 3개 이전 버전은 보존
• 외로운 삭제 마커 자동 정리

이게 버전 관리 켜진 버킷에 거는 정석 라이프사이클 패턴입니다.

최소 저장 기간 — 다시 한 번 강조

이게 라이프사이클 설계할 때 가장 자주 빠지는 함정이라 한 번 더 정리하고 넘어갈게요.

클래스	최소 저장 기간
Standard-IA	30일
One Zone-IA	30일
Glacier Instant	90일
Glacier Flexible	90일
Glacier Deep Archive	180일

최소 기간 안에 객체를 삭제해도 그 기간만큼 요금이 청구됩니다. 그래서 "30일에 IA, 60일에 Glacier" 같은 라이프사이클을 짜면 — IA에 30일밖에 안 머무는데 30일치 요금이 통째로 나가서, 절약 효과가 거의 없거나 오히려 손해예요.

올바른 설계 원칙은 — 각 계층에 최소 기간 이상은 머물게 짜는 거예요. 30일 IA → 90일 Glacier는 IA에 60일 머물러서 OK. 30일 IA → 60일 Glacier는 IA에 30일밖에 안 머무니까 다시 생각해야 합니다.

라이프사이클 vs 수동 관리 — 정리

항목	라이프사이클 정책	수동 관리
자동화	완전 자동	사람이 매번 처리
비용	정책 자체 무료	인건비 발생
일관성	매우 일관적	실수 가능
유연성	규칙 기반 제한	완전 유연
적합한 경우	패턴이 일정한 데이터	복잡한 비즈니스 로직

규칙으로 표현 가능한 단순한 패턴은 라이프사이클로, 복잡한 조건 분기가 필요하면 Lambda + EventBridge 같은 별도 자동화로 — 라고 갈래 잡으면 좋아요.

시리즈 다른 편

같은 시리즈의 다른 글들도 같은 친절 톤으로 묶어 정리되어 있어요.

• 1편 — 기초
• 2편 — 보안
• 3편 — 성능 최적화
• 4편 — 복제
• 5편 — 라이프사이클 (현재 글)
• 6편 — 고급 기능
• 7편 — AWS 통합 (완)

시험 직전 한 번 더 — 자주 헷갈리는 라이프사이클 함정 모음

여기까지가 S3 라이프사이클 5편의 핵심입니다. 시험 직전 또는 실무에서 라이프사이클 정책 짤 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• 라이프사이클 = 객체 자동 관리 위탁 계약, 전환(이동) + 만료(삭제) 두 갈래
• 라이프사이클 정책 자체는 무료, 전환 요청 비용·저장 비용 변화만 발생
• 전환은 한 방향만 — 차가운 → 따뜻한 자동 이동 X (수동 복사만 가능)
• Standard → IA / One Zone-IA / IT 전환은 30일 최소
• Standard → Glacier Instant는 90일 최소
• Glacier Flexible / Deep Archive는 0일도 가능 — 곧장 보낼 수 있음
• 만료 규칙 네 갈래 — 현재 버전 / 이전 버전 / 외로운 삭제 마커 / 미완료 멀티파트
• 이전 버전 만료 — NoncurrentDays + NewerNoncurrentVersions(최신 N개 보존)
• "만료된 삭제 마커" = 다른 버전 없이 혼자 남은 삭제 마커
• 미완료 멀티파트 정리는 모든 버킷에 7일 기본 권장 — 안 걸면 비용이 새는 자리
• 필터 — Prefix / Tag / ObjectSize / 복합 조건은 반드시 And 안에
• Days와 Date는 한 규칙 안에서 동시에 못 씀 — 둘 중 하나만
• 라이프사이클(정해진 시점 이동) ≠ Intelligent-Tiering(접근 패턴 관찰 후 이동)
• IT는 자주 쓰면 다시 Frequent 계층으로 자동 승격, 라이프사이클은 자동 승격 X
• IT 모니터링비 — 객체당 월 $0.0025, 128KB 미만 객체는 모니터링 대상 제외
• 작은 객체가 매우 많으면 IT가 오히려 손해일 수 있음
• Glacier 복원 옵션 — Expedited(1~5분) / Standard(3~5h) / Bulk(5~12h)
• Deep Archive는 Expedited 없음 — Standard(12h) / Bulk(48h)만
• 복원 요청 Days = 임시 접근 사본의 유지 기간, 원본은 Glacier에 그대로
• 복원해도 스토리지 클래스 자체는 안 바뀜 — 영구 Standard화는 별도 PUT/copy
• 최소 저장 기간 — IA 30일 / Glacier Instant·Flexible 90일 / Deep Archive 180일
• 최소 기간 안에 삭제·전환해도 그 기간만큼 요금 청구
• 라이프사이클 설계 — 각 계층에 최소 기간 이상 머물게 짜는 게 비용 최적화 핵심

다음 글(6편)에서는 S3 이벤트 알림과 자동화 — S3 Event Notifications, EventBridge, Lambda 트리거, SNS·SQS 연동을 회사 사물함에 자료가 들어왔을 때 관계 부서로 자동 통지하는 비유로 풀어 갈 예정이에요. 라이프사이클이 "시간 기반 자동화"라면 이벤트는 "사건 기반 자동화"라, 둘이 짝을 이뤄 S3의 자동화 그림을 완성합니다.