S3 Intelligent-Tiering은 왜 많이 선택될까?

접근 패턴을 몰라도 비용을 줄여주는 S3의 자동 최적화 전략

AWS에서 S3를 처음 배울 때는 보통 S3 Standard부터 시작한다. 가장 일반적이고, 성능도 좋고, 가용성도 높고, 무엇보다 이해하기 쉽기 때문이다. 하지만 실제 운영 환경으로 들어가면 이야기가 조금 달라진다. 처음에는 자주 접근할 것 같았던 데이터가 몇 주 뒤에는 거의 읽히지 않기도 하고, 반대로 거의 보관만 할 줄 알았던 데이터가 갑자기 분석 작업이나 고객 요청 때문에 다시 자주 읽히기도 한다.

 

이때 고민이 시작된다.

“이 데이터를 계속 Standard에 둬야 할까?”
“30일 뒤에 Standard-IA로 옮겨도 될까?”
“Glacier로 보내면 비용은 줄겠지만, 나중에 바로 읽어야 하면 어떡하지?”
“수명 주기 정책을 폴더 단위로 걸면 모든 객체에 똑같이 적용되는데, 객체마다 접근 패턴이 다르면 어떻게 하지?”

 

 

이런 고민을 줄여주는 스토리지 클래스가 S3 Intelligent-Tiering이다. 이름 그대로 S3가 객체의 접근 패턴을 감시하고, 접근 빈도에 따라 적절한 내부 티어로 자동 이동시켜주는 방식이다. 사용자가 객체마다 “이건 자주 접근할 데이터”, “이건 30일 뒤부터 잘 안 볼 데이터”, “이건 90일 뒤에는 거의 보관용 데이터”라고 직접 판단하지 않아도 된다.

 

한 문장으로 정리하면 이렇다.

S3 Intelligent-Tiering은 접근 패턴을 예측하기 어려운 데이터를 위해, S3가 객체 단위로 사용 빈도를 감시하고 자동으로 비용을 최적화해주는 스토리지 클래스다.

 

 

 

 

S3 Standard는 “항상 책상 위에 올려둔 문서”와 같다. 언제든 바로 볼 수 있지만, 모든 문서를 책상 위에 두면 공간 비용이 많이 든다.
Standard-IA는 “책상 옆 캐비닛에 넣은 문서”와 비슷하다. 보관 비용은 조금 줄지만, 꺼낼 때 비용이 생길 수 있다.
Glacier Flexible Retrieval이나 Deep Archive는 “창고에 보낸 문서”에 가깝다. 보관 비용은 매우 낮지만, 꺼내려면 시간이 걸린다.
Intelligent-Tiering은 “문서 사용 빈도를 보고 알아서 책상, 캐비닛, 가까운 보관함으로 옮겨주는 관리자”라고 볼 수 있다. 자주 보는 문서는 책상 위에 두고, 한동안 안 본 문서는 캐비닛으로 옮기고, 오래 안 본 문서는 더 저렴한 보관 위치로 옮긴다. 그런데 갑자기 다시 필요해지면 다시 책상 위로 올려준다.

 

---

S3 스토리지 클래스 선택이 어려운 이유

S3에는 여러 스토리지 클래스가 있다. 자주 접근하는 데이터에는 S3 Standard가 적합하고, 자주 접근하지 않지만 필요할 때 빠르게 읽어야 하는 데이터에는 Standard-IA나 One Zone-IA를 고려할 수 있다. 아카이브 성격이 강하면 Glacier Instant Retrieval, Glacier Flexible Retrieval, Glacier Deep Archive 같은 선택지도 있다.

 

문제는 데이터의 미래 접근 패턴을 사람이 정확히 맞히기 어렵다는 점이다.

 

예를 들어 웹 서비스의 이미지 파일을 생각해보자. 업로드 직후에는 사용자가 자주 본다. 하지만 시간이 지나면 대부분의 이미지는 거의 접근되지 않는다. 그런데 일부 이미지는 검색 결과에 노출되거나, 이벤트 페이지에 다시 사용되거나, 고객 문의 때문에 다시 읽힐 수 있다. 모든 이미지를 Standard에 두면 비용이 비싸고, 모든 이미지를 IA나 Glacier로 빨리 옮기면 나중에 읽을 때 검색 비용이나 복원 지연이 문제가 될 수 있다.

 

