[SAA] S3

S3

• 무한대로 확장 가능한 스토리지
• 다양한 서비스에서 사용 가능
• DB, 캐시 백업에도 사용
• 장애 회복에도 사용
• 정적 웹사이트 호스팅
• 미디어 처리
• 데이터 분석
• 소프트웨어 배포에도 사용

버킷

• 디렉토리 형태로 object(파일) 관리
• 모든 리전과 어카운트 내에서 유일한 이름을 가져야 함
• 리전 단위로 생성 가능
• 네이밍 컨벤션 존재
  • 대문자, _ 사용 불가
  • [3,63]자 이내로 생성
  • IP 형식 안됨
  • 숫자 또는 영어 소문자로 시작해야 함
  • xn--으로 시작하면 안됨
  • -s3alias로 끝나면 안됨 (별칭 생성 시 자동으로 생성되는 값임)

객체 (Object)

• 각 오브젝트는 키를 갖고 있다.
• 키는 접근할 수 있는 path
• 키 = prefix / 오브젝트 이름 (ex. kangwlgns/image.png)
• 그러나 디렉토리는 아님. 사람이 보기 편하게 만든 것
• 디렉토리 단위로 권한 처리나 사용자 할당 등이 불가능함.
• 개별 객체의 최대 크기는 5TB
• 5GB 이상 업로드하는 경우, multi-part 업로드를 사용해야 함
• 메타데이터는 키-값 형식으로 사용자 혹은 시스템 메타데이터를 저장
• 태그는 키-값 형식으로 라이프 사이클 관리 혹은 보안용도로 사용
• 버저닝 사용 가능 (파일 변경 시마다 자동으로 버전 id 부여)

내구성과 가용성

• 내구성
  • 손실되는 정도 
  • 멀티 AZ간 오브젝트 내구성 매우 높음 (99.99999999999%)
  • 천만개의 오브젝트를 저장한다고 가정하면, 1만년에 1개정도 손실됨
  • 모든 스토리지 클래스가 동일한 내구성을 가짐
• 가용성
  • 서비스가 얼마나 쉽게 가용 가능한지
  • 스토리지 클래스마다 다름
  • Standard의 경우 99.99%의 가용성
  • 1년 중에 53분 정도는 접근이 안 될 수도 있겠다.

---

버저닝

• s3 오브젝트에 대해 버전 처리 가능
• 버킷 단위로 기능을 끄고 킬 수 있다.
• 실수로 삭제하는 경우 방지
• 롤백이 쉬움
• 버저닝을 처음 적용하면 이전 오브젝트의 버전은 null

복제

• 버저닝이 켜졌을 때만 사용 가능
• CRR(Cross Region Replication), SRR(Same Region Replication) 모두 지원
  
  • CRR은 컴플라이언스, 리전 확장으로 낮은 지연율을 지향, 리전이 다른 계정간 복사를 위해 사용함
  • SRR은 로그 통합, 테스트 환경에서도 상용 리소스를 사용을 위해 사용함.
• aws 계정 간 복사 가능
• 비동기 식으로 복사 발생
• 복제를 위한 적절한 iam 권한이 필요
• 신규 오브젝트부터 복제됨
• 기존의 오브젝트와 복제에 실패한 오브젝트들은 S3 batch replication을 사용해서 복사해야 함.
• 삭제 마커를 남겨서 복제 가능하지만, 버전 id로 삭제하면 복사되지 않음
• 버킷간 복제 체인 불가 A->B, B->C가 활성화 돼있다고 해서 A를 갱신하면 C가 바뀌진 않음

---

스토리지 클래스

• Standard
  • 99.99% 가용성
  • 자주 접근하는 데이터에 용이
  • 낮은 지연시간, 많은 요청
  • 2개의 동시성 장애 방지 장비 유지
  • 빅데이터, 일반 앱, 컨텐츠 분할, 로그 수집 등에 사용
