S3

• S3란
• S3스토리지 타입 / Object의 구성요소 / Data consistency Model / S3요금
• S3 암호화 / 접근권한 / CORS
• S3 실습

---

1. S3(Simple Storage Service)

• 안전하고 가변적인 object 저장공간
  • 안전 : 모든 파일에 일종의 안전장치를 걸어, 허락되지 않은 외부의 접근을 막음
  • 가변 : 저장된 파일들의 크기에 맞춰 저장공간의 크기가 자동으로 커졌다 줄어들었다 함
  • object : 이미지, 파일, 영상 등만 올릴 수 있는 것 > 운영체제를 업로드해서 사용이 불가능(즉 윈도우 파일등을 넣어 부팅 같은 것이 불가능)
• 편리한 UI : 어디서나 쉽게 데이터의 저장 및 로드가 가능
• 파일 크기는 최대 0~5TB까지 가능
• 저장공간 무제한 : 가변적인 S3의 특성상, 전체 파일의 크기가 아무리 늘어나도 다 받아들일 수 있음
• Bucket이라는 이름을 사용하며, 일종의 디렉토리 시스템과 유사함. 다만 각각의 Bucket은 고유해야 함

 

S3의 사용 용례

• 파일 저장소(이미지, 비디오, 압축파일 등 다양한 파일들)
• html, css, js같은 파일을 올려 파일을 업로드 한 후, s3 bucket을 도메인 dns로 사용가능

---

2. S3스토리지 타입 / Object의 구성요소 / Data consistency Model / S3요금

다양한 S3스토리지 타입

• 일반적인 S3
  • 가장 보편적으로 사용되는 스토리지 타입
  • 높은 내구성(데이터의 손실없이 얼마나 잘 복원되는지)과 가용성(데이터 접근의 용이성)
  • 적당한 가격
• S3-IA(infrequent Access)
  • 자주 접근되지는 않으나 접근시 빠른 접근이 요구되는 파일이 많을시 유용
  • 일반 S3에 비해 비용은 저렴 but 접근시 추가비용이 발생
  • 즉 가끔 접근하되 빠르게 대응하는 경우에 많이 사용
  • 멀티 AZ를 통한 데이터 저장
• S3-One Zone IA
  • 단일 AZ에 의존한 데이터 저장 > 데이터 접근에 어려움이 생길 수 있다(조금 낮은 가용성)
  • ex)하나의 AZ가 서버다운 등이 발생시 > 원래 스토리지는 사용이 불가 > 데이터 접근 자체가 불가
  • 이러한 단점으로 인해 S3-IA보다 비용이 20%정도 저렴하다
• Glacier
  • 매우 저렴한 저장비용 but 데이터 접근시 대략 4-5시간 소요(ㄹㅇ빙하느낌. 빙하에 오래보관하되, 빙하를 녹여야 쓸 수 있음)
  • 따라서 접근이나 사용이 거의 없으나 보관하기는 해야하는 데이터를 저장할 떄 많이 사용
• Intellgient Tiering
  • 데이터의 접근 주기가 불규칙할 때 매우 유용
  • 서버가 자체적으로 각 데이터를 데이터 접근 주기에 따라 분석한 후, 각 데이터를 frequet / infrequent 둘중 하나로 분류
    • ex)A데이터에 두달에 한번 접근할 때는 infrequent로 서버가 분류
    • 그러다 매주 한번씩 A데이터에 접근하기 시작하면 A데이터는 frequent로 분류됨
  • frequent한 데이터의 접근 및 저장 비용이 조금 더 비쌈
  • 그러나 자주 쓰지 않은 데이터들이 infrequent로 설정되어 가격이 절감되므로, 비용적인 측면에서는 가장 효율적인 스토리지

 

S3 Object (저장대상)의 구성요소

• key & value
  • object(저장대상)은 key & value 형태로 저장된다.
  • key는 파일명, value 파일의 내용
• Version ID
  • S3의 고유의 특징
  • 똑같은 파일이라도 다른 버전으로 올리고, 버전에 따른 복원도 가능함
• Metadata : 데이터의 데이터
  • 파일 업로드 시간, 업로드한 유저 등에 대한 정보가 있음
  • 당연히 수정도 가능
• CORS(Cross Origin Resource Sharing)
  • 한 버켓의 파일을 다른 버켓에서 접근가능하게 해줌

 

