Amazon S3?

Amazon S3는 AWS의 주요 구성 요소중 하나로 무한하게 확장할 수 있는 스토리지라고 소개하고 있다.

현재 많은 웹사이트에서 Amazon S3를 중추(Backbone)로 활용하며, 많은 AWS 서비스는 Amazon S3 통합을 위해 사용하고 있다.

Amazon S3의 사용 사례

• 백업과 스토리지 ex) 파일 , 디스크 스토리지
• 재해 복구
• 아카이브
• 하이브리드 클라우드 스토리지 : 온프레미스에 스토리지아 있지만 클라우드로 확장하고자 하는 경우
• Application 호스팅
• 데이터 레이크(Data Lakes) & 빅 데이터 분석
• 소프트웨어 전달(Delivery)
• 정적 웹사이트 호스팅

버킷(Buckets)

Amazon S3는 파일을 버킷에 저장한다. 버킷은 상위 레벨 디렉토리(directories)로 표시되고 S3 버킷의 파일은 객체(objects)라고 하며 이 버킷은 계정 안에 생성된다.
버킷에는 전역적으로 고유한 이름이 있어야하는데 이름은 계정에 있는 모든 리전과 AWS에 존재하는 모든 계정에서 고유해야한다.
버킷은 리전 수준에서 정의된다. 버킷의 이름이 전역적으로 고유해도 버킷은 반드시 특정 AWS리전에서 정의되어야한다. 즉, S3는 전역 서비스처럼 보이지만 버킷은 사실상 리전에서 생성된다.

버킷 명명 규칙

• 대문자나 밑줄이 없어야 한다.
• 3자 ~ 63자 사이의 길이
• IP여서는 안된다.
• 소문자나 숫자로 시작해야 한다.
• 몇 가지 접두사도 제한된다.
• 문자와 숫자, 하이픈만 사용가능하다.

객체(Objects)

객체(파일)은 키를 가지며 키는 파일의 전체 경로이다.

• ex:s3//my-bucket/my_file.txt
• ex:s3//my-bucket/my_folder/another_folder/my_file.txt

키는 접두사와 객체 이름으로 구성되며 s3://버킷 명/접두사/객체명 같은 구조를 가진다. (Amazon S3 그 자체로는 디렉토리의 개념은 없다.)
또한 키는 길이가 굉장히 긴 이름으로 슬래시를 포함하며, 키는 접두사와 객체명으로 만들어진다.

객체 정보

• 최대 객체의 크기는 5TB
• 매우 큰 파일을 업로드하는 경우(5GB 이상) 멀티파트 업로드를 사용해서 해당 파일을 여러 부분으로 나눠 업로드해야 한다.
• 객체에는 메타데이터가 있다. (키-값 쌍 리스트)
• 보안과 수명 주기에 유용한 태그를 설정할 수 있다.(유니코드 키-값 쌍 최대 10개)
• 버전 관리를 활성화한 경우 버전 ID를 가질 수 있다.

Amazon S3 보안

• 사용자 기반 (User-Based)
  - IAM 정책 : 어떤 API 호출이 특정 IAM 사용자를 위해 허용되어야 하는지를 승인한다.

• 리소스 기반 (Resource-Based)
  - S3 버킷 정책 : S3 콘솔에서 직접 할당할 수 있는 전체 버킷 규칙으로 버킷을 공개로 만드는 방법
  ex) 특정 사용자가 들어올 수 있게 하거나 다른 계정의 사용자를 허용할 수 있다.
  - 객체 액세스 제어 목록 (ACL : Object Access Control List) : 보다 세밀한 보안으로 비활성화 할 수 있다
  - 버킷 액세스 제어 목록 (ACL : Object Access Control List) : 훨씬 덜 일반적으로 비활성화 할 수 있다.
  

• 암호키 (Encryption) : 암호키를 사용하여 객체를 암호화 할 수 있다.

Amazon S3 보안 관리의 가장 일반적인 방법은 버킷 정책을 사용하는 것이다.

S3 버킷 정책

Json 기반 정책

