S3

  • Amazon S3는 AWS의 주요한 서비스로, "무한하게 확장하는" 스토리지로 광고됨.
  • 많은 웹사이트들이 S3를 백본으로 사용
  • AWS 서비스들도 S3를 통합(integration)으로 사용함

S3 - Use cases

  • 백업 및 저장소
  • 장애 복구
  • 아카이빙
  • 하이브리드 클라우드 저장소
  • 애플리케이션 호스팅
  • 미디어 호스팅
  • 데이터 레이크 & 빅데이터 분석
  • 소프트웨어 배포
  • 정적 웹사이트

S3 - Buckets

  • AWS S3는 사람들이 objects(파일)들을 버킷(directories) 안에 저장할 수 있도록 해줌
  • 버킷은 반드시 전역적으로 고유한 이름을 가져야 함 (모든 리전과 모든 계정 통틀어서)
  • 버킷은 리전 수준에서 정의됨
    • S3는 마치 글로벌 서비스처럼 보이지만 사실 리전 내에 생성됨
  • 네이밍 컨벤션
    • uppercase 안됨, underscore 안됨
    • 3-63자
    • IP 불가
    • 반드시 숫자 또는 lowercase 글자로 시작되어야 함
    • **xn--**으로 시작하는 prefix(접두사)를 붙일 수 없음
    • -s3alias로 끝나는 suffix(접미사)를 붙일 수 없음

S3 - Objects

  • objects(파일)은 하나의 key를 가짐
  • key는 FULL path
    • s3://my-bucket/my_file.txt
    • s3://my-bucket/my_folder1/another_folder/my_file.txt
  • key는 prefix + object name 의 조합
    • s3://my-bucket/my_folder1/another_folder/my_file.txt
      • my_folder1/another_folder/ -> prefix
      • my_file.txt -> object name
  • 버킷에는 "디렉토리" 라는 개념은 없음 (UI가 마치 디렉토리처럼 느껴지도록 할 수는 있지만)
    • 단순히 슬래시(/)를 포함한 매우 긴 key가 있을 뿐임

S3 - Objects content

  • Object value -> body의 content
    • 최대 Object 사이즈는 5TB (5000GB)
    • 만약 5GB 이상의 것을 업로드 한다면, 반드시 "multi-part upload"를 사용해야 함
  • Metadata (텍스트 key-value 페어 목록 - 시스템 또는 이용자 메타데이터)
  • Tags (유니코드 key-value 페어 - 10개까지) - 보안 / 라이프사이클에 유용
  • Version ID (버저닝이 활성화된 상태에서만 존재)

S3 - Security

  • User-Based
    • IAM Policies - IAM으로부터 특정 이용자에 대한 API 호출이 허용되어야 함
  • Resource-Based
    • Bucket Policies - S3 콘솔을 통해 버킷 전반에 적용되는 룰(bucket wide rules)를 정의 -> 다른 계정으로부터의 호출을 허용
    • Object Access Control List (ACL) - 더 미세함 (비활성화 가능)
    • Bucket Access Control List (ACL) - 덜 일반적임 (비활성화 가능)
  • 중요: IAM 책임자(principal)은 다음과 같은 경우라면 S3 오브젝트에 접근할 수 있음
    • 해당 이용자의 IAM 권한이 접근을 허용하거나 또는 리소스 규칙(resouce policy)가 접근을 허용
    • 그리고 명시적인 거부(DENY)가 없어야 함
  • Encryption: S3 내 오브젝트를 encryption key를 통해 암호화

S3 - Bucket Policies

JSON Based Policy

  • JSON based policies
    • Resources: 버킷과 오브젝트
    • Effect: Allow / Deny
    • Actions: 각 API에 대한 Allow / Deny 목록
    • Principal: 규칙을 적용할 계정 또는 이용자
  • 다음과 같은 경우에 S3 버킷에 대한 policy를 사용
    • 버킷에 대한 퍼블릭 액세스를 허용하고자 하는 경우
    • 업로드 시점에 오브젝트가 암호화되도록 강제하고자 할 경우
    • 다른 계정의 액세스를 허용하고자 하는 경우 (Cross Account)

S3 - Bucket settings for Block Public Access

