S3 스토리지 클래스 전환 비용 계산 — 작은 객체는 옮길수록 손해다

S3 수명 주기로 오래된 파일을 싼 클래스로 옮기면 요금이 준다고 생각하기 쉬운데, 작은 객체는 옮길수록 손해다. 8KB 파일을 Standard-IA로 보내면 128KB로 과금된다. 16배다. Deep Archive로 보내면 40KB 오버헤드가 붙어 48KB가 되고, 여기에 전환 요청 요금과 최소 180일 보관이 따라온다. 그래서 AWS는 2024년 9월에 기본 동작을 바꿨다. 128KB 미만 객체는 이제 기본적으로 전환되지 않는다.

전환 비용은 세 갈래로 붙는다

싼 클래스로 옮긴다고 저장 요금만 계산하면 틀린다. 실제로는 이렇게 나뉜다.

전환 요청 요금 — 객체 하나를 옮길 때마다 요청 1건이다. 100만 개를 옮기면 100만 건이다. 저장 요금이 아니라 요청 요금으로 붙는다.

최소 과금 크기 — Standard-IA·One Zone-IA·Glacier Instant Retrieval은 128KB 미만이어도 128KB로 과금된다.

객체당 오버헤드 — Glacier Flexible Retrieval과 Deep Archive는 객체마다 40KB가 더 붙는다. 32KB는 인덱스용으로 목적지 클래스 요금, 8KB는 이름·메타데이터용으로 S3 Standard 요금이다.

8KB짜리 로그 파일 하나로 계산해 보면 이렇게 된다.

옮기는 곳	과금되는 크기	배수
S3 Standard (그대로)	8KB	1배
Standard-IA	128KB (최소 과금)	16배
Deep Archive	48KB (8 + 40KB 오버헤드)	6배

싼 클래스로 옮겼는데 과금 대상이 커진다. 단가가 낮아지는 것보다 크기가 커지는 폭이 크면 손해다. 여기에 전환 요청 요금까지 별도로 나간다.

2024년 9월에 기본 동작이 바뀌었다

이게 조용히 사람을 놀라게 한다.

• 2024년 9월 이전 — 128KB 미만 객체도 Glacier Flexible Retrieval과 Deep Archive로는 전환됐다
• 2024년 9월 이후 — 어떤 클래스로도 전환되지 않는다

문제는 기존 설정이다. 그 전에 만든 수명 주기 설정은 옛 동작을 유지한다. 그런데 규칙을 만들거나 고치거나 지우는 순간 그 설정 전체가 새 동작으로 바뀐다.

즉 무관해 보이는 규칙 하나를 손대면 작은 객체들이 갑자기 전환을 멈춘다. 요금은 줄겠지만, 아카이브되는 줄 알았던 데이터가 Standard에 남는다.

작은 객체도 옮기려면 크기 필터를 명시한다.

{
  "Rules": [
    {
      "ID": "archive-logs",
      "Status": "Enabled",
      "Filter": {
        "And": {
          "Prefix": "logs/",
          "ObjectSizeGreaterThan": 131072
        }
      },
      "Transitions": [
        { "Days": 90, "StorageClass": "GLACIER" }
      ]
    }
  ]
}

ObjectSizeGreaterThan을 128KB(131,072바이트)로 두면 작은 객체를 애초에 걸러 낸다. 옮겨서 손해 볼 것들을 규칙 단계에서 빼는 쪽이 명확하다.

최소 보관 기간 — 일찍 옮기면 두 번 낸다

클래스마다 최소 보관 기간이 있다. 그 전에 지우거나 다른 클래스로 옮기면 남은 기간만큼 비례해서 청구된다.

클래스	최소 보관	최소 과금 크기	검색 요금
S3 Standard	없음	없음	없음
Intelligent-Tiering	없음	없음	없음 (모니터링 요금 별도)
Standard-IA	30일	128KB	있음
One Zone-IA	30일	128KB	있음
Glacier Instant Retrieval	90일	128KB	있음
Glacier Flexible Retrieval	90일	— (40KB 오버헤드)	있음
Deep Archive	180일	— (40KB 오버헤드)	있음

