57장. S3 스토리지 클래스와 수명 주기 — 비용 설계 관점

이 장에서 말하고자 하는 것

S3는 싸다. 그런데 한 가지 가격으로 다 같지는 않다.

S3는 객체마다 스토리지 클래스(Storage Class) 를 가질 수 있다.

자주 읽는 객체와 거의 안 읽는 객체에 같은 비용을 내면 손해다.

1. 주요 스토리지 클래스

2. 어떤 객체에 어떤 클래스?

자주 읽는 사용자 데이터 → Standard
정적 자원 (CloudFront 캐시) → Standard 또는 Intelligent-Tiering
오래된 로그 / 백업 → Glacier
법적 보관용 / 5년 이상 → Deep Archive

3. Intelligent-Tiering — 패턴 모를 때

Intelligent-Tiering
  ↓ 30일간 접근 없음
자동으로 IA로 이동
  ↓ 90일간 접근 없음
자동으로 Archive Instant로 이동

AWS가 알아서 옮긴다.

운영에서 “기본값으로 켤만한” 클래스다

4. 수명 주기 정책 (Lifecycle Policy)

객체가 만들어진 뒤 시간이 지남에 따라 자동으로 옮기거나 삭제하는 규칙이다.

uploads/* 객체
  30일 후 → Standard-IA
  90일 후 → Glacier
  365일 후 → 삭제

운영 비용 최적화의 절반은 이 규칙 한 번 거는 일이다.

5. 버전 관리와 수명 주기

versioning이 켜져 있으면 옛 버전도 보관된다.

현재 버전: Standard
옛 버전:   30일 후 → IA
          90일 후 → Glacier
          365일 후 → 삭제

versioning을 켜고 수명 주기를 안 걸면 청구서가 끝없이 늘어난다.

6. 요청 비용도 무시할 수 없다

S3는 저장 비용 뿐 아니라 요청 비용 도 든다.

PUT · LIST: 비쌈
GET: 쌈

수많은 작은 객체에 LIST를 자주 호출하면 저장 비용보다 요청 비용이 더 클 수 있다.

작은 객체보다는 적절히 묶고, 자주 호출되는 정적 자원은 CloudFront로 흡수

7. 우리 서비스에서

uploads/ (사용자 업로드)
  ├─ 0~90일: Standard
  ├─ 90~365일: Standard-IA
  └─ 365일+ : Glacier

logs/ (ECS 로그 백업)
  ├─ 0~7일: Standard
  ├─ 7~30일: IA
  ├─ 30일+ : Glacier
  └─ 365일+ : 삭제

static/ (CloudFront 캐시)
  └─ Intelligent-Tiering

8. 직접 확인해보기 — CLI

aws s3api head-object \
  --bucket msa-uploads \
  --key users/123/profile.png \
  --query StorageClass

aws s3 cp s3://msa-uploads/key s3://msa-uploads/key \
  --storage-class STANDARD_IA \
  --metadata-directive REPLACE

9. 코드로는 이렇게 생겼다 — Terraform

resource "aws_s3_bucket_lifecycle_configuration" "uploads" {
  bucket = aws_s3_bucket.uploads.id

  rule {
    id     = "tier-uploads"
    status = "Enabled"

    filter { prefix = "uploads/" }

    transition {
      days          = 30
      storage_class = "STANDARD_IA"
    }

    transition {
      days          = 90
      storage_class = "GLACIER"
    }

    expiration {
      days = 365
    }
  }

  rule {
    id     = "old-versions"
    status = "Enabled"

    filter {}

    noncurrent_version_transition {
      noncurrent_days = 30
      storage_class   = "STANDARD_IA"
    }

    noncurrent_version_expiration {
      noncurrent_days = 365
    }
  }
}

이 한 묶음이 비용 절감 효과의 대부분을 만든다.

10. 이렇게 쓰면 망한다 — 안티패턴

안티패턴 1. 모든 객체를 Standard로만 둔다

매달 비용 줄 기회를 놓친다.

안티패턴 2. Glacier에 둔 객체를 자주 꺼낸다

Glacier는 꺼낼 때 비용이 든다. 자주 꺼내면 Standard보다 비싸진다.

안티패턴 3. versioning은 켰는데 옛 버전 수명 주기는 안 건다

옛 버전이 영원히 쌓인다.

안티패턴 4. 작은 객체 수백만 개를 IA / Glacier로 보낸다

IA · Glacier는 최소 과금 크기(128KB) 가 있다. 작은 객체는 손해.

11. 한 줄로 정리

스토리지 클래스 + 수명 주기는 S3의 비용 절반을 결정하는 두 손잡이다

12. 이 장의 핵심 정리

1. S3는 객체마다 클래스를 가진다 — 자주 vs 가끔 vs 거의 안 읽음.
2. Intelligent-Tiering은 패턴 모를 때의 안전한 기본값이다.
3. 수명 주기 정책으로 자동 이동 / 삭제를 건다.
4. versioning과 옛 버전 수명 주기는 항상 함께 설계한다.
5. 작은 객체에 IA/Glacier는 오히려 비싸질 수 있다.
6. 요청 비용도 무시할 수 없다 — CloudFront로 흡수한다.