Block public access

  • 위 옵션들은 기업의 데이터 유출을 막기 위해 생성됨
  • 따라서, 절대 퍼블릭 액세스를 허용해선 안되는 버킷의 경우, 위의 옵션을 유지해둘 것
  • 계정(account) 수준에서 적용 가능

S3 - Static Website Hosting

S3 - Versioning

  • S3에 있는 파일들에 버저닝(versioning)을 할 수 있음
  • 버킷 레벨에서 활성화하는 것도 가능
  • 동일한 key에 대한 덮어쓰기 작업은 key의 버전을 바꾸게 됨 ~ "version": 1, 2, 3...
  • 버킷에다 버저닝을 하는 것이 베스트 프랙티스
    • 의도치 않은 삭제 작업으로부터 보호 가능 (특정 버전으로 복구할 수 있음)
    • 이전 버전으로 롤백하기가 쉬움
  • 중요:
    • 버전 활성화를 할 때, 이전에 버저닝이 되지 않았던 파일들은 null 버전을 갖게 됨
    • 버전의 일시중단(suspend) 작업이 이전 버전들을 삭제하지는 않음

S3 - Replication (CRR & SRR)

  • source 버킷과 destination 버킷들에 대해 버저닝이 활성화되어 있어야 함
  • Cross-Region Replication (CRR)
  • Same-Region Replication (SRR)
  • 다른 AWS 계정에 있는 버킷도 가능
  • 복사 작업은 비동기적
  • 반드시 S3에게 적절한 IAM 권한을 줘야함
  • 사례
    • CRR - 규정 준수, 낮은 레이턴시 접근, 계정이 다른 상황에서의 복제
    • SRR - 로그 집계, 프로덕션 및 테스트 계정 간의 실시간 복제

S3 - Replications (Notes)

  • 복제를 활성화한 이후, 오직 새로운 오브젝트만 복제됨
  • 선택적으로, S3 Batch Replication을 사용하면 기존에 존재하던 오브젝트에 대해서도 복제를 수행할 수 있음
    • 기존에 존재하던 오브젝트나 복제에 실패한 오브젝트를 복제
  • DELETE 작업의 경우
    • source로부터 target에 delete marker들을 복제할 수 있음 (선택 사항)
    • version ID로 삭제한 내용은 복제되지 않음 (malicious delete를 막기 위해)
  • 복제에 "체이닝"은 없음
    • 만약 버킷1을 버킷2에 복제하고, 이 버킷2를 버킷3로 복제했을 때
      • 버킷1에 있는 오브젝트들이 버킷3에 복제되진 않음

S3 - Storage Classes

  • Amazon S3 Standard - General Purpose

  • Amazon S3 Standard-Infrequent Access (IA)

  • Amazon S3 One Zone-Infrequent Access

  • Amazon S3 Glacier Instant Retrieval

  • Amazon S3 Glacier Flexible Retrieval

  • Amazon S3 Glacier Deep Archive

  • Amazon S3 Intelligent Tiering

  • 각 클래스를 수동으로 변경하거나, S3 라이프사이클 설정을 통해 변경할 수 있음

S3 - Durability and Availability

  • Durability:

    • 여러 AZ 간에 오브젝트의 높은 durability (99.999999999%) 보장
    • 만약 S3에 10,000,000 개의 오브젝트를 저장한다고 할 때, 평균적으로 10,000년에 한 번씩 하나의 오브젝트가 손실될 것으로 예상 가능함 (아무튼 드물다는 뜻)
    • 모든 스토리지 클래스에 대해 동일

  • Availability (가용성)

    • 서비스가 말그대로 이용 가능한 상태인지의 여부
    • 스토리지 클래스에 따라 달라짐
    • ex. S3 Standard는 99.99%의 availability를 가짐 => 즉, 1년에 53분 정도는 not available함

S3 Standard - General Purpose

  • 99.99% Availability
  • 자주 액세스되는 데이터에 사용
  • 낮은 latency와 높은 throughput
  • 2개의 concurrent facility failure를 가짐 => 2개의 데이터 센터에 문제가 생겨도, 다른 데이터 센터에서 대처가 가능
  • 사례: 빅데이터 분석, 모바일 & 게임 앱, 컨텐츠 전송(content distribution), ...

