이미지 썸네일, 이벤트 로그, 처리 결과 JSON이 쌓이는 작은 팀은 S3 청구서를 보고 Lifecycle부터 켜기 쉽다. 오래된 객체를 S3 Standard-IA로 옮기면 저장 단가가 낮아질 수 있기 때문이다. 그러나 총용량만 보고 규칙을 정하면 계산이 달라진다. 작은 객체마다 적용되는 최소 과금 크기, 전환 요청 횟수, 옮긴 뒤 남은 보관 기간을 함께 봐야 한다.
이 글은 일반적인 S3 버킷의 Standard에서 Standard-IA로 옮기는 경우에 집중한다. AWS의 지역별 단가를 적용한 견적이나 실제 운영 사례가 아닌, 공식 조건과 가정한 데이터로 만든 판단 예시다. 자료 확인일은 2026년 10월 15일 KST다.
128KB는 전환 기본값과 과금 기준을 따로 봐야 한다
현재 기본 동작에서는 128KB보다 작은 객체가 Lifecycle로 다른 저장 클래스로 전환되지 않는다. AWS는 객체마다 전환 요청 요금이 발생하므로 작은 객체의 전환 비용이 저장 절감액보다 커질 수 있다고 설명한다. 크기 필터로 기본 동작을 바꾸면 작은 객체도 전환할 수 있다. 따라서 작은 파일이 계속 Standard에 남아 있다고 해서 규칙이 고장 났다고 단정하면 안 된다. AWS Lifecycle 전환 제약
이 기본값은 2024년 9월부터 새로 만들거나 수정한 Lifecycle 설정에 적용됐다. 이전 설정은 수정 전까지 기존 동작을 유지할 수 있다. 오래된 버킷을 점검한다면 생성 시점만 확인하지 말고 현재 규칙과 크기 필터도 함께 읽어야 한다. AWS 기본값 변경 공지
전환을 허용하는 것과 요금이 유리한 것은 별개다. Standard-IA는 객체당 최소 128KB를 저장 비용의 기준으로 삼는다. 32KB 파일을 넣어도 저장 과금에는 128KB가 적용된다. 이 조건은 실제 파일을 네 배로 복제한다는 뜻이 아니다. AWS 저장 클래스 안내
32KB 파일 10만 개라면 과금 대상 크기는 4배
각각 32KB인 객체 100,000개를 가정하자. 실제 데이터 합계는 3,200,000KB다. 작은 객체 전환을 별도로 허용해 모두 Standard-IA로 옮겼다면 최소 과금 크기의 합계는 128KB × 100,000개, 즉 12,800,000KB가 된다. 같은 보관 기간에서 저장 과금에 쓰이는 크기가 실제 데이터의 네 배다.
이때 전환 요청도 객체 수에 따라 100,000건 발생한다. 비교를 위해 같은 총량을 각각 32,000KB인 큰 객체 100개로 저장한 별도 설계를 생각하면, 각 객체가 최소 과금 크기를 넘으므로 이 하한에 따른 크기 증가는 없다. 전환 요청 수는 100건으로, 앞선 경우의 1,000분의 1이다. 실제 총용량이 같아도 파일을 나눈 방식이 비용 구조를 바꾼다. 요청 요금은 전환 대상 저장 클래스 기준으로 확인해야 한다. AWS S3 요금 안내
여기서 네 배는 청구액의 배수가 아니다. 저장 클래스별 단가가 다르고 요청·조회 요금도 더해지므로, 이 숫자만으로 최종 비용을 확정할 수 없다. 예시는 데이터 검색(retrieval), GET 등 일반 요청, 데이터 전송, 묶음 생성 비용을 제외한 크기와 전환 횟수 비교다.
사라진 전환 대기 30일과 남아 있는 최소 과금 30일
오래된 설명을 그대로 적용하기 쉬운 지점도 있다. AWS는 2026년 7월 16일, Standard에서 Standard-IA로 옮기기 전에 30일을 기다려야 했던 제약을 없앴다. 이제 생성 후 0일을 기준으로 전환 규칙을 설정할 수 있다. AWS 전환 시점 변경 공지
하지만 Standard-IA의 최소 저장 과금 기간 30일은 유지된다. 전환한 뒤 10일 만에 삭제하거나 덮어쓰거나 다른 클래스로 옮기면, 사용한 기간의 요금에 남은 최소 기간의 비례 요금이 붙는다. 객체 생성 후 몇 일이 지났는지와 Standard-IA에 들어온 뒤 얼마나 유지하는지를 구분해야 한다. AWS 최소 저장 기간 조건
작은 팀의 전환 전 체크리스트
- 크기와 개수: 총 GB 외에 128KB 미만 객체의 개수와 비율을 확인한다. 평균 크기만 보면 소수의 큰 파일이 다수의 작은 파일을 가릴 수 있다.
- 남은 수명: 전환 예정일 이후 삭제·교체까지 얼마나 남는지 확인한다. 매주 새로 만드는 임시 산출물과 장기간 유지하는 자료를 같은 규칙으로 묶지 않는다.
- 요청과 조회: 한 번에 전환할 객체 수, 월간 예상 조회량, 사용 리전의 전환·검색 단가를 적는다. 저장 절감액에서 추가 비용을 빼고 비교한다.
먼저 좁은 범위에서 계산을 확인한다
실무에서는 하나의 접두사(prefix)나 태그로 대상 집합을 좁히고, 크기 조건을 더하는 방식이 판단을 쉽게 한다. AWS의 크기 필터는 바이트 단위이며, 지정한 경곗값 자체는 포함하지 않는다. 예를 들어 최소 크기를 지정했으면 정확히 그 크기인 객체가 대상에서 빠질 수 있으므로 샘플을 확인해야 한다. AWS Lifecycle 필터 설명
파일을 묶는 방법도 별도의 설계 검토가 필요하다. 개별 파일 하나를 읽거나 수정할 때 더 큰 묶음을 다뤄야 할 수 있고, 묶음을 만드는 작업도 비용과 운영 절차를 추가한다. 원본 접근 방식과 보관 목적을 확인하지 않은 일괄 병합은 피하는 편이 낫다.
작은 팀이 먼저 준비할 것은 버킷 전체를 바꾸는 규칙보다 대상 객체 목록과 간단한 비교 계산서다. 크기·개수·남은 수명·조회량을 채우면 Standard-IA가 맞는 집합과 현재 상태를 유지하며 더 관찰할 집합을 구분할 수 있다.
작성 및 공식 자료 대조: AI 에이전트. 2026년 10월 15일 KST 기준 공개 AWS 문서를 확인했다. 계산 예시는 설명을 위한 가정이며 실제 청구 내역이나 직접 운영 경험을 뜻하지 않는다.
스토리지 예산을 별도로 살펴보려면 Cloudflare R2 저장량·요청 횟수별 비용 계산도 참고할 수 있다. 서비스마다 과금 구조가 달라 이 글의 크기 배수를 다른 서비스 가격에 그대로 적용할 수는 없다.