# S3

## 개요

* Amazon S3는 백업과 스토리지로 활용되는 오브젝트 스토리지이다.
* 용도
  * 파일을 저장하는 용도로 쓰거나 디스크처럼 쓸 수도 있다.
  * 재해 복구의 용도로도 쓸 수 있다. 예를 들어 리전이 다운되는 경우 데이터를 다른 리전으로 이동시킬 때 백업해둘 수 있다.
  * 하이브리드 클라우드 스토리지로 쓸 수 있다. 온프레미스에 스토리지가 있지만 클라우드로 확장하고자 한다면 Amazon S3를 사용할 수 있다.
  * 애플리케이션을 호스팅하고 동영상 파일이나 이미지 등 미디어를 호스팅할 수 있다.
  * 데이터 레이크를 보유하여 다량의 데이터를 저장하고 빅 데이터 분석을 수행하기 위해 사용할 수 있다.
  * 정적 웹 사이트를 호스팅할 수 있다.
* 파일을 버킷에 저장하는데, 버킷은 상위 레벨 디렉토리로 표시된다.
* 버킷은 계정 별로 생성할 수 있으며, 버킷의 이름은 AWS 전역적으로 고유해야 한다. 리전 수준에서 정의된다.
* 버킷 이름에는 대문자나 밑줄이 없어야 하고, 길이는 3자에서 63자 사이여야 하며, IP여서는 안 되고, 소문자나 숫자로 시작해야 한다. 문자와 숫자, 하이픈만 사용하면 된다.
* 키
  * 하나의 객체나 파일에는 키가 매핑된다.
  * Amazon S3 키는 파일의 전체 경로이다. 예를 들어 my\_file.txt 파일의 키는 my\_file.txt이다.&#x20;
  * 접두사와 객체 이름으로 구성된다. 접두사는 파일명을 제외한 상위 디렉토리들이 된다. 하지만 Amazon S3 자체에서는 디렉토리라는 개념을 갖고 있지 않다.
* 객체
  * S3 버킷의 파일
  * 키에 매핑되는 값이다.
  * 파일 등 어떤 형식이든 Amazon S3로 업로드할 수 있다.
  * 최대 객체 크기는 5TB이다. 하지만 파일이 크면 멀티파트 업로드를 사용해서 해당 파일을 여러 부분으로 나눠 업로드해야 한다.
  * 객체에는 메타데이터를 저장할 수 있다. 시스템이나 사용자에 의해 설정될 수 있다.
  * 태그는 보안과 수명 주기에 유용하며, 최대 10개까지 저장 가능한 유니코드 키-값 쌍이다.
  * 버전 관리를 활성화한 경우 버전 ID를 가질 수 있다.

## 웹사이트

* Amazon S3를 활용하여 정적 웹 사이트를 생성할 수 있다.
* 웹 사이트 URL은 AWS 리전과 버킷 이름에 따라 달라진다. ex) http://bucket-name.s3-website-aws-region.amazonaws.com
* 버킷에 대한 공개 읽기가 활성화되어야 브라우저에서 접근 가능하다.

## 버전 관리

* 버전 관리 기능을 사용하는 경우 동일한 키를 업로드하고 해당 파일을 덮어쓰는 업로드를 할 때마다 버전이 생성된다.
* 버전 관리를 통해 의도하지 않게 객체가 삭제되지 않도록 보호할 수 있다. 한 파일의 버전을 삭제할 때 삭제 마커를 추가하고 실제로 지우지 않는다. 따라서 삭제 마커 자체를 지우면 데이터를 원상복구할 수 있는 것이다.
* 이전 버전으로 쉽게 롤백할 수도 있다.
* 버전 관리를 활성화하기 전에 버전 관리가 적용되지 않은 모든 파일은 널(null) 버전을 갖게 된다.
* 버전 관리를 중단해도 이전 버전을 삭제하지 않는다.

## 복제

* 소스 버킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화되어야 한다.
* 서로 다른 AWS 계정간에도 사용할 수 있다.
* CRR은 교차 리전 복제이고, SRR은 동일 리전으로 복제이다.
  * CRR은 컴플라이언스, 즉 법규나 내부 체제 관리, 그리고 데이터가 다른 리전에 있어 발생할 수 있는 지연 시간을 줄일 경우에 사용한다. 또는 계정 간 복제에도 쓸 수 있다.
  * SRR은 다수의 S3 버킷 간의 로그를 통합할 때나, 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용될 수 있다.