{
  "Version" : "2012-10-17"
  "Statement" : [
  	{
  		"Sid" : "PublicRead", 
  		"Effect" : "Allow",
  		"Principal" : "*",
  		"Action" : [
  			"s3:GetObject"
		],
		"Resource" : [
          	"arn:aws:s3:::examplebucket/*"        
        ]  		
	}
  ]
}

• Resource : 이 정책이 적용되는 버킷과 객체를 정책에 알려준다.
• Effect : Allow(허용)/(Deny)거부가 있고 Action에 대한 Effect이다.
• Action : API의 집합으로 Effect에서 Allow/Deny 가 가능하다.
• Principal : 정책을 허용할 계정 또는 사용자를 제시한다. 별표(*)를 통해 모든 사용자를 허용할 수 있다.

이 S3 버킷은 버킷 내 모든 객체에 대해 공개 읽기로 설정하고 있다. 이와 같이 필요한 버킷 정책을 사용하여 버킷에 대한 공개 액세스를 허용할 수 있다.

정적 웹사이트 호스팅(Static Website Hosting)

Amazon S3는 정적 웹사이트를 호스팅하고 인터넷에서 액세스 할 수 있게 만든다. 웹 사이트 URL은 이것을 생성하는 AWS 리전에 따라 달라지며 다음 두가지 경우 중 하나가 될 것이다.

• http://[bucket-name].s3-website-[aws-region].amazonaws.com
• http://[bucket-name].s3-website.[aws-region].amazonaws.com

하지만 버킷에서 공개 읽기가 활성화되지 않은 경우 403 Forbidden error가 발생한다.

버전 관리(Versioning)

Amazon S3에서는 파일을 버전 관리할 수 있다. 버전관리는 버킷 수준에서 활성화해야 하는 설정이며 사용자가 파일을 업로드 할 때마다 선택 키에서 해당 파일의 버전이 생성된다. 동일한 키를 업로드하고 해당 파일을 덮어쓰는 경우 버전2, 버전3 등을 생성하게 되어 의도하지 않은 방법으로 파일이 삭제되지 않도록 보호해준다.
파일을 삭제하는 경우에는 사실상 삭제 마커를 추가한 것이 된다. 이 삭제 마커를 통해 이전 버전으로 쉽게 복구하거나 롤백할 수 있다.
유의 사항으로 버전 관리기능을 활성화 하기 전에 버전 관리가 적용되지 않은 파일은 NULL 버전을 가지게 된다. 또한 버전 관리를 중단해도 이전 버전을 삭제하지는 않는다.

Amazon S3 복제

Amazon S3 버킷을 복제 하기 위해서는 가장 먼저 소스 버킷과 복제 대상이 되는 버킷 모두 버전 관리 기능이 활성화 되어 있어야한다. 버킷은 서로 바른 AWS 계정간에도 사용할 수 있고 복제는 비동기식으로 이루어진다.

CRR (Cross-Region Replication)

• 소스 버킷과 복제 대상 버킷의 리전이 서로 달라야 한다.
• 컴플라이언스, 즉 법규나 내부 체제 관리 그리고 데이터가 다른 리전에 있어 발생할 수 있는 지연 시간을 줄일 경우에 사용한다.
• 계정간 복제에 사용할 수 있다.

SRR (Same-Region Replication)

• 소스 버킷과 복제 대상 버킷의 리전이 서로 같아야 한다.
• 다수의 S3 버킷간의 로그를 통합할 때나 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용될 수 있다.

참고 사항

• 복제를 활성화한 후에는 새로운 객체만 복제 대상이 된다.
• 기존의 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다.
• S3 배치 복제 기능은 기존 객체부터 복제에 실패한 객체까지 복제할 수 있다.
• 작업을 삭제하려면 소스 버킷에서 대상 버킷으로 삭제 마커를 복제하면 된다. 이는 설정에서 선택할 수 있다.
• 버전 ID로 삭제하는 경우 버전 ID는 복제되지 않는다.
• 체이닝 복제는 불가하다. 1번 버킷에서 2번 버킷으로 2번 버킷에서 3번 버킷으로 복제한다고 해서 1번에서 3번 버킷으로 복제되지는 않는다.

Amazon S3 Storage Classes

