Amazon Simple Storage Service
개발자 안내서 (API 버전 2006-03-01)

Amazon S3 수명 주기를 사용하여 객체 이전

수명 주기 구성에 규칙을 추가하여 Amazon S3가 객체를 다른 Amazon S3 스토리지 클래스로 전환하도록 지시할 수 있습니다. 예:

  • 객체에 자주 액세스하지 않는 경우, 해당 객체를 STANDARD_IA 스토리지 클래스로 이전할 수 있습니다.

  • 실시간으로 액세스할 필요가 없는 객체를 GLACIER 스토리지 클래스에 보관할 수 있습니다.

다음 단원들에서는 지원되는 전환 작업, 관련 제한 사항 및 GLACIER 스토리지 클래스로의 전환에 대해 설명합니다.

지원되는 전환 작업 및 관련 제한 사항

수명 주기 구성에서, 객체를 한 스토리지 클래스에서 다른 스토리지 클래스로 전환하여 스토리지 비용을 절약하도록 규칙을 정의할 수 있습니다. 객체의 액세스 패턴을 모르거나 시간이 지남에 따라 액세스 패턴이 변하면 자동 비용 절감을 위해 객체를 INTELLIGENT_TIERING 스토리지 클래스로 전환할 수 있습니다. 스토리지 클래스에 대한 자세한 내용은 Amazon S3 스토리지 클래스 단원을 참조하십시오.

Amazon S3는 다음 다이어그램과 같이 스토리지 클래스간 전환을 위한 폭포형(Waterfall) 모델을 지원합니다.


                        Amazon S3 스토리지 클래스 폭포형 그래픽.

참고

다이어그램에서는 REDUCED_REDUNDANCY 스토리지 클래스를 언급하지 않는데, 이는 이것이 권장되지 않기 때문입니다.

Amazon S3는 수명 주기 구성을 사용하여 스토리지 클래스 간에 다음과 같은 수명 주기 전환을 지원합니다.

  • STANDARD 스토리지 클래스에서 다른 스토리지 클래스로 전환할 수 있습니다.

  • 어떤 스토리지 클래스에서 GLACIER 또는 DEEP_ARCHIVE 스토리지 클래스로 이전할 수 있습니다.

  • STANDARD_IA 스토리지 클래스에서 INTELLIGENT_TIERING 또는 ONEZONE_IA 스토리지 클래스로 전환할 수 있습니다.

  • INTELLIGENT_TIERING 스토리지 클래스에서 ONEZONE_IA 스토리지 클래스로 전환할 수 있습니다.

  • GLACIER 스토리지 클래스에서 DEEP_ARCHIVE 스토리지 클래스로 이전할 수 있습니다.

다음 수명 주기 전환은 지원되지 않습니다.

  • 다른 스토리지 클래스에서 STANDARD 스토리지 클래스로 전환할 수 없습니다.

  • 다른 스토리지 클래스에서 REDUCED_REDUNDANCY 스토리지 클래스로 전환할 수 없습니다.

  • INTELLIGENT_TIERING 스토리지 클래스에서 STANDARD_IA 스토리지 클래스로 전환할 수 없습니다.

  • ONEZONE_IA 스토리지 클래스에서 STANDARD_IA 또는 INTELLIGENT_TIERING 스토리지 클래스로 전환할 수 없습니다.

  • GLACIER 스토리지 클래스에서 DEEP_ARCHIVE 스토리지 클래스로만 이전할 수 있습니다.

  • DEEP_ARCHIVE 스토리지 클래스에서 다른 스토리지 클래스로 이전할 수 없습니다.