로그 데이터도 마찬가지다. 애플리케이션 로그, 보안 로그, 분석 로그는 처음 며칠 또는 몇 주 동안 자주 조회될 수 있다. 장애 분석이나 보안 사고 조사가 끝나면 접근 빈도는 급격히 떨어진다. 하지만 감사, 포렌식, 규정 준수, 고객 이슈 대응 때문에 몇 달 뒤 다시 조회할 가능성도 있다.

 

데이터 레이크도 비슷하다. 어떤 파티션은 매일 분석 쿼리에 사용되지만, 어떤 파티션은 거의 읽히지 않는다. 같은 버킷, 같은 prefix 안에 있어도 객체마다 사용 빈도가 다를 수 있다.

 

이런 환경에서 Lifecycle 정책만으로 완벽한 최적화를 하기는 쉽지 않다. Lifecycle은 강력하지만 기본적으로 규칙 기반이다. “생성 후 30일이 지나면 Standard-IA로 이동”, “90일이 지나면 Glacier로 이동” 같은 식으로 정한다. 데이터의 실제 접근 여부보다는 객체의 나이나 prefix, 태그 같은 조건을 기준으로 움직인다.

 

반면 Intelligent-Tiering은 “시간이 지났는가?”보다 “실제로 접근되었는가?”를 기준으로 판단한다. 이 차이가 중요하다.

---

Intelligent-Tiering이 많이 선택되는 이유

1. 접근 패턴을 몰라도 시작할 수 있다

S3 Intelligent-Tiering의 가장 큰 장점은 접근 패턴을 몰라도 된다는 것이다. 운영자가 모든 객체의 사용 패턴을 예측하지 않아도 된다. 신규 서비스, 데이터 레이크, 사용자 업로드 콘텐츠, 백업성 데이터, 분석 데이터처럼 접근 패턴이 변하거나 예측하기 어려운 데이터에 특히 유용하다.

 

S3 Standard는 안전한 선택이지만 장기적으로 비쌀 수 있다. Standard-IA는 저장 비용은 낮지만 읽을 때 검색 요금이 붙는다. Glacier 계열은 더 저렴하지만 복원 시간이나 최소 보관 기간을 고려해야 한다. Intelligent-Tiering은 이런 선택의 부담을 줄인다.

처음에는 Frequent Access tier에 저장하고, 일정 기간 접근이 없으면 자동으로 더 저렴한 내부 티어로 이동한다. 나중에 다시 접근되면 다시 Frequent Access tier로 올라온다. 운영자는 “언제 옮길지”를 세밀하게 판단하지 않아도 된다.

2. 객체 단위로 판단한다

Intelligent-Tiering의 핵심은 객체 단위 최적화다.

 

Lifecycle 정책을 prefix 단위로 설정하면 같은 폴더 안의 객체들이 비슷하게 이동한다. 하지만 실제로는 같은 경로에 있어도 어떤 객체는 자주 읽히고, 어떤 객체는 거의 읽히지 않는다. Intelligent-Tiering은 각 객체의 접근 패턴을 개별적으로 감시한다.

 

예를 들어 다음과 같은 데이터가 있다고 해보자.

• images/2026/01/a.jpg는 매일 접근됨
• images/2026/01/b.jpg는 40일 동안 접근 없음
• images/2026/01/c.jpg는 100일 동안 접근 없음

세 객체가 같은 prefix에 있더라도 Intelligent-Tiering은 동일하게 처리하지 않는다. 자주 접근되는 객체는 Frequent Access tier에 남고, 30일 이상 접근되지 않은 객체는 Infrequent Access tier로 이동하며, 90일 이상 접근되지 않은 객체는 Archive Instant Access tier로 이동한다.

 

이 구조가 비용 최적화 측면에서 매우 유리하다. 사람이 폴더 단위로 뭉뚱그려 판단하지 않고, S3가 객체마다 접근 여부를 기준으로 판단하기 때문이다.

3. Frequent, Infrequent, Archive Instant는 성능 저하 없이 사용할 수 있다

Intelligent-Tiering의 자동 티어는 크게 세 가지로 이해하면 된다.

• Frequent Access tier
• Infrequent Access tier
• Archive Instant Access tier