S3 Storage Classes - Infrequent Access

  • 액세스 빈도가 덜하지만, 필요하다면 빠르게 액세스 되어야 하는 데이터에 사용

  • S3 Standard보다 낮은 비용

  • Amazon S3 Standard-Infrequent Access (S3 Standard-IA)

    • 99.9% Availability
    • 사례: 장애 복구, 백업

  • Amazon S3 One Zone-Infrequent Access (S3 One Zone-IA)

    • 하나의 AZ 내에서 High durability(99.999999999%, 9가 11개), AZ가 파괴되면 데이터가 사라짐
    • 99.5% Availability
    • 사례: 온-프레미스(on-premise) 데이터의 보조 백업 복사본에 대한 저장, 또는 재생성 가능한 데이터

S3 Glacier Storage Classes

  • 아카이빙 / 백업 의도의 낮은 비용 오브젝트 저장소

  • 비용: 스토리지 비용 + 오브젝트 조회(retrieval) 비용

  • Amazon S3 Glacier Instant Retrieval

    • 밀리세컨드(ms) 단위 조회, 분기 별로 한번 액세스되는 데이터의 경우에 좋음
    • 저장소의 최소 지속시간 90일

  • Amazon S3 Glacier Flexible Retrieval (Amazon S3 Glacier 이전 버전)

    • 데이터 조회에 걸리는 시간
      • Expedited (1 ~ 5분), Standard (3 ~ 5시간), Bulk (5 ~ 12시간) - 무료
    • 저장소의 최소 지속시간 90일

  • Amazon S3 Glacier Deep Archive - 장기간 보관에 사용:

    • 데이터 조회에 걸리는 시간
      • Standard (12 시간), Bulk (48 시간)
    • 저장소의 최소 지속시간 180일

S3 Intelligent-Tiering

  • 매달 약간의 모니터링 및 auto-tiering 비용을 지불
  • 사용 패턴에 따라 Access Tier 간에 오브젝트들을 자동으로 이동시킴
  • 별도로 조회(retrieval) 비용이 존재하지 않음
  • 티어 종류
    • Frequent Access tier (자동): 기본 티어
    • Infrequent Access tier (자동): 30일 동안 액세스하지 않은 오브젝트
    • Archive Instant Access tier (자동): 90일 동안 액세스하지 않은 오브젝트
    • Archive Access tier (선택): 90일에서 700+일 사이로 설정 가능
    • Deep Archive Access tier (선택): 180일에서 700+일 사이로 설정 가능

S3 - Moving between Storage Classes

S3 Lifecycle

  • 오브젝트들을 각 스토리지 클래스 간에 전환할 수 있음
  • 자주 액세스되지 않는 오브젝트의 경우, Standard IA로 이동
  • 빠른 액세스가 요구되지 않는, 아카이빙 오브젝트의 경우 Glacier 또는 Glacier Deep Archive로 이동
  • 오브젝트의 이동은 Lifecycle Rules를 통해 자동화 될 수 있음

