AWS 자격증 공부/AWS SAA-C03

AWS SAA : S3

sseldne0 2024. 11. 20. 12:03

S3 use cases

  • 백업과 스토리지로 활용됨
  • 재해 복구
  • 파일 아카이브 → 검색
  • 하이브리드 클라우드 스토리지 → 온프레미스를 확장할 때
  • 애플리케이션 호스팅
  • 미디어 호스팅
  • 데이터 레이크 & 빅데이터 분석
  • 소프트웨어 딜리버리
  • 정적 웹사이트

S3 Bucket

  • 파일 (객체) 를 버킷 (폴더) 에 넣는 것
  • 전역적으로 고유한 이름을 가짐
  • 이름 규칙 : 대문자 안됨, IP주소 안됨, 문자-숫자-하이픈만 사용
  • 리전 수준에서 정의됨

S3 Object

  • 파일 (객체)는 키를 가짐
  • 키 : FULL PATH (파일의 전체 경로)
  • 버켓에서 ‘디렉토리’ 개념은 없고 ‘키’ 개념만 있음
  • 메타데이터 : 키-밸류 쌍으로 구성되어 메타데이터를 지님
  • 태그 : 보안, 수명 주기에 유용함
  • 버전 ID : 버전 관리 가능

S3 Security

  • User based
    • IAM Policies : 사용자에게 IAM 정책이 주어짐. IAM user 에게 각각 어떤 API를 호출할 수 있는지 권한을 부여
  • Resource based
    • Bucket Policies : 교차 계정을 허용, S3 버킷 자체를 공개로 만듦
      • JSON 기반 정책
        • Statement
          • Principle : 정책을 적용할 계정이나 유저
          • Effect : Allow / Deny
          • Action : API 종류
          • Resource : 버켓, 오브젝트 선택
    • Object Access Control List (ACL) : 보다 세밀한 보안.
    • Bucket Access Control List (ACL) : 덜 일반적임
  • Encryption : 암호 키를 사용하여 객체 암호화

S3 Website

  • S3를 활용해 Static Website Hosting이 가능함
  • 403 Forbidden error 해결을 위해 버켓을 public으로 변환해야 함

S3 Versioning

  • 파일 버전 관리 ← 버킷 수준에서 설정
  • 동일한 키를 업로드하고 파일을 덮어쓰기할 경우 버저닝이 가능함
  • 이전 버전으로 롤백 가능
  • 버전 관리가 적용되지 않은 모든 파일은 null 버전임
    • 이걸 삭제하면 delete marker가 설정되고 버켓에서 파일이 보이지 않음. 하지만 사실 삭제된건 아니고, 버전 확인을 통해 삭제된 파일을 확인 가능.
    • delete marker를 삭제하면 다시 파일을 확인할 수 있음.
  • 버전 관리를 중단해도 이전 버전을 삭제하지 않음

S3 Replication

  • 복제할 두 버켓은 버저닝이 활성화되어있어야 함.
  • 복제 종류
    • CRR : Cross Region Replication
      • use case : compliance, lower latency access, replication across accounts
    • SRR : Same Region Replication
      • use case : log aggregation, live replication between production and test accounts
  • 다른 AWS 계정에 버켓이 존재해도 괜찮음
  • 비동기적으로 복사됨
  • 복제 기능 정상 실행을 위해 S3에 올바른 IAM 권한을 부여해야 함
    • 버켓 읽기, 쓰기
  • 복제 활성화한 후, 새로운 객체만 복제 대상이 됨
    • 기존의 객체를 복제하려면, S3 배치 복제 기능을 활성화해야 함
  • 작업 삭제
    • 소스 버킷에서 대상 버킷으로 delete marker 복제
      • settings > Delete marker replication 활성화
    • 버전 ID로 삭제하는 경우 복제되지 않음
  • 체이닝 복제 불가. 1→2 , 2→3 복제되어있다고 해서 1→3이 되지 않음