이 세 티어는 자동으로 관리되며, 낮은 지연시간과 높은 처리량을 제공한다. 즉 Infrequent Access tier나 Archive Instant Access tier로 내려갔다고 해서 애플리케이션이 복원 요청을 먼저 해야 하는 것은 아니다. 일반적인 GET 요청으로 바로 읽을 수 있다.

 

이 점이 Glacier Flexible Retrieval이나 Glacier Deep Archive와의 큰 차이다. Glacier Flexible Retrieval이나 Deep Archive는 비용은 낮지만 즉시 읽는 용도가 아니다. 객체를 먼저 복원해야 하고, 복원 시간도 고려해야 한다. 반면 Intelligent-Tiering의 Archive Instant Access tier는 이름 그대로 즉시 접근 가능한 아카이브 성격의 계층이다.

 

그래서 “비용은 줄이고 싶지만, 갑자기 읽어야 할 수도 있는 데이터”에 Intelligent-Tiering이 잘 맞는다.

4. 검색 요금이 없다

Standard-IA, One Zone-IA, Glacier Instant Retrieval 같은 스토리지 클래스는 저장 비용은 낮지만 데이터를 읽을 때 검색 요금이 붙을 수 있다. 따라서 접근 빈도가 예상보다 높아지면 저장 비용 절감분보다 검색 비용이 더 부담될 수 있다.

 

Intelligent-Tiering은 내부 티어 간 이동 후에도 검색 요금이 없다. Infrequent Access tier나 Archive Instant Access tier에 있던 객체를 읽더라도 일반적인 검색 요금이 부과되지 않는다. 또한 Intelligent-Tiering 내부에서 티어가 이동할 때 별도의 티어링 요금도 없다.

 

물론 S3 요청 비용, 데이터 전송 비용, PUT/COPY/Lifecycle 전환 비용 같은 일반적인 비용 요소는 별도로 고려해야 한다. 하지만 “IA로 내렸더니 읽을 때마다 검색 비용이 붙는다”는 부담이 없다는 점은 Intelligent-Tiering의 큰 장점이다.

5. 최소 보관 기간 부담이 작다

Standard-IA나 One Zone-IA는 최소 보관 기간을 고려해야 한다. Glacier 계열도 최소 보관 기간이 있다. 너무 빨리 삭제하거나 다른 스토리지 클래스로 옮기면 남은 기간에 대한 비용이 발생할 수 있다.

 

Intelligent-Tiering은 일반적인 자동 티어 운영에서 최소 보관 기간 부담이 없다. 이 점은 데이터 수명이 불확실한 서비스에서 특히 유용하다. 사용자 업로드 파일처럼 언제 삭제될지 모르거나, 분석 데이터처럼 프로젝트 상황에 따라 보관 기간이 달라지는 경우에는 최소 보관 기간이 없는 구조가 운영상 편하다.

---

Intelligent-Tiering은 어떻게 감시하고 결정할까?

Intelligent-Tiering의 동작을 이해하려면 “스토리지 클래스”와 “내부 access tier”를 구분해야 한다.

 

객체의 스토리지 클래스는 S3 Intelligent-Tiering이다. 객체가 30일 뒤에 Infrequent Access tier로 이동하거나 90일 뒤에 Archive Instant Access tier로 이동하더라도, 사용자가 보는 스토리지 클래스 자체가 Standard-IA나 Glacier Instant Retrieval로 바뀌는 것은 아니다.

 

즉 객체는 계속 Intelligent-Tiering 스토리지 클래스에 속해 있고, 그 안에서 내부 access tier만 바뀐다.

 

기본 흐름

객체가 S3 Intelligent-Tiering으로 저장되면 처음에는 Frequent Access tier에서 시작한다. 이후 S3가 객체의 접근 패턴을 감시한다.

 

일정 기간 접근이 없으면 다음과 같이 이동한다.

조건	이동 결과
객체 업로드 또는 전환 직후	Frequent Access tier
30일 연속 접근 없음	Infrequent Access tier
90일 연속 접근 없음	Archive Instant Access tier
Infrequent 또는 Archive Instant 상태에서 다시 접근	Frequent Access tier로 자동 복귀

 

이 흐름을 의사코드로 표현하면 다음과 같다.

객체가 S3 Intelligent-Tiering에 저장됨
  → Frequent Access tier에서 시작

객체 크기가 128KB 미만이면
  → 자동 티어링 대상 아님
  → 감시하지 않음
  → 감시 및 자동화 요금 없음
  → Frequent Access tier 요금으로 유지