Amazon S3에서 객체를 생성할 때 클래스를 선택할 수도 있고 스토리지 클래스를 수동으로 수정할 수도 있다. 또한 스토리지 클래스 간에 객체를 자동으로 이동할 수도 있다. 클래스의 종류는 다음과 같다.

• Amazon S3 Standard - Genarel Purpost
• Amazon S3 Standard-Infrequent Access(IA)
• Amazon S3 One Zone-Infrequent Access
• Amazon S3 Glacier Instant Retrieval
• Amazon S3 Glacier Flexible Retrieval
• Amazon S3 Glacier Deep Archive
• Amazon S3 Intelligent Tiering

내구성(Durability)과 가용성(Availability)

• 내구성(Durability) : 객체가 손실되는 횟수로 Amazon S3는 매우 뛰어난 내구성을 제공한다. 99.99999999999의 내구성을 보장하며 평균적으로 천만개의 객체를 저장했을 때 10,000년에 한 번 객체 손실이 예상된다.
• 가용성(Availability) : 서비스가 얼마나 용이하게 제공되는지를 나타내며 스토리지 클래스에 따라 다르다. 예를 들어 S3 Standard의 가용성은 99.99%로 1년에 53분동안은 서비스를 사용할 수 없다는 의미를 가진다. 따라서 애플리케이션 개발시 이러한 부분을 고려하여야 한다.

Amazon S3 Standard - General Purpose

• 99.99%의 가용성
• 자주 액세스하는 데이터에 사용되며 기본적으로 사용되는 스토리지 유형
• 지연 시간이 짧고 처리량이 높다.
• AWS에서 두 개의 기능 장애를 동시에 버틸 수 있다.
• 빅 데이터 분석, 모바일과 게임 애플리케이션 그리고 콘텐츠 배포에 사용된다.

Amazon S3 Storage Classes - Infrequent Access (IA)

• 자주 액세스 하지는 않지만 필요한 경우 빠르게 액세스해야하는 데이터에 사용된다.
• S3 Standard보다 비용이 적게 들지만 검색 비용이 발생한다.

Amazon S3 Standard-IA

• 가용성은 99.9%로 S3 Standard 보다 약간 떨어진다.
• 사용 사례로는 재해복구와 백업으로 사용된다.

Amazon S3 One Zone-IA

• 단일 AZ 내에서는 높은 내구성을 갖지만 AZ가 파괴된 경우 데이터를 잃게 된다.
• 가용성은 99.5%로 더 낮은 가용성을 가진다.
• 사용 사례로는 온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장한 용도로 쓰인다.

Amazon S3 Glacier Storage Classes

• Glacier 이라는 이름처럼 콜드 스토리지로 아카이빙과 백업을 위한 저비용 객체 스토리지이다.
• 비용으로 스토리지 비용과 검색 비용이 들어간다.

Amazon S3 Glacier Instant Retrieval

• 밀리 초 단위로 검색이 가능하다. 분기에 한 번 액세스하는 데이터와 같은 경우 적합하다.
• 최소 보관 기간이 90일이기 떄문에 백업이지만 밀리초 이내에 액세스해야하는 경우 적합하다.

Amazon S3 Glacier Flexible Retrieval

• Amazon S3 Glacier Flexible Retrieval에는 3가지 옵션이 있다.
  • Expedited : 데이터를 1~5분 이내에 받을 수 있다
  • Standard : 데이터를 돌려받는데 3~5시간이 소요된다.
  • Bulk : 무료지만 데이터를 돌려받는데 5~12시간이 소요된다.
• Flexible은 데이터를 검색하는데 최대 12시간까지 기다려야 한다는 의미로 보면된다.

Amazon S3 Glacier Deep Archive

• 장기 보관을 위한 스토리지 클래스로 두 가지 검색 티어가 있다.
• Standard는 데이터를 검색하는데 12시간이 걸리고 Bulk는 48시간이 걸린다.
• 오래 걸리지만 비용이 가장 저렴하다.
• 최소 보관 기간은 180일

Amazon S3 Intelligent-Tiering

