AWS Technical Essentials #3

스토리지 유형

 

AWS 스토리지 서비스는 파일 스토리지, 블록 스토리지, 객체 스토리지의 총 3가지 범주로 그룹화된다. 파일 스토리지에서 데이터는 계층 구조에 따라 파일로 저장된다. 블록 스토리지에서 데이터는 고정된 크기의 블록으로 저장된다. 객체 스토리지에서 데이터는 버킷 내에 객체로 저장된다.

 

Windows 파일 탐색기 또는 macOS의 Finder와 같은 파일 스토리지 시스템을 사용해 봤다면 파일 스토리지에 익숙할 수 있을 것이다. 파일은 폴더 및 하위 폴더로 구성된 트리 같은 계층 구조로 구성된다. 예를 들어, 랩탑에 수백 개의 수달 사진이 있는 경우 Sudal photos라는 폴더를 생성하고 이미지를 이 폴더 안에 배치하여 정리할 수 있을 것이다. 이러한 이미지가 애플리케이션에서 사용된다는 것을 알고 있으므로 Sudal photos 폴더를 Application files라는 다른 폴더 안에 넣을 수 있다.

 

파일 스토리지의 구체적 사용사례로는 다음이 있다.

① 웹 서비스 : 클라우드 파일 스토리지 솔루션은 개발자에게 익숙한 일반적인 파일 수준의 프로토콜, 파일 명명 규칙, 권한을 따른다. 따라서 파일 스토리지를 웹 애플리케이션과 통합할 수 있다. ② 분석 : 많은 분석 워크로드는 파일 인터페이스를 통해 데이터와 상호 작용하며 파일 잠금 또는 파일의 일부에 작성하는 기능을 사용한다. 클라우드 기반 파일 스토리지는 일반적인 파일 수준의 프로토콜을 지원하며, 용량과 성능의 크기를 조정하는 기능을 제공한다. 따라서 파일 스토리지를 분석 워크플로에 편리하게 통합할 수 있는 것이다. ③ 미디어 및 엔터테인먼트 : 많은 기업은 하이브리드 클라우드 배포를 사용하며 파일 시스템 프로토콜(NFS, SMB 등) 또는 동시 프로토콜 액세스를 사용한 표준화된 액세스를 필요로 한다. 클라우드 파일 스토리지는 기존의 파일 시스템 의미 체계를 따른다. 따라서 콘텐츠 프로덕션, 디지털 공급망, 미디어 스트리밍, 방송 재생, 분석, 아카이브 처리 및 협업을 위해 리치 미디어 콘텐츠 스토리지를 통합할 수 있다. ④ 홈 디렉터리 : 클라우드의 확장성과 비용적 이점을 활용하려는 기업에서는 많은 사용자들을 위해 홈 디렉터리에 대한 액세스를 확장하고 있다. 클라우드 파일 스토리지 시스템은 일반적인 파일 수준의 프로토콜과 표준 권한 모델을 따른다. 따라서 고객은 이러한 기능이 필요한 애플리케이션을 클라우드로 리프트 앤 시프트할 수 있다.

 

파일 스토리지는 파일을 단일 단위로 취급하지만 블록 스토리지는 고유한 주소를 가진 블록이라는 고정된 크기의 데이터 청크로 파일을 분할한다. 각 블록은 데이터 스토리지의 개별 조각이다. 블록마다 주소를 지정할 수 있기 때문에 블록을 효과적으로 검색할 수 있다. 블록 스토리지를 데이터에 액세스하기 위한 더 직접적인 라우팅이라고 생각하면 되는 것이다.

데이터가 요청되면 스토리지 시스템에서 주소를 사용하여 블록을 올바른 순서로 구성하고 요청자에게 반환할 전체 파일을 구성한다. 주소 외에는 각 블록에 추가 메타데이터가 연결되지 않는다. 파일의 문자 하나를 변경하려는 경우, 해당 문자가 포함된 블록, 즉 파일 조각을 변경하기만 하면 된다. 이러한 액세스 용이성 덕분에 블록 스토리지 솔루션은 빠르고 대역폭을 적게 사용한다.

 

블록 스토리지는 지연 시간이 짧은 작업에 최적화되어 있기 때문에 고성능 엔터프라이즈 워크로드와 트랜잭션 유형의 I/O 집약적 미션 크리티컬 애플리케이션에서 선호하는 스토리지 옵션이며, 구체적 사용사례는 다음과 같다.