객체 크기가 128KB 이상이면
  → S3가 객체 단위 접근 패턴 감시

30일 연속 접근 없음
  → Infrequent Access tier로 이동

90일 연속 접근 없음
  → Archive Instant Access tier로 이동

Infrequent Access 또는 Archive Instant Access 상태에서 객체 접근 발생
  → Frequent Access tier로 자동 이동

 

여기서 중요한 기준은 “연속 미접근 기간”이다. 단순히 객체가 생성된 지 30일이 지났다고 무조건 이동하는 것이 아니라, 접근되지 않은 기간을 기준으로 판단한다.

 

어떤 행위가 접근으로 인정될까?

S3가 Intelligent-Tiering의 티어 이동을 판단할 때 모든 API 호출을 동일하게 접근으로 보지는 않는다. 실제 객체 데이터를 읽거나 쓰는 성격의 작업이 접근으로 인정된다.

 

예를 들어 일반적으로 다음과 같은 작업은 객체가 접근된 것으로 간주된다.

• 콘솔에서 객체 다운로드
• 콘솔에서 객체 복사
• GetObject
• PutObject
• CopyObject
• UploadPartCopy
• RestoreObject
• CompleteMultipartUpload
• S3 Batch Replication에 의한 복제

반면 다음과 같은 작업은 객체를 Frequent Access tier로 올리는 접근으로 보지 않는다.

• HeadObject
• GetObjectTagging
• PutObjectTagging
• ListObjects
• ListObjectsV2
• ListObjectVersions
• UpdateObjectEncryption

이 차이는 실무에서 중요하다. 예를 들어 단순히 목록을 조회하거나 메타데이터를 확인했다고 해서 모든 객체가 다시 Frequent Access tier로 올라오면 비용 최적화가 어려워진다. 그래서 S3는 실제 데이터 접근과 관리성 작업을 구분한다.

 

파일 내용을 실제로 읽거나 쓰는 행동은 접근으로 보고,
단순 목록 조회나 태그 조회 같은 관리성 작업은 접근으로 보지 않는다.

---

선택형 아카이브 티어까지 켜면 어떻게 될까?

Intelligent-Tiering은 기본적으로 세 개의 자동 티어를 제공한다.

• Frequent Access tier
• Infrequent Access tier
• Archive Instant Access tier

여기까지는 즉시 접근 가능한 계층이다. 하지만 더 낮은 비용을 원하고, 데이터를 즉시 읽을 필요가 없다면 선택형 아카이브 티어를 추가로 활성화할 수 있다.

 

선택형 아카이브 티어는 다음과 같다.

• Archive Access tier
• Deep Archive Access tier

Archive Access tier는 최소 90일 이상 접근이 없는 객체를 대상으로 사용할 수 있고, Deep Archive Access tier는 최소 180일 이상 접근이 없는 객체를 대상으로 사용할 수 있다. 설정에 따라 이 기간은 더 길게 조정할 수도 있다.

 

다만 이 두 티어는 즉시 접근용이 아니다. 객체가 Archive Access나 Deep Archive Access tier에 들어가면 읽기 전에 RestoreObject를 통해 복원해야 한다. 따라서 애플리케이션이 즉시 파일을 읽어야 하는 구조라면 신중하게 사용해야 한다.

정리하면 다음과 같다.

구분	즉시 접근 가능 여부	설명
Frequent Access	가능	기본 티어
Infrequent Access	가능	30일 미접근 후 자동 이동
Archive Instant Access	가능	90일 미접근 후 자동 이동
Archive Access	복원 필요	선택 활성화, 분~시간 단위 복원
Deep Archive Access	복원 필요	선택 활성화, 장기 보관용

 

운영 환경에서는 Archive Access와 Deep Archive Access를 무조건 켜기보다, 데이터의 사용 방식에 따라 결정해야 한다. 특히 사용자 다운로드, 웹 서비스 이미지, 분석 쿼리 대상 데이터처럼 즉시 접근이 필요한 데이터라면 기본 세 티어만 사용하는 것이 더 안전할 수 있다.

---

감시료는 어떻게 계산될까?

Intelligent-Tiering은 객체의 접근 패턴을 감시하고 자동 이동을 수행하기 때문에 월별 감시 및 자동화 요금이 있다. US East, N. Virginia 기준으로 감시 및 자동화 요금은 객체 1,000개당 월 0.0025달러다.