• 사용 패턴에 따라 액세스된 티어간에 객체를 이동할 수 있게 해준다.
• 소액의 월별 모니터링 비용과 티어링 비용이 발생한다.
• 검색 비용이 없다.
• S3 Intelligent-Tiering은 객체를 알아서 이동시켜 주기 때문에 편하게 스토리지를 관리할 수 있다.
• FrequnetAccess 티어는 자동이고 기본 티어이다.
• Infrequent Access 티어는 30일 동안 액세스하지 않는 객체 전용 티어이다.
• Archive Instant Access 티어도 자동이지만 90일 동안 액세스하지 않는 전용 티어이다.
• Archive Access 티어는 선택 사항으로 90일에서 700일 이상까지 구성할 수 있다.
• Deep Archive Access 티어는 180일에서 700일 이상 액세스하지 않는 객체에 구성할 수 있다.
  

수명 주기 규칙(Lifecycle Rules)

스토리지 클래스 간 객체를 옮길 때, 예를들어 Standard에서 Standard-IA로 그리고 다시 Intelligent Tiering으로 이런 객체들을 수작업으로 옮길 수도 있지만 수명 주기 규칙(Lifecycle Rule)을 이용한다면 자동으로 쉽게 옮길 수 있다. 그러한 규칙들은 다음과 같다.

1. Transition Actions : 다른 스토리지 클래스로 이전하기 위해 객체를 설정한다.
   ex) 생성된 지 60일 후에 Standard 클래스로 이전한다고 설정하거나 6개월 후 Glacier로 이전해서 아카이브화 한다.
2. Expiration actions : 설정하여 일정한 시간 뒤에 만료시켜 객체를 삭제하도록 설정할 수 있다.
   ex) 액세스 로그 파일은 365일 후에 삭제할 수 있다. 또는 버저닝을 활성화했다면 Expiration actions를 사용해서 모든 파일 버전을 삭제할 수 있다. 또는 이걸 사용해서 멀티파트 업로드를 삭제할 수도 있다.
3. 특정한 접두어에 대해 지정 가능 - 버킷 전체 또는 버킷 안의 특정한 경로에 적용하거나 특정한 객체 태그에 대해 규칙을 지정할 수 있다.
   ex) 특정 부서 안에서 규칙을 적용하여 객체에 대한 규칙을 만들 수 있다.

Amazon S3 요청자 지불(Requester Pays)

일반적으로 버킷 소유자가 버킷과 관련된 모든 Amazon S3 스토리지 및 데이터 전송 비용을 지불한다. 요청자, 즉 사용자가 버킷으로부터 파일을 다운로드하는 네트워킹 비용 또한 버킷 및 객체 소유자에게 청구된다. 그러나 많은 대형 파일들이 있고 일부 고객이 이것을 다운로드 하기 위해서는 요청자 지불 버킷을 활성화 해야한다.
요청자 지불 버킷을 활성화 하면 버킷 소유자가 아닌 요청자가 객체 다운로드 비용을 지불한다. 소유자가 여전히 객체 스토리지 비용을 부담하겠지만 요청자의 객체 다운로드 요청에 대한 다운로드 네트워킹 비용은 요청자가 부담하게 된다. 대량의 데이터 셋을 다른 계정과 공유하려할 때 매우 유용하다. 그리고 이러한 방식을 사용하기 위해서는 요청자가 익명이여서는 안된다. AWS로 부터 인증을 받아야 객체를 다운로드한 요청자에게 비용을 청구할 수 있기 때문이다.

Amazon S3 이벤트 알림

Amazon S3에서 이벤트란 객체가 생성되었거나 삭제되었거나 복구되었거나 복제되는 등의 행위를 의미한다. 그리고 Amazon S3에서는 그러한 이벤트들을 필터링 할 수 있다. 예를 들면 jpg 확장자를 가지는 객체만 고려하고 싶다던가 하는 경우이다.

이벤트 알림의 활용 사례로는 Amazon S3에서 일어나는 특정 이벤트에 자동으로 반응하기 위해 사용한다. Amazon S3에 업로드 된 모든 이미지이 섬네일을 생성한다던가 이벤트 알림을 만들어 몇몇 대상 (SNS 토픽, SQS Queue, 람다 함수 등)에 전송할 수 있다. 그리고 원하는 만큼 S3 이벤트를 만들 수 있고 원하는 어떤 타겟에도 전송할 수 있다. 통상적으로 몇 초 안에 전달되지만 간혹 몇 분정도 걸릴 수 있다.