① 트랜잭션 워크로드 : 시간에 민감한 미션 크리티컬 트랜잭션을 처리하는 조직에서는 지연 시간이 짧고 용량이 크며 내결함성이 높은 데이터베이스에 해당 워크로드를 저장한다. 블록 스토리지를 사용하면 강력하고 확장성이 높으며 매우 효율적인 트랜잭션 유형의 데이터베이스를 설정할 수 있다. 각 블록이 독립적인 단위이므로 저장된 데이터가 많아져도 데이터베이스가 최적의 성능을 발휘한다.

② 컨테이너 : 개발자는 블록 스토리지를 사용하여 컨테이너화된 애플리케이션을 클라우드에 저장한다. 컨테이너는 컴퓨팅 환경에 배포하기 위한 애플리케이션과 리소스 파일이 포함된 소프트웨어 패키지다. 컨테이너와 마찬가지로 블록 스토리지 역시 유연하고 확장 가능하며 효율적이다. 블록 스토리지를 사용하면 서버, 위치, 운영 환경 간에 컨테이너를 원활하게 마이그레이션할 수 있다.

③ 가상 머신 : 블록 스토리지는 널리 사용되는 가상 머신(VM) 하이퍼바이저를 지원한다. 사용자는 운영 체제, 파일 시스템, 기타 컴퓨팅 리소스를 블록 스토리지 볼륨에 설치할 수 있다. 방법은 블록 스토리지 볼륨을 포맷하고 VM 파일 시스템으로 변환하는 것이다. 따라서 가상 드라이브의 크기를 언제든지 확장 및 축소하고 가상화된 스토리지를 한 호스트에서 다른 호스트로 전송할 수 있다.

 

마지막으로, 객체 스토리지에서는 파일이 객체로 저장된다. 파일과 마찬가지로 객체는 저장될 때 구분된 단일 데이터 단위로 처리된다. 그러나 파일 스토리지와는 달리, 이 객체는 평면 구조를 사용하여 버킷에 저장된다. 즉, 폴더나 디렉터리, 복잡한 계층 구조가 없다는 것이다. 대신, 각 객체에는 고유 식별자가 있다. 이 식별자와 기타 메타데이터가 데이터와 번들로 저장된다.

 

블록 스토리지에서보다 객체에서 하나의 문자를 변경하는 것이 더 어렵다. 객체에서 한 문자를 변경하려면 전체 객체를 업데이트해야 하기 때문이다.

 

객체 스토리지를 사용하면 거의 모든 유형의 데이터를 저장할 수 있으며, 저장되는 객체 수에는 제한이 없으므로 확장성이 높다. 객체 스토리지는 일반적으로 대규모 또는 비정형 데이터 집합을 저장하는 데 유용하며, 구체적 사용사례는 다음과 같다.

① 데이터 아카이빙 : 클라우드 객체 스토리지는 장기 데이터 보존에 매우 적합하다. 대량의 리치 미디어 콘텐츠를 비용 효율적으로 아카이브할 수 있고, 규제를 받는 데이터를 더 오랜 기간 보존할 수 있다. 또한 온프레미스 테이프 및 디스크 아카이브 인프라를 교체하는 데도 클라우드 객체 스토리지를 사용할 수 있다. 이 스토리지 솔루션은 향상된 데이터 내구성, 즉각적인 검색 시간, 향상된 보안 및 규정 준수, 더 높은 데이터 액세스 가능성을 제공한다. 

② 백업 및 복구 : 콘텐츠를 복제하도록 객체 스토리지 시스템을 구성하여 물리적 디바이스에 장애가 생길 경우, 중복된 객체 스토리지 디바이스를 사용할 수 있다. 이렇게 하면 시스템과 애플리케이션을 중단 없이 계속해서 실행할 수 있다. 또한, 여러 개의 데이터 센터와 지리적 리전에 데이터를 복제할 수도 있다.

③ 리치 미디어 : 객체 스토리지를 사용하면 애플리케이션을 가속화하고 동영상, 디지털 이미지, 음악 같은 리치 미디어 파일을 저장하는 비용을 절감할 수 있다. 스토리지 등급과 복제 기능을 사용하여 비용 효율적이며, 전역적으로 복제되는 아키텍처를 생성함으로써 분산된 사용자들에게 미디어를 제공할 수 있다.

 