객체 수로 환산하면 다음과 같다.

객체 수	월 감시 및 자동화 요금
1,000개	0.0025달러
100,000개	0.25달러
1,000,000개	2.50달러
10,000,000개	25.00달러
100,000,000개	250.00달러

 

이 비용만 보면 매우 작아 보인다. 하지만 객체 수가 수억 개 이상으로 커지면 무시할 수 없는 비용이 될 수 있다. 특히 작은 로그 파일, 썸네일, IoT 이벤트 조각처럼 객체 수가 매우 많은 구조에서는 반드시 계산해야 한다.

 

다만 128KB 미만 객체는 자동 티어링 대상이 아니며 감시 및 자동화 요금도 부과되지 않는다. 이러한 작은 객체는 Intelligent-Tiering에 저장할 수는 있지만, 항상 Frequent Access tier 요금으로 유지된다.

 

그래서 비용을 볼 때는 “전체 용량”뿐 아니라 “객체 수”도 함께 봐야 한다. S3 비용 최적화에서 흔히 실수하는 부분이 바로 이 지점이다. 10TB를 저장하더라도 객체가 10만 개인 경우와 10억 개인 경우는 감시료 관점에서 완전히 다르다.

---

Lifecycle과 Intelligent-Tiering은 경쟁 관계일까?

Lifecycle 정책과 Intelligent-Tiering은 서로 경쟁하는 기능이라기보다 목적이 다르다.

 

Lifecycle은 정책 기반 자동화다. 예를 들어 “logs/ prefix 아래 객체는 30일 뒤 Standard-IA, 90일 뒤 Glacier Deep Archive로 이동”처럼 명확한 규칙을 적용한다. 데이터의 수명과 접근 패턴을 이미 알고 있다면 Lifecycle이 더 단순하고 저렴할 수 있다.

 

반면 Intelligent-Tiering은 관찰 기반 자동화다. S3가 객체별 접근 패턴을 감시하고, 접근이 없으면 자동으로 더 저렴한 티어로 내린다. 접근 패턴이 불확실하거나 객체마다 다를 때 유리하다.

 

둘을 비교하면 다음과 같다.

구분	Lifecycle	Intelligent-Tiering
기준	생성 후 경과일, prefix, 태그 등	객체별 접근 패턴
장점	예측 가능한 데이터에 강함	예측 어려운 데이터에 강함
단점	실제 접근 여부와 무관하게 이동 가능	감시 및 자동화 요금 존재
적합한 예	로그, 백업, 규정상 장기 보관 데이터	데이터 레이크, 사용자 업로드, 신규 서비스 데이터
운영 방식	사람이 규칙 설계	S3가 객체별 자동 판단

 

접근 패턴이 명확하면 Lifecycle,
접근 패턴이 불확실하면 Intelligent-Tiering

---

어떤 상황에서 Intelligent-Tiering을 선택하면 좋을까?

신규 서비스의 사용자 업로드 데이터

신규 서비스에서는 어떤 데이터가 얼마나 자주 읽힐지 예측하기 어렵다. 사용자가 업로드한 이미지, 문서, 동영상, 첨부파일은 초기에 자주 접근되다가 시간이 지나면서 접근 빈도가 줄어드는 경우가 많다. 하지만 일부 콘텐츠는 나중에 다시 인기를 얻거나 고객 문의로 조회될 수 있다.

 

이런 경우 처음부터 Standard-IA나 Glacier로 보내는 것은 부담스럽다. Intelligent-Tiering을 사용하면 초기에 Standard처럼 빠르게 접근하다가, 접근이 줄어든 객체만 자동으로 저렴한 티어로 내려갈 수 있다.

 

데이터 레이크와 분석 데이터

데이터 레이크에는 다양한 데이터가 섞인다. 어떤 데이터는 매일 분석 쿼리에 사용되고, 어떤 데이터는 과거 이력으로만 남는다. 파티션, 날짜, 고객, 서비스별로 접근 빈도가 다를 수 있다.

 

Lifecycle만으로 모든 데이터를 정확히 분류하려면 규칙이 복잡해진다. Intelligent-Tiering은 객체 단위로 접근 패턴을 감시하므로 데이터 레이크처럼 접근 빈도가 다양한 환경에 잘 맞는다.

 

보안 로그와 감사 데이터