또한 이벤트 알림이 작동하려면 IAM 권한을 가지고 있어야한다. S3 서비스의 데이터를 SNS에 전송하기 위해서는 소위 SNS 리소스 정책을 첨부해야하고 SQS를 사용한다면 SQS 리소스 정책을 첨부해야한다. 그리고 람다 함수에 전달 하기위해서는 람다함수에 첨부하여 Amazon S3가 우리의 함수를 호출할 권한을 제공해야 한다.

Amazon S3의 모든 이벤트는 결국 Amazon EventBridge로 가게 된다. EventBridge에서 여러가지 규칙을 설정할 수 있고 규칙들로 인해 이벤트들을 18가지의 AWS 서비스에 전송할 수 있다. 이렇게 하여 Amazon S3의 이벤트 알림의 능력이 크게 향상된다.

Amazon S3 성능

기준 성능(Baseline Performance)

Amazon S3는 요청이 아주 많을 때 자동으로 확장된다. S3로부터 첫 번째 바이트를 수신하는데 100~200ms사이로 아주 짧다. 또한 접두사당 초당 3,500개의 PUT/COPY/POST/DELETE 그리고 초당 5,500개의 GET/HEAD 요청을 지원한다.

버킷 내에서 접두사 수에 제한이 없다. 접두사란 예를 들어 bucket/folder/sub/file 이라는 객체가 있을때 bucket과 file 사이가 접두사가 된다. 그러므로 이 접두사를 갖는 file은 초당 3,500개의 PUT 요청과 5,500개의 GET요청을 처리할 수 있다.

멀티파트 업로드

100MB가 넘는 파일은 멀티파트 업로드를 사용하는 것이 좋고 5GB가 넘는 파일은 반드시 사용해야 한다. 멀티파트는 업로드를 병렬화하여 전송 속도를 높여 대역폭을 최대화할 수 있다. 멀티파트 업로드는 큰 파일을 여러 파트로 나누어 작은 청크 단위로 업로드한다. Amazon S3에 모든 파트가 업로드되면 자동으로 하나의 큰 파일로 다시 합친다.

S3 전송 가속화

파일을 AWS 엣지 로케이션으로 전송해서 전송 속도를 높이고 데이터를 대상 리전에 있는 S3 버킷으로 전달한다. 엣지 로케이션은 AWS의 CDN들의 여러 서비스들을 가장 빠른 속도로 캐싱하기 위한 거점으로 리전보다 수가 많고 현재 엣지 로케이션은 그 수가 계속 증가하여 200개가 넘는다.

전송 가속화는 멀티파트 업로드와 같이 사용될 수 있다. 가장 가까운 엣지 로케이션으로 파일을 업로드하고 요청자와 가까운 엣지 로케이션으로 Amazon S3 버킷으로 빠른 프라이빗 AWS 네트워크를 통해 데이터를 전송한다. 즉, 퍼블릭 인터넷의 사용량을 최소화하고 프라이빗 AWS 네트워크의 사용량을 최대화하는 것이다.

S3 바이트 범위 가져오기

파일에서 특정 바이트 범위를 가져와서 GET 요청을 병렬화한다. 특정 바이트 범위를 가져오는 데 실패한 경우에도 더 작은 범위에서 재시도하므로 실패한 경우에도 복원력이 높다.
사용 사례로는 다운로드 속도를 높이거나 파일의 일부만 검색하기 위해서 사용된다. 파일의 앞 부분인 첫 번째 파트를 요청하고 두 번째 파트부터 N 번째 파트까지 요청하여 모든 파트 부분을 특정 바이트 범위 가져오기로 요청한다. 이 요청은 모두 병렬화 되고 GET 요청 병렬화를 통해 다운로드 속도를 높일 수 있다.

S3 Select & Glacier Select

