[AWS] Developer Associate #6 S3

스토리지란

• 스토리지란 컴퓨터 시스템에서 명령어와 데이터를 저장하기 위해 사용하는 장치입니다.
• AWS는 데이터를 저장하는 방법으로 객체 스토리지(S3), 블록 스토리지(EBS), 파일 스토리지(EFS, Fsx)를 제공합니다.
• 객체 스토리지는 데이터를 객체(Object)라는 개별 단위로 저장하고 관리합니다. 문서, 이미지와 같은 실제 데이터와 객체에 대한 추가 정보인 메타 데이터로 구성됩니다. 객체 스토리지는 대용량 비정형 데이터에 가장 적합합니다.
• 블록 스토리지는 데이터를 고정된 크기의 블록으로 나누어 개별 단위로 저장하는 방식으로 작동합니다. 고속 데이터 처리, 짧은 레이턴시를 제공하며 데이터에 빠르게 액세스해야하는 모든 서비스에 적합합니다.
• 파일 스토리지는 파일 데이터에 대한 공유 액세스를 계층적 스토리지입니다. 사용자가 동시에 액세스해야 할 때 가장 적합합니다.
• 확장성을 오브젝트 스토리지, 블록 스토리지, 파일 스토리지 순으로 좋습니다.

S3와 Bucekt, Object

• Amazon S3(Simple Storage Service)는 확장성, 가용성, 보안 및 성능이 우수한 객체 스토리지 서비스입니다.
• S3는 데이터 레이크, 웹 사이트, 모바일 애플리케이션, 백업 및 복원, 아카이브, 엔터프라이즈 애플리케이션, IoT 디바이스, 빅 데이터 분석 등 다양한 사용 사례에서 원하는 양의 데이터를 저장하고 보호할 수 있습니다.
• Object(객체)는 S3에 저장되는 단위로 Ojbect data(또는 value)와 metadata로 구성됩니다. metadata는 객체를 설명하는 name-value의 집합입니다.
• 1개의 Object는 최대 5TB까지 가능합니다. Object가 100MB가 넘는 경우 Multipart upload 할 것을 권장하며 5GB 이상인 경우 반드시 Multipart upload로 업로드해야 합니다.
• Bucket(버킷)은 Object를 저장하는 저장소로 버킷에 저장할 수 있는 Object 수에는 제한이 없습니다.
• Bucket 이름은 partition 내의 모든 AWS 리전과 모든 AWS 계정에서 고유해야합니다. partition은 AWS 리전 그룹으로 aws(표준 리전), aws-cn(중국 리전), aws-us-gov(미국 정부 리전) 3개의 파티션이 있습니다.
• 정적 웹 사이트 호스팅에만 사용되는 버킷을 제외하고 버킷 이름에 점(.)을 사용하지 않는 것이 좋습니다.
• Object Key(또는 Key name)는 객체에 할당한 이름으로 버킷에서 객체를 고유하게 식별하는데 사용되며 대소문자를 구분합니다.
• Object Key는 Prefix(접두사)와 Object 이름으로 구성됩니다. Prefix는 Object key의 시작 부분에 있는 문자열입니다.
• S3에는 계층 구조가 없으나 키 이름에 접두사와 구분 기호(’/’)를 사용하여 콘솔에서 논리적인 계층 구조(폴더 개념)를 도입할 수 있습니다.

Object metadata

• Metadata는 Object 관련 정보를 저장하기 위한 name-value 쌍의 집합입니다.
• Object의 metadata는 system-defined metadata(시스템 정의 메타데이터)와 user-defined metadata(사용자 정의 메타데이터)라는 2가지 종류가 있습니다.
• REST API로 객체를 업로드 할 때 사용자 정의 메타데이터(user-defined metadata)의 이름은 다른 HTTP 헤더와 구분할 수 있도록 x-amz-meta-로 시작해야합니다.

S3 Bucket Policy와 ACL

• S3는 요청을 받으면 요청자가 필요한 권한을 보유하고 있는지 확인하고 모든 액세스 정책과 User policy와 Resource-based policy를 평가하여 승인 여부를 결정합니다.
• Bucket policy는 버킷과 내부 객체에 대한 액세스 권한을 부여할 수 있는 리소스 기반 정책(resource-based policy)입니다.
• Bucket Access control list과 Object Access control list는 버킷과 객체에 대한 액세스를 관리할 수 있는 리소스 기반 정책(resource-based policy)입니다.
• S3의 최신 사용 사례의 대부분에서는 더 이상 ACL을 사용할 필요가 없습니다. 각 객체에 대해서 액세스를 개별적으로 제어할 필요가 있는 드문 상황을 제외하고는 ACL을 비활성화하는 것이 좋습니다.