S3 Data Consistency Model

• Read after Write Consistency(PUT)
  • 우리는 파일을 rest api 처럼 put을 이용해 올림
  • 올려진 파일은 딜레이 없이 그 즉시 활용될 수 있다(바로 읽을 수 있다)
• Eventual Consistency(update,delete)
  • 이미 버킷에 올라간 파일을 변경(update)하거나 삭제(delete)할 경우, S3내부에서 그 즉시 반영되지 않는다
  • 물론 육안으로 보기에는 바로 반영된 것처럼 보일 수 있음. 다만 S3내부에서 실제로 파일의 변경내역이 반영되기까지는 시간이 좀 걸린다(즉 딜레이가 좀 발생한다)

 

S3요금

• GB당 지불(1gb 당 0.0023$)
• 얼마나 put, get, copy를 사용하는지
• 얼마나 데이터를 다운로드 하는지 / 다른 리소스로 전송하는지
• Metadata에 따라(Metadata에 추가적인 tag등이 달리면 비용이 더 요구됨)

---

3. S3 암호화 / 접근권한 / CORS

S3 암호화 종류

• 파일 업로드 / 다운로드시에 SSL/TLS 암호화가 발생
  • 유저의 개입은 필요없으며(신경쓸 필요가 없으며), AWS내부에서 알아서 진행해줌
  • SSL : 도메인 주소 맨 앞에 https가 붙는 것. 조금 더 안전해짐
  • TLS : SSL에서 파생된 기능으로 보안적으로 조금 더 강력함
• 가만히 있을 때 발생 : SEE-S3 / SSE-KMS / SSE-C
  • SEE-S3
    
    • S3는 S3버켓에 저장된 모든 obj들을 그들만의 고유한 키로 암호화하며, 암호화시에 마스터키를 사용한다.
    • SEE-S3는 이 마스터키를 일정시간마다 변경시킨다.(질문)
  • SSE-KMS
    • AWS에서 일괄적으로 관리
    • KMS 암호화키를 통해, 누가 언제 어떻게 암호를 풀었는지에 대한 기록이 남아있음 > 추적이 가능
  • SSE-C
    • 우리가 암호키를 직접 다룰 수 있음
    • 따라서 키값을 우리가 변경시켜줘야 함

 

S3 암호화 과정

• S3파일을 업로드할 시 Put요청이 발생함. 헤더를 살펴보면
  
  • x-amz-server-side-encrytion-parameter라는게 있음
  • 만약 우리가 파일을 put요청으로 s3에 업로드시에, 헤더에 이게 있으면 s3는 우리가 암호화요청을 건 것으로 간주하고 암호화를 걸어줌
  • x-amz-server-side-encrytion-parameter는 벨류값으로 알고리즘의 종류를 넣어주며, 넣은 알고리즘을 바탕으로 암호화가 실행됨
• 암호화가 걸리지 않은 파일을 버켓에 못올리게 하려면? >
  • 버켓 정책설정을 통해, 업로드 요청의 헤더에 x-amz-server-side-encrytion-parameter가 없으면 업로드가 불가능하게 함

 

S3 접근 권한

• S3를 최초 생성시, bucket생성자를 제외하면 bucket 및 bucket의 내용에 아무도 접근할 수 없음
• 이때, bucket정책을 변경시 bucket내의 모든 파일들에 대한 권한이 한번에 변경됨
  • ex) bucket정책을 public으로 바꾸면, 모든 파일에 접근이 가능해짐
• 접근 제어 리스트를 변경할 수도 있음
  • 파일 하나하나에 접근가능한 유저를 다르게 주는 것
  • ex)A파일에 user B,C만 접근할 수 있는 권한을 준다.

 

CORS

• s3버켓들에는 각각의 리전이 존재함
• 예를 들어 A버켓은 서울에 위치하고 B버켓은 virginia에 위치할 때, A버켓으로 웹사이트 호스팅을 돌리면서 B버켓에 해당 웹사이트에서 사용되는 데이터를 읽거나 저장함
• 원래라면 Bucket A에서 Bucket B에 접근시 region이 다르므로 에러가 발생하는 것이 맞음
• 이러한 에러를 잡아줘서, region이 다른 bucket끼리 원할하게 소통할 수 있도록 해주는 것이 CORS

---