S3 Storage Classes

  • Standard - General Purpose
    • Availability : 99.99%
    • 자주 접근하는 데이터에 사용
    • 지연 시간이 짧고, 처리량이 높음
    • 2개의 기능 장애를 동시에 버팀
    • 빅데이터 분석, 모바일과 게임 애플리케이션, 콘텐츠 배포
  • Standard-Infrequent Access (IA)
    • 자주 액세스하지 않지만 필요한 경우 빠르게 액세스하는 데이터에 사용
    • 비용이 적지만 검색 비용이 발생
    • Availability : 99.9%
    • 재해 복구, 백업
  • One Zone-Infrequent Access (IA)
    • 자주 액세스하지 않지만 필요한 경우 빠르게 액세스하는 데이터에 사용
    • 비용이 적지만 검색 비용이 발생
    • 단일 AZ 내에서는 높은 내구성, but AZ 가 destroy 되면 데이터 손실
    • Availability : 99.5%
    • 온프레미스 데이터 2차 백업, 재생성 가능한 데이터 저장
  • Glacier
    • Cold Storage : 아카이빙, 백업을 위한 저비용 스토리지
    • 스토리지 비용, 검색 비용 발생
    • 종류
      • Glacier Instant Retrieval
        • 데이터 검색 시, 밀리초 단위 안에 리턴 가능 : 분기에 한번 액세스하는 데이터에 적합
        • 최소 보관 기간 : 90일
      • Glacier Flexible Retrieval
        • 종류 : 데이터 검색 시 리턴하는 시간에 따라 분류
          • Expedited : 1~5분 내 데이터 받음
          • Standard : 3~5시간 내 데이터 받음
          • Bulk: 5~12시간 내 데이터 받음 : 무료
        • 최소 보관 기간 : 90일
      • Glacier Deep Archive
        • 장기 보관 → 가장 저렴
        • 종류
          • Standard : 12시간
          • Bulk : 48시간
        • 최소 보관 기간 : 180일
  • Intelligent Tiering
    • 사용 패턴에 따라 액세스된 티어간 객체를 자동으로 이동
    • 소액의 월별 모니터링 비용과 티어링 비용 발생 but 검색 비용이 들지 않음
    • Tier
      • Frequent Access tier : default
      • Infrequent Access tier : 30일동안 접근 X
      • Archive Instant Access tier : 90일동안 접근 X
      • Archive Access tier : 90~700일동안 접근 X
      • Deep Archive Access tier : 180~700일동안 접근 X
  • Durability : S3로 인해 객체가 손실되는 횟수, 모든 Storage Class에서 동일
  • Availability : 서비스가 얼마나 용이하게 제공되는지, Storage Class마다 다름

S3 Moving between storage classes

Lifecycle Rule을 적용하여 스토리지 클래스 변환 가능

  1. Transition Action : 다른 스토리지 클래스로 객체 이동
  2. Expiration Action : 특정 시간 이후 객체 삭제

→ 이런 규칙은 prefix에게 적용할 수도 있고, object Tag에게 적용할 수도 있음

S3 Analysis를 활용하여 라이프 사이클을 설정하는 데 도움을 받을 수 있음. 하지만 Standard, Standard IA에만 적용 가능

S3 Requester Pays

보통 버킷 소유자가 버킷과 관련된 모든 스토리지와 데이터 전송 비용을 지불함

하지만 Requester Pay bucket을 활성화하면, 요청자가 객체를 다운로드할 때 요청자가 비용을 지불함. 그렇기 때문에 익명 요청자이면 안되고, AWS에서 인증을 받은 요청자야만 함. ← 대량의 데이터셋을 여러명과 공유할 때 좋음

S3 Event Notification

Event : 객체 생성, 삭제, 복구, 복제

필터링 : ex. jpg 객체만 고려

특정 이벤트에 자동으로 어떤 반응 (특정 서비스 사용) 을 하는 것

특정 서비스(SNS, SQS, Lambda)를 사용하려면, IAM 권한이 있어야 함.

→ S3 버킷이 특정 서비스에 데이터 전송할 수 있도록 리소스 액세스 정책을 첨부

S3에 Event 발생 시, EventBridge로 모든 Event가 전송됨

EventBridge에 규칙을 설정해서 특정 서비스(18개)에 전송 가능