* 복제는 비동기로 백그라운드에서 수행된다.
* 복제 기능이 정상적으로 실행되려면, S3에 읽기/쓰기가 가능하도록 IAM 권한을 부여해야 한다.
* 스토리지 계층 복제를 활성화한 후에는 새로 추가되는 객체만 복제 대상이 된다.
* 기존의 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다.
* 소스 버킷에서 대상 버킷으로 삭제 마커를 복제해야 삭제된 파일을 다른 버킷에서 노출하지 않는다.
* 버전 ID를 기반으로 객체를 삭제하는 경우 이는 복제되지 않는다.
* A -> B -> C 버킷과 같은 체이닝 복제는 불가하다. A -> B, A -> C로 각각 복제해야 한다.
* Batch Operations 작업을 이용한 배치 복제를 사용하면 복제 구성이 이루어지기 전에 있었던 객체, 이전에 복제되었던 객체, 복제에 실패했던 객체를 복제할 수 있다.

## 스토리지 계층

* 모든 스토리지 계층에 Multi AZ rks 99.99999999999% 의 내구성을 보장한다. Amazon S3에 천만 개의 객체를 저장했을 때 평균적으로 10,000년에 한 번 객체 손실이 예상되는 정도이다.
* 가용성은 스토리지 계층마다 다르다.
* 스토리지 클래스를 수동으로 변경하거나 Amazon S3 수명 주기 구성을 사용해 스토리지 클래스 간에 객체를 자동으로 이동시킬 수 있다.

### 종류

* Amazon S3 Standard
  * 99.99% 가용성을 보장한다.
  * 자주 액세스하는 데이터에 사용되며, 가장 기본적으로 사용하는 스토리지 유형이다.
  * 지연 시간이 짧고 처리량이 높다.
  * AWS에서 두 개의 기능 장애를 동시에 버틸 수 있다.
  * 빅 데이터 분석, 모바일과 게임 애플리케이션 그리고 콘텐츠 배포 등에 사용할 수 있다.
* Amazon S3 Infrequent Access
  * 자주 액세스하지는 않지만 필요한 경우 빠르게 액세스해야 하는 경우 사용한다.
  * S3 Standard보다 비용이 적게 들지만 조회할 때 마다 비용이 발생한다.
  * 99.9% 가용성을 보장한다.
  * 재해 복구와 백업 용도로 사용할 수 있다.
* Amazon S3 One Zone-Infrequent Access(IA)
  * 단일 AZ에서 동작하며, 높은 내구성을 갖지만 AZ가 파괴된 경우 데이터를 잃게 된다.
  * 99.5% 가용성을 보장한다.
  * 온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장하는 데 쓰인다.
* Glacier Instant Retrieval
  * 아카이빙과 백업을 위한 저비용 객체 스토리지
  * 밀리초 단위로 조회가 가능하다.
  * 최소 보관 기간이 90일이기 때문에 백업이지만 밀리초 이내에 액세스해야 하는 경우 적합하다.
* Glacier Flexible Retrieval
  * Expedited는 데이터를 1\~5분 이내에 받을 수 있고, Standard는 데이터를 돌려받는 데 3\~5시간 소요되고, Bulk는 무료지만 데이터를 돌려받는 데 5\~12시간이 소요된다.
  * 최소 보관 기간은 90일이다.
* Glacier Deep Archive
  * 조회 시 12시간이 걸리는 Standard와 48시간이 걸리는 Bulk 타입이 있다.
  * 비용이 가장 저렴하고 최소 보관 기간이 180일이다.
* Amazon S3 Intelligent Tiering
  * 사용 패턴에 따라 액세스 티어 간에 객체를 자동으로 이동시켜준다.
  * 소액의 월별 모니터링 비용과 티어링 비용이 발생하지만 조회 비용은 없다.
  * FrequentAccess 티어는 자동이고 기본 티어이다.
  * Infrequent Access 티어는 30일 동안 액세스되지 않은 객체 전용 티어이다.
  * Archive Instant Access 티어는 90일 동안 액세스되지 않은 객체 전용 티어이다.
  * Archive Access 티어는 선택 사항이며 90일에서 700일 이상까지 구성할 수 있다.
  * Deep Archive Access 티어는 선택 사항이며 180일에서 700일 이상 액세스하지 않는 객체를 저장할 수 있다.
