Amazon Simple Storage Service(S3)는 일반 사용자, 애플리케이션, 그리고 많은 AWS 서비스를 위한 데이터 저장소이며 다음 용도로 널리 사용이 된다.
EC2의 OS 볼륨이 블록 스토리지인 반면 S3는 좀 더 다양한 용도로 활용할 수 있는 무제한 용량의 객체 스토리지 이다.
S3에 파일을 저장하면 2KB 용량의 메타데이터도 함께 저장된다. S3 메타데이터는 데이터 퍼미션, 버킷 내 파일 시스템에서의 위치 정보를 키 형식으로 제공한다.
블록 스토리지
-> 파일시스템을 위해 물리적 저장 장치를 블록 단위로 나눠둔 것
파일 시스템
-> OS 작동에 필요한 데이터를 읽어드리기 위해 관련된 것을 젖아하는 공간을 분할 및 할당하는 역할)
객체 스토리지
-> 우리가 가전 어떠한 형식의 데이터라도 저장할 수 있는 공간으로 권한을 부여받은 누구나 접속해서 어떤 포맷의 데이터도 저장을 할 수 있다.
S3 파일은 버킷에 저장한다. 기본적으로 우리의 계정에는 최대 100개의 버킷을 생성할 수 있으며,추가적으로 필요하다면 AWS측에 요청을 해야한다.
S3 버킷 및 그 속에 저장된 콘텐츠는 단일 AWS 리전에만 존재할 수 있으며, 버킷의 이름은 전세계 S3 시스템을 기준으로 유일한 것이여야 한다는 특징이있다.
버킷의 이름에는 나름의 명명 규칙이 있다. 사용자들은 대부분 운영 효율 및 법규 등의 준수를 위해 특정 지역의 리전을 선호하는 반면, 버킷 이름에 특정 리전에 구체적으로 드러나는 것을 원치 않는 경우가 많다.
버킷 = bucktname, 파일 = filename
url : s3.amazonaws.com/bucketname/filename
aws cli : s3://bucketname/filename
S3는 버킷 내에 별도의 하위 폴더 계층 구조 없이 객체를 저장하지만, 사용자는 좀 더 체계적으로 저장 객체를 관리하기 위해 버킷에 접두사 또는 구분문자를 추가해서 사용할 수 있다.
접두사는 스토리지 구조 레벨을 표기하기 위한 텍스트 문자열로 구분문자 / 다음에 단어를 사용하는 식으로 사용한다. 예를들어 contranct/acme.pdf 그리고 contract/dynamic.pdf 이런 식으로 사용하면 그룹화를 할 수 있고 S3 버킷 내에서도 이와 같은 폴더 구조를 인식해 해당 계층 구조에 따라 파일을 업로드 할 수 있으며, 슬래시 기호는 자동으로 폴더를 나타내는 구문자로 변화한다.
이론적으로는 버킷에 저장할 수 있는 데이터의 총용량에는 제한이 없지만 객체 하나의 용량은 5TB를 초과할 수 없으며, 한 번의 업로드 작업은 5GB를 초과할 수 없다.
이와같은 용량 제한 문제를 피하는 방법으로 100MB초과 객체의 경우 멀티파트 업로드 기능을 사용할 것을 권장한다.
멀티파트 업로드란 말그대로 S3에 하나의 대용량 파일을 업로드할 떄 여러 개의 부분으로 분리해 업로드하는 기능이며, 여러 부분 중 일부가 업로드에 실패하더라도 반복적으로 업로드 작업을 수행한다는 특징이 있다.
AWS는 세심한 설정이 필요한 S3 업로드를 위해 저수준 API 제공하고, 좀 더 자동화 수준이 높은 S3 업로드 작업을 위한 고수준 API도 제공을 한다.
대용량 파일을 전송하는 경우 Amazon s3 transfer acceleration 환경설정을 통해서 전송 속도를 높혀줄 수 있다.
웹사이트와 같이 외부에 공개하는 정보가 아닌 이상 S3에 저장되는 데이터는 기본적으로 암호화를 할 필요가 있다.
S3에 데이터를 저장할 때는 암호화 키를 이용 할 수 잇고, Amazon의 암호화된 API 엔드포인트를 이용해 S3에서 다른 서비스 또는 리소스로 전송되는 데이터를 암호화 할 수 있다.
대기 상태의 데이터는 서버측 암호화 및 클라이언트측 암호화 기법으로 보호할 수 있다.
S3의 각종 이벤트를 추적해 로그 파일에 기록으로 남기는 것은 기본적으로 불능으로 설정돼 있다. 이는 S3 버킷의 작업이 워낙 많이 이뤄지기 때문에 S3에서 생성되는 로그 데이터를 일일이 기록하는 것이 그리 효율적이지 않기 때문이다.
S3 로그 기능을 활성화 하려면 소스버킷(작업 내용을 추적하는 버킷)과 타겟 버킷(로그 파일을 저장하는 버킷)을 설정해야 한다. 또한 생성일 및 시간을 나타내는 접두사 및 분리기호를 지정해 다수의 소스 버킷에서 생성되는 다양한 로그 기록을 좀더 찾기 쉽게 만든 뒤 타겟 서버에 저장할 수 있다.
S3의 로그의 포함 내역
- 요청자의 계정 및 IP 주소
- 소스 버킷 이름
- 요청 작업 내역
- 요청을 한 시간
- 요청에 대한 응답 상세
S3 버킷은 CloudWatch 및 CloudTrail등 다른 AWS 서비스의 로그 및 객체 저장(EBS 스냅샷등)을 위해서도 사용된다.
S3는를 선택할때는 내구성 (데이터가 유지되어야 하는지 여부에 따라), 가용성(신속하게 데이터를 인출할 수 있는지 여부에 따라),비용효율성(비용을 얼마나 절약할 수 있는지 여부에 따라)들중 원하는 가치에 따라서 클래스를 선택적으로 사용할 수 있다.
S3의 내구성은 99.999999999%에 달하며 이는 대부분의 S3클래스 및 Amazon Glacier에 해당한다.
지정된 객체에 대한 연간 평균 손실 가능성은 0.000000001%로 이는 10,000,000개의 객체를 저장했다면 10,000년마다 단 하나의 객체가 손실될 수 있는 확률을 의미한다.
즉 AWS 인프라가 실패하더라도 S3/Glacier플랫폼에 저장된 데이터의 손실 가능성은 사실상 0에 가깝다.
그럼에도 불구하고 중요한 데이터는 복수의 장소에 백업해서 보관하는것이 좋다.
S3가 이처럼 높은 내구성을 가질 수 있는것은 S3가 최소 세개의 AZ, 가용성지역에 자동으로 데이터를 복제해 놓기 때문에 가능하다.
S3 객체의 가용성(availability)은 연간 개체에 대한 지속적인 요청을 처리할 수 있는 능력을 퍼센트로 표시한 것이다.
Amazon S3 Standard 클래스는 연간 99.99%의 응답 가능성을 보증한다.
이는 연간 9시간 미만의 다운타임이 발생할 수 있다는 의미이며, 이 시간을 초과해서 발생하는 다운타임에 대해서는 서비스 크레딧을 적용할 수 있다.
S3는 다수의 지역에 데이터를 복제한다는 사실을 기억해야 한다. 이는 기존 객체를 업데이트 하면 시스템 전체에 이러한 사실이 전파될 때까지 약간의 시간 지연이 발생 할 수 있기 때문이다. 파일의 새버전을 업로드한 직후 구 버전 파일을 삭제하면, 특정 위치에서는 이러한 변경 사항이 미처 전파되지 못하는 상황이 발생할 수 있다.
이러한 문제를 예방하기 위해서 데이터는 종국적 일관성 표준에 따라 관리해야한다. 즉 데이터 상태 변경에 대한(1~2초) 시간 지연을 감안한 뒤관련 작업 수행의 방식을 설계해야 한다.
업데이트 및 삭제 작업은 종국적 일관성 기준이 적용되지만, 새 객체의 생성에 대해서는 이와 같은 문제가 발생할 가능성이 없으며, 새 객체 생성 또는 PUT과 같은 덮어쓰기 작업에는 쓰기 후 읽기 일관성 기준이 적용된다.
S3는 백업 아카이브로서 많이 사용이 된다. 백업을 하면서는 기존 아카이브 버전을 유지하는것도 중요하지만 비용과 공간관리를 위해서 구 버전을 사겢하거나 폐쇄하는 작업도 필요하며 S3는 이를 위해 버전 관리 및 생애주기 관리 기법을 제공한다.
동일한 이름으로 파일들을 저장하고 히스토리들에 접근이 가능한 방식으로,
객체의 구버전들을 모두 관리하는것 가능하지만 저장 공간이 지나치게 커지는 문제가 발생할 수 있다 이에 대한 해법으로 생애주기 관리가 있다.
버킷 레벨의 생애주기 규칙을 작성하면 지정 일수에 따라 자동으로 클래스가 변경되도록 설정할 수 있다.
예를들어서, 처음 30일은 S3 Standard클래스에 객체를 저장하고 다음 30일은 좀 더 저렴한 One Zone IA 클래스에 객체를 저장하는 생에주기 규칙을 작성할 수 있다.
접두사를 이용해서 버킷 내 일부 객체에 대해서만 생애주기 규칙을 적용하는 것도 가능하다.
본인의 S3가 아니면 다른 사용자가 마음대로 해당 버킷에 접근할 수 없다.
버킷의 데이터에 접근을 허용하기 위해서는 접근 제어 규칙(ACL)과 S3버킷 정책, IAM 정책을 통해 세분화된 접근 제어를 할 수 있다.
ACL 접근 제어 기법(오래전 방식)은 보다는 S3 버킷 정책과 IAM 정책으로 접근 제어하는것이 권장 된다.
프라이빗 객체에 대해 일시적으로 접근을 허용하고자 할 때는 프리사인 URL(presigned url) 을 생성해서 제공하면 된다. CLI를 통해서 프로그래밍 기법으로 생성하는 프리사인 URL은 일정 시간 동안만 유효하며, 시간이 경과하면 접속할 수 없게 된다.
S3 버킷은 정적 웹사이트를 위한 HTML 파일 호스팅에도 사용할 수 있다.
저렴하면서도 신뢰 할 수 있는 플랫폼인 S3는 정적 웹사이트 호스팅에 적합하며,
S3 버킷을 정적 웹사이트 호스팅용으로 설정하면, 트레픽은 자동으로 index.html 등 웹사이트의 루트 문서로 이동게 된다.
또한 DNS 가 필요한 경우 Route53으로 버킷의 엔드포인트를 추가할 수 있다. 단 도메인 네임은 S3의 버킷의 네임과 같아야한다.
또한 AWS Certificate Manager에서 사이트 암호화를 위한 SST/TLS 인증을 무료로 받을 수 있다.
Glacier는 다른 S3 스토리지 클래스와 비슷한 부분이 많으며 99.999999999%을 지니고 S3 수명주기 환경설정에 통합해서 사용할 수 있다.
S3와 다른 부분
- 저장 용량 40TB (s3는 제한없음)
- 아카이브 생성시 기본적으로 저장 데이터를 암호화(s3는 옵셔널임)
- 아카이브 이름음은 기계 생성 ID 형식
- 등등
가장 큰 차이점은 데이터 인출 시간 이다.
Glacier 아카이브에서 데이터를 인출하는데는 수 시간이 소요될 수 있지만 S3 버킷에서는 거의 즉각적으로 객체를 인출할 수 있다.
즉 Glacier는 저장된 데이터를 거의 인출하지 않는 저렴하게 사용할 수 있는 장기 보관용 스토리지 이다.
Glacier에서 아카이브는 문서,비디오,TAR,ZIP파일등 저장 객체를 가리키는 말이며 Glacier 볼트(S3의 버킷느낌 But 유일무이 이름 x) 에 저장 된다.
정기적으로 데이터를 보관을 해야한다면 다음과 같은 방식으로 정책을 가져갈 수 도 있다. 최초에 30일은 S3 Standard에 보관하고 다음은 S3 One Zone-IA로 옮겨서 90일간 보관하고 그 이후 Glacier로 옮겨서 2년간 보관한 뒤 삭제한다.