AWS S3

S3의 용도

백업 및 스토리지, 재해복구, 아카이브, 하이브리드 클라우드 스토리지 ( 온프레미스 + 아마존 ),애플리케이션 호스팅

미디어 호스팅, 데이터 저장 ( 빅데이터 용 ),  정적 웹사이트 호스팅, 소프트웨어 딜리버리, 등

 

S3는 파일을 버켓에 저장한다. 버킷은 상위 레벨 디렉토리로 표시된다. 버켓은 반드시 유니크한 이름을 가지고 있어야한다. 모든 리전사이에서 AWS에서 단 하나), 버킷은 글로벌 서비스처럼 보이지만 반드시 한 리전에 만들어져야한다.

 

S3 Object

오브젝트나 파일에는 키라는 것이 있다. 키는 파일의 풀 경로를 의미한다.

예를들어 s3://my-bucket/myfile.txt 가 있다면 ( 버킷은 my-bucket ) myfile.txt의 키는 myfile.txt이다.

이런경우에는 s3://my-bucket/folder1/folder2/myfile.txt  myfile.txt의 키는 folder1/folder2/myfile.txt이다.

버킷의 이름을 뺀 경로라고 생각하면 된다. 키에서 파일명을 제외한 것을 prefix라고 하고 파일명을 object name이라 한다.

S3에서 디렉토리같은 컨셉은 없다 실제로 그렇게 보이기는 하지만

 

S3에 파일을 업로드 할 수 있는데 한 파일당 최대 5TB이고, 5gb를 넘으면 멀티 파트 업로드라고 해서 분해해서 올려야한다.

버전관리 또한 할 수 있다. 

 

파일을 하나 업로드 하면 S3 URL이 나오는데 이걸 주소창에 치면 브라우저에서 확인할 수 있다.

근데 퍼블릭 액세스를 허용하지 않으면 일반 URL에서는 확인이 안된다. 권한 없다고 뜸

왜그럴까? aws 사이트에서 S3 url을 클릭하면 내가 현재 누르고 있다는 프리사인이 뒤에 붙기에 접속을 가능하게 하지만

일반 url은 aws사이트에서 누른것이 아니라 접근이 불가능한것이다.

 

S3보안정책

사용자 기반에 대해 알아보자.

user-based

사용자에게는 Iam정책이 주어지는데 이를 바탕으로 허가해줌

 

resource-based

bucket policy
이건 s3콘솔에서 직접 할당 할 수 있다.

특정 사용자가 들어올 수 있게 하거나 다른 계정의 사용자를 허용할 수 있다.

object ACL

이건 세밀한 보안이며 비활성화할 수 있다.

bucket ACL

object ACL보다 훨씬더 일반적임 비활성화 가능

 

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

IAM유저로 어떻게 접근할 수 있을까?

IAM권한이 그걸 허용하던지 아니면 resource policy가 그걸 허용하던지 할 것이다. 

 

s3 bucket policy는

JSON형태로 되어있다. 

resource라는 키값에는 해당 버킷이 어떤 버켓과 오브젝트에 적용될 것인지 정할 수 있다.

affect 허용, 거부 를 적을 수 있다.

action에는 떤 작업을 허용 할지를 적는다. GetObject라는 작업이 있다면 이건 오브젝트를 확인할 수 있는 행위이다.

principal은 폴리시가 적용될 account나 user를 적는다.

*을 적으면 모두에게 적용되는뜻

 

우리가 직접 작성할 수도 있지만 IAM처럼 미리 만들어 져있는 것도 있다., 이걸 bucket policy라고 한다. 이걸 사용해서 버킷에 대한 공개 액세스를 허용할 수 있다.

 

하나의 버켓이 있고 그 버켓에 모두에게 공개하는 버킷폴리시가 붙어있다면 유저는 인터넷에서 그 오브젝트를 볼 수 있다.

유저를 특정지을 수도 있다 예를 들어 iam유저에게 iam policy를 부여하여 s3 버켓에 접근할 수 있도록 해줄 수 있다. 

 

이번엔 인스턴스에서 s3 버켓에 접근할 수 있도록 해주려면 ec2에 iam role을 부여하여 접속할 수 있는 권한을 줄 수도 있다. 

 

다른 계정(iam 말고 account)에서 들어올 수 있도록 하려면 교차 계정 액세스) 버킷 정책을 사용해야한다. 그렇게 해주면

