S3 Glacier 스토리지 클래스 완전 가이드 — 연 1회 감사 데이터를 위한 최적 아카이빙 전략

연간 감사(Audit)를 위해 딱 한 번만 꺼내볼 데이터를 S3 Standard에 그대로 두고 있다면, 매달 필요 이상의 비용을 지불하고 있는 것이다. S3 Glacier 계열 스토리지 클래스는 이런 장기 보관 시나리오를 위해 설계되었지만, 세 가지 Glacier 티어 중 어떤 것을 선택하느냐에 따라 복원 속도, 비용 구조, 운영 복잡도가 크게 달라진다.

TL;DR — S3 Glacier 스토리지 클래스 비교

스토리지 클래스	최소 보관 기간	복원 소요 시간	주요 사용 사례
S3 Glacier Instant Retrieval	90일	밀리초	분기 1회 이하 접근, 즉시 복원 필요
S3 Glacier Flexible Retrieval	90일	1분~12시간	연 1~2회 접근, 수 시간 내 복원 허용
S3 Glacier Deep Archive	180일	12시간~48시간	연 1회 이하 접근, 최저 스토리지 단가

결론부터: 연 1회 감사 목적이라면 S3 Glacier Flexible Retrieval 또는 S3 Glacier Deep Archive가 최적 후보다. 복원 시점을 며칠 전에 예측할 수 있다면 Deep Archive가 스토리지 단가 측면에서 가장 저렴하다. 당일 복원이 필요하다면 Flexible Retrieval의 Bulk 또는 Standard 검색 옵션을 사용한다.

S3 Glacier가 동작하는 방식 — 복원 메커니즘 이해

Glacier 계열 클래스에 저장된 객체는 즉시 읽을 수 없다. 복원(Restore) 요청을 제출하면 AWS가 내부적으로 객체를 준비하고, 지정한 보관 기간(days) 동안 S3 Standard 계층에 임시 사본을 생성한다. 애플리케이션은 이 임시 사본을 통해 데이터에 접근한다. 임시 사본의 보관 기간이 만료되면 자동으로 삭제되며, 원본 Glacier 객체는 그대로 유지된다.

이 구조에서 비용이 발생하는 지점은 세 곳이다: 저장 비용(Glacier 단가), 복원 요청 비용(검색 옵션별 상이), 임시 사본의 S3 Standard 스토리지 비용(보관 기간 동안). 감사처럼 복원 후 며칠 내에 작업을 완료하는 시나리오라면 임시 사본 비용은 미미하다.

sequenceDiagram participant App as 애플리케이션 participant S3 as S3 API participant Glacier as Glacier 스토리지 participant Std as S3 Standard 계층 App->>S3: PUT Object (StorageClass: DEEP_ARCHIVE) S3->>Glacier: 객체 저장 Glacier-->>S3: 저장 완료 S3-->>App: 200 OK Note over App,Glacier: 감사 시즌 — 복원 요청 App->>S3: RestoreObject (Days: 7, Tier: Standard) S3->>Glacier: 복원 작업 시작 Note over Glacier,Std: 최대 12시간 소요 (Standard 옵션) Glacier->>Std: 임시 사본 생성 (S3 Standard) S3-->>App: 복원 완료 알림 App->>S3: GET Object S3->>Std: 임시 사본 읽기 Std-->>S3: 데이터 반환 S3-->>App: 200 OK + 데이터 Note over Std: 7일 후 임시 사본 자동 삭제 Note over Glacier: 원본 객체 유지

1. 객체 업로드: 데이터를 Glacier 클래스로 직접 PUT하거나, S3 Lifecycle 정책으로 자동 전환한다.
2. 복원 요청: RestoreObject API를 호출하여 검색 옵션(Expedited/Standard/Bulk)과 임시 사본 보관 기간(days)을 지정한다.
3. 임시 사본 생성: 복원이 완료되면 S3 Standard 계층에 임시 사본이 생성된다. 원본 Glacier 객체는 변경되지 않는다.
4. 데이터 접근: 임시 사본이 존재하는 동안 일반 S3 GET 요청으로 데이터를 읽는다.
5. 임시 사본 만료: 지정한 days 경과 후 임시 사본이 자동 삭제된다. 원본은 Glacier에 유지된다.