4. S3 실습

 

S3 생성

• 일반구성
  • 버킷이름 : 내 AWS전체에서 고유한 이름 설정
• 객체소유권
  • S3에 올린 파일의 소유권을, 서버개설자에게 줄 것인지 or 파일을 업로드한 사람에게 줄 것인지
  • 이 부분은 명확하지 않은데, ACL을 활성화 시켜야 외부에서 접근이 가능한 것 같음
• 퍼블릭 엑세스 차단을 위한 버킷 설정
  • 모든 퍼블릭 엑세스 차단 : 만든 버킷에 대한 외부접근 자체가 불가(즉 다른 사람이 아무도 이걸 쓸 수 없음)
    • 이걸 선택하면, 어떤 파일도 외부에서 접근할 수 없고 & 사용자 입장에서도 각 파일들이 외부 공개되도록 설정을 진행할 수 없음
  • 일단은 테스트를 위해, 모든 체크란을 해제
• 버킷버전관리 : 그대로 둠
• 태그 : 그대로 둠
• 기본 암호화 : 그대로 둠
• 고급설정
  • 객체잠금 : 활성화될 경우, 한번 s3에 올라간 파일은 수정이나 덮어씌우는 것이 불가능. 즉 원본 파일을 온전히 보존할 때 사용
  • 비활성화 선택

 

파일 업로드

• S3선택
• 폴더생성 > 폴더 선택 > 업로드 > 파일 추가 > 파일 선택
• 권한 : 퍼블릭 엑세스 설정(ACL)에 관한 설정. 일단은 아무것도 안 건드림
• 속성 : 스토리지 클래스, 암호화 설정, 태그, 메타데이터 등에 관해 설정. 일단은 아무것도 안 건드림
  • 태그 같은 경우, 잘 사용하면 여러파일을 매우 효율적으로 관리할 수 있다.

 

파일 열기

1)파일클릭  > 우측상단에 열기. 이때는 어떤 경우든지 잘 열린다.

2)파일 클릭 > 객체 URL로 열어줄 수도 있다.

• S3 생성시 퍼블릭 엑세스 자체를 막은 경우,  다음과 같이 access-denied가 나올 수 있음 

• 이때 체크 해야할 부분이
  • 객체소유권 > ACL 활성화
  • 퍼블릭 엑세스 차단을 위한 버킷 설정 > 모든 체크 해제
  • 파일의 권한 변경 or 버킷 자체의 권한 변경(정책 변경)
  • 파일의 권한을 변경하려면, 해당 파일 클릭 > 권한 > ACL 편집 > 모든사람(퍼블릭 액세스)에 읽기를 체크해주면 됨

 

버킷 정책 변경

• 파일 하나하나의 권한을 변경해서, 다른 사람들이 접근할 수 있게 해줄 수 도 있으나 이건 너무 번거로움
• 버킷 정책을 바꿀 경우, 모든 파일에 대한 권한을 일괄적으로 변경시켜줄 수 있다.
• 버킷 > 권한 > 버킷정책 > 편집 > 정책 생성기
  • json파일로 직접 만들어줄 수도 있으나 너무 번거로움
  • 따라서 정책 생성기를 활용해 만드는 것을 추천

 

• Type of policy : S3 bucket policy
• Effect : Allow
• Principal
  • 우리가 만들 새로운 정책을 어떤 유저에게 적용시켜 줄 것인지에 관함
  • 유저나 그룹의 ARN을 넣어주면 된다.(IAM가서 사용자, 그룹을 누르면 각 사용자나 그룹의 ARN을 확인할 수 있음)
  • 참고) ARN = Amazon Resouce Name
• Actions
  • Get Bucket Policy 선택
• Amazon Resource Name(ARN)
  • S3 bucket의 ARN을 넣어주면 됨
  • 버킷 > 속성으로 들어가면 확인 가능
• 그러고 나서 add statement를 누르면 밑에 generate policy가 활성화됨. 이걸 누르면 json형태의 정책이 나옴
• 나온 json형태의 정책을 긁어다가 버킷 정책에 집어넣어주면 됨(넣어 주기 전에 뭔가 있는데, 그거 다 지우고 넣으면 됨)

 

 

추가) 보면서 s3실습내용 다시 정리 ( 장고 코드와 함꼐)

https://velog.io/@gogimon/Django-s3-boto3