S3 스토리지 클래스, 싸게 옮기면 붙는 최소 기간
보관료가 싼 등급이 전체 비용도 쌀까요? 파일 크기와 보관 기간, 다시 꺼내는 비용과 대기 시간을 함께 살펴봐요.
이 글의 목차싼 자리에는 기간이 붙는다4
창고 대여점에 짐을 맡길 때 층마다 값이 달라요. 1층은 비싸고 아무 때나 꺼낼 수 있어요. 지하 깊은 곳은 아주 싼데 대신 최소 몇 달치를 내야 하고, 꺼내려면 미리 말하고 기다려야 해요. 그래서 어느 층에 둘지는 짐의 크기가 아니라 얼마나 자주 꺼낼지로 정해요.
Amazon S3의 스토리지 클래스가 이 층이에요. 앞 시리즈에서 클라우드 청구서를 다루며 켜 둔 시간과 옮긴 바이트를 이야기했는데, 저장 쪽에는 한 가지 축이 더 있어요. 어디에 두었는가예요.
싼 자리에는 기간이 붙는다
문서가 이 조건을 수치로 못 박아 두었어요. 수명 주기 규칙으로 객체를 만료시킬 때, 자주 안 쓰는 등급에 30일이 안 된 객체라면 30일치를, 유연 검색 아카이브에 90일이 안 된 객체라면 90일치를, 깊은 아카이브에 180일이 안 된 객체라면 180일치를 청구한다는 것이에요.
AWS는 등급마다 무엇이 다른지를 한자리에서 비교해 두었는데, 갈리는 축은 보관값, 검색 방식, 그리고 최소 보관 기간이에요.
이 규칙이 만드는 상황이 있어요. 30일 뒤에 지우기로 한 데이터를 “싸니까” 아카이브로 옮겨 두면, 지운 뒤에도 남은 기간만큼 값이 붙어요. 옮기지 않고 표준 등급에 두었다가 지우는 편이 오히려 쌀 수도 있어요.
| 이 데이터를 언제까지 두나 | 어디에 둘까 | 왜 |
|---|---|---|
| 몇 주 뒤에 지운다 | 그냥 둔다 | 옮겨도 최소 기간이 더 길다 |
| 오래 두는데 가끔 읽는다 | 덜 읽는 등급 | 보관값이 낮고 기간도 짧다 |
| 오래 두는데 거의 안 읽는다 | 아카이브 등급 | 꺼낼 일이 드물어 검색값을 감당한다 |
읽는 빈도와 지우는 시점이 중요하지만 크기도 빼놓을 수 없어요. 등급마다 최소 청구 크기나 객체별 비용이 달라서 작은 파일이 아주 많으면 계산이 달라져요. ‘오래된 파일은 모두 아카이브로’보다 파일의 크기, 개수, 다시 읽는 방식까지 묶어 보는 편이 정확해요.
해당 클래스에 보관한 기간을 바꿔 최소 저장 요금의 기간을 비교해 보세요. 막대 단위는 일이에요.
Standard-IA30
Glacier Flexible90
Glacier Deep Archive180
Standard-IA100
Glacier Flexible100
Glacier Deep Archive180
최소 저장 과금 기간이 30일·90일·180일인 클래스는 그보다 빨리 지워도 남은 기간의 요금이 붙어요.
20일 뒤 삭제해도 클래스에 따라 30일·90일·180일분의 저장 요금이 남아요.
클래스에 들어간 뒤의 보관 일수만 비교해요. 삭제 금지 기간이 아니며 파일 크기·요청·복원·리전별 가격은 계산하지 않아요.
꺼낼 때 또 붙는다
AWS는 아카이브 등급들을 비교하면서 최소 보관 기간과 함께 꺼내는 방식과 걸리는 시간이 등급마다 다르다는 것을 정리해 둬요. 즉시 꺼낼 수 있는 것도 있고, 요청한 뒤 기다려야 하는 것도 있어요.
그래서 값을 볼 때 봐야 하는 것이 셋이에요. 보관하는 값, 옮기는 값, 꺼내는 값. 보관값만 비교하면 아카이브가 압도적으로 싸 보이지만, 한 달에 몇 번씩 꺼내는 데이터라면 나머지 둘이 그 차이를 지워요.
여기에 시간이라는 축이 하나 더 있어요. 앞 글에서 복구를 다루며 이야기할 부분과도 겹치는데, 급하게 필요할 때 몇 시간을 기다려야 하는 자리에 둔 데이터는 사실상 그 시간 동안 없는 것과 같아요. 값을 아끼려고 옮긴 결정이 대응 시간을 늘리는 결정이 되어 있는 셈이에요.
규칙으로 옮기되 예외를 남긴다
수명 주기 규칙은 조건에 맞는 객체를 다른 등급으로 옮기거나 만료시켜요. 새 객체뿐 아니라 이미 있던 객체에도 적용돼요. 예를 들어 생성 후 일정 기간이 지난 객체를 지우는 규칙을 켜면, 기존 파일 중 이미 그 나이를 넘긴 것도 대상이 될 수 있어요. 나중에 태그를 붙여 대상을 구분할 수도 있지만, 그 이름표가 어떤 규칙을 작동시키는지 먼저 봐야 해요.
그리고 규칙은 조용히 동작해요. 몇 달 뒤에 누군가 옛 데이터를 찾다가 “왜 바로 안 열리지”라고 묻기 전까지 아무도 그 규칙을 떠올리지 않아요. 걸어 둔 규칙과 그 이유를 어디엔가 적어 두지 않으면, 시간이 지나면 아무도 왜 그렇게 되어 있는지 모르게 돼요.
저는 무엇을 옮기지 않았나
제가 만드는 앱에서 저장하는 것 중 큰 것은 이미지예요. 처음에는 오래된 것을 싼 자리로 옮길 생각을 했어요.
세어 보니 옮길 이유가 없었어요. 오래된 이미지도 사용자가 자기 기록을 다시 볼 때 그대로 열리고, 그 빈도가 낮지도 않았어요. 옮기면 그때마다 꺼내는 값이 붙고 어떤 등급에서는 기다리기까지 해요. 총량이 작아서 아끼는 몫보다 화면이 느려지는 대가가 컸어요.
이 결정은 데이터를 얼마나 오래 두느냐가 아니라 그 데이터를 다시 볼 사람이 있느냐로 갈렸어요. 다시 볼 사람이 있으면 싸게 두는 것 자체가 비용이었어요.