수명 주기 스토리지 클래스 전환에는 다음과 같은 제약이 있습니다.

  • STANDARD 또는 STANDARD_IA 스토리지 클래스에서 INTELLIGENT_TIERING로. 다음과 같은 제약이 적용됩니다.

    • 큰 객체의 경우 INTELLIGENT_TIERING으로 전환하면 비용상의 이점이 있습니다. Amazon S3는 128KB보다 작은 객체를 INTELLIGENT_TIERING 스토리지 클래스로 전환하지 않습니다. 왜냐하면 비용 대비 효과적이지 않기 때문입니다.

       

  • STANDARD 스토리지 클래스에서 STANDARD_IA 또는 ONEZONE_IA로의 전환. 다음과 같은 제약이 적용됩니다.

     

    • 큰 객체의 경우 STANDARD_IA 또는 ONEZONE_IA로 전환하면 비용상의 이점이 있습니다. Amazon S3는 128KB보다 작은 객체를 STANDARD_IA 또는 ONEZONE_IA 스토리지 클래스로 전환하지 않습니다. 왜냐하면 비용 대비 효과적이지 않기 때문입니다.

       

    • 현재 스토리지 클래스에 30일 이상 저장된 객체만 STANDARD_IA 또는 ONEZONE_IA로 전환할 수 있습니다. 예를 들어, 생성 후 1일이 지난 객체를 STANDARD_IA 스토리지 클래스로 전환하도록 요구하는 수명 주기 규칙을 생성할 수 없습니다.

       

      새 객체는 더 자주 액세스되거나 STANDARD_IA 또는 ONEZONE_IA 스토리지에 적합해지기 전에 삭제되는 경우가 종종 있기 때문에 Amazon S3는 최초 30일 동안에는 객체를 전환하지 않습니다.

       

    • 최신 버전이 아닌 객체를 전환할 경우(버전이 지정된 버킷에서) 30일 이상 된 비 최신 객체만 STANDARD_IA 또는 ONEZONE_IA 스토리지로 전환할 수 있습니다.

       

  • STANDARD_IA 스토리지 클래스에서 ONEZONE_IA로. 다음과 같은 제약이 적용됩니다.

    • STANDARD_IA 스토리지 클래스에 30일 이상 저장된 객체만 ONEZONE_IA 클래스로 전환할 수 있습니다.

       

이와 같은 수명 주기 작업들을 결합하여 객체의 전체 수명 주기를 관리할 수 있습니다. 예를 들어, 생성하는 객체의 수명 주기가 명확하게 정의되어 있다고 가정해봅시다. 처음 30일 동안에는 객체에 자주 액세스합니다. 그 후, 최대 90일 동안에는 객체에 가끔 액세스합니다. 그 다음에는 객체가 더 이상 필요하지 않아서 보관하거나 삭제하기로 선택할 것입니다.

이 시나리오에서는 INTELLIGENT_TIERING, STANDARD_IA 또는 ONEZONE_IA 스토리지로의 최초 전환 작업과 보관을 위한 GLACIER 스토리지로의 다른 전환 작업, 그리고 만료 작업을 지정하는 수명 주기 규칙을 만들 수 있습니다. 한 스토리지 클래스에서 다른 스토리지 클래스로 객체를 이동하면 스토리지 비용이 절약됩니다. 비용 고려 사항에 대한 자세한 내용은 Amazon S3 요금을 참조하십시오.

중요

GLACIER 또는 DEEP_ARCHIVE 이전이 INTELLIGENT_TIERING, STANDARD_IA 또는 ONEZONE_IA 이전 후 30일이 경과하기 전에 수행될 경우 INTELLIGENT_TIERING(또는 STANDARD_IA 또는 ONEZONE_IA)과 GLACIER 또는 DEEP_ARCHIVE 이전 모두에 대해 하나의 수명 주기 규칙을 지정할 수는 없습니다. INTELLIGENT_TIERING, STANDARD_IA와 ONEZONE_IA 스토리지 클래스와 관련한 스토리지 요금이 최소 30일을 기준으로 하고 있기 때문입니다.

STANDARD_IA 스토리지에서 ONEZONE_IA 또는 INTELLIGENT_TIERING 스토리지로의 전환을 지정할 때에도 똑같이 최소 30일이 적용됩니다. 이를 달성하기 위해 두 가지 규칙을 지정할 수 있지만 사용자는 최소 스토리지 요금을 지불하게 됩니다. 비용 고려 사항에 대한 자세한 내용은 Amazon S3 요금을 참조하십시오.

GLACIER 및 DEEP_ARCHIVE 스토리지 클래스로 이전(객체 보관)

수명 주기 구성을 사용하여 아카이브를 위해 객체를 GLACIER 또는 DEEP_ARCHIVE 스토리지 클래스로 이전할 수 있습니다. GLACIER 또는 DEEP_ARCHIVE 스토리지 클래스를 선택하면 객체가 Amazon S3에 남아 있습니다. 별도의 Amazon S3 Glacier 서비스를 통해 직접 액세스할 수 없습니다.

객체를 보관하기 전에 이와 관련된 고려 사항에 대해 설명한 다음 단원들을 살펴보십시오.

일반적인 고려 사항

