🔥 스토리지 클래스: Standard·IA·Glacier의 차이

처음 S3 청구서를 줄여 보겠다고 마음 먹었을 때 가장 먼저 떠올린 길은 단순했다. 잘 안 읽는 데이터를 IA 클래스로 옮기면 단가가 절반으로 줄어드니, Lifecycle 한 줄로 30일 지난 객체를 통째로 옮기면 청구서가 절반이 되리라. 한 달 뒤 명세서를 다시 봤을 때 청구서는 거의 같은 숫자를 적고 있었다. 그 결과를 시작점으로 이 글을 짚는다.

S3란 무엇인가: 오브젝트 스토리지의 구조에서 주요 storage class 8가지를 한 줄씩 짚어 두었다. Standard·Intelligent-Tiering·Standard-IA·One Zone-IA·Glacier 3종(Instant Retrieval·Flexible Retrieval·Deep Archive)·Express One Zone. 이외에도 deprecated된 Reduced Redundancy Storage와 on-prem용 S3 Outposts storage class가 docs에 함께 나열되지만, 이 글은 위 8가지 일반 클래스만 다룬다. 각 이름이 어떤 형태의 클래스인지는 그 글에서 정의했다. 오늘은 한 발 더 들어가서 왜 그 형태인지, 그리고 언제 클래스를 옮기지 말아야 하는지를 짚는다. 단가만 보고 IA로 한 번 옮긴 결과로 청구서가 더 늘어나는 경우가 있고, Intelligent-Tiering이 모든 워크로드의 답이 아닌 경우가 있다.

6개 클래스의 좌표, 단가와 접근 지연이 만드는 4분면

가장 먼저 떠올려야 할 그림은 단가와 접근 지연 두 축으로 6개 클래스가 어디에 놓이는지다. 단가는 AWS S3 pricing 페이지의 US East 기준 GB당 월 단가 스냅샷을 그대로 쓴다.

가로축에 접근 지연을 두고 세로축에 단가를 두면 좌상단(Standard)에서 우하단(Deep Archive)까지 클래스들을 한 줄로 길게 늘어놓을 수 있다. 좌상단은 비싸지만 즉시 응답하는 클래스, 우하단은 싸지만 한참 기다려야 하는 클래스. Standard와 Deep Archive 사이의 단가 차이는 약 23배다. Standard가 Deep Archive의 약 23배 가격이고, 뒤집으면 Deep Archive가 Standard의 약 4.3% 가격이라는 뜻이다. 한 자릿수도 아니고 두 자릿수 차이가 두 클래스 사이에 굳어 있다.

같은 ms 응답 클래스 안에서도 세 단계로 나뉜다. Standard와 Standard-IA의 단가 차이는 약 1.84배고, Standard와 Glacier Instant Retrieval은 약 5.75배다. 모두 즉시 응답이지만 단가가 차례로 내려간다. 차이를 만드는 건 단가가 아니라 부속 비용이다. 최소 보관일, retrieval 요금, transition 요청 요금. 단가만 보고 옮겨 갔다가 부속 비용에서 차이가 나는 부분이 청구서를 다시 부풀리는 함정이다.

One Zone-IA는 한 곳만 다르다. Standard-IA와 형태는 같은데 데이터를 한 AZ에만 둔다. 단가가 더 싸지만 그 AZ가 통째로 무너지면 데이터를 잃는다. 공식 docs는 가용성을 99.5% (designed for)로 표기한다. Standard-IA의 99.9%보다 한 자릿수 낮다 (SLA 환불 임계치는 별도 S3 SLA 페이지에 명시). 재생성 가능한 데이터(다른 곳에 사본이 있는 derived 데이터, 빌드 산출물, 캐시) 외에는 권하지 않는다.

Lifecycle Rule Transition, 시간이 흐른 뒤 자동으로 옮기는 길

PUT 시점에 클래스를 정할 수도 있다. PUT Object 요청 헤더에 x-amz-storage-class: STANDARD_IA처럼 한 줄을 넣으면 처음부터 그 클래스로 들어간다. 하지만 일반적인 패턴은 시간이 흐른 뒤 자동으로 옮기는 길이다. 새 객체는 처음에 Standard로 들어가서 자주 GET을 받다가, 한 달이 지나면 read 빈도가 내려가고, 90일이 지나면 거의 GET이 없다. 이 패턴을 Lifecycle Rule의 Transition 액션으로 표현한다.