세 가지 Glacier 클래스 심층 비교

S3 Glacier Instant Retrieval

2021년에 출시된 이 클래스는 기존 S3 Glacier(현재의 Flexible Retrieval)와 달리 밀리초 단위 복원을 지원한다. 내부적으로는 S3 Standard-IA와 유사한 즉시 접근 구조를 가지면서 스토리지 단가는 더 낮다. 분기에 한 번 정도 접근하지만 복원 지연을 전혀 허용할 수 없는 의료 영상, 뉴스 아카이브 같은 시나리오에 적합하다. 연 1회 감사 데이터라면 이 클래스의 즉시 복원 능력은 과잉 사양이고, 스토리지 단가도 Flexible Retrieval보다 높다.

S3 Glacier Flexible Retrieval

과거 'S3 Glacier'로 불리던 클래스다. 세 가지 검색 옵션을 제공한다:

• Expedited: 1~5분. 온디맨드 또는 프로비저닝된 용량(Provisioned Capacity) 사용. 긴급 복원 시 사용.
• Standard: 3~5시간. 가장 일반적인 선택.
• Bulk: 5~12시간. 대용량 데이터 복원 시 가장 저렴한 검색 비용.

연 1회 감사라면 감사 일정을 며칠 전에 알 수 있으므로 Standard 또는 Bulk 검색으로 충분하다. Bulk는 검색 비용이 가장 낮아 대용량 아카이브에 유리하다.

S3 Glacier Deep Archive

S3에서 제공하는 스토리지 클래스 중 단가가 가장 낮다. 복원에 Standard 옵션 기준 최대 12시간, Bulk 옵션 기준 최대 48시간이 소요된다. 최소 보관 기간이 180일이므로, 180일 미만 보관 후 삭제하면 잔여 기간에 대한 스토리지 비용이 청구된다. 연 1회 감사처럼 데이터를 수년간 보관하고 접근 빈도가 극히 낮은 경우 — 예를 들어 금융 규정 준수를 위한 7년 보관 의무 데이터 — 에 가장 적합하다.