S3 Versioning

• S3 Versioning은 같은 버킷 안에서 여러 버전의 Object를 저장하는 방법으로 같은 key로 객체를 업로드하면 파일을 덮어쓰는 것이 아니라 다른 버전으로 모든 객체가 저장됩니다.
• Versioning을 사용하면 의도치 않은 삭제에 대응할 수 있습니다. Versioning이 설정된 버킷에서 어떤 버전의 객체을 삭제하면 단지 삭제 마커를 추가되는 것으로 삭제 마커가 현재 버전이 됩니다. 실제로 삭제되진 않기 때문에 언제든지 이전 버전으로 복원할 수 있습니다.
• Versioning은 버킷 단위로 설정이 가능하며 Versioning을 활성화하기 이전에 저장된 객체의 버전은 null입니다.
• Versioning을 비활성화하여도 기존 객체는 변경되지 않습니다. 이후 요청에 대해서 S3가 객체를 처리하는 방법만 변경됩니다.

S3 Storage Class

• S3는 성능, 비용 등의 요구사항에 따라 선택할 수 있는 다양한 Storage class를 제공합니다.
• 자주 액세스하는 객체를 위한 스토리지 클래스(S3 Standard과 S3 Express One Zone)와 자주 액세스하지 않는 객체를 위한 스토리지 클래스(S3 Standard-IA, S3 One Zone-IA), 객체 아카이빙을 위한 스토리지 클래스(S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval 및 S3 Glacier Deep Archive), 액세스 패턴을 알 수 없는 경우 자동으로 최적화하는 스토리지 클래스(S3 Intelligent-Tiering)가 있습니다.
• 모든 S3 Storage Class는 99.999999999%(11 nines) 내구성을 제공하지만 보관되는 가용영역 최소 보관 기간 등이 달라집니다.
  S3 RSS(Reduced Redundancy Storage)는 99.99% 내구성을 제공하고 저렴한 옵션을 제공하지만 사용하지 않는것이 좋습니다.

S3 Life Cycle

• Lifecycle을 설정하여 수명이 다한 객체를 삭제(Expiration)하거나 저렴한 스토리지로 전환(Transition)하여 비용 효율적으로 객체를 저장할 수 있습니다.
• Lifecycle은 Transition action(전환 작업)과 Expiration action(만료 작업) 작업 유형이 있습니다.
• Transition action(전환 작업)은 정해진 기간이 지나면 더 저렴한 스토리지로 전환하거나 아카이브합니다.
• Expiration action(만료 작업)은 정해진 기간이 지나면 객체를 자동으로 삭제합니다.
• Key prefix(키 접두사)와 Object tag(태그)를 활용하여 버킷 전체 또는 하위 집합에 Lifecycle을 적용할 수 있습니다.
• Lifecycle을 설정하고 적용하는 데는 추가 비용이 들지 않습니다. 하지만 객체가 Transition 되는 경우 객체 별로 Lifecycle Transition request 비용이 발생(Object PUT 비용과 동일)합니다.

S3 Replication

• S3 Replication을 통해 객체를 비동기식으로 자동 복사할 수 있습니다. Source bucket(소스 버킷)과 Destination bucket(대상 버킷)의 위치에 따라 Cross-Region Replication(CRR)과 Single-Region Replication(SRR)로 나뉩니다.
• Destination bucket은 동일한 AWS 계정뿐만 아니라 다른 계정에도 존재할 수 있습니다. 1개의 Source 버킷에서 여러 대상 버킷에 복제할 수도 있습니다.
• 소스 버킷과 대상 버킷 모두에서 Versioning을 설정해야하고 소스 버킷에 S3 객체 잠금이 설정되어 있는 경우에 대상 버킷에도 S3 객체 잠금이 설정되어 있어야 합니다.
• Replication를 설정하기 전에 업로드된 객체는 자동으로 복제되지 않습니다. Replication를 설정하기 전에 업로드된 객체를 복제하려면 S3 Batch Replication를 사용해야합니다.
• 사용자가 Source bucket에서 객체를 삭제하는 경우 기본적으로 Source bucket에만 삭제 마커를 추가합니다. 삭제 마커를 복제하기 위해서는 추가적인 요소(Filter)를 지정해줘야 합니다.
• 사용자가 Source bucket에서 버전 ID를 지정하여 삭제(영구적인 삭제)하는 경우에 Destination bucket의 복제본은 삭제되지 않습니다.
• 버킷 A가 소스이고 버킷 B가 대상인 Replication을 구성하는 경우. 버킷 B가 소스이고 버킷 C가 대상인 Replication을 추가로 구성한다고 했을때 버킷 B에 존재하는 버킷 A의 복제 Object는 버킷 C에 복제되지 않습니다.