{
  "Rules": [
    {
      "ID": "log-archival",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ]
    }
  ]
}

{
  "Rules": [
    {
      "ID": "log-archival",
      "Filter": { "Prefix": "logs/" },
      "Status": "Enabled",
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER" },
        { "Days": 365, "StorageClass": "DEEP_ARCHIVE" }
      ]
    }
  ]
}

생성 30일 뒤에 Standard-IA로, 90일 뒤에 Glacier Flexible Retrieval로, 1년 뒤에 Deep Archive로. 한 객체는 이 한 줄 위를 시간 축에 따라 미끄러져 내려간다.

여기서 한 가지 공식 docs가 명시하는 함정이 따라온다.

"Objects smaller than 128 KB will not transition by default to any storage class."

128 KB 미만 객체는 기본 동작상 어떤 클래스로도 자동 전이하지 않는다. 이 동작은 2024년 9월부터 default다. 이유는 한 줄로 정해 두었다. 객체당 한 번씩 transition 요청 요금을 청구하기 때문에, 작은 객체는 storage 절감액보다 transition 요금이 더 클 수 있어서다. Lifecycle Rule에 ObjectSizeGreaterThan 또는 ObjectSizeLessThan 필터를 넣지 않는 한, 작은 객체는 그 위치에 그대로 머문다. 1억 개의 8 KB 로그 fragment를 IA로 옮기려고 한 줄을 적어 두었어도 자동으로는 작동하지 않는다는 뜻이다.

또 한 가지가 따라온다. Standard-IA와 One Zone-IA에는 최소 보관일 30일이 있다. 공식 docs는 Lifecycle Rule이 30일 미만에 IA로 transition을 시도할 수 없게 막아 두었다고 명시한다.

"Before you transition objects to S3 Standard-IA or S3 One Zone-IA, you must store them for at least 30 days in Amazon S3."

Standard로 4일을 두었다가 IA로 옮기는 Lifecycle Rule은 만들 수 없다. Glacier 3종도 마찬가지로 더 긴 최소 보관일이 정해져 있어서, Glacier Instant Retrieval과 Flexible Retrieval은 90일, Deep Archive는 180일, 한 객체를 짧은 시간 안에 여러 클래스로 빠르게 흘려보내는 형태는 만들 수 없다.

마지막 한 가지. 일방통행이다. Glacier Deep Archive에서는 다른 클래스로의 Transition Rule을 만들 수 없다. Glacier Flexible Retrieval에서는 Deep Archive로만 갈 수 있고 Standard 쪽으로 못 돌아온다. Lifecycle은 시간 축의 한 방향 미끄럼틀이다. cold 쪽으로만 진행한다.

Storage Class Analysis, 자동 전이의 근거를 측정하는 도구

"30일 뒤에 IA로 보낸다"는 결정의 근거가 어디서 오는가. 감으로 정한 30이 아니라 실제 액세스 패턴을 측정해서 정해야 한다. AWS는 이 위치에 Storage Class Analysis라는 도구를 두었다. 공식 docs가 한 줄로 끝낸다.

"This new Amazon S3 analytics feature observes data access patterns to help you determine when to transition less frequently accessed STANDARD storage to the STANDARD_IA storage class."

여기서 짚어야 하는 단어가 두 개다. 하나는 STANDARD storage. Storage Class Analysis는 Standard 클래스에 들어 있는 객체만 관찰한다. Glacier 클래스에 있는 객체는 분석 대상이 아니라는 뜻이다. 다른 하나는 STANDARD_IA storage class. 추천도 Standard-IA로의 전이만 한다. Glacier로 언제 옮길지를 추천해 주는 도구가 아니다.

분석은 버킷 전체에 켤 수도 있고, prefix·tag·둘 모두로 좁혀서 켤 수도 있다. 출력은 객체 나이대(<15일, 15~29일, 30~44일 식)별로 액세스 패턴을 집계한 표 형태고, 각 행에는 ObjectAgeForSIATransition처럼 추천 전이 시점을 같이 적는다. 단, 분석 결과가 통계적으로 의미를 가지려면 30일 이상의 관찰 기간이 필요하다는 게 docs의 단서다. 그 결과를 보고 결정하는 건 하나뿐이다. Standard에 있는 어느 prefix를 며칠 시점에 Standard-IA로 옮길지. Standard ↔ Glacier 전이 결정은 별도로 정해야 한다는 게 도구의 경계다.