S3 Performance

  • S3 Baseline Performance
    • 기본적으로 매우 높은 요청 수로 자동으로 스케일링되며, 매우 짧은 지연 시간을 가짐
    • 버킷의 prefix당, 1초에 3,500개의 PUT, COPY, POST, DELETE 연산이나 5,500개의 GET, HEAD 연산 수행 가능
    • 버킷의 prefix 개수에 제한을 받지 않음
  • prefix란, object path에서 bucket과 object 사이의 경로 자체
    • bucket/folder1/sub1/file ⇒ /folder1/sub1/
    • bucket/1/file ⇒ /1/
  • S3 Performance
    • Multi-Part Upload
      • 100MB가 넘는 파일에 대해서 권장, 5GB 넘으면 무조건 사용
      • 업로드를 병렬화하므로, 전송 속도를 높여 대역폭을 확장
    • S3 Transfer Acceleration
      • 업로드, 다운로드 속도 가속화 가능
      • 파일을 AWS 엣지 위치로 전송해 전송 속도를 높임 → 해당 데이터가 대상 지역의 S3 버킷으로 전달됨
      • USA의 파일을 Australia의 버킷으로 업로드할 때, public internet을 사용하여 파일을 USA 엣지로 업로드하고, private network를 사용하여 파일을 USA 엣지에서 Australia 버킷으로 업로드
    • 위 2개는 호환 가능
  • S3 Byte-Range Fetches
    • 가장 효율적인 방법으로 파일을 읽는 방법 (다운로드 속도 가속)
    • 파일의 특정 바이트 범위를 가져와 가져오기를 병렬화
    • 파일의 일부만 검색해 필요한 정보만 가져옴

S3 Select & Glacier Select

파일 검색 시, 검색한 뒤 모든 데이터 상에서 필터링하면 너무 많은 데이터를 검색함

대신 S3 Select를 사용하면 SQL문을 이용하여 서버 측 필터링을 수행함

→ network transfer 감소, client-side 의 CPU cost 감소, 속도 증가, 비용 감소

S3 Batch Operation

  • 단일 요청으로 기존 S3 객체에서 대량 작업 수행
    • 한번에 많은 S3 객체의 metadata와 property를 수정 가능
    • S3 버킷 간 객체 복사
    • S3 버킷 내 암호화되지 않은 모든 객체를 암호화 가능
    • ACL, tag 수정
    • S3 Glacier의 객체 복원
    • Lambda 함수 호출해 S3 Batch Operation의 모든 객체에서 사용자 지정 작업 수행 가능
  • Job 작업
    • 객체 목록 ← S3 Inventory 기능 사용해 객체 목록 가져옴, S3 Select 기능 사용해 필터링한 결과
    • 수행할 작업
    • 매개변수
  • 재시도 관리, 진행 상황 추적, 작업 완료 알림, 보고서 생성 가능

S3 Storage Lens

AWS 조직에서 스토리지를 이해, 분석, 최적화하는데 도움이 되는 서비스

  • 이상 징후 발견, 비용 효율성 파악, 전체 AWS 조직에 보호 모범 사례 적용
  • 조직 / 특정 계정 / 지역 / 버킷 / prefix 별로 데이터 집계 가능
  • 기본 대시보드 확인 혹은 직접 제작 가능
    • 여러 계정과 여러 지역에 걸쳐 데이터가 있음
  • 모든 메트릭과 리포트를 CSV 또는 parquet 형식으로 export

Metric

  • Summary Metric
    • 일반적인 인사이트 제공
    • StorageBytes, ObjectCount
    • Fast-growing / Not-used bucket 이나 prefix 확인 등
  • Cost-Optimization Metric
    • 스토리지 비용 관리, 최적화하는 인사이트 제공
    • NonCurrentVersionStorageBytes, IncompleteMultipartUploadStoargeBytes
    • 불완전한 멀티파트 업로드된 버킷 확인, 비용 절감이 가능한 스토리지 클래스로의 전환 확인 등
  • Data-Protection Metric
    • 데이터 보호 기능에 대한 인사이트 제공
    • VersioningEnabledBucketCount, MFFADeleteEnabledBucketCount, SSEKMSEnabledBucketCount, CrossRegionReplicationRuleCount
    • 데이터 보호 모범 사례를 만족하지 않는 버킷 확인 등
  • Access-management Metric
    • 버킷 소유권에 대한 인사이트 제공
    • ObjectOwnershipBucketOwnerEnforcedBucketCount
    • 버킷이 현재 어떤 객체 소유권 설정을 사용하고 있는지 식별 등
  • Event Metric
    • 이벤트 알림에 대한 인사이트 제공
    • EventNotificationEnabledBucketCount
    • 이벤트 알림이 구성된 버킷의 수 식별 및 파악 등
  • Performance Metric
    • Transfer Acceleration 에 대한 인사이트 제공
    • TransferAccelerationEnabledBucketCount
    • 전송 가속 활성화된 버킷 수 확인 등
  • Activity Metric
    • 스토리지가 request되는 방법에 대한 인사이트 제공
    • AllRequests, GetRequests, PutRequests, ListRequests, BytesDownloaded
  • Detailed Status Code Metric
    • HTTP 상태 코드에 대한 인사이트 제공
    • 200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount
  • Free Metric : 모든 고객에게 자동으로 제공. 28개의 사용량 지표. 쿼리에 대한 데이터는 14일간 조회.
  • Paid Metric : 고급 지표 및 권장 사항 제공. CloudWatch 배포. 접두사 수준에서 메트릭 수집 가능. 쿼리에 대한 데이터는 15개월동안 조회.