• Standard IA(Infrequent Access)
  • 자주 접근하진 않지만, 필요한 경우 빠르게 접근
  • 비용이 저렴
  • 99.9% 가용성
  • 백업, 장애 복구 용도로 사용
• One Zone IA
  • 특정 AZ 한정으로 높은 내구성 (99.99999999999%)
  • AZ에 문제가 생기면 손실됨
  • 99.5% 가용성
  • One zone만 사용하므로 가용성이 상대적으로 떨어짐
• Glacier
  • 아카이빙 또는 백업 용도로 사용
  • 가격정책: 저장비용(싸다) + 오브젝트 조회 비용(비싸다)
  • Instant Retrieval
    • 가져오는 데 밀리초 단위
    • 분기에 한번 접근하는 경우에 유용
    • 최소 90일의 보관 기간
  • Flexible Retriever
    • 조회 시간에 따라 Expedited(1-5분), Standard(3-5시간), Bulk(5-12시간)로 구분
    • 최소 90일의 보관기간
    • Bulk의 경우 조회 비용이 무료
  • Deep Archive
    • 조회 시간에 따라 Standard(12시간), Bulk(48시간)로 구분
    • 최소 180일의 보관기간
    • 장기 보관 용도
• Intelligent Tiering
  • 월간 모니터링 비용과 자동 티어링 비용이 다소 있음
  • 사용량에 따라 자동 티어링
  • 데이터 조회비용은 따로 없음
  • 자동 티어링 비용이 존재하지만, 운영 초기에 라이프 사이클 룰이 지정되지 않았다면 사용하는 것을 권장
  • Frequent - 기본
  • Infrequent - 30일간 조회되지 않은 경우
  • Archive Instant - 90일간 조회되지 않은 경우
  • Archive Access - 사용자가 [90,700]일 사이로 지정, 지정하지 않으면 넘어가지 않음
  • Deep Archive - 사용자가 [180,700]일 사이로 지정, 지정하지 않으면 넘어가지 않음

스토리지 클래스 변경

• 오브젝트를 스토리지 클래스 변경이 가능
• 자주 쓰면 Standard, 자주 쓰지 않으면 IA 등.. 용도에 맞게 적절히 변경 가능
• Life Cycle Rule을 사용하면 자동화해서 관리 가능

Life Cycle Rule

• 전송 액션
  • 오브젝트를 다른 스토리지 클래스로 전송하도록 지정
  • ex. 생성 이후 60일이 지나면 IA로 이동
• 만료 액션
  • 특정 시점이 지나면 오브젝트를 삭제
  • 버저닝 사용 시, 오래된 버전을 삭제
  • 완료되지 않은 multi-part(큰 용량의 파일을 여러번 걸쳐서 보내는 경우) 업로드 파일 삭제
  • ex. log 파일 1년 뒤 삭제
• 스토리지 클래스 분석
  • 언제 적절한 클래스로 오브젝트를 이전할지 도와줌
  • 스탠다드, 스탠다드IA 중 적절하게 추천
  • 일간 단위로 리포트 업데이트
  • 결과 확인은 1~2일 정도 걸림
  • Lifecycle을 초기에 적용할 때 괜찮음.
  • 거버넌스를 잡을 때 좋음

---

비용

• 버킷 관리자가 비용 지불
• 요청자 지불 버킷을 사용하면 요청자가 데이터 다운로드 비용 지불 (타 계정과 협업 시 유용)
• 요청자도 AWS를 통한 인증이 되어야 함.

---

이벤트 알림

• 오브젝트에 액션이 발생하면 이벤트 발행 가능
• S3:ObjectCreated, ObjectRemoved, ObjectRestore, Replication 등의 액션에 적용 가능
• 오브젝트 이름 필터로 개별 관리 가능
• 이미지 후처리작업이 필요한 경우 등에 사용 가능 (이 경우는 시스템에 이벤트를 발행하는 것)
• 이벤트 숫자에는 제한이 없음. (그냥 Pub/Sub 구조)
• 람다, SQS, SNS 등의 서비스로 이벤트 핸들링 가능
• 대부분 1초 이내에 이벤트가 전달, 가끔은 좀 걸림