Intelligent-Tiering, 자동의 약속과 청구서 함정

자주 GET을 받을지 안 받을지 알 수 없을 때 AWS가 권하는 길이 Intelligent-Tiering이다. 객체가 들어오면 처음에 Frequent Access tier(Standard와 같은 단가)에 두고, 30일 동안 GET이 없으면 Infrequent Access tier(Standard-IA와 같은 단가)로 자동 이동, 90일 GET이 없으면 Archive Instant Access tier(Glacier IR과 같은 단가)로 보낸다. 옵트인하면 Archive Access tier(90일+, configurable up to 730일)와 Deep Archive Access tier(180일+, configurable up to 730일)까지 자동 이동을 켤 수 있다.

자동의 대가는 객체당 monitoring fee다. AWS pricing 페이지는 1,000 객체당 월 $0.0025로 표기한다. 객체 1,000만 개면 월 $25, 1억 개면 월 $250을 storage 단가와 별도로 청구서에 더한다.

여기서 worked example을 한 번 본다. 객체 1,000만 개, 평균 크기 200 KB. 총 storage는 약 1,907 GiB (10M × 200 × 1,024 bytes ÷ 1,024³ ≈ 1,907 GiB; 약 2 TB로 본다).

• Standard에 그대로 두면: 1,907 × $0.023 ≈ $43.86/월
• Intelligent-Tiering에 두고, 60일 시점에 모든 객체가 IA tier로 자동 이동했다고 가정하면:
  • storage: 1,907 × $0.0125 ≈ $23.84
  • monitoring: 10,000,000 / 1,000 × $0.0025 = $25.00
  • 합계: 약 $48.84/월

자동 분류 기능을 켰는데 월 청구서가 오히려 약 $4.98 더 많다. 단가는 절반으로 줄었지만 monitoring fee가 절감액을 통째로 잡아먹었다. 객체 평균 크기가 작고 개수가 많은 워크로드일수록 이 함정이 단단하다.

공식 docs가 이 함정을 한 곳에서 명시적으로 막는 안전장치를 둔다.

"If the size of an object is less than 128 KB, it is not monitored and is not eligible for automatic tiering. Smaller objects are always stored in the Frequent Access tier."

128 KB 미만 객체는 애초에 monitoring 대상이 아니고 auto-tiering 대상도 아니다. Frequent Access tier에 그대로 머문다. 이 조건의 객체에는 monitoring fee가 안 붙고, 단가도 Standard와 동일하다. Intelligent-Tiering을 켜도 동일한 비용이 나온다는 뜻이다.

128 KB라는 경계를 정한 이유는 위 함정과 같다. 128 KB 미만 객체가 IA로 내려가면 GB당 절감액이 monitoring fee보다 작아지는 지점이 그 근처라서, AWS가 그 경계 이하에서는 자동 이동을 시도하지 않게 default를 정한 셈이다. Lifecycle Transition의 <128 KB 자동 제외 default(2024-09부터)와 같은 이유에서 같은 경계를 정했다.

요약하면 Intelligent-Tiering은 액세스 패턴을 모르고, 객체가 충분히 크고, 객체 개수가 monitoring fee를 흡수할 수 있을 때 답이다. 작고 많은 객체에는 답이 아니다.

Glacier에서 데이터를 다시 꺼내는 길, 3가지 retrieval tier와 임시 사본

Glacier Flexible Retrieval과 Glacier Deep Archive에 들어간 객체는 즉시 GET이 안 된다. RestoreObject API로 임시 사본을 요청해 두고, 일정 시간이 흐른 뒤 사본이 같은 버킷에 만들어지면 그 사본을 GET 한다. retrieval에는 세 가지 tier가 있다.

• Expedited. Glacier Flexible Retrieval 전용. 1–5분 안에 사본을 받는다. 한 retrieval 요청당 단가가 비싸다.
• Standard. Flexible Retrieval은 3–5시간, Deep Archive는 12시간 안에 사본을 받는다. 보통의 선택.
• Bulk. 가장 싸지만 가장 느리다. Flexible Retrieval은 5–12시간, Deep Archive는 48시간까지 소요한다. 큰 dataset을 야간 배치로 한 번에 끌어올릴 때 쓴다.