Amazon EFS 및 Amazon FSx에서 파일 스토리지 사용

Amazon Elastic File System(Amazon EFS)은 파일을 추가하고 삭제함에 따라 자동으로 확장되고 축소되는 특징이 있어 한 번 설정하고 나면 신경 쓰지 않아도 되는 파일 시스템이다. 스토리지 용량과 성능을 프로비저닝하고 관리할 필요가 없다는 장점이 있다. Amazon EFS는 AWS 컴퓨팅 서비스 및 온프레미스 리소스와 함께 사용할 수 있다. 수십 개, 수백 개 또는 수천 개의 컴퓨팅 인스턴스를 동시에 Amazon EFS 파일 시스템에 연결할 수 있으며, Amazon EFS는 각 컴퓨팅 인스턴스에 일관된 성능을 제공한다.

 

Amazon EFS의 간단한 웹 인터페이스를 사용하면 최소 수수료 또는 설정 비용 없이 파일 시스템을 빠르게 생성하고 구성할 수 있다. 사용한 스토리지에 대해서만 비용을 지불하며, 다양한 스토리지 등급 중에서 사용 사례에 맞는 것을 선택하면 되는 것이다.

 

Amazon FSx는 클라우드에서 고성능 파일 시스템을 쉽고 비용 효율적으로 시작, 실행, 규모 조정하는 데 도움이 되는 다양한 기능과 함께 신뢰성, 보안, 확장성을 제공하는 완전관리형 서비스다. Amazon FSx를 사용하면 널리 사용되는 4가지 파일 시스템인 Lustre, NetApp ONTAP, OpenZFS, Windows File Server 중에서 선택할 수 있다. 파일 시스템에 대한 익숙함이나 워크로드의 기능 집합, 성능 프로필, 데이터 관리 기능 요구 사항에 따라 선택할 수 있을 것이다.

 

Amazon EC2 인스턴스 스토어 및 Amazon EBS에서 블록 스토리지 사용

 

Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공한다. 이 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치한다. 따라서 데이터 수명 주기가 EC2 인스턴스의 수명 주기와 연동된다. 인스턴스를 삭제하면 인스턴스 스토어도 삭제된다. 이 때문에 인스턴스 스토어는 임시 스토리지로 간주되기도 한다. 

인스턴스 스토어는 데이터를 Hadoop 클러스터 등 다른 EC2 인스턴스로 복제하는 애플리케이션을 호스팅하는 경우에 적합하다. 이러한 클러스터 기반 워크로드의 경우, 로컬로 연결된 볼륨의 속도와 복제된 데이터의 복원력을 통해 고성능으로 데이터 배포를 달성할 수 있다. 또한 버퍼, 캐시, 스크래치 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보를 임시로 저장하는 데도 적합하다 볼 수 있다.

 

EBS의 경우, 이름에서 알 수 있듯이 Amazon Elastic Block Store는 Amazon EC2 인스턴스에 연결할 수 있는 블록 수준 스토리지로, 외장 드라이브를 랩톱에 연결하는 방법에 비유할 수 있다. 연결 가능한 이 스토리지를 EBS 볼륨이라고 한다. EBS 볼륨은 여러 측면에서 외장 드라이브와 유사하게 작동한다.

 

① 분리 가능 : EC2 인스턴스에서 EBS 볼륨을 분리한 후 동일한 가용 영역 내의 다른 EC2 인스턴스에 연결하여 데이터에 액세스할 수 있다.
② 별개의 스토리지 : 외장 드라이브는 컴퓨터와 별개다. 즉, 사고가 발생하여 컴퓨터가 다운되더라도 외장 드라이브에 데이터가 남아 있는데, EBS 볼륨도 마찬가지다.
③ 제한된 크기 : 확장 가능성에 일정한 제한이 있으므로 크기가 외장 드라이브의 크기로 제한된다. 볼륨에 저장할 수 있는 콘텐츠의 양에 최대 제한이 있다.
④ 일대일 연결: 대부분의 외장 드라이브는 한 번에 1대의 컴퓨터에만 연결할 수 있다. 대부분의 EBS 볼륨은 EC2 인스턴스와 일대일 관계가 있으므로 한 번에 여러 인스턴스에서 공유하거나 연결할 수 없다.

 