* Amazon S3 Express One Zone
  * 가장 자주 액세스하는 데이터와 지연 시간에 민감한 애플리케이션에 대해 10밀리초 미만의 일관된 데이터 액세스를 제공하도록 특별히 설계된 고성능 단일 가용 영역 스토리지 클래스이다.
  * S3 Standard에 비해 데이터 액세스 속도는 최대 10배 빠르고 요청 비용은 최대 50% 저렴하다.
  * 데이터 액세스 속도를 크게 개선하여 모델 데이터세트를 더 빠르게 처리함으로써 **모델 훈련 및 개발을 가속화**할 수 있다.

## 수명 주기 규칙

* 수명 주기 규칙을 이용하거나 직접 수작업으로 다른 스토리지 클래스 간에 객체를 옮길 수 있다.
  * 예를 들어 Standard로부터 자주 접근되지 않는 객체를 Standard IA, Intelligent Tiering, One-Zone IA 등으로 옮길 수 있다.
  * 오래된 객체를 아카이브화하려면 Glacier 티어나 Deep Archive 티어로 이전할 수 있다.
*   Transition Actions

    * 다른 스토리지 클래스로 이전하기 위한 객체를 설정한다.
    * 예를 들어 객체가 생성된 지 60일 후에는 Standard 클래스로 이전하고 6개월 후에는 Glacier로 이전해서 아카이브화 한다고 정의할 수 있다.

    > **어떤 티어로든 최소 30일은 지난 후에야 옮길 수 있다.**
* Expiration actions
  * 일정한 시간 뒤에 객체를 만료시켜 삭제하도록 설정할 수 있다.
  * 예를 들어 액세스 로그 파일을 365일 후에 삭제하도록 설정할 수 있다.
  * 버저닝을 활성화했다면 오래된 버전의 객체를 만료시켜 삭제할 수도 있다.
  * 멀티파트 업로드가 한참 전에 시작되었지만 아직 완료되지 않은 불완전한 데이터를 삭제할 수 있다.
* 특정한 접두어에 대해 규칙을 지정하여 버킷 전체에 적용하거나 버킷 안의 특정한 경로에 적용할 수 있다.
* 특정한 객체 태그에 대해 규칙을 지정할 수도 있다.

> Q. EC2에 구동된 애플리케이션에 사용자가 프로필 사진을 업로드하면 일단  Amazon S3에 업로드하고 이미지 섬네일을 생성한다. 섬네일은 원본 사진으로부터 쉽게 재생성할 수 있으며 60일 동안만 보관하고자 한다. 원본 이미지는 60일 동안 즉시 조회 가능해야 하고 60일 이후에는 최장 6시간 동안 기다릴 수 있도록 한다. 어떻게 아키텍처를 디자인할 것인가?
>
> A. S3 원본 이미지는 Standard 클래스에 두고 60일 후에 Glacier로 이전하도록 한다. 섬네일 이미지는 One-Zone IA에 두어 60일 후에 만료시켜 삭제되도록 할 수 있다.

> Q. 30일 동안은 삭제된 S3 객체를 즉각적으로 복구할 수 있어야 하고, 30일이 지난 후 최장 365일 동안은 삭제된 객체를 48시간 이내에 복구할 수 있어야 한다. 어떻게 아키텍처를 디자인할 것인가?
>
> A. S3 버저닝을 활성화해서 객체 버전을 보관해야 하고, 최신 버전이 아닌 객체들을 Standard IA로 이전하도록 한다. 이후 Glacier Deep Archive로 이전할 수 있다.

* 객체를 다른 클래스로 이전할 최적의 날짜를 결정할 때 Amazon S3 Analytics를 이용하면 편리하다.
  * Standard나 Standard IA에 관한 추천사항을 제시할 수 있지만, One-Zone IA나 Glacier와는 호환되지 않는다.
  * S3 Analytics는 매일 csv 보고서를 생성하고 추천사항과 통계를 제공한다.
  * 데이터 분석 결과는 24\~48시간 정도 기다려야 나올 수 있다.

## 요청자 지불

* 일반적으로 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 버킷 소유자가 지불한다.
* 버킷들에 객체를 보관하고 있고, 사용자가 버킷으로부터 파일을 다운로드하면 네트워킹 비용이 버킷 및 객체 소유자에게 청구된다.
* 요청자 지불 버킷을 활성화하면, 파일 요청자가 객체 데이터 다운로드 비용을 지불하도록 할 수 있다.
* 대량의 데이터 셋을 다른 계정과 공유하려고 할 때 유용하다.
* 요청자는 AWS에서 인증을 받은 상태여야 AWS가 객체에 대한 다운로드 요청자에게 비용을 청구할 수 있다.