Deep Archive에는 Expedited tier가 없다. 공식 restoring objects 페이지가 명시한다. Expedited는 Glacier Flexible Retrieval과 Intelligent-Tiering Archive Access tier에서만 가능하다.

여기서 한 가지를 짚고 가야 한다. 임시 사본이라는 단어다. restore가 끝나면 원본 archived 객체는 그대로 Glacier에 남아 있고, 그 옆에 복원 사본을 같은 버킷에 만든다. 사본은 사용자가 지정한 일수 동안만 살아 있다가 자동으로 만료한다. 같은 docs가 한 줄로 짚는다.

"When you restore an archived object from the S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive storage classes, you pay for both the archived object and the copy that you restored temporarily."

restore 기간 동안 두 벌의 storage 비용을 청구서에 더한다는 뜻이다. 1 TB짜리 archive를 7일 restore해서 받아 본다면, 그 7일 동안 Deep Archive 단가의 원본과 별도 사본 storage를 함께 청구한다. retrieval 요청 자체의 GB당 요금도 따로 더한다.

이 형태 때문에 Glacier 클래스로 옮긴 데이터에서 한 달에 한 번 이상 GET이 일어나는 경우, 단가만 비교해서 결정하면 함정이다. AWS는 retrieval 요청 요금과 임시 사본 storage를 매번 청구서에 더한다.

언제 클래스 전환을 시도하지 말아야 하는가

지금까지 잡고 온 keyThread 중 두 가지를 이 글에서 직접 다룬다. 하나는 '관리형'이라는 단어가 감추는 비용이고, 다른 하나는 언제 이 서비스를 쓰지 말아야 하는가다.

storage class 전환은 그 자체로 관리형 도구다. Lifecycle Rule 한 줄, Intelligent-Tiering 한 토글로 자동 분류가 일어난다. 하지만 자동의 대가가 매번 따라온다. Lifecycle Transition은 객체당 transition 요청 요금. Intelligent-Tiering은 객체당 monitoring fee. Glacier retrieval은 GB당 retrieval 요금과 임시 사본 storage. 단가표에는 안 보이는 부속 비용이 청구서를 다시 키운다.

그래서 클래스 전환을 시도하지 말아야 하는 곳이 세 가지다.

첫째, 객체가 작고 개수가 많은 워크로드. 평균 크기 128 KB 미만이거나 그 근처라면, Lifecycle Transition은 자동 제외고 Intelligent-Tiering은 monitoring fee가 절감액을 잡아먹는다. 이 워크로드에 storage class 자동화 도구는 답이 아니다. Standard에 그대로 두는 것이 정답이다.

둘째, 보관 기간이 최소 보관일보다 짧을 가능성이 있는 워크로드. 임시 빌드 산출물, 7일짜리 trace 데이터, 한 달 안에 지워질 가능성이 있는 캐시. Standard-IA(30일 최소)·Glacier 3종(90~180일 최소)으로 옮기면 짧은 보관에서 Standard보다 더 비싸다. 100 GB를 7일만 보관할 때 Standard는 약 $0.54, Glacier IR은 90일치 청구로 약 $1.20이다. 단가가 1/5인데 청구서는 2배가 된다.

셋째, 빈번하게 GET이 일어나는 워크로드. IA·Glacier 3종은 모두 retrieval 요청 요금을 따로 받는다. 매일 GET이 한 번이라도 일어난다면 Standard에 두는 게 거의 항상 더 싸다. AWS docs는 Glacier 3종의 액세스 빈도 전제를 더 구체적으로 적는다. Glacier Instant Retrieval은 분기에 한 번, Flexible Retrieval은 연에 한 번, Deep Archive는 연에 한 번 미만 액세스를 전제로 단가를 정한다. 그 전제가 깨지면 원래 형태보다 더 비싼 청구서로 끝난다.

이 세 곳 외에는 storage class 전환이 답이 된다. 충분히 큰 객체가 충분히 오래 보관되면서 접근 빈도가 낮을 때, Lifecycle Transition도 Intelligent-Tiering도 청구서를 줄여 준다. 그 전제가 깨질 위치를 미리 보고 결정해야 한다는 뜻이다.

처음에 적어 둔 사건, Lifecycle 한 줄 적었는데 청구서가 그대로였던 그 한 달은 위 세 조건 중 하나가 깨진 결과다. 객체가 작거나, 보관이 짧거나, 자주 읽히거나. 단가표를 본 게 아니라 그 세 조건부터 봤어야 했다.