S3 Static Website Hosting

• S3를 사용해서 정적 웹 사이트를 호스팅할 수 있습니다. 정적 웹 사이트는 client-side 스크립트를 포함할 수 있습니다.
• 웹 호스팅을 사용하기 위해서는 index document(인덱스 문서)를 구성하고 업로드해야합니다.
  index document는 웹페이지의 home page이거나 default page(기본페이지)입니다.
• 인터넷에 공개되는 정적 웹사이트를 구성하기 위해서는 버킷에 퍼블릭 읽기 권한을 부여해야합니다.
  버킷에 퍼블릭 읽기 권한을 부여하지 않고 웹사이트를 인터넷에 공개하고 싶다면 CloudFront distribution를 이용하여 구성할 수 있습니다.
• 리전에 따라 S3 웹사이트 엔드포인트는 http://bucket-name.s3-website-Region.amazonaws.com 또는 http://bucket-name.s3-website.Region.amazonaws.com를 사용합니다. 이러한 URL은 index document를 반환합니다.
• S3 웹 사이트 엔드포인트는 HTTPS를 지원하지 않습니다. HTTPS를 사용하려는 경우 CloudFront를 추가로 구성해야 합니다.

S3 Event Notifications

• S3 Event Notifications를 사용하면 S3 버킷에 특정 이벤트가 발생할 때 notification을 받을 수 있습니다.
• S3는 SNS, SQS, Lambda, EventBridge로 notification을 보낼 수 있습니다.
• SNS topic, SQS queue, Lambda function에 연결된 IAM 정책에 S3가 이벤트를 전송할 수 있도록 권한(Resource-based policies)을 부여해야 합니다.

S3 Access Log

• S3 버킷에 전달되는 모든 요청에 대해 Access Log를 생성하도록 버킷을 구성할 수 있습니다.
• Access Log를 활성화하면 S3는 Destination bucket(또는 target bucket)에 Source bucket에 대한 Access Log를 전송합니다.
• Source bucket과 Destination bucket은 동일한 계정에 동일한 리전에 존재해야합니다.
• Destination bucket은 Access Log를 활성화하면 안됩니다.
• Source bucket과 Destination bucket을 동일하게 설정하면 무한 루프가 발생하므로 권장하지 않습니다.
• Access Log는 Best-effort에 기반하여 항상 모든 레코드가 전송된다고 보장할 수는 없습니다.

S3 Presigned URL

• Presigned URL(미리 서명된 URL)을 사용하면 버킷의 정책을 업데이트하지 않아도 객체를 다운로드하거나 업로드하도록 허용할 수 있습니다.
• Presigned URL은 URL을 생성한 유저의 권한을 사용하게 되며 만료 시간까지 여러 번 사용할 수있습니다.

S3 CORS

• Cross-Site Request Forgery(CSRF)는 클라이언트의 브라우저에서 다른 애플리케이션으로 가짜 클라이언트의 요청을 전송하도록 합니다. 그렇기 때문에 거의 모든 브라우저에서 동일 오리진 정책(Same-origin policy)을 강제합니다.
• 예를 들어 “http://store.aws.com/dir/page.html”과 "http://store.aws.com/dir2/new.html”는 같은 origin이고,
  ”http://store.aws.com/dir/page.html”과 “https://store.aws.com/page.html”는 프로토콜이 다르기 때문에 다른 origin입니다.
  또한 "http://store.aws.com/dir/page.html”과 “http://news.aws.com/dir/page.html” 는 호스트가 다르기 때문에 다른 origin입니다.
• Same-origin policy는 매우 안전하지만 실제 사용 사례에서는 유연하지 못합니다. CORS는 Same-origin policy를 확장한 것으로 다른 오리진(외부)에서 데이터를 가져오려는 경우 CORS가 필요합니다.
• S3에서 CORS를 사용하면 다양한 클라이언트 측 웹 애플리케이션을 구축하고, S3 리소스에 대한 Cross-Origin 액세스를 선택적으로 허용할 수 있습니다.
• S3 CORS configuration에는 버킷 액세스를 허용할 오리진, HTTP 메서드 등이 포함됩니다.