S3 Object Encryption

  • Server-Side Encryption (SSE)
    • SSE-S3 : S3-managed 키를 사용
      • AWS가 처리하고 관리하며 소유한 키를 이용해 암호화
      • 그 키에 우리는 절대 접근 불가
      • AES-256 타입으로 암호화
      • 헤더 설정 “x-amz-server-side-encryption”:”AE256”
      • 새로운 버킷과 객체에 대해 기본값으로 활성화됨
    • SSE-KMS : KMS에 저장된 키를 사용
      • KMS를 사용해 키 관리 서비스를 이용해 직접 자신의 키를 관리함
      • KMS에서 키를 직접 생성하고, CloudTrail을 이용해 키 검사
        • CloudTrail : 누군가가 KMS에서 키를 사용할 때마다 AWS 안에서 일어나는 모든 걸 로깅하는 서비스
      • S3 버킷의 파일을 읽기 위해서는 객체 자체에 액세스할 수 있어야하고, KMS 키에도 접근할 수 있어야 함
      • KMS API 호출해서 접근하는데, 이 때 처리량이 많은 서비스의 경우 KMS API 자체 throughput에서 막혀 Throttling (쓰로틀링) 발생
        • GenerateDataKey : 업로드
        • Decrypt : 복호화
      • 헤더 설정 “x-amz-server-side-encryption”:”aws:kms”
    • SSE-C : Customer-Provided 키를 사용
      • 키가 AWS 외부에서 관리되지만, 여전히 서버 측 암호화임. 왜냐면 AWS 서버로 보내기 때문!
      • S3는 암호화키를 저장하지 않음
      • HTTPS 가 무조건 사용되어야 함
      • HTTPS 헤더에 암호화키가 제공되어야 하고, 사용자가 다시 그 파일을 읽으려면 역시 파일을 암호화한 키에 제공해야 함
  • Client-Side Encryption
    • Client-Side Encryption Library를 사용
    • 클라이언트가 직접 데이터를 암호화한 뒤 S3에 전송
    • 복호화도 S3 밖에서, 직접 해야 함
  • Encryption in transit (SSL/TLS)
    • 전송 중 암호화 / 통신 중 암호화
    • 2개의 엔드포인트
      • HTTP : 암호화되지 않음
      • HTTPS : 암호화됨
    • HTTPS로 보내도록 forcing할 수 있음. S3 버킷 정책으로 GetObject 작업 거부 (if condition = ‘aws:SecureTransport’ : ‘false’)

S3 CORS

교차 오리진 리소스 공유 : Cross-Origin Resource Sharing

Origin = scheme (protocol) + host (domain) + port

웹 브라우저 기반 보안 보안 메커니즘

→ 메인 오리진을 방문하는동안 다른 오리진에 대한 요청을 허용하거나 거부

⇒ 다른 오리진의 S3 버킷에 들어있는 이미지, 자산, 파일을 요청할 수 있게 함

오리진이

Access-Control-Allow-Origin : 웹에서 다른 웹으로 요청을 보낼 때, 다른 오리진이 CORS 헤더를 사용해 요청을 허용하지 않는 한 해당 요청은 이행되지 않음

CORS header를 정확하게 활성화해야 cross-origin request를 수행 가능

특정 오리진이나 전체 오리진 (*) 을 허용할 수 있음

  1. 웹브라우저가 index.html 파일이 들어있는 enable website가 되어있는 S3 Bucket (A) 에 GET 요청을 날려, html 파일을 받아옴
  2. index.html 파일에는 enable website가 되어있는 S3 Bucket(B) 에 담긴 coffee.jpg 가 필요해서, 다시 웹브라우저에서 coffee.jpg에 대한 Host (B) 와 Origin (A) 를 가지고 요청을 보내고, CORS가 활성화되어있을 경우 그 파일을 받을 수 있음

S3 MFA Delete 보안

MFA (Multi Factor Authentication) : 사용자가 장치에서 코드를 생성하도록 강제

버킷 버저닝한 뒤 사용 가능

버킷 소유자 (루트 계정)만이 MFA Delete를 enable / disable 할 수 있음

아래와 같은 상황에서 사용

  • 오브젝트 버전에 대한 영구 삭제
  • 버킷 버저닝 중단