보안 로그는 사고 직후에는 자주 조회되지만, 시간이 지나면 거의 조회되지 않는다. 그러나 규정 준수나 침해 사고 조사 때문에 나중에 다시 필요할 수 있다. 즉 “평소에는 잘 안 보지만, 필요할 때는 바로 접근해야 하는 데이터”에 가깝다.

 

이런 경우 Archive Instant Access까지 자동으로 내려가도 즉시 접근 가능한 Intelligent-Tiering이 유용할 수 있다. 단, 선택형 Archive Access나 Deep Archive Access를 켜는 경우에는 복원 시간이 필요하므로 보안 관제나 사고 대응 요구사항을 먼저 확인해야 한다.

 

접근 패턴을 아직 모르는 마이그레이션 데이터

온프레미스에서 S3로 데이터를 대량 이전할 때도 Intelligent-Tiering은 좋은 출발점이 될 수 있다. 기존 파일 서버나 NAS의 접근 패턴을 정확히 모르는 경우가 많기 때문이다.

 

무작정 Standard에 두면 비용이 높고, 무작정 Glacier로 보내면 나중에 업무 중단이 생길 수 있다. Intelligent-Tiering을 기본값으로 두면 실제 접근 패턴을 보면서 자동으로 비용을 낮출 수 있다.

 

---

언제 Intelligent-Tiering을 피해야 할까?

Intelligent-Tiering이 항상 정답은 아니다.

데이터가 항상 자주 읽힌다면

모든 객체가 계속 자주 읽힌다면 Intelligent-Tiering의 장점이 크지 않다. 객체가 Frequent Access tier에 계속 남아 있을 가능성이 높기 때문이다. 이 경우 S3 Standard와 비슷한 저장 비용을 내면서 감시료만 추가될 수 있다.

 

웹 서비스의 핵심 정적 자산, 매번 읽히는 모델 파일, 빈번히 참조되는 설정 파일처럼 항상 hot data라면 Standard가 더 단순할 수 있다.

 

접근 패턴이 명확하다면

예를 들어 “이 로그는 7일 동안만 자주 보고, 30일 뒤에는 거의 보지 않으며, 1년 뒤에는 삭제한다”처럼 수명 주기가 명확한 데이터는 Lifecycle이 더 적합할 수 있다.

 

정해진 규칙대로 이동하면 되는데 굳이 감시료를 내면서 Intelligent-Tiering을 사용할 필요가 없을 수 있다.

 

매우 작은 객체가 너무 많다면

128KB 미만 객체는 Intelligent-Tiering에 저장할 수 있지만 자동 티어링 대상은 아니다. 감시료도 부과되지 않지만, 항상 Frequent Access tier 요금으로 유지된다. 즉 작은 객체가 많다고 해서 Intelligent-Tiering이 자동으로 비용을 크게 줄여주지는 않는다.

 

작은 객체가 매우 많은 환경에서는 객체 병합, 압축, 파티셔닝, 로그 포맷 개선 같은 데이터 구조 개선이 더 중요할 수 있다.

 

즉시 접근이 필요한데 선택형 Deep Archive를 켜는 경우

Intelligent-Tiering의 기본 자동 티어인 Archive Instant Access는 즉시 접근 가능하다. 하지만 선택형 Archive Access와 Deep Archive Access는 복원 과정이 필요하다. 애플리케이션이 객체를 바로 읽어야 하는 구조인데 Deep Archive Access를 켜면 장애처럼 보이는 상황이 생길 수 있다.

 

따라서 선택형 아카이브 티어는 “정말 복원 지연을 받아들일 수 있는 데이터”에만 적용하는 것이 안전하다.

 

---

실무 적용 예시

새로 업로드하는 객체를 Intelligent-Tiering으로 저장하려면 PUT 요청 시 스토리지 클래스를 지정할 수 있다.

aws s3api put-object \
  --bucket my-bucket-name \
  --key uploads/sample.jpg \
  --body ./sample.jpg \
  --storage-class INTELLIGENT_TIERING

 

기존 객체를 Intelligent-Tiering으로 복사하면서 스토리지 클래스를 바꿀 수도 있다.

aws s3api copy-object \
  --bucket my-bucket-name \
  --copy-source my-bucket-name/uploads/sample.jpg \
  --key uploads/sample.jpg \
  --storage-class INTELLIGENT_TIERING \
  --metadata-directive COPY

 

