S3 스토리지 클래스, 싸게 옮기면 붙는 최소 기간

S3 버킷의 관리 탭에서 수명 주기 규칙을 만들다 보면 객체를 다른 스토리지 클래스로 옮기는 작업을 고르는 칸이 나온다.
객체를 만든 지 며칠이 지나면 어느 클래스로 옮길지 정하는 자리다.

목록에는 Standard-IA, Glacier Instant Retrieval, Glacier Deep Archive처럼 이름이 낯선 클래스가 줄지어 있다.
Glacier가 붙은 클래스일수록 저장 요금이 싸니, 오래된 파일은 전부 가장 싼 곳으로 보내면 될 것 같다.

그런데 저장 요금이 싼 클래스일수록 따라붙는 조건도 많다.

객체마다 붙는 스토리지 클래스

S3에서는 파일 하나를 객체라고 부른다.
객체는 버킷이라는 저장 공간 안에 키라는 이름으로 들어간다.
S3의 모든 객체에는 스토리지 클래스가 하나씩 붙고, 따로 정하지 않으면 표준 클래스인 S3 Standard가 붙는다.

스토리지 클래스는 그 객체를 어떻게 보관할지 정하는 등급이다.
저장 요금과 읽는 속도, 최소 보관 기간, 꺼낼 때의 요금이 클래스마다 다르다.

드물게 읽고 꺼내는 데 오래 걸리는 클래스일수록 저장 요금이 낮다.
자주 안 읽는 데이터용인 Standard-IA, 아카이브용인 Glacier 계열 세 가지가 대표적이다.
IA는 드문 접근(infrequent access)⁠의 약자다.

클래스 표에 적힌 GB당 저장 요금은 비용의 일부일 뿐이다.
최소 보관 기간, 최소 청구 크기, 옮기는 요금, 꺼내는 요금이 함께 붙는다.

일찍 지워도 정해진 날수만큼 낸다

표준 클래스에는 최소 보관 기간이 없다.
Standard-IA는 30일, Glacier Instant Retrieval과 Glacier Flexible Retrieval은 90일, Glacier Deep Archive는 180일이다.

이 기간을 채우기 전에 객체를 지우거나, 같은 키로 덮어쓰거나, 다른 클래스로 옮기면 남은 날수만큼 요금이 붙는다.
손으로 지운 파일도, 같은 이름으로 다시 올린 파일도 이 계산에 들어간다.

수명 주기 규칙의 만료 동작도 마찬가지다.
Glacier Flexible Retrieval에 들어간 지 90일이 안 된 객체를 규칙으로 지우면 90일 치가 청구된다.
Deep Archive라면 180일 치다.

그래서 30일 뒤에 지울 데이터를 싸다는 이유로 아카이브 클래스로 옮기면, 보관하지도 않은 기간의 요금을 낸다.

객체를 다른 등급으로 옮긴 뒤 지우는 시점에 따라 청구되는 기간이 달라진다. 위 막대는 실제로 보관한 기간, 아래 막대는 청구되는 기간이다.

보관한 기간 60일

청구되는 기간 90일 · 30일 추가

03090180일

최소 보관 기간보다 일찍 지워도 그 기간만큼 청구된다. 유연 검색 아카이브에 옮긴 객체를 60일 뒤에 지우면 90일 치가 청구된다.

기간만 비교한 예시다. 실제 요금은 저장 용량과 객체 수, 전환과 검색 요금, 리전에 따라 다르다.

작은 파일은 계산이 따로 붙는다

크기도 따져 봐야 한다.
Standard-IA와 Glacier Instant Retrieval은 128KB보다 작은 객체도 128KB로 계산한다.
10KB짜리 썸네일에도 128KB 치 요금이 나간다.

Glacier Flexible Retrieval과 Deep Archive는 방식이 다르다.
객체마다 40KB의 메타데이터가 더 붙고, 그중 8KB는 표준 클래스 요금으로 계산된다.
객체가 많을수록 이 몫이 쌓인다.

옮기는 데도 돈이 든다.
수명 주기 규칙으로 객체를 다른 클래스로 옮길 때마다 전환 요청 한 건이 청구된다.
파일 크기와 상관없이 개수만큼이다.