graph TD Start(["접근 빈도 및 복원 요건 확인"]) --> Q1{"분기 1회 이상 접근
또는 즉시 복원 필요?"} Q1 -->|Yes| Instant["S3 Glacier Instant Retrieval
밀리초 복원"] Q1 -->|No| Q2{"당일 복원 필요
(수 시간 내)?"} Q2 -->|Yes| Flexible["S3 Glacier Flexible Retrieval
Standard: 3~5시간"] Q2 -->|No| Q3{"복원 시점을
하루 전에 예측 가능?"} Q3 -->|Yes| Deep["S3 Glacier Deep Archive
최저 스토리지 단가"] Q3 -->|No| Flexible2["S3 Glacier Flexible Retrieval
Bulk: 5~12시간"] style Instant fill:#f0f4ff,stroke:#4a6cf7 style Flexible fill:#f0fff4,stroke:#38a169 style Deep fill:#fff0f0,stroke:#e53e3e style Flexible2 fill:#f0fff4,stroke:#38a169

1. 접근 빈도가 분기 1회 이상이거나 즉시 복원이 필요하면 Glacier Instant Retrieval로 이동한다.
2. 연 1~2회 접근하고 당일 복원(수 시간 내)이 필요하면 Glacier Flexible Retrieval을 선택한다.
3. 연 1회 이하 접근하고 복원 시점을 하루 전에 예측할 수 있으면 Glacier Deep Archive가 최저 비용이다.

S3 Lifecycle 정책으로 Glacier 자동 전환 설정

데이터를 처음부터 Glacier로 업로드할 수도 있지만, 실무에서는 S3 Standard로 업로드 후 Lifecycle 정책으로 자동 전환하는 패턴이 더 일반적이다. 최근 90일간 활발히 사용되던 데이터를 갑자기 Glacier로 보내면 운영 혼선이 생기기 때문에, 전환 전 충분한 유예 기간을 두는 것이 좋다.

아래는 버킷에 Lifecycle 정책을 적용하는 예시다. 생성 후 365일이 지난 객체를 Glacier Deep Archive로 전환하고, 2555일(약 7년) 후 삭제한다.

🔽 Lifecycle 정책 JSON 예시 (클릭하여 펼치기)

{
  "Rules": [
    {
      "ID": "archive-audit-data",
      "Status": "Enabled",
      "Filter": {
        "Prefix": "audit-logs/"
      },
      "Transitions": [
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 2555
      }
    }
  ]
}

AWS CLI로 위 정책을 적용하는 명령어:

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

적용된 정책 확인:

aws s3api get-bucket-lifecycle-configuration \
  --bucket my-audit-bucket

Glacier 객체 복원 — 실전 CLI

감사 시즌이 되어 실제로 데이터를 꺼내야 하는 상황이다. 복원 요청은 restore-object 명령으로 제출한다. --restore-request의 Days는 임시 사본이 S3 Standard 계층에 유지될 기간이고, GlacierJobParameters.Tier는 검색 속도 옵션이다.

Glacier Flexible Retrieval — Standard 검색 (3~5시간):

aws s3api restore-object \
  --bucket my-audit-bucket \
  --key audit-logs/2023/annual-report.csv \
  --restore-request '{"Days": 7, "GlacierJobParameters": {"Tier": "Standard"}}'

Glacier Deep Archive — Standard 검색 (최대 12시간):

aws s3api restore-object \
  --bucket my-audit-bucket \
  --key audit-logs/2023/annual-report.csv \
  --restore-request '{"Days": 7, "GlacierJobParameters": {"Tier": "Standard"}}'

복원 상태 확인 — HeadObject로 x-amz-restore 헤더를 확인한다:

aws s3api head-object \
  --bucket my-audit-bucket \
  --key audit-logs/2023/annual-report.csv

응답에서 Restore 필드가 ongoing-request="false"로 바뀌면 임시 사본이 준비된 것이다. ongoing-request="true"면 아직 복원 진행 중이다.

실제 운영에서 마주치는 함정 — 오진에서 정확한 원인까지

Glacier Deep Archive로 전환한 직후 팀에서 '데이터가 사라졌다'는 제보가 들어오는 경우가 있다. S3 콘솔에서 객체를 클릭하면 다운로드가 되지 않고, AWS CLI로 GET을 시도하면 InvalidObjectState 오류가 반환된다. 처음에는 Lifecycle 정책이 잘못 적용되어 객체가 삭제된 것으로 의심하기 쉽다.

실제 원인은 단순하다. Glacier 계열 객체는 복원 요청 없이 직접 GET할 수 없다. InvalidObjectState는 객체가 없는 게 아니라, 해당 스토리지 클래스에서 직접 읽기 작업이 허용되지 않는다는 의미다. head-object로 객체 메타데이터를 확인하면 객체가 존재하고 스토리지 클래스가 DEEP_ARCHIVE임을 확인할 수 있다.

aws s3api head-object \
  --bucket my-audit-bucket \
  --key audit-logs/2023/annual-report.csv

응답 예시:

{
    "ContentType": "text/csv",
    "StorageClass": "DEEP_ARCHIVE",
    "ContentLength": 204800
}

객체가 존재하고 StorageClass가 DEEP_ARCHIVE로 표시되면, 복원 요청 없이 GET을 시도한 것이 원인이다. restore-object를 먼저 실행하고 복원 완료를 기다려야 한다.

Glacier는 콜드 스토리지 창고와 같다. 물건이 창고에 있다고 해서 즉시 꺼낼 수 있는 게 아니라, 창고 직원에게 요청하고 물건이 입구로 나올 때까지 기다려야 한다. InvalidObjectState는 '물건 없음'이 아니라 '아직 입구에 도착하지 않음'이다.

최소 보관 기간과 조기 삭제 비용

Glacier Flexible Retrieval과 Instant Retrieval의 최소 보관 기간은 90일, Deep Archive는 180일이다. 이 기간 이전에 객체를 삭제하거나 다른 클래스로 전환하면 잔여 기간에 해당하는 스토리지 비용이 청구된다. 예를 들어 Deep Archive에 업로드한 지 30일 만에 삭제하면 150일치 스토리지 비용이 추가로 부과된다.

이 점은 단기 보관 후 삭제하는 임시 데이터에 Glacier를 사용할 때 주의해야 한다. 연간 감사 데이터처럼 수년간 보관하는 경우에는 최소 보관 기간이 사실상 무의미하다.

graph LR Upload(["객체 업로드"]) --> Store["Glacier 저장 시작"] Store --> MinPeriod["최소 보관 기간 카운트 시작"] MinPeriod --> Q{"삭제 시점"} Q -->|"최소 보관 기간 이전"| EarlyDelete["조기 삭제
잔여 기간 비용 청구"] Q -->|"최소 보관 기간 이후"| NormalDelete["정상 삭제
추가 비용 없음"] Note1["Flexible/Instant: 90일"] -.-> MinPeriod Note2["Deep Archive: 180일"] -.-> MinPeriod style EarlyDelete fill:#fff0f0,stroke:#e53e3e style NormalDelete fill:#f0fff4,stroke:#38a169

1. 업로드 시점: 객체가 Glacier 클래스에 저장되고 최소 보관 기간 카운트가 시작된다.
2. 조기 삭제 구간: 최소 보관 기간 이전에 삭제하면 잔여 기간 비용이 청구된다.
3. 정상 삭제 구간: 최소 보관 기간 이후 삭제는 추가 비용 없이 처리된다.

IAM 권한 — Glacier 복원에 필요한 최소 권한

Glacier 객체 복원과 상태 확인에 필요한 최소 IAM 권한이다. 복원 요청은 s3:RestoreObject, 상태 확인은 s3:GetObject가 필요하다.

🔽 IAM 정책 예시 (클릭하여 펼치기)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GlacierRestoreAccess",
      "Effect": "Allow",
      "Action": [
        "s3:RestoreObject",
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-audit-bucket",
        "arn:aws:s3:::my-audit-bucket/*"
      ]
    },
    {
      "Sid": "LifecycleManagement",
      "Effect": "Allow",
      "Action": [
        "s3:PutLifecycleConfiguration",
        "s3:GetLifecycleConfiguration"
      ],
      "Resource": "arn:aws:s3:::my-audit-bucket"
    }
  ]
}