이벤트 브릿지

• 이벤트 브릿지 서비스를 통해 연결 가능
• JSON 정책을 기반으로 더 심화된 필터 적용 가능
• 다양한 목적지로 이벤트 전달 가능
• 비동기적 이벤트 전달
• 이벤트 아카이빙, 재시도, 전달 확인 등의 기능 지원

---

성능

• S3는 부하가 많아지면 자동으로 스케일링(지연율을 100ms~200ms로 유지)
• prefix 초당 처리량 기준 PUT,COPY,POST,DELETE는 3500개 이상의 요청
• GET,HEAD는 5500개 이상의 요청
• prefix 수의 제한 없음
• prefix 별로 분산해서 요청하면 병렬로 처리 가능 (ex. 서로 다른 두 prefix 호출 시 GET 요청 날리면 11000개를 불러올 수 있음)

Multi-Part upload - Upload

• 100MB 이상 파일에 추천
• 5GB 이상이면 필수
• 병렬 처리로 전송 속도 상승

S3 Transfer Acceleration - Upload

• 장거리 파일 전송을 가속화
• AWS Edge location으로 파일을 전송하고, Edge location이 대상 리전의 S3로 전송하는 방식
• ex. 미국에서 edge location으로 파일 전송, AWS 내부망(빠름)을 통해 edge location to S3
• 멀티 파트 업로드와 호환 가능

S3 Byte-Range Fetches - Get

• 병렬로 GET 요청
• 바이트 단위를 지정해서 해당 단위로 분산해서 데이터 요청
• 다운로드 실패에 견고함. (fali에 대해 부분별로 재시도가 가능)
• 다운로드 속도 증가
• 특정 부분만 가져올 수 있다. (첫 1500바이트만 가져와서 확인한다든가..)

S3 Select & Glacier Select - Get

• 서버 사이드 필터링을 사용해서 SQL을 기반으로 적은 양의 데이터 가져옴
• 기존 서비스가 S3에서 냅다 가져와서 다른 서비스에서 조작하는 거였으면, 얘는 S3에서 미리 필터링해서 적은 양을 보내는 것
• 정형 데이터 파일을 가져올 때 SQL 구문으로 가져올 수 있다.
• 빠르고 저렴하다.
• 단순한 SQL 구문으로 열과 행을 필터링 가능
• 네트워크 전송량을 줄이고, 클라이언트의 CPU 비용 감소

S3 Inventory - Get

• S3 Inventory는 List 요청 X
• S3 API로 불러오는 GET 요청은 초당 5500건 정도, 배치 처리에는 부족할 수 있음
• 그래서 GET, LIST 등 API 요청이 아닌 별도의 탐색 서비스
• 그러므로 배치 작업이 터져도 상용 작업(API)는 멀쩡함.

S3 Batch Operation - Update

• 올려놓은 S3 오브젝트에 대한 일괄 처리를 한번의 요청으로 처리
  • 암복호화
  • 메타데이터나 속성 일괄 변경
  • ACL 혹은 태그 수정
  • Glacier에 있는 오브젝트 일괄 복구
  • 개별 오브젝트에 대한 람다 함수 호출해서 조작(이미지 리사이즈해서 다시 저장한다거나)
  • 등등
• 오브젝트 리스트, 수행작업, 추가적인 매개변수를 전달해서 사용
• 재시도, 작업 수행 트래킹, 완료 알림 전송, 결과 레포트 생성 등의 작업을 진행
• S3 select, S3 Inventory와 연동 가능
• 클라이언트가 Batch작업 요청하면, S3 Inventory가 S3 Select에 목록 전달, Select가 필터링해서 다시 Batch로 전달, Batch Operation이 오브젝트에 대한 변경 작업 수행

---

보안