S3 - Lifecycle Rules

  • Transition Actions - 오브젝트를 다른 스토리지 클래스로 전환하도록 설정

    • 생성 이후 60일이 지나면 Standard IA 클래스로 오브젝트 이동
    • 6개월이 지나면 Glacier로 이동

  • Expiration Actions - 일부 시간이 지나면 오브젝트를 만료(삭제)하도록 설정

    • 액세스 로그 파일들은 365일이 지난 이후에는 삭제되도록 설정
    • 오래된 버전의 파일들은 삭제되도록 설정 (버저닝이 활성화되어 있는 경우)
    • 불완전한 Multi-Part 업로드들에 대해서는 삭제하도록 설정

  • 특정한 prefix를 가진 경우에 대해서만 적용할 수도 있음 (ex. s3://mybucket/mp3/*)

  • 특정한 오브젝트 태그를 가진 경우에만 적용할 수도 있음 (ex. Department: Finance)

S3 - Lifecycle Rules (Scenario 1)

내 EC2 애플리케이션은 프로필 사진을 썸네일로 만들어 업로드한다. 이 썸네일들은 쉽게 재생성될 수 있고, 60일 동안 보존되어야 한다. 소스 이미지들은 60일 동안 즉각적으로 조회될 수 있어야하고, 60일이 지난 이후에는 6시간까지 기다릴 수 있다. 이를 어떻게 구현할 수 있을까?

  • S3 소스 이미지는 Standard로 두고, 60일이 지나면 Glacier로 전환하도록 라이프사이클 설정을 할 수 있다.
  • S3 썸네일 이미지는 One-Zone IA로 두고, 60일이 지나면 이것이 만료되도록(삭제하도록) 설정할 수 있다.

S3 - Lifecycle Rules (Scenario 2)

내 회사에는 삭제된 S3 오브젝트를 30일 동안은 드물긴 하겠지만 즉각적으로 복구할 수 있어야 한다는 룰이 성명되어 있다. 또 30일이 지난 이후, 최대 365일 동안은 삭제된 오브젝트들이 48시간 내에는 복구 가능(recoverable)한 상태에 있어야 한다.

  • 오브젝트들이 버전을 갖도록 S3 버저닝을 활성화한다. 이를 통해, "삭제된 오브젝트"는 실제로 삭제된 것이 아니라, "delete marker"를 가짐으로써, 사실을 숨김 처리가 되었을 뿐, 복구 가능한 상태가 된다.
  • 오브젝트의 비현재 버전(noncurrent version)들을 Standard IA로 전환한다.
  • 시간이 지난 이후에는 비현재 버전(noncurrent version)들을 Glacier Deep Archive로 전환한다.

S3 - Storage Class Analysis

  • 오브젝트를 적절한 스토리지 클래스로 전환할 때 결정을 도와줌
  • Standard와 Standard IA의 경우 추천
    • One-Zone IA나 Glacier에는 적용되지 않음
  • 1일 단위로 리포트가 업데이트됨
  • 데이터 분석 시작까지 24 ~ 48시간
  • 라이프사이클 룰을 적용(또는 향상)하기 위한 좋은 시작

S3 - Requester Pays

  • 일반적으로 버킷 소유자는 S3 스토리지와 해당 스토리지와 관련된 모든 데이터 전송 비용을 지불함
  • 하지만 Requester Pays 버킷을 사용하면, 버킷 소유자가 아닌 요청자(requester)가 버킷으로부터의 데이터 다운로드 및 요청 비용을 지불
  • 다른 계정과 거대한 데이터셋을 공유하고자 할 때 유용함
  • requester는 반드시 AWS 상에서 인증되어야 함 (익명 이용자가 될 수 없음)

S3 - Event Notifications

  • S3:ObjectCreated, S3:ObjectRemoved, S3:ObjectRestore, S3:Replication...
  • 오브젝트 명칭에 대한 필터링 가능 (ex. *.jpg)
  • 사례: S3로 업로드되는 이미지에 대한 썸네일 생성
  • 원하는 만큼의 "S3 이벤트"를 생성할 수 있음
  • AWS SNS, SQS, Lambda와 연동 (EventBridge를 통해 더 많은 Destination과 연동 가능)
  • S3 event notifications는 이벤트 전달에 일반적으로 몇 초 정도가 소요되지만, 가끔 1분, 또는 그 이상이 소요될 수 있음

S3 - Event Notifications with Amazon EventBridge

  • JSON 룰을 이용한 고급 필터링 (메타 데이터, 오브젝트 크기, 명칭...)
  • Multiple Destinations - ex. Step functions, Kinesis Streams / Firehose...
  • EventBridge Capabilities - Archive, Replay Event, Reliable delivery

S3 - Baseline Performance

  • S3는 많은 요청 횟수를 처리하고 100-200ms의 레이턴시를 보유하도록 자동으로 스케일링됨
  • 하나의 버킷에 각 prefix 당 매초 최소 3,500 개의 PUT/COPY/POST/DELETE 또는 5,500 GET/HEAD 요청 작업을 수행할 수 있음
  • 하나의 버킷에 가질 수 있는 prefix 갯수의 제한은 없음
  • 예시 (object path => prefix):
    • bucket/folder1/sub1/file => /folder1/sub1/
    • bucket/folder1/sub2/file => /folder1/sub2/
    • bucket/1/file => /1/
    • bucket/2/file => /2/
  • 위 4개의 prefix 모두에 균등하게 읽기를 분산시키면, GET과 HEAD에 대해 초당 22,000건의 요청을 달성할 수 있음

S3 - Performance

  • Multi-Part upload:
    • 100MB 이상의 파일에 추천
    • 5GB 이상의 파일에는 필수
    • 업로드를 병렬화(parallelize)할 수 있음 (전송 속도 상승)
  • S3 Transfer Acceleration
    • 타깃 리전에 해당하는 S3 버킷으로 데이터를 전달하는 AWS 엣지 로케이션으로 파일을 전송하여 전송 속도를 향상시킴
    • Multi-part upload와 호환 가능함

S3 - Performance ~ S3 Byte-Range Fetches

  • 특정 바이트 범위(byte range)에 대한 요청을 보내서 GET 요청을 병렬화
  • 장애 발생 시 복원력(resilience) 향상
  • 다운로드 속도를 향상시킬 수 있음
  • 데이터의 일부만 조회하는데에 사용할 수 있음 (ex. 파일 헤드)

S3 - Select & Glacier Select

  • SQL을 사용하는 서버사이드 필터링을 적용하여 적은 데이터를 조회할 수 있음
  • row & column으로 필터링 가능 (간단한 SQL 문)
  • 더 적은 양의 네트워크 전송이 이루어지고, 또 더 적은 클라이언트 측 CPU 비용이 발생

S3 - Batch Operations

  • 존재하는 S3 오브젝트들에 하나의 요청을 통해 대량 작업을 수행

    • 오브젝트의 메타데이터와 프로퍼티를 수정
    • S3 버킷 간에 오브젝트 복사
    • 비암호화된 오브젝트를 암호화
    • ACL과 태그를 수정
    • S3 Glacier로부터 오브젝트들을 복구
    • 각 오브젝트에 커스텀 액션을 수행하는 람다 함수를 실행

  • 대상 오브젝트 목록, 수행할 액션, 옵션 파라미터로 하나의 작업이 구성됨

  • S3 Batch Operation로 재시도를 관리하고, 진행 상황을 추적하고, 완료 알림을 보내고, 리포트를 생성할 수 있음

  • 대상 오브젝트 목록을 얻기위해 S3 Inventory를 사용할 수 있고, 그 목록을 필터링하기 위해 S3 Select를 사용할 수 있음

S3 - Object Encryption

  • S3 버킷 내 오브젝트들은 아래 4가지 방법 중 하나로 암호화할 수 있음 ~ 어떤 상황에서 어떤 암호화를 적용할 지 이해하는 것이 중요함

  • Server-Side Encryption (SSE)

    • Server-Side Encryption with Amazon S3-Managed Keys (SSE-S3) - 기본 활성화
      • AWS로부터 소유/관리되는 키를 통해 S3 오브젝트를 암호화
    • Server-Side Encryption with KMS Keys stored in AWS KMS (SSE-KMS)
      • 암호화 키 관리를 위해 AWS Key Management Service (AWS KMS)를 활용
    • Server-Side Encryption with Customer-Provided Keys (SSE-C)
      • 본인의 커스텀 암호화 키로 관리하고자 할 때

  • Client-Side Encryption

S3 Encryption - SSE-S3

  • AWS가 다루고, 관리하고, 소유한 키를 통해 암호화
  • 오브젝트는 서버사이드에서 암호화됨
  • 암호화 타입은 AES-256
  • 반드시 헤더에 다음을 포함 => "x-amz-server-side-encryption": "AES256"
  • 새로 만든 버킷 & 새로운 오브젝트들에는 기본적으로 활성화되어 있음

S3 Encryption - SSE-KMS

  • AWS KMS(Key Management Service)를 통해 관리되는 키로 암호화
  • KMS 이점: 이용자 통제 + CloudTrail을 사용한 키 사용 감사(audit)
  • 오브젝트는 서버사이드에서 암호화됨
  • 반드시 헤더에 다음을 포함 => "x-amz-server-side-encryption": "aws:kms"

SSE-KMS Limitation

  • SSE-KMS를 사용하는 경우, KMS의 한계에 부딫힐 수도 있음
  • 업로드 시에, GenerateDataKey KMS API를 호출함
  • 다운로드 시에, Decrypt KMS API를 호출함
  • 초당 KMS 할당량(quota)에 포함됨 (리전에 따라 5500, 10000, 30000 req/s)
  • Service Quotas Console을 사용해서 quota 증량을 요청할 수 있음

S3 Encryption - SSE-C

  • AWS 외부의, 이용 고객으로부터 완전히 관리되는 키를 통한 서버사이드 암호화
  • S3는 관리자(나)가 제공하는 암호화 키를 보관하지 않음
  • HTTPS 필수
  • 모든 HTTP 요청의 HTTP 헤더에 암호화 키가 제공되어야 함

SE Encryption - Client-Side Encryption

  • Amazon S3 클라이언트 사이드 암호화 라이브러리같은 클라이언트 라이브러리를 사용
  • 클라이언트 쪽에서 S3로 데이터를 전송하기 전에 반드시 스스로 암호화를 해서 보내야 함
  • 클라이언트 쪽에서 S3로부터 데이터를 조회할 때도 반드시 스스로 복호화를 해야함
  • AWS 이용고객(나)가 key와 암호화 사이클을 모두 관리해야함

S3 - Encryption in transit (SSL/TLS)

  • 전송 중 암호화(Encryption in flight)는 SSL/TLS로도 불림

  • S3는 다음의 두가지 엔드포인트를 노출

    • HTTP Endpoint - 비암호화
    • HTTPS Endpoint - encryption in flight

  • HTTPS가 권장됨

  • HTTPS는 SSE-C를 사용하고자 하는 경우 필수

  • 대부분의 클라이언트들은 기본적으로 HTTPS 엔드포인트를 사용

S3 - Force encryption in Transit

Secure Transport

  • aws:SecureTransport를 사용

S3 - Default Encryption vs. Bucket Policies

  • SSE-S3 암호화는 S3 버킷에 저장되는 새 오브젝트들에 자동으로 적용됨
  • 선택적으로, bucket policy를 활용하여 암호화를 강제하거나, ecnryption header(SSE-KMS 또는 SSE-C)가 없는 경우는 PutObject API 호출을 거부할수도 있음
  • 중요: Bucker Policy는 Default Encryption보다 우선하여 적용됨

S3 - CORS

What is CORS?

  • Cross-Origin Resource Sharing (CORS)
  • Origin = scheme (protocol) + host (domain) + port
    • ex.) https://www.example.com (포트 - 443 for HTTPS, 80 for HTTP)
  • 웹 브라우저는 기본 오리진을 방문하는 동안, 다른 오리진에 대한 요청을 허용
    • 동일 오리진: http://example.com/app1 & http://example.com/app2
    • 서로 다른 오리진: http://www.example.com & http://other.example.com
  • 다른 오리진에서 일어난 요청은 CORS 헤더를 사용하여 요청을 허용하지 않는 한 처리되지 않음 (ex. Access-Control-Allow-Origin)