버킷의 특정 prefix에 대해 Lifecycle 정책으로 Intelligent-Tiering 전환을 적용할 수도 있다. 예를 들어 uploads/ 아래 객체를 생성 후 0일 뒤 Intelligent-Tiering으로 전환하려면 다음과 같은 정책을 사용할 수 있다.

{
  "Rules": [
    {
      "ID": "transition-to-intelligent-tiering",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "uploads/"
      },
      "Transitions": [
        {
          "Days": 0,
          "StorageClass": "INTELLIGENT_TIERING"
        }
      ]
    }
  ]
}

 

적용은 다음과 같이 할 수 있다.

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket-name \
  --lifecycle-configuration file://lifecycle.json

 

실무에서는 전체 버킷에 무조건 적용하기보다 prefix나 태그 기준으로 나누는 것이 좋다. 예를 들어 사용자 업로드 파일은 Intelligent-Tiering, 정적 웹 리소스는 Standard, 명확한 장기 보관 로그는 Lifecycle을 통해 Glacier Deep Archive로 보내는 식이다.

---

비용 판단을 위한 간단한 체크리스트

Intelligent-Tiering을 적용하기 전에 다음 질문을 해보면 좋다.

1. 이 데이터의 접근 패턴을 정확히 예측할 수 있는가?
2. 객체마다 접근 빈도가 크게 다른가?
3. 나중에 갑자기 다시 읽을 가능성이 있는가?
4. 검색 요금이 예측 불가능한 것이 부담되는가?
5. 객체 수가 지나치게 많아 감시료가 커지지는 않는가?
6. 128KB 미만의 작은 객체가 대부분은 아닌가?
7. 선택형 Archive Access나 Deep Archive Access를 켜도 복원 지연을 감당할 수 있는가?
8. Lifecycle로 더 단순하고 저렴하게 해결할 수 있는 데이터는 아닌가?

이 질문에 대해 “접근 패턴을 잘 모르겠다”, “객체마다 사용 빈도가 다르다”, “다시 읽을 가능성이 있다”, “운영자가 매번 정책을 조정하기 어렵다”라는 답이 많다면 Intelligent-Tiering이 좋은 선택지가 될 가능성이 높다.

 

반대로 “항상 자주 읽는다”, “정확히 90일 뒤부터는 절대 안 읽는다”, “1년 보관 후 삭제한다”처럼 패턴이 명확하다면 Standard나 Lifecycle 기반 전환이 더 적합할 수 있다.

---

결론: Intelligent-Tiering은 모르는 것을 인정하는 설계다

클라우드 비용 최적화에서 가장 위험한 것은 잘못된 확신이다. “이 데이터는 앞으로 안 볼 거야”라고 생각했는데 실제로는 자주 읽힐 수 있고, “이 데이터는 계속 필요할 거야”라고 생각했는데 몇 달 동안 아무도 보지 않을 수 있다.

 

S3 Intelligent-Tiering은 이런 불확실성을 전제로 설계된 스토리지 클래스다. 사람이 모든 접근 패턴을 예측하지 않고, S3가 객체 단위로 접근 여부를 감시한 뒤 자동으로 적절한 티어로 옮긴다.

 

그래서 Intelligent-Tiering은 단순히 “저렴한 스토리지 클래스”가 아니다. 더 정확히 말하면 “예측이 어려운 데이터를 위한 자동 비용 최적화 전략”이다.

 

이렇게 정리하면 좋다.

• 접근 패턴이 명확하면 Lifecycle을 설계한다.
• 접근 패턴이 불확실하면 Intelligent-Tiering을 검토한다.
• 즉시 접근이 필요하면 기본 자동 티어까지만 사용한다.
• 장기 보관이고 복원 지연을 감당할 수 있으면 선택형 Archive / Deep Archive까지 고려한다.
• 객체 수와 128KB 미만 객체 비율은 반드시 확인한다.

S3 비용 최적화의 핵심은 무조건 가장 싼 스토리지 클래스를 고르는 것이 아니다. 데이터의 접근 방식, 복원 요구사항, 요청 비용, 운영 복잡도까지 함께 고려해 전체 비용을 줄이는 것이다. 그 관점에서 S3 Intelligent-Tiering은 “운영자가 미래를 정확히 맞히지 않아도 되는” 매우 실용적인 선택지다.