• 사용자 기반
  • IAM 정책을 사용하여 특정 IAM 사용자를 허용
  • 명시적인 DENY는 없어야 한다. (당연)
• 리소스 기반
  • 버킷 정책: s3 콘솔에서 설정한 버킷 단위의 룰
  • Object ACL: 객체 단위 ACL 구성
  • Bucket ACL: 버킷 단위 ACL 구성

버킷 정책

• JSON 형태
  • Resource: 대상 버킷 혹은 오브젝트
  • Effect: allow or deny
  • Action: 수행할 수 있는 작업 (get, pu 등등)
  • Principal: 계정 혹은 사용자 지정
• 버킷을 외부 공개용으로 구성할 때 사용
• 업로드 시점에 암호화 강제 가능
• 다른 aws 계정에서 올리도록 할 수 있음

ACL

암호화

• SSE-S3
  • 기본 설정
  • S3 오브젝트 암호화에 사용하는 키를 AWS가 소유, 관리, 핸들링
  • 완전 관리
  • AES-256 암호화
  • 헤더에 "x-amz-server-side-encryption" : "AES256" 추가해야 함.
• SSE-KMS
  
  • AWS Key Management System(AWS KMS)을 사용해서 키 관리
  • KMS를 사용해서 사용자가 키를 컨트롤 가능
  • 키에 대한 변경, 사용은 CloudTrail에서 추적 가능
  • KMS 제한에 영향을 받을 수 있다.
  • 업로드 및 다운로드 시점에 KMS API를 쓰기 때문에 KMS 초당 요청 제한에 걸릴 수 있음.
  • 헤더에 "x-amz-server-side-encryption" : "aws:kms" 추가해야 함.
  • 더 많은 요청이 필요하다면 Service Quotas Console을 통해 요청할 것.
• SSE-C
  • 사용자가 제공한 키를 이용한 암호화
  • 완전 자유
  • S3가 키를 저장하지 않음
  • HTTPS 통신 강제 (키 탈취 방지)
  • 암호화 키가 반드시 헤더에 포함되어야 하고, 모든 API 요청에 대해 포함해야 함.
• Client Side Encryption (CSE)
  • 클라이언트 라이브러리 사용 (ex. Amazon S3 Client-Side Encryption Library)
  • 클라이언트는 반드시 S3 업로드 전에 데이터 암호화
  • 마찬가지로 반드시 데이터를 가져온 뒤 복호화해야 함.
  • 사용자가 모든 암호화 과정을 관리 (매우 특수한 상황)
• SSL/TLS
  • 전송간 암호화
  • S3는 HTTP / HTTPS 엔드포인트 제공하지만, SSL/TLS는 HTTPS만 지원
  • SSE-C는 반드시 HTTPS, 그 외에는 HTTPS 권장
  • Bucket Policy를 통해 HTTPS 강제 가능 ("aws:SecureTransport": true)

Bucket Policy

• 실제 S3로 요청이 가기 전에 만나는 장벽
• Bucket Policy를 통해 SSE-KMS, SSE-C와 같은 암호화를 사용할 수 있다. (필수 헤더 없으면 deny)

CORS