S3에서 파일을 검색할 때 검색한 다음 필터링을 거치게 되면 너무 많은 데이터를 검색하게 된다. 그 대신 서버 측에서 필터링을 수행하는 경우 SQL을 이용해서 간단히 열과 행을 사용해 필터링 할 수 있다. 이 방법은 네트워크 전송이 줄어들기 때문에 데이터 검색과 필터링에 드는 클라이언트 측의 CPU 비용도 절감할 수 있다.

S3 Select를 사용하면 Amazon S3가 대신 파일을 필터링해 주고 필요한 데이터만 검색할 수 있다. Amazon S3 Select는 기존의 모든 데이터를 검색 후 애플리케이션 측에서 필요한 데이터를 필터링하여 찾는 방식보다 속도는 400% 빨라지고 비용은 80% 절감할 수 있게 되었다. 그러므로 간단한 필터링에는 S3 Select나 Glacier Select를 추천한다.

S3 Batch Operations

S3 Batch Operations는 단일 요청으로 기존 S3 객체에서 대량 작업을 수행하는 서비스로 사용 사례가 매우 많다. 사용사례는 다음과 같다.

• 한번에 많은 S3 객체의 메타데이터와 프로퍼티를 수정
• 배치 작업으로 S3 버킷 간에 객체를 복사
• S3 버킷 내 암호화되지 않은 모든 객체를 암호화
• ACL이나 태그를 수정
• S3 Glacier에서 한 번에 많은 객체를 복원
• Lambda 함수를 호출해 S3 Batch Operations의 모든 객체에서 사용자 작업을 수행

객체 목록에서 원하는 작업은 무엇이든지 수행할 수 있다. 작업은 객체의 목록, 수행할 작업 옵션 매개 변수로 구성된다. S3 Batch Operations를 사용하면 재시도를 관리할 수 있고 진행 상황을 추적하고 작업 완료 알림을 보내고 보고서 생성 등을 할 수 있다.

S3 Batch에 전달할 객체 목록 생성 과정

1. S3 Invertory 기능을 사용해 객체 목록을 가져온다.
2. 배치작업에 포함하려는 필터링된 객체 목록을 얻는다.
3. S3 Batch Opertions에 수행할 작업, 매개 변수와 함께 객체 목록을 전달한다.
4. S3 Batch 가 작업을 수행하고 객체를 처리한다.

S3 Storage Lens

S3 스토리지 렌즈는 전체 AWS 조직에서 스토리지를 이해하고, 분석하고, 최적화하는데 도움이 되는 서비스이다.

• S3 스토리지 렌즈를 통해 이상 징후를 발견하고, 비용 효율성을 파악하며, 전체 AWS 조직에 보호 모범 사례를 적용할 수 있다. (30일 사용량 및 활동 메트릭이 제공)
• 조직 수준에서 또는 특정 계정, 지역, 버킷 또는 접두사별로도 데이터를 집계할 수 있다.
• 나만의 대시보드를 만들거나 스토리지 렌즈 서비스에서 제공하는 기본 대시보드를 사용할 수 있다.
• 모든 메트릭과 모든 리포트를 CSV 또는 parquet 형식으로 S3 버킷으로 내보낼 수 있다.
• Storage Lens는 이 모든 데이터를 분석하여 도움이 되는 보고서로 집계한다.

기본 대시보드 (Default Dashboard)

스토리지 렌즈 서비스를 사용하면 기본 대시보드가 제공되는데 이 대시보드는 무료 및 고급 지표에 대한 요약된 인사이트와 트랜드를 확인할 수 있다. 또한 여러 지역과 여러 계정의 데이터가 표시되므로 필터를 설정하기 위해 여러 지역과 여러 계정의 데이터가 표시되므로 필터를 설정하기 위해 따로 작업을 할 필요가 없다.

기본 대시보드는 Amazon S3에 의해 사전 구성되고 삭제할 수 없지만 원하는 경우 비활성화할 수 있다.

지표 (Metrics)

Summary Metrics

• S3 스토리지에 대한 일반적인 인사이트를 제공
• 스토리지 바이트는 스토리지 및 객체의 크기를 파악하는데 사용
• 가장 빠르게 성장하거나 사용하지 않는 버킷과 접두사를 식별하는데 유용

Cost-Optimization Metrics