S3 Glacier로 연간 감사 데이터 아카이빙 — 마무리 및 다음 단계

연 1회 감사 데이터라는 조건 하나만으로도 스토리지 클래스 선택이 상당히 좁혀진다. 복원 시점을 하루 전에 알 수 있다면 S3 Glacier Deep Archive가 스토리지 단가 측면에서 최선이다. 당일 복원이 필요하다면 S3 Glacier Flexible Retrieval의 Standard 또는 Bulk 검색 옵션을 사용한다. 두 경우 모두 S3 Lifecycle 정책으로 자동 전환을 설정하면 운영 부담 없이 비용을 최적화할 수 있다.

다음 단계로 고려할 사항:

• S3 Intelligent-Tiering과의 비교 — 접근 패턴이 불규칙하다면 자동 계층 이동이 유리할 수 있다.
• S3 Object Lock — 규정 준수를 위해 삭제 방지가 필요한 경우 Glacier와 함께 사용 가능하다.
• AWS Backup — Glacier를 백업 대상으로 사용하는 중앙화된 백업 정책 관리.

정확한 스토리지 단가와 검색 비용은 리전마다 다르므로, 최신 정보는 AWS S3 공식 요금 페이지에서 확인한다.

핵심 용어 정리

용어	설명
RestoreObject	Glacier 객체의 임시 사본을 S3 Standard 계층에 생성하는 API 작업
검색 옵션 (Retrieval Tier)	Expedited / Standard / Bulk — 복원 속도와 비용의 트레이드오프를 결정하는 옵션
최소 보관 기간 (Minimum Storage Duration)	조기 삭제 시 잔여 기간 비용이 청구되는 기준 기간. Flexible Retrieval/Instant Retrieval: 90일, Deep Archive: 180일
S3 Lifecycle 정책	객체 생성 후 경과 일수에 따라 스토리지 클래스 전환 또는 삭제를 자동화하는 버킷 수준 규칙
InvalidObjectState	Glacier 계열 객체를 복원 없이 직접 GET 시도할 때 반환되는 오류 코드