[aws] S3 버킷

 

 

이 글의 일부는 aws 공식문서의 내용을 참조하였음을 밝힙니다.

 

 

 

📌 AWS 스토리지 서비스와 S3

 

AWS의 스토리지 서비스는 세 개의 카테고리로 나눌 수 있다.

• 객체 스토리지 - 여기서 객체란 문서, 이미지, 비디오 등 비교적 단순한 구조에 메타데이터를 포함하고 있는 데이터 조각을 의미하며, 인터넷으로 연결된 API를 통해 데이터를 애플리케이션에 제공한다. 
• 블록 스토리지 - 블록 스토리지에서 데이터란 서버 인스턴스에 디스크 볼륨 형태로 제공되는 데이터를 의미하며, 이를 통해 EC2 인스턴스에 포함된 볼륨에 고속으로 접근할 수 있다. 블록 저장의 대포적 서비스는 EBS 가 있다.
• 파일 스토리지 - 파일 스토리지에서 데이터란 서버 인스턴스에 파일 시스템 인터페이스 또는 파일 시스템 시멘티스 방식으로 제공되는 데이터를 의미하며 서버 인스턴스에 파일 스토리지를 추가하면 로컬 파일 시스템처럼 작동한다. 대표적으로 EFS가 있다. 

 

S3는 객체 스토리지 서비스로 전 세계 어디에서나 대규모 데이터를 저장하고 인출할 수 있는 인터페이스를 제공한다. S3의 저장공간은 무제한이며 , 99.99%에 이르는 고신뢰성을 제공한다. 이는 연평균 0.00000000001% 객체 데이터가 손실된 확률 수준을 의미한다. S3 버킷안에 파일은 객체라고 칭하며 버킷은 계정 안에 생성된다. 버킷에는 전역적으로 고유한 이름이 있어야 하는데 모든 리전을 통틀어서 딱 하나 뿐이어야 한다. 하나 중요하게 알아야 될 것은 S3는 전역 서비스처럼 보이지만 사실상 리전에서 생성된다 . 

 

객체에는 키라는 것이 있는데 이 키는 파일의 전체 경로를 의미한다. 이미지에서 파란색으로 표기 되어 있는 것들이 여기서 객체의 키이다. 

 

 

키는 접두사와 객체의 이름으로 구성되어있는데 노란색으로 표기 되어 있는 것이 접두사 그리고 초록색으로 표기 되어 있는 것이 객체의 이름이다.S3 그 자체로는 디렉토리의 개념이 없지만 콘솔을 통해 UI를 보게 되면 디렉토리 생성이 있다. 하지만 이것은 사실 키의 접두사이다.

 

 

 

최대 객체 크기는 5TB 이고, 5GB 보다 큰 파일을 업로드 해야할 시 멀티파트 업로드를 사용해서 해당 파일을 여러 부분으로 나눠 업로드해야한다. 만약 5TB의 파일을 가지고 있다면 최소 1000개 부분으로 나눠서 업로드해야된다는 말과 같다. 

 

 

 

📌 S3 - 접근성 통제 및 접근 정책

 

접근성 통제란 S3 버킷에 누가, 어떻게 접근하도록 할것인지 정의하는 것이다. S3 버킷에 접근하는 방법에는 여러 가지가 있으며, 다양한 방법 모두를 적절한 방식으로 통제하는데 의미를 두어야 한다. 접근성 통제를 통해 S3에 저장된 객체를 세분화해 통제하기 위한 접근 정책, 버킷 정책, 접근 제어 목록 등 세 가지 주요 방식을 알아보자.

 

접근 정책

 

IAM, 즉 신분 및 접근 관리 정책으로 S3의 객체를 매우 세분화 해 통제할 수 있다. 먼저 유저, 그룹, 롤 등 IAM 정책을 정의한다. 예를 들어, S3 풀 액세스 정책을 생성하고 유저에게 할당하면 버킷에 대한 풀액세스를 주면 S3 버킷에 대한 풀 액세스 권한에 접근할 수 있다. 

 

버킷 정책  

 

버킷 정책이란 버킷 레벨에서 생성한 정책을 의미하며, S3 버킷을 세분화된 방식으로 제어할 수 있게 해준다.  IAM 없이 버킷 정책만으로도 맥락에 따른 사용자 접근 제한이 가능하며, 심지어 다른 AWS 계정 또는 IAM 유저에게 특정 객체 또는 폴더 속 데이터에 대한 접근 권한을 부여할 수 도 있다. 

 

접근 제어 목록

 

접근 제어 목록은 각각의 버킷과 그 속에 포함된 객체는 ACL과 연동 되므로 ACL을 통해 S3의 버킷 레벨 또는 객체 레벨에서 접근을 제어할 수 있다.  IAM 정책과 버킷 정책이 세분화된 제어가 가능 했지만 접근 제어 목록 방식은 넒은 범위의 제어에 초점을 맞추고 있으며, 단지 접근 승인을 한 곳과 접근 승인을 받은 곳으로만 나타낼 수 있다. 

 

 

 