• 스토리지 비용을 관리하고 최적화할 수 있는 인사이트를 제공
• 현재 버전이 아닌 버전에 대한 정보를 제공
• 스토리지 바이트는 최신이 아닌 버전 객체의 수, 실제로 차지하는 공간 또는 불완전한 멀티파트 업로드 스토리지 바이트 수를 의미
• 어떤 버킷이 다중 파트 업로드에 실패했는지 또는 어떤 객체를 더 저렴한 스토리지 클래스로 전환할 수 있는지 확인

Data-Protection Metrics

• 데이터 보호 기능에 대한 인사이트를 제공
• VersioningEnabledBucketCount를 통해 모든 버킷이 버전 관리 등을 통해 활성화되었는지 확인
• MFADeleteEnabledBucketCount, SSCKMSEnabledBucketCount, CrossRegionReplicationRuleCount 등이 있다.
• 데이터 보호 모범 사례를 따르지 않는 버킷을 식별하기 위해 사용

Access-management Metrics

• S3 버킷 소유권에 대한 인사이트를 제공
• 버킷이 현재 어떤 객체 소유권 설정을 사용하고 있는지 식별

Event Metrics

• S3 이벤트 알림에 대한 인사이트를 얻고 S3 이벤트 알림이 구성된 버킷의 수를 파악 가능

Performance Metrics

• S3 전송 가속에 대한 인사이트를 얻고 S3 전송 가속이 활성화된 버킷의 수를 파악 가능

Activiry Metrics

• AllRequests, GetRequests, PutRequests, ListRequests, BytesRequests 등이 이에 해당

Detailed Status Code Metrics

• HTTP 상태 코드에 대한 인사이트를 제공
• 2000OKStatus Count, 403ForbiddenErrorCount 등으로 버킷의 사용 유형을 파악

비용

스토리지 렌즈에는 무료 지표과 유료 지표가 있다. 무료 지표는 모든 고객에게 자동으로 제공되며 약 28개의 사용량 지표가 포함되어 있으며 쿼리에 대한 데이터는 14일 동안 조회할 수 있는 반면 고급 지표 및 권장 사항의 경우 활동, 고급 비용 최적화, 고급 데이터 보호 및 상태코드와 같은 추가 유료 지표 및 기능을 사용할 수 있다.
또한 이러한 지표는 CloudWatch에 퍼블리시되어 추가 비용 없이 액세스할 수 있다. 그런 다음 S3 버킷내의 접두사 수준에서 지표를 수집할 수 있다.
마지막으로 결제 시 데이터는 15개월동안 사용할 수 있다.

S3 객체 암호화

서버 측 암호화(SSE:Server-Side Encryption)

Server-Side Encryption with Amazon S3-Managed Keys(SSE-SE)

• SSE-S3는 Amazon S3에서 관리하는 키를 이용한 서버측 암호화로 버킷과 객체에 대해 기본값으로써 활성화되어 있다.
• 사용자는 키에 절대 액세스할 수 없다.
• 암호화의 보안 유형은 AES-256으로 Amazon S3가 SSE-S3 매커니즘을 사용하기 위해 헤더를 "x-amz-server-side-encryption":"AES256"이라고 설정해야 한다.

Server-Side Encryption with KMS Keys stored in AWS KMS(SSE-KMS)

• SSE-KMS는 AWS와 S3 서비스가 보유한 키에 의존하지 않고 KMS(Key Management Service)를 이용해서 자신의 키를 직접 관리한다.
• KMS는 사용자가 키를 직접 생성하고 관리할 수 있다는 장점이 있다.
• CloudTrail을 이용해서 키 사용을 검사할 수 있다. 누군가가 KMS에서 키를 사용할 때 마다 CloudTrail에 로깅된다.
• "x-amz-server-side-encryption":"aws:kms" 라는 헤더가 반드시 있어야 객체가 서버 측에서 암호화가 된다.
• SSE-KMS는 제한사항이 있는데 Amazon S3로 업로드하고 다운로드하기 때문에 KMS 키를 직접적으로 사용해야하는데 자체 API를 사용해서 복호화를 해야한다. 그래서 API 호출 건은 모두 KMS의 초당 API 호출 쿼터에 합산된다. 때문에 S3 버킷의 처리량이 매우 많고 모두 KMS 키로 암호화되어 있다면 스로틀링 활용 사례가 될 수 있다(?).