다음은 객체를 보관하기 전에 고려할 일반적인 사항들입니다.

  • 암호화된 객체는 스토리지 클래스 전환 프로세스 전체에서 암호화된 상태로 유지됩니다.

     

  • GLACIER 또는 DEEP_ARCHIVE 스토리지 클래스에 저장된 객체는 실시간으로 사용할 수 없습니다.

     

    보관된 객체는 Amazon S3 객체이지만 보관된 객체에 액세스하려면 먼저 해당 객체의 임시 복사본을 복원해야 합니다. 복원된 객체 사본은 요청자가 복원 요청에서 지정한 기간 동안만 사용할 수 있습니다. 그 이후에 Amazon S3은 임시 복사본을 삭제하고 해당 객체가 Amazon S3 Glacier에 아카이브된 상태로 유지됩니다.

     

    Amazon S3 콘솔을 사용하거나 코드에 AWS SDK 래퍼 라이브러리 또는 Amazon S3 REST API를 사용하여 프로그래밍 방식으로 객체를 복원할 수 있습니다. 자세한 내용은 보관된 객체의 복원 단원을 참조하십시오.

     

  • GLACIER 스토리지 클래스에 저장된 객체는 DEEP_ARCHIVE 스토리지 클래스로만 이전할 수 있습니다.

     

    수명 주기 구성 규칙을 사용하여 객체의 스토리지 클래스를 GLACIER에서 DEEP_ARCHIVE 스토리지 클래스로만 변환할 수 있습니다. GLACIER에 저장된 객체의 스토리지 클래스를 DEEP_ARCHIVE가 아닌 스토리지 클래스로 변경하려면 복원 작업을 사용하여 객체의 임시 복사본을 먼저 만들어야 합니다. 그런 다음 복사 작업을 사용하여 STANDARD, INTELLIGENT_TIERING, STANDARD_IA, ONEZONE_IA 또는 REDUCED_REDUNDANCY를 스토리지 객체로 지정하여 객체를 덮어씁니다.

     

  • 객체를 DEEP_ARCHIVE 스토리지 클래스로 이전할 때는 한 방향으로만 이동할 수 있습니다.

     

    수명 주기 구성 규칙을 사용하여 객체의 스토리지 클래스를 DEEP_ARCHIVE에서 다른 스토리지 클래스로 변환할 수는 없습니다. 아카이빙된 객체의 스토리지 클래스를 다른 스토리지 클래스로 변경하고자 하는 경우, 먼저 복원 작업을 통해 객체의 임시 사본을 만들어야 합니다. 그런 다음 복사 작업을 사용하여 STANDARD, INTELLIGENT_TIERING, STANDARD_IA, ONEZONE_IA, GLACIER 또는 REDUCED_REDUNDANCY를 스토리지 객체로 지정하여 객체를 덮어씁니다.

     

  • GLACIER 및 DEEP_ARCHIVE 스토리지 클래스에 저장된 객체는 표시되며 Amazon S3을 통해서만 사용할 수 있습니다. 별도의 Amazon S3 Glacier 서비스를 통해 사용할 수는 없습니다.

     

    이들은 Amazon S3 객체이므로 Amazon S3 콘솔 또는 Amazon S3 API를 통해서만 액세스할 수 있습니다. 별도의 Amazon S3 Glacier 콘솔 또는 Amazon S3 Glacier API를 통해서는 아카이브에 보관된 객체에 액세스할 수 없습니다.

비용 고려 사항