📌 S3 - 버저닝

 

S3 에서는 파일을 버전 관리 할 수 있다. 이것은 버킷 수준해서 활성해야하는 설정이며 사용자가 파일을 업로드 할 때마다 선택 키에서 해당 파일의 버전이 생성된다. 즉, 동일한 키를 업로드하고 해당 파일을 덮어쓰는 경우  버전2, 버전3 등을 생성하게 된다. 이 방법은 객체 삭제와도 유서가 깊은데 s3에서 어떤 객체를 삭제하면 그 객체는 실질적으로 삭제 되는 것이 아니라 삭제 마커를 추가하게 되고 그 다음 버전을 보여주게 된다. 따라서 삭제되었더라도 삭제된게 아니기 때문에 이전 버전으로 쉽게 롤백이 가능하며 영구 삭제를 원한다면 영구 삭제를 해야한다.

 

 

 

 

📌 S3 - 복제

 

S3의 복제 기능에는 두 가지 종류가 있다. 교차 리전 복제인 CRR과 같은 리전 복제인 SRR이다. 이 복제는 비동기 복제이며, 소스 버킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화되어야한다. 복제 기능이 정상적으로 실행되려면 S3에 올바른 IAM 권한, 즉 읽기, 쓰기 권한을 S3에 부여해야 한다. 복제를 활성화한 후에는 새로운 객체만 복제 대상이 되며 기존의 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다. 이 기능은 기존 객체부터 복제에 실패한 객체까지 복제할 수 있는 기능으로 작업을 삭제하려면 소스 버킷에서 대상 버킷으로 삭제 마커를 복제하면 된다. 이 절에서 헷갈리지 말아야 할 부분은 버킷을 복제한다고 해서 독립적인 버킷이 생성됨이 아니라 소스 버킷과 동기화되는 버킷이 복제된다는 것이다. 아까 비동기 복제라고 설명한 부분에 대해서는 기존까지 소스 버킷에 객체들이 복제 버킷에 복제 되지 않는 다는 점에서 비동기 복제라고 하지만 복제가 된 후에는 실시간으로 동기화 되는 복제 버킷이 된다는 것을 알아두자. 

 

 

 

 

 

 

 

 

📌 S3 - 스토리지 클래스

 

Amazon S3는 다양한 상황에 대응할 수 있도록 다양한 스토리지 클래스를 제공한다. 기업의 활용 방식 및 비즈니스 니즈에 따라 적합한 스토리지 클래스를 선택할 수 있으며 상황 변화에 따라 하나의 스토리지 클래스에서 또 다른 클래스로 데이터를 이동 시킬 수 있다. 객체를 생성할 때 클래스를 생성할 수 도 있고 데이터 라이프 사이클 정책을 사용하면 자동으로 하나의 스토리지 클래스에서 다른 클래스로 파일을 이동시킬 수 있다. 

 

S3 스토리지 클래스는 다음과 같다. 

 

• S3 Standard - AWS의 기본형 스토리지로 빈번하게 접근하는 데이터를 위한 고신뢰성, 고가용성, 고성능을 제공한다. 가장 많은 사용자가 선택하는 클래스이며 웹사이트, 컨텐츠 스토리지 , 빅데이터 분석, 모바일 어플리케이션등 다양한 용도로 사용된다.
• S3 Standard IA - IA는 Infrequent Access의 약자로 다른 클래스에 상대적으로 접근 빈도가 낮은 데이터를 위한 스토리지 클래스이다. 접근 빈도가 낮은 만큼 Standard에 비해 비용이 저렴하고 장기 저장, 백업, 재해 복구 등의 목적으로 활용된다.
• S3 One Zone IA - 평소에는 낮은 빈도로 접근하지만, 때에 따라서 매우 신속하게 접근할 수 있는 스토리지 클래스이다. 세 개의 AZ에 저장되는 Standard와 달리 단일 AZ에만 저장되지만 Standard 나 StandardIA와 동일한 수준의 고신뢰성, 고가용성,고속 전송성을 제공하면서도 Standard IA 보다 20% 저렴하다. 
• S3 Glacier - Glacier는 데이터 아카이브, 즉 데이터 장기 보관을 목적으로 활용된다. 비용에는 스토리지 비용과 인출 비용이 들어가며 Glacier 스토리지에는 또 세 가지 클래스로 분리된다.
  • S3 Glacier Instant Retrieval - 밀리초 단위로 인출이 가능하며 분기에 한 번 액세스 하는 데이터에 아주 적합하다. 이는 최소 보관 기간이 90일 이기 때문에 백업이지만 밀리초 이내에 액세스 하는 경우에 적합하다. 
  • S3 Glacier Flexible Retrieval - 기존 Glacier이라고 하였지만 티어가 추가가 되면서 이름이 바뀌었다. 데이터를 인출할 때는 촉진, 표준, 벌크 등 소요기간과 비용이 다른 세 가지 옵션 중 하나를 선택할 수 있다. 촉진 옵션은 1~5분, 표준은 3~5시간, 벌크는 페타바이트급 데이터를 하루 정도의 시간 내에 인출 받을 수 있다.
  • S3 Glacier Deep Archive - 장기 아카이브 스토리지로 모든 데이터를 7년 또는 10년간 보관해야 하는 경우 유용한 선택안이된다. Deep Archive는 3개의 서로 다른 AZ에 데이터를 저장하므로 고내구성을 제공하며 여기에 보관된 데이터는 Standard 인경우 12시간, Bulk 인 경우 48 시간의 데이터 인출 시간이 소요된다. 최소 보관 기간은 180일이지만 비용이 가장 저렴하다.

 

 

 

 