Server-Side Encryption with Customer-Provided Keys(SSE-C)

• 고객이 제공한 키를 사용하여 키를 관리한다.
• Amazon S3는 제공된 암호화 키를 절대 저자하지 않는다. 사용한 후에 폐기한다.
• 키를 Amazon S3로 전송하기 때문에 반드시 HTTPS를 사용해야하고 모든 요청에 HTTP 헤더의 일부로서 키를 전달해야 한다.

클라이언트 측 암호화(Client-Side Encryption)

• 클라이언트 측 암호화 라이브러리 등을 활용하여 더 쉽게 구현할 수 있다.
• 클라이언트가 직접 데이터를 암호화한 다음에 Amazon S3로 전송한다.
• Amazon S3 외부의 클라이언트에서 이루어지고 클라이언트가 키와 암호화 사이클을 완전하게 관리하는 것이다.

전송 중 암호화 (SSL/TLS)

• Amazon S3 버킷에는 기본적으로 2개의 엔드포인트가 있다. 암호화 되지 않는 HTTP 엔드포인트와 전송 중 암호화가 제공되는 HTTPS 엔드포인트가 있다.
• Amazon S3를 사용할 때는 물론 데이터 송신 보안을 위해 HTTPS를 사용하도록 권고하고 있다.
• 모든 클라이언트는 기본 값으로 HTTPS 엔드포인트를 사용한다.
• 암호화를 강제하기 위해 버킷 정책을 첨부하여 HTTP를 사용하려는 사용자는 차단하고 HTTPS를 사용하는 사용자는 허용될 수 있다.

기본값 암호화 VS 버킷 정책

기본값으로써 모든 버킷은 SSE-S3 암호화가 적용되어 있다. 버킷에 저장된 새로운 객체에 SSE-S3 암호화가 자동으로 적용되지만 사용자는 SSE-KMS 같은 다른 암호화를 기본 암호화로 변경할 수 있다. 그렇지만 버킷 정책을 이용해서 암호화를 강제하고 올바른 암호화 헤더가 없는 경우에는 S3 객체 API 호출을 거절할 수 있다. 이 말의 핵심은 버킷 정책으로도 버킷 안의 암호화를 강제할 수 있다는 의미이다.

그리고 버킷 정책은 항상 기본값 암호화 설정 이전에 평가된다. 버킷 정책은 암호화 기본값 적용 이전에 선제적으로 적용되기 때문에 암호화를 강제할 수 있다.

S3 CORS

CORS(Cross-Origin Resource Sharing)?

CORS는 교차 오리진 리소스 공유(Cross-Origin Resource Sharing)의 약자로 오리진은 체계(프로토콜)와 호스트(도메인) 그리고 포트로 구성된다.

예를 들면 https://www.example.com 이라는 도메인이 있다면 포트는 HTTPS를 사용중이므로 443이고
도메인은 www.example.com이다. CORS는 웹 브라우저 기반 보안 메커니즘으로 메인 오리진을 방문하는 동안 다른 오리진에 대한 요청을 허용하거나 거부한다. 오리진이 같다는 것은 체계, 호스트, 포트가 동일할 때 오리진이 같다고 한다.

같은 오리진 : http://example.com/app1 과 http://example.com/app2
다른 오리진 : http://www.example.com 과 http://other.example.com

웹 브라우저가 다른 웹사이트에 요청을 보내야할 때 다른 오리진이 CORS 헤더를 사용해서 요청을 허용하지 않는한 해당 요청은 이행되지 않는다. 이를 액세스 제어 허용 오리진 헤더 라고 한다.

Amazon S3에서의 CORS

클라이언트가 S3 버킷에서 교차 오리진 요청을 하면 정확한 CORS 헤더를 활성화해야 한다.
이 작업을 수행하려면 특정 오리진을 허용하거나 *를 붙여 모든 오리진을 허용한다. S3 버킷이 정확한 CORS 헤더를 갖도록 구성되지 않았다면 요청을 거부한다.