S3 Encryption

• S3에 저장되는 데이터를 보호하는 방법에는 Server-side encryption(서버 측 암호화)와 Client-side encryption(클라이언트 측 암호화)가 있습니다.
• 서버 측 암호화는 AWS 데이터 센터의 디스크에 저장되기 전에 S3가 데이터를 암호화하고, 데이터를 다운로드할 때 복호화합니다.
• 돌일한 객체에 서로 다른 서버 측 암호화 유형을 동시에 적용할 수는 없습니다.
• 클라이언트 측 암호화는 S3에 업로드하기 전에 데이터를 암호화하여 업로드하는 방식입니다. 이 경우 사용자가 암호화 프로세스와 키를 관리해야합니다.
• 서버 측 암호화는 Server-side encryption with Amazon S3 managed keys(SSE-S3), Server-side encryption with AWS KMS keys(SSE-KMS), Dual-layer server-side encryption with AWS KMS keys(DSSE-KMS), Server-side encryption with customer-provided keys(SSE-C) 4가지 옵션을 제공합니다.
• SSE-S3는 S3의 기본 암호화 방식으로 암호화 방식을 지정하지 않으면 자동으로 적용되며 암호화키는 S3가 관리합니다.
• SSE-KMS는 KMS를 사용하여 암호화하는 방식으로 AWS managed key 또는 customer managed key를 사용할 수 있습니다.
• DSSE-KMS는 KMS를 사용하여 두 계층 암호화를 적용하는 방식으로 복잡한 컴플라이언스를 쉽게 준수할 수 있습니다.
• SSE-C는 고객이 제공한 키(customer-provided keys)로 암호화하는 방식으로 S3는 고객이 암호화에 사용한 키는 저장하지 않고 Hash-based Message Authentication Code(HMAC)로 검증합니다.

S3 Performance

• S3는 요청 빈도에 따라 자동으로 확장됩니다. S3가 요청 빈도에 따라 확장되는 동안 503 오류가 발생할 수 있으나 크기 조정(scaling)이 완료되면 사라집니다.
• 버킷의 prefix마다 초당 최소 소 3,500개의 PUT/COPY/POST/DELETE 또는 5,500개의 GET/HEAD 요청을 달성할 수 있습니다. 버킷의 prefix 10개를 만들어 병렬화하는 경우 초당 읽기 성능을 55,000개로 조정할 수 있습니다.

S3 Select

• S3 Select는 객체의 전체 데이터를 가져오지 않고 SQL 쿼리로 원하는 데이터만 검색하는 방법입니다.
• S3 Select를 사용하여 객체 안에 데이터를 필터링(쿼리)하면 S3가 전송하는 데이터 양을 줄이고 검색하는데 드는 비용과 지연 시간이 줄어듭니다.
• S3 Select은 한 번에 하나의 객체만 쿼리할 수 있으며 CSV, JSON 또는 Apache Parquet 형식으로 저장된 객체에 작동합니다.

S3 Access Point

• S3 access point는 bucket에 연결된 네트워크 엔드포인트로 S3 객체에 접근하는 방법을 간소화합니다.
• 각 S3 access point는 1개의 bucket이 연결되고 Access point policy가 적용됩니다.
• bucket의 이름과 account id를 사용해서 cross account access point를 생성할 수 있습니다.

S3 Object Lambda

• S3 Object Lambda는 S3가 데이터를 반환하기 전에 자체 코드를 추가하여 처리할 수 있는 기능입니다.
• Lambda 함수는 표준 S3 GET, LIST, HEAD 요청에 인라인으로 호출되므로 애플리케이션 코드를 변경할 필요가 없습니다.
• Lambda 함수를 구성한 후 S3 Object Lambda Access Point와 연결합니다. Object Lambda Access Point는 Supporting Access Point라고 불리는 S3 Access Point를 사용하여 S3에 액세스합니다.
• 데이터 유출을 막기 위해 사용자마다 다른 워터마크를 넣는 경우, 데이터를 제공하기 전에 민감 정보가 있는지 스캔하는 경우, 마케팅에 활용되는 데이터에 추가 세부 정보를 보강하는 경우 등에 사용 가능합니다.

S3 MFA Delete

• S3 버킷에 Versioning이 활성화된 경우 MFA Delete를 설정하여 추가적인 보안 설정이 가능합니다.
• MFA Delete는 객체 버전의 영구적인 삭제, 버킷의 버전 관리 상태 변경에 대해 추가적인 인증을 요구합니다.