AWS CORS

S3 - CORS ~ allow origin

  • 만약 클라이언트가 cross-origin 요청을 S3 버킷에 보낸다면, 적절한 CORS 헤더를 활성화해야 함
  • 시험에 잘 나옴
  • 특정 오리진 또는 *(모든 오리진)을 허용할 수 있음

S3 - MFA Delete

  • MFA (Multi-Factor Authentication) - 이용자가 S3에서 중요한 작업을 수행하기 전에, 디바이스(주로 모바일 또는 하드웨어)를 통해 코드를 생성하여 인증하도록 강제
  • MFA는 다음과 같은 경우에 요구됨
    • 오브젝트 버전을 영구적으로 삭제
    • 버킷의 버저닝을 중지
  • MFA가 요구되지 않는 경우
    • 버저닝의 활성화
    • 삭제된 버전의 리스팅
  • MFA Delete를 사용하려면, 버킷에 반드시 버저닝이 활성화되어야 함
  • 버킷 소유자(루트 계정)만이 오직 MFA Delete를 활성화/비활성화할 수 있음

S3 - Access Logs

  • 감사(audit) 목적으로, S3에 대한 모든 액세스를 로그하고 싶을 수 있음
  • 인증 유무에 상관없이 어떤 계정이든 S3에 이루어진 어떤 요청이 다른 S3 버킷에 로깅됨
  • 데이터 분석 툴을 통해 분석될 수 있음
  • 타깃이 되는 로그 버킷(로그가 저장되는 버킷)은 동일한 AWS 리전 내에 있어야 함