다른 계정의 iam유저는 s3 bucket에 접속할 수있게 된다.  (api등을통해)

 

버킷을 생성할 때 bucket settings for block public access라는 것을 본 적이 있을 수 있는데

만약 버킷 정책을 공개로 하여 모든 사람이 볼 수 있도록 설정해놓았다 하더라도 이 것이 체크되어있으면 결코 공개되지 않을 것이다.

 

S3 Static Website Hosting

s3는 웹사이트를 호스팅하고 인터넷에서 액세스할 수 있도록 함

html과 이미지를 넣고 버킷을 외부에서 접속할 수 있도록 해주면된다.

 버켓을 생성하고 properties로 가면 아래에 static website hosting이 있다. 그걸 편집을 누르고

enabled로 바꾸면 여러 설정을 선택할 수 있다. 거기서 인덱스 문서를 지정해주고 그 파일을 올리면 그게 기본화면이 된다.

이 파일에 접속하여 html을 보고 싶다면 공개적으로 읽을 수 있도록 퍼블릭 설정을 꼭 해주어야 한다. 

그렇게 해주면 엔드포인트 주소가 생기고 그걸 주소창에 입력하면 html을 확인할 수가 있다. 

 

S3버전관리

s3는 파일을 버전관리할 수 있다., 버킷수준에서 활성화해야하고. 사용자가 파일을 업로드 할 때마다 선택키에서 해당 파일의 버전이 생성이 될 것이다. 버전관리를 활성화하기 전에 버전 관리가 적용되지 않은 모든 파일은 널 버전을 가질 것이고, 널 버전 관리를 중단해도 이전 버전을 삭제하지 않을 것이다. 

 

이걸 하기 위해서 프로퍼티로 접속을 한다. 그럼 아래쪽에 버킷 버전 관리 설정이 있다.  그걸 편집 하고 enable을 클릭한다.

이후 파일을 덮어쓰게 되면 이 것이 버킷의 버전으로 추가된다.

 

만약 웹사이트를 업데이트 하고 싶다면 기존에 만들었던 index.html파일을 좀 수정하고 다시 업로드한다.

갱신한 내용이 업데이트 될 것이다. 파일이 덮어씌워진 것을 확인할 수 있다. 여기서 기존의 것이 사라진 것은 아닐까 할 수 있는데

show version토글을 누르면 각 파일의 버전id가 나온다. 기존에 있던 파일들 즉 덮어 씌워지지 않은 파일들은 version ID가 null이라고 적혀있고, 방금 덮어쓴 것은 버전id에 괴상한 문자열이 들어가 있는 것을 확인할 수 있을 것이다. 이 버전을 이용해서 롤백을 할 수 있다 아까 수정했던 것을 되돌려보자. 특정한 버전id를 클릭해서 지우면 된다. 

 

기존에 있던 파일을 지운 뒤 show version을 눌러보면 지운 것 또한 버전 아이디가 부여되어있다. 따라서 show version을 다시 돌리면 안보이지만 삭제 된 것처럼 삭제 마크가 붙어있기 때문에 실제로는 삭제되어지지 않은 것이다. 다시 복원하고 싶다면 삭제마크만 지워면 된다.

 

S3복제 

CRR cross region replication, 

SRR same region replication

이렇게 두가지 종류가 있다. 

서로 다른 계정간에도 사용할 수 있다. 

다른 레전간의 버킷을 복사하려고한다. 비동기 복사를 한다고 하자. 가장 먼저 소스 커킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화 되어야한다. 복제 기능이 정상적으로 실행되려면 S3에 올바른 IAM권한 즉 읽기 쓰기 권한을 부여해야한다.

 

서울리전에만 버킷을 하나 올려두고 사용하였는데 미국에서 파일을 받는데 시간이 오래걸린다고 하면

서울리전에 있는 버킷을 복사하여 미국 리전에 두면된다. 그럼 파일을 서울리전에 올리고 똑같은 파일을 미국리전에 올려야 하는데

그럼 번거로워질 것이다. 이 때 복제규칙을 사용하면 서울에만 파일을 올려도 알아서 복제된 s3에도 복사가 된다고한다.

 

먼저 2개의 버킷을 만들자

두개다 버전활성화를 enable해줘야 한다. 그리고 첫번째 버킷을 원본이라고 생각하고 거기에 파일을 업로드 해보자