그래서 AWS는 기본값을 바꿨다.
2024년 9월부터 수명 주기 규칙은 기본적으로 128KB보다 작은 객체를 어느 클래스로도 옮기지 않는다.
작은 객체는 전환 요금이 아끼는 저장 요금보다 커질 수 있다는 이유에서다.

S3 수명 주기 전환 문서도 작은 파일을 아카이브해야 한다면 여러 개를 큰 파일 몇 개로 묶어서 옮기라고 권한다.
객체 수가 줄면 객체마다 붙는 요금도 함께 줄어든다.

꺼낼 때는 요금과 시간이 함께 든다

Standard-IA와 Glacier 계열은 읽을 때 GB당 검색 요금이 붙는다.
저장 요금이 싼 대신 꺼낼 때 돈을 내는 구조라서, 자주 읽는 데이터라면 아낀 저장 요금을 검색 요금이 금방 따라잡는다.

기다리는 시간도 있다.
Glacier Instant Retrieval은 밀리초 만에 읽히지만, Flexible Retrieval은 몇 분에서 12시간, Deep Archive는 9시간에서 48시간이 걸린다.

뒤의 두 클래스는 객체를 바로 열지 못한다.
먼저 복원 요청을 보내 임시 사본을 만들고, 그 요청이 끝난 뒤에야 읽을 수 있다.
복원할 때 고르는 속도 옵션도 있는데, 오래 기다리는 옵션일수록 싸다.

장애를 복구하다가 아카이브에 있는 파일이 급히 필요해지면, 그 몇 시간 동안은 데이터가 있어도 쓰지 못한다.
복구 계획에 쓰일 파일이라면 꺼내는 시간도 그 계획에 넣어 둬야 한다.

수명 주기 규칙은 이미 있던 객체에도 걸린다

수명 주기 규칙은 새로 올라오는 객체뿐 아니라 이미 버킷에 있던 객체에도 적용된다.
오늘 ‘만든 지 30일 지나면 삭제’ 규칙을 걸면, 이미 30일이 넘은 객체는 곧바로 삭제 대상이 된다.

버킷 정책으로도 수명 주기 규칙의 삭제와 전환은 막을 수 없다.
모든 동작을 거부하는 정책이 붙어 있어도 규칙은 그대로 실행된다.

버전 관리를 켠 버킷이라면 하나 더 있다.
만료 동작은 데이터가 없는 삭제 표시를 새 현재 버전으로 얹고, 원래 버전은 이전 버전으로 남겨 둔다.

삭제 표시가 현재 버전이면 객체는 지워진 것처럼 보인다.
그래도 남은 버전은 하나하나 온전한 객체로 요금이 나가니, 지우려면 이전 버전 만료 규칙을 따로 걸어야 한다.

어느 클래스에 둘까

데이터의 쓰임	어울리는 곳	따져 볼 점
몇 주 안에 지운다	표준 그대로	옮기면 최소 기간 요금이 붙음
오래 두고 가끔 읽는다	Standard-IA	읽을 때마다 검색 요금
오래 두고 거의 안 읽는다	아카이브 클래스	꺼낼 때 몇 시간 대기
얼마나 읽힐지 모른다	Intelligent-Tiering	객체마다 붙는 관리 요금

Intelligent-Tiering은 S3가 접근 기록을 보고 객체를 알아서 옮겨 주는 클래스다.
검색 요금이 없는 대신 객체마다 모니터링 요금이 붙고, 128KB보다 작은 객체는 옮기지 않는다.

얼마나 읽히는지 감이 없다면 S3의 스토리지 클래스 분석(Storage Class Analysis)⁠으로 접근 패턴부터 본다.
표준 클래스의 객체를 올라온 지 며칠 됐는지로 묶어 30일 이상 지켜본 뒤, Standard-IA로 옮기기에 알맞은 시점을 알려 준다.

아카이브 클래스로 옮길지는 이 분석이 답해 주지 않는다.
데이터를 며칠 동안 두고, 몇 번 읽고, 파일이 얼마나 작은지를 알면 고를 클래스가 거의 정해진다.

실무에서는 규칙을 걸 때 그 이유도 함께 적어 둔다.
수명 주기 규칙은 조용히 돌기 때문에, 몇 달 뒤 누군가 옛 파일이 왜 바로 안 열리느냐고 물으면 답을 찾기 어렵다.