• 서로 다른 두 Origin에서 resource를 공유하는 것
• Origin: scheme + 호스트(도메인) + 포트로 구분
• 웹 브라우저 기반 기술
• 다른 오리진으로 향하는 요청을 허용할지 말지 결정
• 타 사이트에서 내 정보를 빼가지 못하도록 함.
• Access-Control-Allow-Origin으로 허용할 origin을 지정 (ex. https://www.example.com)
• Access-Control-Allow-Method로 허용할 method를 지정 (ex. POST, GET)
• MaxAgeSeconds로 브라우저가 인증을 캐시할 수 있는 시간을 지정할 수 있음.
• preflight request(OPTIONS)를 통해서 헤더를 전달한 후에, 헤더를 확인하고 허락된 origin과 method인지 확인하는 절차(CORS)를 거친다.

MFA

• 사용자가 S3에서 중요한 동작을 할 때 별도의 애플리케이션 또는 디바이스를 통해 한번 더 인증 하도록 함.
• 오브젝트의 버전 삭제, 버킷 버저닝 중지 등 사용 상의 지장을 주는 행동들에 MFA를 적용할 수 있음.
• 버저닝을 동작시키는 등의 동작은 지장을 주지 않으므로 인증 불필요
• 버저닝이 적용됐을 때만 사용할 수 있다.
• 버킷 소유자만 MFA 설정을 건드릴 수 있다.

Access Logs

• S3 버킷에 대한 활동을 로깅
• 모든 AWS 계정, 인증되거나 인증되지 않은 모든 요청들이 다른 로깅용 버킷에 저장됨
• 로깅용 버킷도 동일 리전에 있어야 함.
• 절대절대절대 로그를 같은 버킷에 넣으면 안된다.
• 왜냐면 로그를 쌓는 작업에 대한 로그를 쌓는 무한 루프가 발생하기 때문에 비용이 엄청나게 됨.

Pre Signed URL

• 특정 시간이 지나면 만료되는 url 생성 가능
• pre-signed url은 S3 콘솔, CLI, SDK에서 사용 가능
• 콘솔에서 만들면 [1,720]분 동안 유효
• CLI를 통해 생성하면 168시간까지 설정 가능
• 생성할 때 만들어진 GET / PUT에 대한 권한을 최종 사용자가 가질 수 있음.
• 로그인한 사용자에게만 다운로드 URL 제공할 때, 일시적으로 권한을 부여하는 경우 등등 사용 가능
• 항상 public으로 여는 경우는 없기 때문에 유용하게 쓸 수 있다. (웹페이지 assets 제외)

Glacier Vault Lock

• Vault Lock Policy를 생성해서 적용 가능
• 한번 작성되면 삭제 및 변경 불가
• 컴플라이언스, 데이터 불변성 보장되어야 할 때 사용
• Write Once Read Many(WORM) 모델

Object Lock

• 오브젝트 버저닝이 활성화 되어 있어야 함.
• 오브젝트의 버전 삭제를 특정 기간동안 방지
• 마찬가지로 WORM 모델
• 설정한 Retention 기간 동안 오브젝트를 lock할 수 있다. (연장 가능)
• legal hold 기능을 사용하면 retention과 별도로 오브젝트를 무기한 보호
• Retention Mode - 컴플라이언스
  • 모든 계정에 대해 오브젝트 버전 덮어쓰기 및 삭제 불가
  • 모드 변경 불가, 기간 조정 불가
• Retention Mode - 거버넌스
  • 권한이 있는 일부 사용자만 설정을 변경하거나 오브젝트 삭제 가능

Access Point

• S3 버킷에 대한 보안 관리
• DNS에 맞게 접근하는 사람을 제한하는 기능
• 개별 DNS 이름을 갖는다
• 버킷 정책과 비슷한 access point policy를 갖는다.
• 하나의 버킷에 여러개 생성 가능
• VPC origin
  • VPC 내부에서만 Access Point에 접근 가능
  • VPC Endpoint를 반드시 생성해야 함
  • Endpoint 정책에 대상 버킷의 Access Point에 접근 가능하도록 해야 한다.
• Internet origin
  • 인터넷에서도 Access Point에 접근 가능한 듯.
  • AWS 리소스에서 이쪽으로 접근하면 보안, 성능, 비용 측면에서 손해일 듯.

Object lambda Access Point

• point에 접근하면 애플리케이션이 오브젝트를 읽어오기 전에 lambda가 먼저 오브젝트를 변경
• 하나의 버킷에 여러개 생성할 수 있음.
• 원본은 수정하기 싫은데 전처리가 필요한 경우 사용하면 된다.

---

안정성과 비용, 속도를 위해 S3에 대한 이해를 바탕으로 각 서비스를 다룰 수 있도록 한다.