버킷을 복제하기 전에 복제 규칙을 생성해보자

management로 들어가서 replication rules를 생성한다. 

choose a rule scope에서

apply to all objects in the bucket을 고른다. 버킷 내 모든 객체에 적용 되도록 설정하는 것이다.

destination은 복제할 버킷인데, 이 계정의 버킷이나, 다른 계정의 버킷으로 지정할 수 있다. 버킷의 이름을 적어주자.

IAM역할에서는 옵션 중 새로운 역할 생성이라는 걸 선택하자. 그럼 기존 객체를 복제하겠냐고 묻는 팝업이 뜬다.

복제를 하면 새롭게 업로드 하는 파일만 복제가 된다. 하지만 기존의 파일까지 복사하고 싶다면 예스를 선택하자.

이건 S3배치 작업을 처리실행한다고한다. 이건 복제기능과는 다른 기능이다.  새로운 파일을 원본에서 업로드 하면 복제본에서도 생성이 되는데 버전을 보면 같은 버전을 공유하고 있다. 

 

management에서 복제규칙을 선택하고 규칙편집으로 들어간 뒤 제일 아래에

삭제마커복제라는 옵션이있다. 기본적으로 삭제 마커는 복제되지 않는데 이를 설정하는 기능이 있다. 이걸 활성화하고

원본에서 파일을 지우면 삭제 마커가 생성이 될테고 버전으로써) 그리고 복제 버킷을 확인해보면 해당 파일 역시 삭제 마커가 복제된 것을 확인할 수 있다.

 

S3 storage classes

S3 Standard-general purpose

S3 Standard-Infrequent Access (IA)

S3 One Zone-Infrequent Access

S3 Glacier Instant Retrieval

S3 Glacier Flexible Retrieval

S3 Glacier Deep Archive

S3 Intelligent Tiering

 

S3 Standard-general purpose

99.99 가용성을 가지고 있고,

자주 액세스 하는 데이터에 사용된다. 

기본적으로 사용하는 스토리지유형이다. 

지연시간이 짧고 처리량이 높다. 

두개의 기능 장애를 동시에 버틸 수 있다.

빅 데이터 분석, 모바일 게임 애플리케이션 콘텐츠 배포등에 쓰인다.

 

S3 Standard-Infrequent Access (IA)

접근 횟수는 적지만 접근 시의 지연스간은 낮게 유지하고자 할 때 사용

필요한 경우 빠르게 액세스 하는 데이터이다.

비용이 좀 적게들지만 검색비용이 발생한다.

가용성은 99.9퍼센트이다.

재해 복구와 백업등에 쓰인다. 

 

S3 One Zone-Infrequent Access

하나의 존에만 객체를 생성되는 객체이다. 객체의 손실 가능성이 존재

단일 AZ내에서는 높은 내구성을 갖지만 AZ가 파괴된 경우에는 데이터를 잃게된다.

가용성은 더 낮은 수준인 99,5%이다/

온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장하는데 쓰임

 

 

S3 Glacier Instant Retrieval

콜드 스토리지이고 아카이빙과 백업을 위한 저비용 객체 스토리지이다.

비용에는 스토리지 비용과 검색 비용이 들어간다. 

밀리초 단위로 검색이 가능하다. 

분기에 한번 액세스 하는 데이터에 아주 적합하다. 

최소 보관 기간이 90일이기 때문에 백업이지만 밀리초 이내에 액세시 해야하는경우 적합

 

 

S3 Glacier Flexible Retrieval

3가지 옵션이 존재

Expedited는 데이터를 1~5분 이내에 받을 수 있고 

standard는 데이터를 돌려받는데 3~5시간이 들고

Bulk는 데이터를 돌려받는데 5~12시간이 든다. 

최소 보관 기간은 90일이다. 

 

 

 

S3 Glacier Deep Archive

여기에는 2가지 검색 티어가 있다.

12시간인 Standard와, 48시간인 Bulk가 있다. 

데이터를 검색하는데 오래걸리는데 비용이 가장 저렴하다 최소 보관기간도 180일 이다.

 

 

S3 Intelligent Tiering

데이터에 대한 접근 패턴을 알지 못할 때 사용한다.

사용패턴에 따라액세스된 티어간에 객체를 이동할 수 있도록 해줌

소액의 월별 모니터링 비용과 티어링 비용이 발생한다. 

검색비용이 없다.