한편, 2가지 방법으로 EBS 볼륨의 크기를 조정할 수 있다.

 

① 볼륨 크기 증대 : 최대 크기 한도를 초과하지 않는 선에서 볼륨 크기를 늘린다. 선택한 볼륨에 따라 Amazon EBS는 현재 최대 64테비바이트(TiB)의 볼륨 크기를 지원한다. 예를 들어, 5TiB io2 블록 익스프레스 볼륨을 프로비저닝하면, 64TiB에 도달할 때까지만 볼륨의 크기를 늘릴 수 있는 것이다.

 

② 다중 볼륨 연결 : 하나의 EC2 인스턴스에 다중 볼륨을 연결한다. Amazon EC2는 EBS 볼륨과 일대다 관계가 있다. EC2 인스턴스 생성 중 또는 이후에 이러한 볼륨을 추가하여 호스트에 더 많은 스토리지 용량을 제공할 수 있다.

 

Amazon EBS는 데이터를 빠르게 검색하고 데이터를 장기간 유지해야 하는 경우에 유용하며, 볼륨은 다음 시나리오에서 흔히 사용된다.

① 운영 체제 : 부팅 볼륨과 루트 볼륨은 운영 체제를 저장하는 데 사용할 수 있다. Amazon Machine Image(AMI)에서 시작된 인스턴스의 루트 디바이스는 일반적으로 EBS 볼륨이다. 이를 흔히 EBS 지원 AMI라고도 한다.

② 데이터베이스 : Amazon EC2에서 실행되는 데이터베이스의 스토리지 계층으로, 성능 요구 사항에 따라 크기가 조정되며 일관적이고 지연 시간이 짧은 성능을 제공한다.

③ 엔터프라이즈 애플리케이션 : Amazon EBS는 비즈니스 크리티컬 애플리케이션을 실행할 수 있도록 가용성과 내구성이 뛰어난 블록 스토리지를 제공한다.

④ 빅 데이터 분석 엔진 : Amazon EBS는 데이터 지속성, 동적 성능 조정, 볼륨 분리 및 재연결 기능을 제공하므로, 빅 데이터 분석을 위해 클러스터의 크기를 조정할 수 있다.

 

그리고 EBS 볼륨은 솔리드 스테이트 드라이브(SSD) 및 하드 디스크 드라이브(HDD)의 2가지 주요 범주로 구성된다. SSD는 I/O 크기가 작고 읽기/쓰기 작업 빈도가 높은 트랜잭션 워크로드에 사용되고, HDD는 처리량 성능이 높아야 하는 대규모 스트리밍 워크로드에 사용된다.

Amazon EBS의 이점은 매우 다양한데, 열거하자면 다음과 같다.

① 고가용성 : EBS 볼륨을 생성하면 해당 가용 영역 내에 자동으로 복제되어 단일 장애 지점으로 인한 데이터 손실을 방지한다.

② 데이터 지속성 : 인스턴스가 중지되거나 종료되더라도 스토리지는 지속된다.  

③ 데이터 암호화 : 사용자가 활성화하면 모든 EBS 볼륨이 암호화를 지원한다. 

④ 유연성 : EBS 볼륨은 실행 중 변경을 지원한다. 인스턴스를 중지하지 않고 볼륨 유형, 볼륨 크기, 초당 입출력 작업 수(IOPS)를 수정할 수 있다.

⑤ 백업 : Amazon EBS는 EBS 볼륨의 유형과 상관없이 어디에나 백업을 생성하는 기능을 제공한다.

 

그런데 사람인 이상, 실수는 발생하기 마련일 것이다. 데이터를 백업하지 않아 결국 손실로 이어지는 것도 한 가지 실수다. 이런 실수를 방지하기 위해서는 AWS에서도 언제나 데이터를 백업해야 한다. EBS 볼륨에는 EC2 인스턴스의 데이터가 들어 있기 때문에 이런 볼륨의 백업, 즉 스냅샷을 만들어야 한다. EBS 스냅샷은 마지막 스냅샷 이후 변경된 볼륨의 블록만 저장하는 증분식 백업이다. 예를 들어 볼륨에 10GB의 데이터가 있고 마지막 스냅샷 이후 2GB만 수정되었다면 변경된 2GB만 Amazon S3에 작성되는 것이다.