30일짜리 데이터를 Standard-IA에 넣고 20일 만에 지우면, 20일치가 아니라 30일치를 낸다.

규칙 하나로 연속 전환을 못 한다

여기서 걸린다. 최소 보관 기간이 지나기 전에 다음 클래스로 넘기는 규칙은 만들 수 없다.

AWS 문서의 예로, Glacier Instant Retrieval은 최소 90일이다. "4일 후 GIR → 20일 후 Deep Archive" 같은 규칙은 거부된다. Deep Archive 전환은 최소 94일 뒤여야 한다.

규칙을 두 개로 나누면 만들어지기는 하는데, 최소 보관 기간 요금은 그대로 낸다. 우회가 아니다.

전환은 비동기인데 과금은 즉시다

이건 정산할 때 헷갈린다.

수명 주기 전환은 비동기로 처리된다. 규칙에 적은 날짜와 실제로 물리적으로 옮겨지는 날짜 사이에 지연이 있다.

그런데 요금은 규칙 조건을 만족한 날부터 목적지 클래스 기준으로 붙는다. 물리적 전환이 아직 안 끝났어도 그렇다. 최소 보관 기간과 40KB 오버헤드도 그 시점부터 시작한다.

Intelligent-Tiering만 예외다. 이쪽은 물리적 전환이 끝난 뒤에 과금이 바뀐다.

복원할 때는 두 번 낸다

Glacier Flexible Retrieval과 Deep Archive는 실시간 접근이 안 된다. 복원 요청을 넣고 임시 복사본을 받아야 한다.

이때 아카이브 요금과 임시 복사본의 S3 Standard 요금을 둘 다 낸다. 복원한 복사본은 지정한 기간만 유지되고 사라지지만, 그 기간 동안은 이중으로 나간다.

그리고 Deep Archive는 단방향이다. 수명 주기 규칙으로는 다른 클래스로 되돌릴 수 없다. 되돌리려면 복원한 뒤 복사 작업으로 덮어써야 한다.

FAQ

작은 파일이 많은데 어떻게 하나요

옮기지 말거나, 여러 개를 하나로 묶는다. AWS 문서도 작은 객체를 아카이브할 때는 큰 객체로 합치라고 권한다. 로그라면 일 단위로 묶어 하나로 올리는 쪽이 개수와 오버헤드를 동시에 줄인다.

Intelligent-Tiering을 쓰면 신경 안 써도 되나요

접근 패턴을 모를 때는 좋은 선택이다. 최소 보관 기간도 검색 요금도 없다. 다만 객체당 모니터링 요금이 붙고, 128KB 미만 객체는 모니터링 대상이 아니라 항상 Frequent Access 계층에 남는다. 작은 객체가 많으면 여기서도 이득이 안 난다.

이미 잘못 옮겼으면 되돌려야 하나요

되돌리는 것도 요청과 최소 보관 기간이 걸린다. 되돌리는 비용이 두는 비용보다 클 수 있다. 규칙부터 고쳐 새로 들어오는 객체를 막고, 기존 것은 최소 보관 기간이 지난 뒤에 판단하는 편이 낫다.

확인한 것과 확인하지 못한 것

이 글의 수치는 전부 AWS 공식 문서에서 확인했다. 클래스별 최소 보관 기간(30/90/180일)과 최소 과금 크기(128KB), Glacier 계열의 40KB 오버헤드 구성(32KB는 목적지 요금, 8KB는 Standard 요금), 2024년 9월 기본 동작 변경, 최소 기간 전 연속 전환 불가, 그리고 비동기 전환과 과금 시점 차이가 그렇다.

확인하지 못한 것은 리전별 실제 단가다. 요금 페이지가 스크립트로 렌더링되어 값을 직접 읽지 못했다. 그래서 이 글에는 "얼마 아낀다"가 아니라 과금 대상 크기의 배수만 적었다. 배수는 리전과 무관하지만, 손익이 갈리는 지점은 단가에 달려 있다.

계산이 필요하면 S3 요금 페이지에서 리전을 골라 세 갈래(저장·전환 요청·검색)를 각각 봐야 한다. 저장 단가만 비교하면 프리티어를 요청 수로 넘기는 것과 같은 실수를 하게 된다.