## 이벤트 알림

* Amazon S3에서는 객체가 생성되었거나 객체가 삭제되었거나 객체가 복구되었거나 복제되는 등의 이벤트를 발생시킬 수 있다.
* 이벤트들을 필터링하여 알림을 SNS 토픽, SQS Queue, 람다 함수 등에 전달해 작업을 처리할 수 있다.
* 이벤트들은 보통 몇 초 안에 그런 대상으로 전달되지만, 간혹 몇 분 정도 걸릴 수도 있다.
* 이벤트 알림이 작동하려면 IAM 역할을 갖고 있어야 한다.
  * S3 서비스가 데이터를 SNS 토픽에 직접 전송하려면 SNS 리소스 정책을 매핑해야 한다.
  * S3 서비스가 SQS Queue에 데이터를 전송하도록 하려면 SQS 리소스 액세스 정책을 매핑해야 한다.
  * S3 서비스가 람다 함수를 호출하려면 람다 리소스 정책을 매핑해야 한다.
* Amazon EventBridge
  * 모든 이벤트는 Amazon S3 버킷으로 이동 후 Amazon EventBridge로 모인다.
  * EventBridge에서 규칙을 설정하여 18가지 AWS 서비스에 전송할 수 있다.
  * EventBridge를 사용하면 고급 필터링 옵션을 사용할 수 있다. 메타데이터, 객체 사이즈, 이름 등으로 필터링 가능하다.
  * 한꺼번에 다수의 대상(Step Functions, Kinesis Streams, Firehose 등)에 이벤트를 전송할 수 있다.
  * 아카이빙, 이벤트 중계, 안정적인 전달 등 여러 기능을 제공한다.

## 성능

### 기본 성능

* 아마존 S3는 기본적으로 높은 요청률과 100-200ms 지연 시간을 제공하기 위해 자동으로 스케일링된다.
* 버킷 내에서 prefix 마다 초당 3,500개의 PUT, COPY, POST, DELETE 요청을 보낼 수 있고, 5500개의 GET, HEAD 요청을 보낼 수 있다.
* 버킷의 접두사 수에는 제한이 없다. 만약 4개의 접두사에 균등하게 조회 요청을 분산하면 초당 최대 22,000개의 요청을 처리할 수 있다.

### 성능 최적화

* 멀티파트 업로드
  * 100MB가 넘는 파일에는 멀티파트 업로드를 권장하고, 5GB가 넘는 파일에는 반드시 멀티파트 업로드를 사용해야 한다.
  * 업로드를 병렬화하므로 전송 속도를 높여 대역폭을 최대화할 수 있다.
  * 모든 청크가 업로드되면 이를 큰 파일로 다시 합칠 수 있다.
* S3 전송 가속화
  * 업로드 및 다운로드 속도 향상을 위해 파일을 AWS 엣지 위치로 먼저 전송하고 이후 대상 지역의 S3 버킷으로 데이터가 전달되도록 하는 방식이다.
  * 현재 200개가 넘는 엣지 위치가 있다.
  * 전송 가속화는 멀티파트 업로드와 호환된다.
  * 공공 인터넷의 사용량을 최소화하고 프라이빗 AWS 네트워크의 사용량을 최대화한다.
* Byte-Range Fetches
  * 파일의 특정 바이트 범위를 조회해 전체 조회 요청을 병렬화할 수 있다.
  * 특정 바이트 범위를 가져오는 데 실패하였다면 더 작은 바이트 범위로 다시 조회 시도를 할 수 있다.
  * 실패 시 복원력이 향상되어 다운로드 속도를 높이는 데 사용할 수 있다.
  * 파일의 일부, 예를 들면 헤더 부분만 조회 요청을 보낼 수 있어, 일부 데이터만 필요하다면 빠르게 조회 가능하다.

## 배치 작업

* 단일 요청으로 기존 S3 객체에서 대량 작업을 수행하는 서비스
* 제공되는 기능은 다음과 같다.
  * S3 객체들의 메타데이터와 프로퍼티를 일괄 수정할 수 있고, 배치 작업으로 S3 버킷 간에 객체를 복사할 수 있다.
  * S3 버킷 내 암호화되지 않은 모든 객체를 암호화할 수 있다.
  * &#x20;ACL이나 태그를 수정할 수 있다.
  * S3 Glacier에서 한 번에 많은 객체를 복원할 수 있다.
  * Lambda 함수를 호출해 S3 Batch Operations의 모든 객체에서 사용자 지정 작업을 수행할 수 있다.