EBS 볼륨의 스냅샷을 생성하면 Amazon S3을 사용하여 여러 가용 영역에 백업이 중복 저장된다. Amazon S3에 백업을 저장하는 이 부분은 AWS에서 처리하므로 EBS 스냅샷에 대한 작업을 수행하기 위해 Amazon S3와 상호 작용할 필요가 없다. 스냅샷은 Amazon EC2 콘솔의 일부인 Amazon EBS 콘솔에서 관리한다.

EBS 스냅샷은 동일한 가용 영역이든 다른 가용 영역이든 관계없이 여러 개의 새 볼륨을 생성하는 데 사용할 수 있다. 스냅샷에서 새로운 볼륨을 생성하는 경우, 새로운 볼륨은 해당 스냅샷이 생성된 시점의 원래 볼륨과 정확히 일치하는 사본일 것이다.

 

Amazon S3에서 객체 스토리지 사용

 

Amazon EBS와 달리 Amazon Simple Storage Service(Amazon S3)는 컴퓨팅과 연동되지 않는 독립형 스토리지 솔루션이다. Amazon S3을 사용하면 웹의 어느 곳에서나 데이터를 검색할 수 있다. 온라인 스토리지 서비스를 사용하여 로컬 머신의 데이터를 백업한 경우, Amazon S3와 유사한 서비스를 사용했을 가능성이 크다. 이러한 온라인 스토리지 서비스와 Amazon S3의 가장 큰 차이점은 스토리지 유형이다.

Amazon S3은 객체 스토리지 서비스다. 객체 스토리지는 데이터를 평면 구조에 저장한다. 객체는 메타데이터와 결합된 파일이며, 이러한 객체를 원하는 만큼 저장할 수 있다. 고로, 객체 스토리지의 모든 특성은 Amazon S3의 특성이기도 하다.

 

Amazon S3에서는 버킷이라는 컨테이너에 객체를 저장한다. 버킷을 먼저 생성하지 않으면 사진 한 장조차도 객체를 Amazon S3에 업로드할 수 없을 것이다. 버킷에 객체를 저장할 때, 버킷 이름, 키, 버전 ID가 조합되어 객체를 고유하게 식별할 수 있다.

 

Amazon S3은 이른바 '국룰'처럼 불릴 정도로 널리 사용되는 스토리지 서비스로, 구체적 사용사례는 다양하다.

① 백업 및 스토리지 : Amazon S3은 중복성이 높기 때문에 파일을 백업하기에 유용하다. AWS는 EBS 스냅샷을 Amazon S3에 저장하여 S3의 고가용성을 활용한다.  

② 미디어 호스팅 : 최대 5TB 크기의 객체를 제한 없이 저장할 수 있는 Amazon S3은 동영상, 사진, 음악 파일을 업로드하여 호스팅하기에 적합한 위치다.

③ 소프트웨어 전달 : Amazon S3을 사용하여 고객이 다운로드할 수 있는 소프트웨어 애플리케이션을 호스팅할 수 있다.

④ 데이터 레이크 : Amazon S3은 무제한에 가까운 확장성 덕분에 데이터 레이크에 가장 적합한 기반이다. 스토리지의 용량을 기가바이트에서 페타바이트로 늘리고 사용한 만큼만 비용을 지불할 수 있다.

⑤ 정적 웹 사이트 : HTML, CSS, 클라이언트 측 스크립트의 정적 웹 사이트를 호스팅하도록 S3 버킷을 구성할 수 있다.

⑥ 정적 콘텐츠 : 무제한의 확장성과 대규모 파일 지원, 언제든지 웹을 통해 어느 객체에나 액세스할 수 있다는 사실 덕분에 Amazon S3은 정적 콘텐츠를 저장하기에 완벽한 장소라 할 수 있다.

 

Amazon S3의 보안

 

Amazon S3의 모든 항목은 비공개가 기본값이다. 즉, 버킷, 객체와 같은 모든 Amazon S3 리소스는 해당 리소스를 생성한 사용자 또는 AWS 계정에서만 볼 수 있다. Amazon S3 리소스는 모두 처음부터 프라이빗으로 설정되어 보호된다.