아래와 같은 상황에서 사용 X

  • 삭제된 버전에 대한 리스트업
  • 버킷 버저닝 활성화

S3 Access Logs

감사를 목적으로 S3 Bucket에 대한 모든 로그를 저장

모든 계정이 S3로 보낸 모든 요청은 승인 또는 거부 여부와 상관없이 다른 S3 버킷 (같은 리전에 존재해야 함) 에 파일로 기록됨

주의할 점 : 모니터링 버킷과 로깅 버킷을 같은 버킷으로 설정하면 안됨 !!

S3 Pre-Signed URL

S3 Console, AWS CLI, SDK를 이용하여 pre-signed URL 생성 가능

URL 만료 기간

  • S3 Console : 1min ~ 720min (12hours)
  • AWS CLI : expires-in parameter 로 설정 : (max : 168hours)

pre-signed URL을 받는 사용자는 생성한 사용자의 GET, PUT에 대한 권한 상속

비공개 버킷의 특정 파일에 임시로 접근할 때 자주 사용

S3 Glacier Vault Lock

WORM 모델을 채택하기 위해 Glacier Vault를 잠그는 것

  • WORM : Write Once Read Many

객체를 Glacier Vault에 저장한 뒤, 수정하거나 삭제할 수 없도록 잠금

관리자나 AWS 서비스를 사용해도 삭제할 수 없음

규정 준수와 데이터 보존에 효과적임

S3 Object Lock : 버킷 수준의 잠금이 아닌, 객체 수준에 각각 잠금 적용 → 특정 객체 버전이 특정 시간동안 삭제되는걸 차단할 수 있음

  • 버킷의 버저닝 활성화, WORM 모델 채택
  • 모드
    • Retention mode - Compliance (규정 준수 모드) : 사용자를 포함한 그 누구도 객체 버전을 덮어쓰거나 삭제할 수 없음. 누구도 객체 변경 불가. Glacier Vault 와 비슷함. retention mode 바꿀 수 없고, 기간도 바꿀 수 없음
    • Retention mode - Governance (거버넌스 모드) : 대부분의 사용자는 객체 버전을 덮어쓰거나 삭제할 수 없으나, 관리자와 같이 특정 허용규칙이 있는 사용자는 retention mode 바꿀 수 있고, 기간도 바꿀 수 있음
  • Retention Period : 보존 기간 설정해, 고정된 기간동안 객체 보호.
  • Legal Hold : 법적 보존을 통해 S3 버킷 내 모든 객체를 영원히 보호. 대개 재판에서 사용될 수 있는 중요한 객체에 적용. 보존 모드나 기간에 관계 없이! s3:putObjectLegalHold IAM 정책을 적용받는 사용자만이 이를 설정하거나 삭제할 수 있음

S3 Access Point

S3 버킷에 보안 규칙을 적용하는 대신, 엔드포인트에 보안 규칙을 적용하여 팀별로 팀별 엔드포인트에 각각 접근 → 보안 관리 간소화

Endpoint

  • DNS 이름을 가짐.
    • Internet Origin
    • VPC Origin ← Private Traffic
      • private access 가 가능하도록 정의
      • VPC Endpoint는 VPC 안에 존재. VPC 오리진 (VPC 밖에 존재, S3 버킷에 대한 Access point) 을 통해 타깃 버킷에 private하게 접속.
      • ex. VPC의 EC2 인스턴스는 인터넷을 통하지 않고 VPC 액세스 포인트와 VPC 오리진을 통해 S3 버킷에 액세스할 수 있음
  • 액세스 포인트 정책 첨부

S3 Object Lambda

caller application에 의해 호출되기 전에 객체를 수정하고 싶을 때 사용

같은 데이터를 가진 버킷을 여러 개 만드는 대신, 버킷에 supporting Access Point를 만들고, 이에 lambda function 을 연결해서 버킷 내 객체에 대해 특정 수정 작업을 거친 결과를 보내줌. 보내는 곳은 각자 요청한 caller application의 access point.

ex. 식별정보 마스킹, 워터마크 추가 등등

'AWS 자격증 공부 > AWS SAA-C03' 카테고리의 다른 글

AWS SAA : Storage  (2) 2024.11.20
AWS SAA : CloudFront  (2) 2024.11.20
AWS SAA : Elastic Beanstalk  (2) 2024.11.19
AWS SAA : Route 53  (2) 2024.11.19
AWS SAA : RDS, Aurora, ElastiCache  (1) 2024.11.19