자주 액세스하지 않는 데이터를 몇 달 또는 몇 년 동안 아카이브에 보관할 계획이라면 GLACIER 및 DEEP_ARCHIVE 스토리지 클래스로 스토리지 비용을 절감할 수 있습니다. 그러나 GLACIER 및 DEEP_ARCHIVE 스토리지 클래스가 적합한지 확인하려면 다음을 고려하십시오.

  • 스토리지 오버헤드 요금 – 객체를 GLACIER 및 DEEP_ARCHIVE 스토리지 클래스로 이전할 때 객체 관리를 위한 메타데이터를 수용하기 위해 고정된 양의 스토리지가 각 객체에 추가됩니다.

     

    • GLACIER 또는 DEEP_ARCHIVE에 아카이브된 각 객체에 대해 Amazon S3은 객체 이름 및 기타 메타데이터에 8KB의 스토리지를 사용합니다. Amazon S3은 이 메타데이터를 저장하므로 Amazon S3 API를 사용하여 아카이브된 객체의 실시간 목록을 얻을 수 있습니다. 자세한 내용은 GET Bucket (List Objects) 단원을 참조하십시오. 이 추가 스토리지에 대해 Amazon S3 스탠다드 요금이 청구됩니다.

       

    • GLACIER 또는 DEEP_ARCHIVE에 아카이브된 각 객체에 대해 Amazon S3은 인덱스 및 관련 메타데이터용으로 32KB의 스토리지를 추가합니다. 이 추가 데이터는 객체를 식별하고 복원하는 데 필요합니다. 이 추가 스토리지에 대해 GLACIER 또는 DEEP_ARCHIVE 요금이 청구됩니다.

       

    작은 크기의 객체를 보관할 경우 이러한 스토리지 요금을 고려해야 합니다. 또한 크기가 작은 여러 객체를 더 적은 수의 크기가 큰 객체로 통합하면 오버헤드 비용을 줄일 수 있습니다.

     

  • 객체의 보관 일수—GLACIER 및 DEEP_ARCHIVE는 장기 보관 솔루션입니다. 최소 스토리지 기간은 GLACIER 스토리지 클래스의 경우 90일, DEEP_ARCHIVE의 경우 180일입니다. 삭제한 객체가 최소 스토리지 기간보다 오래 보관되는 경우 Amazon S3 Glacier에 보관된 데이터를 삭제하는 것은 무료입니다. 최소 기간 내에 보관된 객체를 삭제하거나 덮어쓸 경우 Amazon S3은 비례 할당으로 계산된 조기 삭제 요금을 부과합니다.

     

  • Amazon S3 GLACIER 및 DEEP_ARCHIVE 이전 요청 요금— GLACIER 또는 DEEP_ARCHIVE 스토리지 클래스로 이전하는 각 객체는 하나의 이전 요청을 구성합니다. 그러한 각 요청에 대해 비용이 부과됩니다. 많은 수의 객체를 이전할 경우 요청 요금을 고려해야 합니다. 스몰 객체를 아카이브 중인 경우 많은 스몰 객체를 적은 수의 라지 객체로 집계하여 변환 요청 비용을 절감할 것을 고려해 보십시오.

     

  • Amazon S3 GLACIER 및 DEEP_ARCHIVE 데이터 복원 요금—GLACIER 및 DEEP_ARCHIVE는 자주 액세스하지 않는 데이터의 장기 보관을 위한 솔루션입니다. 데이터 복원 요금에 대한 자세한 내용은 Amazon S3 FAQ에서 How Amazon S3 Glacier에서 데이터를 검색하는 데 드는 비용은 얼마인가요? 항목을 참조하십시오. Amazon S3 Glacier에서 데이터 복원 방법에 대한 자세한 내용은 보관된 객체의 복원 항목을 참조하십시오.

객체 수명 주기 관리를 사용하여 Amazon S3 Glacier에 데이터를 보관할 경우 Amazon S3는 이러한 객체를 비동기 방식으로 이전합니다. 수명 주기 구성 규칙의 이전 날짜와 실제 이전 작업 수행 날짜 간에 약간의 지연이 발생할 수 있습니다. 그러나 Amazon S3 Glacier 요금은 규칙에 지정된 이전 날짜를 기준으로 청구됩니다.

Amazon S3 제품 세부 정보 페이지에 자세한 요금 정보와 Amazon S3 객체 보관의 요금 계산 예제가 나와 있습니다. 자세한 내용은 다음 항목을 참조하십시오.

보관된 객체의 복원

보관된 객체에는 실시간으로 액세스할 수 없습니다. 먼저 복원 요청을 시작한 후 요청에 지정된 기간 동안 객체의 임시 사본을 사용할 수 있게 될 때까지 기다려야 합니다. 복원된 객체의 임시 복사본을 받으면 객체의 스토리지 클래스는 GLACIER 또는 DEEP_ARCHIVE에 유지됩니다. (HEAD 객체 또는 GET Object API 작업 요청은 GLACIER 또는 DEEP_ARCHIVE를 스토리지 클래스로 반환합니다.)

참고

아카이브를 복원하면 아카이브(GLACIER 또는 DEEP_ARCHIVE 요금) 및 임시로 복원한 복사본(REDUCED_REDUNDANCY 스토리지 요금) 모두에 대해 요금이 청구됩니다. 요금에 대한 자세한 내용은 Amazon S3 요금을 참조하십시오.

프로그래밍 방식으로 또는 Amazon S3 콘솔을 사용하여 객체 사본을 복원할 수 있습니다. Amazon S3는 각 객체에 대해 한 번에 하나의 복원 요청만 처리합니다. 자세한 내용은 보관된 객체의 복원 단원을 참조하십시오.