모든 인터넷 사용자가 사진을 볼 수 있도록 하려는 경우, 버킷과 객체를 퍼블릭으로 설정할 수 있다. 퍼블릭 리소스는 인터넷상의 모든 사람이 볼 수 있음을 의미한다. 대부분의 경우, 권한을 모두 허용하거나 모두 거부하지는 않는다. 일반적으로 리소스에 대한 액세스 권한을 조금 더 세분화해서 제공하기를 원하기 때문이다.

 

Amazon S3은 Amazon S3 리소스에 대해 누가 어떤 작업을 수행할 수 있는지 더 구체적으로 정할 수 있도록 IAM 정책, S3 버킷 정책, 암호화 같은 보안 관리 기능을 제공하므로 자체 보안 정책을 수립하고 구현할 수 있다.

 

 IAM 정책이 리소스 또는 IAM 사용자, 그룹, 역할에 연결되면, 해당 정책은 이들이 수행할 수 있는 작업을 정의한다. 리소스에 연결하는 액세스 정책은 리소스 기반 정책이라 하고, 계정 내의 사용자에게 연결하는 액세스 정책은 사용자 정책이라 한다. IAM 정책과 마찬가지로 S3 버킷 정책은 JSON 형식으로 정의된다. 리소스 및 사용자에 연결되는 IAM 정책과 달리, S3 버킷 정책은 S3 버킷에만 연결할 수 있다. 버킷에 연결된 정책은 해당 버킷의 모든 객체에 적용된다. S3 버킷 정책은 버킷에 대해 허용 또는 거부되는 작업이 무엇인지 정의한다.

 

한편, Amazon S3은 전송 중 및 저장 중 암호화를 강화한다. 데이터를 보호하기 위해 Amazon S3은 업로드 시 모든 객체를 자동으로 암호화하며, Amazon S3의 모든 버킷에 대한 기본적인 수준의 암호화로 비용 추가 없이 S3 관리형 키를 사용하여 서버 측 암호화를 적용한다.

 

Amazon S3 스토리지 등급

Amazon S3에 객체를 업로드할 때 스토리지 등급을 지정하지 않으면 기본 스토리지 등급에 업로드하게 된다. Amazon S3 스토리지 등급을 통해 데이터 특징이 변경될 때 스토리지 티어를 변경할 수 있다. 예를 들어, 오래된 사진에 가끔씩만 액세스하는 경우, 그 사진의 스토리지 등급을 변경하여 비용을 절감하는 것이 좋은 것처럼 말이다.

 