• S3 Intelligent Tiering -  Intelligent Tiering 은 위 스토리지 클래스 계층과 다르게 독자적인 스토리지 클래스 계층을 이룬다. Intelligent Tiering 은 사용 패턴에 따라 자동으로 기본 티어의 스토리지(Frequent Access tier)에서 낮은 티어의 스토리지로 점차 이동시켜 비용을 최적화한다. 예를 들어 특정 객체에 30일 이상 접근하지 않는 경우 자동으로 해당 객체를 한 단계 낮은 티어로 이동시키고 파일을 다시 이용하게 되면 상위 티어로 이동시킨다. 이 기능은 소액의 월별 모니터링 비용과 티어링 비용이 발생하지만 데이터 인출 비용이 없으며 티어는 다음과 같다. 
  • Frequent Access tier - 자동 및 기본 티어
  • Infrequent Access tier - 30일동안 액세스 하지 않는 티어
  • Archvie Instant Access tier - 90일동안 액세스 하지 않는 티어
  • Archive Access tier - 90일에서 700일 이상 까지 액세스 하지 않는 티어
  • Deep Archive Access tier - 180일에서 700일 이상 까지 액세스 하지 않는 티어

 

📌 S3 객체 암호화

 

s3에서 데이터를 암호화하는 방법은 크게 두 가지가 있다. 하나는 전송 중인 데이터를 암호화하는 것이고, 다른 하나는 저장된 데이터를 암호화하는 것이다. 전송 중인 데이터의 암호화란 데이터가 한 지점에서 다른 지점으로 이동할 때 암호화되고, 저장된 데이터의 암호화란 데이터 또는 객체가 버킷에 저장돼 대기상태 일 때의 암호화를 의미한다. 서버 측 암호화 SSE에 대해서 먼저 알아보자.

 

 

• S3 키 매니지먼트 기반의 SSE(SSE-SE) - S3가 저장된 데이터를 암호화하고 암호화 키 또한 관리하는 방식 으로 각각의 객체는 객체별 키를 통해 암호화 된다. 객체별 키는 마스터 키로 암호화되며 S3 키 매니지먼트를 통해 해당 마스터 키를 관리한다.

 

 

 

• S3 KMS 기반의 SSE(SSE-KMS) - KMS는 S3 서비스가 보유한 키에 의존하지 않고 AWS의 키 매니지먼트 전문 서비스인 KMS를 이용한다. 즉 키 관리 서비스를 이용해서 직접 자신의 키를 관리하며  KMS를 사용할 경우에는 사용자가 키를 통제할 수 있다는 장점이 있다. 즉 KMS에서 직접 키를 생성하고 S3에 저장된 객체에 대한 비승인 접근을 효과적으로 통제할 수 있는 추가 보안 레이어를 제공한다. KMS의 기능을 이용하면 누가,언제, 어떤 데이터에 접근했는지 확인하거나 암호화 된 데이터를 승인 없이 접근하려는 시도가 있었는지 여부 또한 상세히 파악할 수 있다.

 

 

 

• 고객 자체 생성 키 기반의 SSE(SSE-C) - 고객이 자체 생성한 커스텀 암호화 키로 데이터를 암호화하는 방식으로 자체 생성한 커스텀 키를 업로드하면 S3는 해당 키로 데이터를 암호화한다. 암호화된 데이터를 인출할 때도 커스텀 키를 제공하면 S3 해당 키로 데이터를 복호호한 뒤 인출하는데 이 때 S3는 커스텀키를 저장하지 않으며 사용된 키는 즉시 삭제한다. 

 

 

 

• 클라이언트 측 암호화 - 클라이언트가 직접 데이터를 암호화한 다음 S3에 전송한다는 개념으로 데이터의 복호화도 외부의 클라이언트 측에서 이루어진다. 이 암호화는 클라이언트가 키와 암호화 사이클을 완전하게 관리할 수 있다.

 

 

 

• 전송중 암호화(SSL/TLS) - S3에는 기본적으로 HTTP 와 HTTPS 엔드 포인트 두 가지를 제공하는데 버킷 정책을 첨부하고 있다. 이 둘의 차이는 여기에서 설명하지 않겠다. HTTPS 엔드포인트로 데이터를 보내는 것을 전송 중 암호화라 하며 이를 강제하려면 버킷 정책에서  aws:SecureTransport : true로 설정함으로써  전송중 암호화를 강제할 수 있다.