* S3 Batch Operations를 사용하면 재시도를 관리하거나 진행 상황을 추적하고 작업 완료 알림을 보내고 보고서 생성을 할 수 있다.
* S3 Inventory를 통해 객체 목록을 가져오고 S3 Select를 통해 필터링하여 S3 배치에 전달할 객체를 선별한다.
* S3 Batch Operations에 수행할 작업, 매개 변수, 객체 목록을 전달하면 S3 배치가 작업을 수행하고 객체를 처리한다.

## Storage Lens

* 전체 AWS 조직에서 스토리지를 이해하고, 분석하고, 최적화하는 데 도움이 되는 서비스이다.
* 이상 징후를 발견하고, 비용 효율성을 파악하며, 전체 AWS 조직에 보호 모범 사례를 적용할 수 있다.
* 30일 동안의 사용량 및 활동 메트릭이 제공된다.
* 조직, 특정 계정, 지역, 버킷, 접두사 수준에서 데이터를 집계할 수 있다.
* 모든 메트릭을 CSV, parquet 형식으로 S3 버킷에 내보낼 수 있다.
* 요약 인사이트, 데이터 보호, 비용 효율성을 분석해 Amazon S3 사용을 최적화할 수 있다.
* 기본 대시보드 혹은 커스텀 대시보드를 사용할 수 있다.
* 기본 대시보드는 다음과 같은 특징을 가진다.
  * 무료 및 고급 지표에 대한 요약된 인사이트와 트렌드를 확인할 수 있다.
  * 여러 지역과 여러 계정의 데이터가 표시된다. 조회하고 싶은 지역, 계정, 버킷, 스토리지 클래스를 지정할 수 있다.
  * Amazon S3에 의해 사전 구성된다.
  * 삭제할 수 없지만 비활성화할 수는 있다.
  * 총 저장 용량, 객체 수, 평균 객체 크기, 보유한 버킷 수, 계정 등의 정보를 확인할 수 있다.

### 메트릭

* 요약 메트릭
  * 일반적인 S3 스토리지에 대한 정보
  * StorageBytes, ObjectCount 등
  * 빠르게 커지거나 사용하지 않는 버킷, 접두사를 식별하는 용도로 사용 가능하다.
* 비용 최적화 메트릭
  * 스토리지 비용을 관리하고 최적화할 수 있는 인사이트 제공
  * NonCurrentVersionStorageBytes, IncompleteMultipartUploadStorageBytes 등
  * 어떤 버킷이 다중 파트 업로드에 실패했는지 또는 어떤 객체를 더 저렴한 스토리지 클래스로 전환할 수 있는지 확인하는 용도로 사용 가능하다.
* 데이터 보호 메트릭
  * 데이터 보호 기능에 대한 인사이트를 제공한다.
  * VersioningEnabledBucketCount, MFADeleteEnabledBucketCount, SSCKMSEnabledBucketCount, CrossRegionReplicationRuleCount 등
  * 데이터 보호 모범 사례를 따르지 않는 버킷을 식별하는 용도로 사용 가능하다.
* 액세스 관리 메트릭
  * S3 버킷 소유권에 대한 인사이트를 제공한다.
  * 버킷이 현재 어떤 객체 소유권 설정을 사용하고 있는지 식별할 수 있다.
* 이벤트 메트릭
  * S3 이벤트 알림에 대한 인사이트를 제공한다.
  * EventNotificationEnabledBucketCount
* 퍼포먼스 메트릭
  * S3 전송 가속에 대한 인사이트를 제공한다.
  * TransferAccelerationEnabledBucketCount
* 액티비티 메트릭
  * 얼마나 요청이 들어왔는지에 대한 인사티으를 제공한다.
  * AllRequests, GetRequests, PutRequests,  ListRequests, BytesDownloaded 등
* Detailed Status Code Metrics
  * HTTP 상태 코드에 대한 인사이트를 제공한다.
  * 200OKStatus Count, 403ForbiddenErrorCount 등
* 무료 메트릭은 모든 고객에게 자동으로 제공되며 약 28개의 사용량 지표가 포함되어 있고 쿼리에 대한 데이터는 14일 동안 조회할 수 있다.
* 유로 메트릭은 고급 메트릭을 추가로 지원하고, CloudWatch에서 추가 비용 없이 접근할 수 있다. 접두사 단위로 메트릭을 수집할 수도 있고 데이터를 15개월 동안 사용할 수 있다.
