AWS S3 완전 해부 — 어디에 쓰고, 얼마가 나오나

1. S3는 무엇인가 — 파일 서버가 아니다

많은 프로젝트가 S3를 "네트워크 드라이브"처럼 생각하고 시작했다가 문제를 겪습니다. S3는 파일 시스템이 아니라 객체 스토리지입니다. 이 차이가 설계와 비용 모두를 결정합니다.

2. 실제 사용 용도 10가지

현장에서 S3가 실제로 쓰이는 패턴을 정리하면 다음 10가지로 수렴합니다. 각 용도마다 권장 스토리지 클래스가 다릅니다.

3. 스토리지 클래스 8종

S3의 비용 설계는 사실상 "어떤 데이터를 어떤 클래스에 두느냐"의 문제입니다. 모든 클래스는 동일한 11 nines 내구성을 제공합니다(One Zone 계열 제외). 차이는 가용성·최소 보관 기간·검색 비용·검색 시간입니다.

같은 데이터 10TB를 1년간 보관할 때 클래스별 저장 비용만 비교하면 차이가 분명해집니다.

※ 10TB = 10,240GB × 12개월 기준 저장 요금만 계산. 요청·검색·전송 비용은 제외한 수치입니다.

4. 가격을 구성하는 5가지 요소

S3 청구서는 항상 다음 다섯 가지의 합입니다. 대부분의 예상 초과는 1번이 아니라 2·3번에서 발생합니다.

① 저장 용량 (Storage)

GB-월 단위로 과금됩니다. 월 중간에 올리고 지우면 보관한 시간에 비례해 일할 계산됩니다. 주의할 점은 버전 관리를 켠 버킷에서는 이전 버전과 삭제 마커도 모두 과금 대상이라는 것입니다.

② 요청 (Requests)

숫자만 보면 사소해 보이지만, 객체 수가 많으면 요청 비용이 저장 비용을 추월합니다. 1KB짜리 로그 객체 1억 개를 올린다고 가정하면 저장 용량은 약 100GB($2.5)에 불과하지만 PUT 요청 비용은 1억 ÷ 1,000 × $0.0045 = $450입니다. 저장 요금의 180배입니다.

③ 데이터 전송 (Data Transfer)

④ 검색 · 조기 삭제 (Retrieval & Early Delete)

IA 이하 클래스는 읽을 때마다 GB당 검색 요금이 붙고, 최소 보관 기간 전에 삭제하면 남은 기간이 청구됩니다. "가끔 읽는 데이터"라고 IA에 넣었는데 실제로는 자주 읽는다면 Standard보다 비싸집니다.

# 손익분기점 계산 — 1TB를 Standard-IA에 두는 것이 유리한가?

Standard   : 1,024GB × $0.025            = $25.60 / 월
Standard-IA: 1,024GB × $0.0138           = $14.13 / 월
             + 읽은 용량 × $0.01 (검색)

# 차액 $11.47을 검색 요금으로 소진하는 지점
$11.47 ÷ $0.01 = 1,147GB

# → 월 1.1TB 이상 읽으면 IA가 오히려 손해
# → 즉 "전체 용량의 월 100% 이상을 읽는다면" Standard 유지

⑤ 관리 기능 (Management & Analytics)

5. 워크로드별 비용 시뮬레이션

시나리오 A — 중소기업 정적 웹사이트

용량 20GB, 월 방문 트래픽 500GB, 월 요청 200만 건.

소규모 사이트에서는 CloudFront 무료 사용량(월 1TB 전송)만으로 배포 비용이 사실상 0에 수렴합니다. CloudFront를 붙이지 않을 이유가 없습니다.

시나리오 B — 로그 아카이브 (연 30TB 누적)

매월 2.5TB 로그 유입, 최근 30일만 조회, 3년 보존 규정.

// 라이프사이클 규칙 — 로그 버킷 표준 구성
{
  "Rules": [{
    "ID": "log-archive-tiering",
    "Status": "Enabled",
    "Filter": { "Prefix": "logs/" },
    "Transitions": [
      { "Days": 30,  "StorageClass": "STANDARD_IA" },
      { "Days": 120, "StorageClass": "DEEP_ARCHIVE" }
    ],
    "Expiration": { "Days": 1095 },
    // 미완료 멀티파트 업로드 정리 — 잊으면 유령 비용이 쌓입니다
    "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
  }]
}

시나리오 C — 데이터 레이크 (5TB, Athena 분석)

6. 청구서를 부풀리는 7가지 함정

7. 클래스 선택 결정 트리

8. 비용 최적화 실전

8-1. 먼저 측정하세요 — S3 Storage Lens

최적화의 출발점은 "어느 버킷의 어떤 프리픽스가 얼마를 쓰고 있는가"입니다. Storage Lens 기본 대시보드는 무료이며, 계정·리전·버킷별 용량 추이, 미완료 멀티파트 업로드, 비현행 버전 비중, 클래스 분포를 한 화면에서 보여줍니다.

# 버킷별 용량·객체 수 빠르게 확인 (CloudWatch 지표 활용)
aws cloudwatch get-metric-statistics \
  --namespace AWS/S3 --metric-name BucketSizeBytes \
  --dimensions Name=BucketName,Value=my-bucket \
               Name=StorageType,Value=StandardStorage \
  --start-time 2026-09-01T00:00:00Z --end-time 2026-09-14T00:00:00Z \
  --period 86400 --statistics Average

# 미완료 멀티파트 업로드 점검 — 유령 비용의 주범
aws s3api list-multipart-uploads --bucket my-bucket \
  --query 'Uploads[].{Key:Key,Initiated:Initiated}' --output table

# 버킷 키 활성화 — KMS 호출 최대 99% 절감
aws s3api put-bucket-encryption --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "alias/s3-cmk"
      },
      "BucketKeyEnabled": true
    }]
  }'

8-2. 절감 효과가 큰 순서

8-3. 최적화 체크리스트

• S3 Storage Lens 기본 대시보드 활성화 (무료)
• 모든 버킷에 AbortIncompleteMultipartUpload 7일 규칙 적용
• 버전 관리 버킷에 NoncurrentVersionExpiration 설정
• 만료된 삭제 마커 정리 규칙 추가
• S3 게이트웨이 VPC 엔드포인트 생성 — 무료, NAT 비용 제거
• 퍼블릭 배포는 예외 없이 CloudFront 경유
• 라이프사이클 전환 규칙에 ObjectSizeGreaterThan: 131072 필터 추가
• 전환 일수를 최소 보관 기간(30·90·180일)보다 길게 설계
• SSE-KMS 사용 버킷에 버킷 키(Bucket Keys) 활성화
• 접근 패턴이 불확실한 데이터는 Intelligent-Tiering으로 이전
• Storage Class Analysis로 전환 시점 근거 확보 후 규칙 확정
• 전체 목록 순회 배치를 S3 Inventory 또는 이벤트 기반으로 전환
• 분석 대상 데이터는 Parquet + 날짜 파티셔닝으로 적재
• 크로스 리전 복제는 DR 요건이 있는 버킷에만 선별 적용
• Cost Anomaly Detection에 S3 서비스 모니터 등록
• 비용 할당 태그(Service·Env·Owner) 적용 후 Cost Explorer로 분기 검토

마무리

S3 비용 관리의 핵심은 단순합니다. 데이터를 성격별로 분류하고, 분류에 맞는 클래스로 자동 이동시키고, 배포는 CloudFront로 빼는 것입니다. 대부분의 과다 청구는 정교한 최적화가 부족해서가 아니라, 기본 설정 몇 가지를 빠뜨려서 발생합니다.