스토리지 등급	설명
S3 Standard	클라우드 애플리케이션, 동적 웹 사이트, 콘텐츠 배포, 모바일 및 게이밍 애플리케이션, 빅 데이터 분석을 위한 범용 스토리지로 간주된다.
S3 Intelligent-Tiering	이 티어는 데이터의 액세스 패턴을 알 수 없거나 패턴에 변동성이 있는 경우에 유용하다. S3 Intelligent-Tiering은 객체를 3개의 티어, 즉 Frequent Access 티어, Infrequent Access 티어, Archive instance access 티어에 저장한다. Amazon S3이 데이터의 액세스 패턴을 모니터링하고 액세스 빈도에 따라 데이터를 가장 비용 효율적인 스토리지 티어로 자동으로 옮긴다.
S3 Standard - Infrequent Access(S3 Standard-IA)	이 티어는 자주 액세스하지는 않지만 필요할 때 빠른 액세스가 필요한 데이터에 적합하다. S3 Standard-IA는 S3 Standard의 뛰어난 내구성, 높은 처리량, 짧은 지연 시간을 저렴한 GB당 스토리지 요금과 GB당 검색 요금으로 제공한다. 이 스토리지 티어는 장기 백업, 재해 복구 파일 등을 저장하려는 경우에 적합하다.
S3 One Zone-Infrequent Access(S3 One Zone-IA)	최소 3개의 가용 영역에 데이터를 저장하는 다른 S3 스토리지 등급과 달리, S3 One Zone-IA는 하나의 가용 영역에 데이터를 저장하기 때문에 S3 Standard-IA보다 저렴하다. S3 One Zone-IA는 자주 액세스하지 않는 데이터를 위한 저렴한 옵션을 원하지만, S3 Standard 또는 S3 Standard-IA의 가용성과 복원력이 필요 없는 고객에게 적합하다. 이 서비스는 온프레미스 데이터나 쉽게 다시 생성할 수 있는 데이터의 보조 백업 복사본을 저장하기에 좋은 선택이다.
S3 Glacier Instant Retrieval	S3 Glacier Instant Retrieval은 액세스 빈도는 낮지만, 몇 밀리초 만에 검색해야 하는 데이터를 아카이브하는 데 사용된다. 이 스토리지 등급에 저장되는 데이터는 S3 Standard-IA 스토리지 등급과 비교하여 최대 68%의 비용 절감 효과를 제공하는 한편, 지연 시간과 처리량 성능은 동일하다.
S3 Glacier Flexible Retrieval	S3 Glacier Flexible Retrieval은 1년에 한두 번 액세스하는 아카이브된 데이터를 위한 저렴한 스토리지를 제공한다. S3 Glacier Flexible Retrieval에서는 신속 검색을 사용하여 데이터에 1~5분 만에 액세스할 수 있다. 최대 5~12시간 만에 제공되는 대량 검색을 무료로 요청할 수도 있다. 백업, 재해 복구, 오프사이트 데이터 스토리지 요구 사항에 이상적이며, 일부 데이터를 몇 분 만에 검색해야 하는 경우에도 적합한 솔루션이다.
S3 Glacier Deep Archive	S3 Glacier Deep Archive는 비용이 가장 저렴한 Amazon S3 스토리지 등급이다. 1년에 한두 번 액세스하는 데이터의 장기 보존 및 디지털 보존을 지원한다. S3 Glacier Deep Archive 스토리지 등급에 저장된 데이터의 기본 검색 시간은 12시간이다. 규정 준수 요건을 충족하기 위해 7~10년 또는 그 이상의 기간 동안 데이터세트를 보존하는 고객을 위해 설계되었다. 따라서 예시로는 금융 서비스, 의료 서비스, 공공 부문 등 규제가 엄격한 산업의 고객을 들 수 있다.
S3 on Outposts	Amazon S3 on Outposts는 S3 API 및 기능을 사용하여 온프레미스 AWS Outposts 환경에 객체 스토리지를 제공한다. 지역의 데이터 레지던시 요구 사항을 준수해야 하거나 성능을 위해 온프레미스 애플리케이션과 가까이에 데이터를 보관해야 하는 워크로드의 경우, S3 Outposts 스토리지 등급이 적합한 옵션이다.

 

스토리지 수명 주기 관리

 

 

직원 사진과 같은 객체를 한 스토리지 티어에서 다른 스토리지 티어로 계속해서 수동으로 변경하는 경우, Amazon S3 수명 주기 정책을 구성하여 이 프로세스를 자동화하는 것이 좋을 것이다. 객체 또는 객체 그룹에 수명 주기 구성을 정의할 때 전환과 만료라는 2가지 작업 유형 중 하나를 자동화하도록 선택할 수 있다.

① 전환 작업은 객체가 다른 스토리지 등급으로 전환될 시기를 정의한다.
② 만료 작업은 객체가 만료되어 영구적으로 삭제되는 시점을 정의한다.

 

예를 들어, 객체를 생성한 후 30일이 지나면 S3 Standard-IA 스토리지 등급으로 전환할 수 있다. 그게 아니라면 객체를 생성하고 1년이 지나면 S3 Glacier Deep Archive 스토리지 등급으로 객체를 아카이브할 수도 있을 것이다.

 

수명 주기 구성 규칙을 사용하기에 적절한 사례는 다음과 같다.

① 주기적 로그 : 버킷에 주기적으로 로그를 업로드할 경우, 애플리케이션에서는 이 로그를 한 주나 한 달 동안 필요로 할 수 있다. 그 이후에는 로그를 삭제하고 싶을 것이다.

② 액세스 빈도가 변경되는 데이터 : 일부 문서는 제한된 기간 동안 자주 액세스되지만 그 이후에는 가끔 액세스된다. 어느 시점이 되면 이러한 문서에 실시간으로 액세스할 필요가 없지만, 조직 또는 규정에서 특정 기간 동안 해당 문서를 아카이브할 것을 요구할 수도 있다. 그 후에는 문서를 삭제할 수 있다.