로그 포맷 
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DOC-EXAMPLE-BUCKET1 [06/Feb/2019:00:00:38 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be 3E57427F3EXAMPLE REST.GET.VERSIONING - "GET /DOC-EXAMPLE-BUCKET1?versioning HTTP/1.1" 200 - 113 - 7 - "-" "S3Console/0.4" - s9lzHYrFp76ZVxRcpX9+5cjAnEH2ROuNkd2BHfIa6UkFVdtjf5mKR3/eTPFvsiP/XV/VLi31234= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader DOC-EXAMPLE-BUCKET1.s3.us-west-1.amazonaws.com TLSV1.2 arn:aws:s3:us-west-1:123456789012:accesspoint/example-AP Yes
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DOC-EXAMPLE-BUCKET1 [06/Feb/2019:00:00:38 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be 891CE47D2EXAMPLE REST.GET.LOGGING_STATUS - "GET /DOC-EXAMPLE-BUCKET1?logging HTTP/1.1" 200 - 242 - 11 - "-" "S3Console/0.4" - 9vKBE6vMhrNiWHZmb2L0mXOcqPGzQOI5XLnCtZNPxev+Hf+7tpT6sxDwDty4LHBUOZJG96N1234= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader DOC-EXAMPLE-BUCKET1.s3.us-west-1.amazonaws.com TLSV1.2 - -
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DOC-EXAMPLE-BUCKET1 [06/Feb/2019:00:00:38 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be A1206F460EXAMPLE REST.GET.BUCKETPOLICY - "GET /DOC-EXAMPLE-BUCKET1?policy HTTP/1.1" 404 NoSuchBucketPolicy 297 - 38 - "-" "S3Console/0.4" - BNaBsXZQQDbssi6xMBdBU2sLt+Yf5kZDmeBUP35sFoKa3sLLeMC78iwEIWxs99CRUrbS4n11234= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader DOC-EXAMPLE-BUCKET1.s3.us-west-1.amazonaws.com TLSV1.2 - Yes
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DOC-EXAMPLE-BUCKET1 [06/Feb/2019:00:01:00 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be 7B4A0FABBEXAMPLE REST.GET.VERSIONING - "GET /DOC-EXAMPLE-BUCKET1?versioning HTTP/1.1" 200 - 113 - 33 - "-" "S3Console/0.4" - Ke1bUcazaN1jWuUlPJaxF64cQVpUEhoZKEG/hmy/gijN/I1DeWqDfFvnpybfEseEME/u7ME1234= SigV4 ECDHE-RSA-AES128-GCM-SHA256 AuthHeader DOC-EXAMPLE-BUCKET1.s3.us-west-1.amazonaws.com TLSV1.2 - -
79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DOC-EXAMPLE-BUCKET1 [06/Feb/2019:00:01:57 +0000] 192.0.2.3 79a59df900b949e55d96a1e698fbacedfd6e09d98eacf8f8d5218e7cd47ef2be DD6CC733AEXAMPLE REST.PUT.OBJECT s3-dg.pdf "PUT /DOC-EXAMPLE-BUCKET1/s3-dg.pdf HTTP/1.1" 200 - - 4406583 41754 28 "-" "S3Console/0.4" - 10S62Zv81kBW7BB6SX4XJ48o6kpcl6LPwEoizZQQxJd5qDSCTLX0TgS37kYUBKQW3+bPdrg1234= SigV4 ECDHE-RSA-AES128-SHA AuthHeader DOC-EXAMPLE-BUCKET1.s3.us-west-1.amazonaws.com TLSV1.2 - Yes

S3 - Access Logs: Warning

  • 모니터링 버킷(감시 대상이 되는 버킷)을 로깅 버킷으로 설정해서는 안됨
  • 이 경우, 로깅 루프를 유발하여, 버킷이 무한정 커지게 됨

S3 - Pre-Signed URLs

  • S3 콘솔, AWS CLI 또는 SDK를 통해, pre-signed URL을 생성
  • URL Expiration
    • S3 Console - 1분에서 720분(12시간)까지
    • AWS CLI - --expires-in 파라미터로 초 단위 유효기간 설정 가능 (기본 3600초, 최대 604800초 ~ 168시간)
  • pre-signed URL를 전달받은 이용자는 GET/PUT에 대한 URL을 생성한 이용자의 권한을 상속받음
  • 예시:
    • 로그인을 한 유저에게만 S3 버킷으로부터 프리미엄 비디오를 다운로드할 수 있도록 하는 경우
    • 끊임없이 변화하는 이용자 목록들에게만 파일 다운로드 경로를 동적으로 제공하고자 하는 경우
    • S3 버킷의 특정한 위치에 이용자가 파일을 업로드하도록 일시적으로 허용하고자 하는 경우

S3 - Glacier Vault Lock

  • WORM(Write Once Read Many) 모델 적용
  • Vault Lock Policy를 생성
  • 추후의 변경에 대해 policy를 잠금 (더 이상 변경되거나 삭제될 수 없음)
  • 규정 준수(compliance)와 데이터 보관(data retention)에 유용

S3 - Object Lock (versioning must be enabled)

  • WORM(Write Once Read Many) 모델 적용
  • 특정 시간 동안 오브젝트 버전의 삭제를 막음
  • Retention mode - Compliance:
    • 루트 이용자를 포함해 그 누구도 버전을 덮어씌우거나 삭제할 수 없음
    • 해당 모드는 변경될 수 없고, 정해진 기간도 더 줄일 수 없음
  • Retention mode - Governance:
    • 대부분의 이용자들은 오브젝트 버전을 덮어씌우거나 삭제하거나, 잠겨진 세팅을 변경할 수 없음
    • 일부 이용자들에게 보관된 내용을 변경하거나, 오브젝트를 삭제할 수 있는 특별한 권한을 부여할 수 있음
  • Retention Period:
    • 정해진 기간 동안 특정한 오브젝트를 보호하며, 연장될 수 없음
  • Legal Hold:
    • 보관 기간과 무관하게 오브젝트를 무기한 보호
    • s3:PutObjectLegalHold IAM 권한을 통해 보호를 해제하거나, 오브젝트를 삭제할 수 있음

S3 - Access Points

  • Access Point는 S3 버킷에 대한 보안 관리를 쉽게 만들어줌
  • 각각의 Access Point는 다음을 가짐:
    • 본인의 DNS 네임 (인터넷 오리진 or VPC 오리진)
    • 액세스 포인트 정책 (버킷 정책과 유사함) - 규모에 따라 보안을 관리

S3 - Access Points ~ VPC Origin

S3 Access Points by VPC Origin

  • VPC 내에서만 액세스할 수 있도록 액세스 포인트를 정의할 수도 있음
  • 반드시 액세스 포인트로 액세스하는 VPC 엔드포인트를 만들어야 함 (Gateway 또는 Interface 엔드포인트)
  • 반드시 타깃 버킷과 액세스 포인트에 대한 액세스를 VPC 엔드포인트 정책 상으로 허용하고 있어야 함

S3 Object Lambda

S3 Object Lambda

  • 호출 애플리케이션(caller application)에 의해 오브젝트가 조회되기 전에, AWS 람다 함수를 오브젝트에 적용할 수 있음
  • S3 Access Point와 S3 Object Lambda Access Points를 갖고 있는 하나의 S3 버킷만 필요함
  • 사례:
    • 분석 또는 비프로덕션 환경을 위한 개인 식별 정보 삭제
    • 데이터 포맷 간의 변환 (ex. XML to JSON)
    • 오브젝트를 요청한 사용자 등 호출 세부 정보(caller-specific detail)를 사용하여 즉석에서 이미지 크기를 조정하거나, 워터마킹을 할 수 있음