woongs dogfoot

AWS Snow Family

• AWS Snow Family : 보안성 있는 휴대기기 -> edge에서 데이터를 수집하고 처리하거나, 데이터를 AWS 안팎으로 마이그레이션

• Use cases

1. Data migration : 많은 양의 데이터를 제한없이 전송하기위한 경우 -> AWS에서 우편을 통해 물리적인 기기를 배송 -> 해당 기기에 데이터를 올리고 다시 AWS에 배송 (네트워크가 아닌 물리적 배송방식을 이용)
   • Snowcone
   • Snowball Edge
   • Snowmobile
2. Edge computing
   • Snowcone
   • Snowball Edge
     
     
     

• Snowball Edge

1. TBs or PBs 용량의 데이터를 AWS와 교환하기 위해 사용
2. 전송작업당 비용 지불
3. Storage Optimized : 80TB 하드디스크 용량 제공, block volume이나 S3 호환
4. Compute Optimized : 42TB 하드디스크 or 28TB NVMe 용량 제공
   
   
   

• Snowcone

1. 작은 휴대기기, 견고하고 안전
2. 열악한 환경에 강함
3. 가벼움, 드론탑재 가능
4. 8TB HDD or 14TB SSD 제공
5. 공간제약이 있는 경우 활용
6. 오프라인으로 데이터 전송 or 기기에 데이터를 담은 후에 인터넷을 통해 데이터센터에 연결 (AWS DataSync 서비스 사용, 사전 설치 되어있음)
   
   
   

• Snowmobile

1. 데이터를 옮기는 실제 트럭임
2. 1EB(1,000PB)급 데이터를 옮길 수 있음 (한 대당 100PB 가능, 1EB는 10대 필요)
3. 에어컨이 있어 온도조절 가능
4. 실시간 GPS 추적 및 비디오 감시

• Data migration을 위한 처리과정

1. AWS console에서 기기배송 요청
2. Snowball client or AWS OpsHub 설치
3. Snowball을 설치된 서버에 연결하고 파일복사 시작
4. 전자마커를 통해 목적지 AWS시설로 기기반송
5. S3 Bucket에 데이터 로딩
6. Snowball에서 데이터 완전삭제
   
   
   

• Edge Computing : Edge 위치에서 데이터를 생성하고 해당 데이터를 기기내 AWS인스턴스를 활용하여 처리한다음 AWS에 반송하는 case (Edge : 인터넷이 없거나 Cloud에서 멀리 떨어진 환경, ex. 도로 위 트럭, 바다 위 배, 지하광산 등) -> Snowball Edge, Snowcone 활용

1. 해당 Snowcone 기기들은 EC2 인스턴스와 Lambda Function 실행 가능 (AWS IoT Greengrass 서비스 활용)
2. 장기렌트 가능
   
   
   

• OpsHub : 컴퓨터에 설치하는 소프트웨어 -> Snow Device에 연결하고 설정할 수 있음, 파일전송 및 Snow Family의 인스턴스를 시작하고 관리 가능
  
  
  

• Snowball 데이터를 Glacier로 옮기는 방법

1. Snowball 데이터를 먼저 S3로 옮김
2. S3 lifecycle policy를 생성하여 object를 Glacier로 전환

Amazon FSx

• Amazon FSx : AWS에서 완전 관리해주는 서비스로 타사의 고성능 파일 시스템을 실행 (RDS에서 MySQL or Postgres를 실행하는 것과 동일개념)

• FSx for Windows File Server

1. SMB protocol과 Windows NTFS를 지원
2. 사용자 보안 추가, ACL로 Access 제어 가능
3. Linux EC2 인스턴스에도 Windows Fil Server 마운트 가능
4. DFS (Distributed File System)을 활용하여 File System 그룹화 가능 (온프레미스와 결합 가능)
5. 초당 수십GB, 수백만 IOPS, 수백PB 데이터 확장
6. SSD : 지연시간이 짧아야 하는 경우 (DB, 미디어 처리, 데이터 분석 등)
7. HDD : 비용이 저렴, 더 넓은 스펙트럼 (홈 디렉토리, CMS 등)
8. Private하게 온프레미스에서 접근 가능
9. Multi-AZ 가능
10. 재해복구 목적으로 S3에 매일 백업
    
    
    

• FSx for Lustre

1. Lustre (Linux + Cluster) : 분산 파일 시스템, 대량 처리 연산에 활용 (머신러닝, HPC 등)
2. 동영상처리나 금융모델링, 전자설계 자동화 등의 app에서 활용
3. 확장성이 높음
4. 초당 수백GB, 수백만 IOPS, ms보다 짧은 지연시간
5. SSD : 지연시간이 짧아야 하는 경우
6. HDD : 처리량이 많거나 크기가 큰 시퀀스 파일 작업에 활용하는 경우
7. FSx로 S3를 File System처럼 읽을 수 있음 (다시 연산 출력값을 S3에 쓸 수 있음)
8. VPN 및 직접 연결을 통해 온프레미스 서버에서 활용 가능
   
   
   

• FSx File System Deployment Options

1. Scratch File System
   • 임시 스토리지로 데이터 복제 x (파일 유실 가능성 있음)
   • High burst 사용 가능 (최적화로 성능을 높일 수 있다는 말, 200MBps per TiB)
   • 단기 처리데이터에 쓰임
   • 비용 최적화 가능
   • 추가 데이터 저장소로 S3 Bucket을 둘 수 있음
2. Persistence File System
   • 동일 AZ에 데이터복제됨
   • 민감 데이터의 장기 처리 및 Storage에 활용

• FSx for NetApp ONTAP

1. AWS 관리형 NetApp ONTAP File System
2. NFS, SMB, iSCSI Protocol 호환
3. 온프레미스의 ONTAP이나 NAS에서 실행중인 워크로드를 AWS로 옮길 수 있음
4. 스토리지는 자동으로 확장/축소됨
5. 복제 및 스냅샷 기능 제공
6. 저비용, 데이터 압축, 데이터 중복제거 가능
7. 지정시간 복제 기능 -> 신속한 복제 및 스테이징 File System 구축 가능
8. 호환 OS

• FSx for OpenZFS

1. AWS 관리형 OpenZFS File System
2. 여러 버전에서의 NFS Protocol과 호환 가능
3. ZFS에서 사용된 워크로드를 AWS로 옮길 때 사용
4. 최대 백만 IOPS, 지연시간은 0.5ms 이하
5. 스냅샷, 압축 기능 제공
6. 지정시간 동시 복제 기능 -> 새로운 워크로드 테스트 시에 유용
7. 호환 OS

AWS Storage Gateway

• AWS에서는 Hybrid Cloud 권장 (Hybrid Cloud : 일부는 AWS, 나머지는 온프레미스인 환경)

• Cloud Migration이 오래걸림

• 보안/규정 준수 요건이 있는 경우

• S3는 EFS/NFS와는 다른 Storage 기술 -> S3를 온프레미스에 연결하는 방법 고안 필요 -> AWS Storage Gateway 활용
  
  
  

• AWS Storage Cloud Native Options

• AWS Storage Gateway : 온프레미스 데이터와 클라우드 데이터 간의 다리역할
  
  
  

• Use cases

1. 재해복구 목적으로 온프레미스 데이터를 클라우드에 백업
2. 백업 및 복구 목적으로 Cloud Migration 및 Cloud간 Storage 확장 (Cloud엔 Cold Data, 온프레미스엔 Warm Data)
3. 파일 액세스 지연을 줄이기 위해 온프레미스 Cache 활용
   
   
   

• Storage Gateway Types

1. S3 File Gateway
2. FSx File Gateway
3. Volume Gateway
4. Tape Gateway
   
   
   

• S3 File Gateway

1. S3 class중 Glacier는 활용 불가
2. 온프레미스 app -> AWS S3 Bucket, 온프레미스에서는 NFS or SMB protocol을 활용하여 S3 File Gateway에 요청을 보냄
3. S3 File Gateway는 해당 요청을 받아 HTTPS요청으로 변환하여 S3 Bucket에 전달함
4. S3 Life Cycle Policy를 통해 Object를 Glacier로 저장 가능
5. S3 File Gateway를 통해 받은 데이터는 해당 Gateway에 캐싱됨
6. 각 File Gateway마다 IAM Role 생성 필요
7. SMB Protocol을 활용하는 경우, 사용자 인증을 위해 Gateway와 Active Directory를 통합해야 함 -> 사용자가 File Gateway에 접근할 때 인증처리 진행

• FSx File Gateway

1. Amazon FSx for Windows File Server에 Native Access 제공 -> 온프레미스에서의 접근 가능
2. 온프레미스에서 접근 가능함에도 불구하고 FSx File Gateway를 사용하는 이유는 캐싱기능 떄문
3. SMB, NTFS, Active Directory 호환 가능 -> 그룹 파일 공유나 온프레미스를 연결할 홈 디렉토리로 사용 가능

• Volume Gateway

1. iSCSI protocol 사용
2. Volume이 EBS snapshot으로 저장되어 필요에 따라 온프레미스에서 Volume을 복구할 수 있음
3. Cached volumes : 저지연 접근
4. Stored volumes : 전체 데이터가 온프레미스에 있고, 주기적으로 S3에 백업

• Tape Gateway

1. 물리적으로 Tape을 사용하는 백업 시스템이 있는 회사가 백업으로 Tape대신 Cloud에 데이터를 백업할 수 있도록 해줌
2. VTL (Virtual Tape Library)로 Amazon S3와 Glacier를 이용
3. 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업

• Hardware appliance

1. 온프레미스에 Gateway를 설치할 가상서버가 없는 경우에 활용 (Amazon.com에서 신청)
2. Hardware appliance를 Amazon에서 주문 후, 온프레미스에 물리적 설치 -> Gateway로 설정

• Summary

AWS Transfer Family

• AWS Transfer Family : FTP protocol로 S3 및 EFS에 데이터를 전송하려는 경우 사용
  
  
  

• Supported Protocols

1. AWS Transfer for FTP
2. AWS Transfer for FTPS
3. AWS Transfer for SFTP

DataSync

• DataSync : 데이터 동기화를 통한 대용량의 데이터를 한곳에서 다른 곳으로 옮김
  
  
  

• 온프레미스나 AWS의 다른 클라우드로 데이터를 옮길 수 있음

• 서버를 NFS, SMB, HDFS, others... 다른 프로토콜에 연결해야 함 -> 연결할 온프레미스나 다른 클라우드의 Agent가 필요

• 다른 Storage간 데이터 Migration도 가능 -> Agent 불필요

• 복제는 일정을 지정하여 주기적으로 실행

• 파일 권한과 메타데이터 저장기능이 있음 -> NFS POSIX 파일 시스템 및 SMB 권한 준수

• Agent 하나의 task가 초당 10Gb까지 사용 가능, 대역폭 제한 가능

• 네트워크 용량이 부족한 경우, Snowcone 장치 사용 가능 (DataSync Agent가 사전에 설치)

• NFS or SMB 서버에 연결하려면 DataSync Agent 설치 필요
  
  
  

• 동기화 가능 Storage list

1. Glacier를 포함한 모든 Storage Class의 S3
2. Amazon EFS
3. Amazon FSx
   
   
   

• SMB/NFS 프로토콜의 온프레미스 파일을 AWS로 동기화하는 예시

• 서로다른 AWS Storage 서비스간 동기화 예시

Storage 비교

CloudFront

• CloudFront : CDN (Content Delivery Network), 웹사이트의 컨텐츠들을 서로 다른 edge location에 캐싱하여 읽기 성능을 높임
  
  
  

• 특징

1. 전세계 216개의 edge location 활용
2. 컨텐츠가 여러 location에 분산되어 있어 DDoS(동시에 모든 서버가 공격받는 방식) 공격에서 보호받을 수 있음
   
   
   

• 미국의 사용자는 주변 edge location에 호주에 있는 S3 Object를 요청하면, edge location을 통해 호주의 S3 Bucket에 접근함 -> 그후 해당 컨텐츠는 edge location에 캐싱되어 다른 미국 사용자가 바로 받아올 수 있음
  
  
  

• Origin(AWS 인스턴스를 말하는 듯) 제공 방식

1. S3 Bucket으로 CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 설정 (CloudFront를 생성하면서 origin 선택) -> S3 Bucket에는 CloudFront만 접근할 수 있게 설정 -> OAC (Origin Access Control) 활용 (Legacy OAI (Origin Access Identity) 대체) -> CloudFront의 접근권한은 S3 Bucket 권한에 따름 -> CloudFront에서 OAC 활성화 후, CloudFront를 허용하는 S3 Bucket policy를 선택해주면 됨
2. Ingress : CloudFront를 통해 S3 Bucket으로 데이터를 보낼 수 있음
3. S3 Bucket 말고도 Load Balancer, EC2 등의 HTTP Origin을 제공받을 수 있음
   
   
   

• CloudFront 동작방식 : client가 Edge location에 get 요청을 보내면, edge location의 CloudFront는 해당 객체가 캐싱되어 있는지 먼저 확인 -> 캐싱되어 있지 않는 경우, 원본 origin으로 가서 객체를 가져옴 -> 가져온 객체는 캐싱됨

• Origin이 CloudFront에 의해 Object를 전달할 경우, 해당 origin은 OAS(Origin Access Control)에 의해 관리되고, S3 Bucket policy와 같은 개별 origin policy에 의해 접근을 제어

• CloudFront (정적 컨텐츠) vs S3 Cross Region Replication (동적 컨텐츠도 포함)

ALB or EC2 as an Origin

• EC2 : public EC2 필수, edge location의 public ip가 EC2에 접근할 수 있도록 Security Group을 설정해줘야 함

• ALB : private EC2 가능 (public ALB와 연결 가능), public ALB 필수, edge location의 public ip가 ALB에 접근할 수 있도록 Security Group을 설정해줘야 함

Geo Restriction

• Geo Restriction : 지역에 따라 Object 접근을 제한하는 기능 -> 접근이 가능한(Allow List) 또는 불가능한(Block List) 지역 list를 만드는 방식
  
  
  

• Use cases : 컨텐츠 저작권법으로 인한 제한이 필요할 때 등

• CloudFront의 Geographic restrictions에서 설정 가능
  
  
  

Pricing

• Edge Location마다 데이터 전송 비용이 상이
• Price Classes (global Edge location 수를 줄이는 방식으로 가격 절감)

1. Price Class All : 모든 region 대상
2. Price Class 200 : 가장 비싼 region을 제외한 대부분의 region 대상
3. Price Class 100 : 저렴한 region 100개만 대상

Cache Invalidations (무효화)

• Cache Invalidations : 전체 또는 일부의 cache를 새로고침하여 캐시의 TTL을 모두 삭제하는 기능 (특정 Object 대상 전달 필요)
• CloudFront는 백엔드의 업데이트 사항을 인지하지 못함 -> TTL로 캐시가 만료되기 전까진 백엔드의 업데이트 사항을 못받음 -> Cache Invalidations 활용

Global Accelerator

• 문제 상황

1. global application을 global 사용자들이 접근함
2. application은 하나의 region에만 배포되어 있음
3. 하나의 region에만 있기 때문에 전세계 사용자가 해당 ALB로 public internet을 통해 접근하게 되면 상당한 지연시간 발생
4. public internet으로 인한 지연시간을 최소화하기 위해 AWS Network 활용 필요 -> Global Accelerator 활용

• Unicast vs Anycast

1. Unicast : 하나의 client 한 개의 Server IP일 때, 해당 IP로 접근하게 되면 해당 Server로 접근
2. Anycast : 하나의 client 한 개의 Server IP이고, 여러 서버가 한 개의 Server IP를 공유할 때, client가 해당 ip로 접근하게 되면 동일 ip를 공유하는 다수의 Server중 client로부터 가장 가까운 서버로 접근하게 됨 -> Global Accelerator의 원리
   
   
   

• Global Accelerator

1. 두 개의 고정 ip 제공 -> 보안성 확보
2. 두 개의 고정 ip에 요청 시, Anycast원리대로 edge location을 통해 AWS 네트워크를 거쳐 application에 요청이 전달됨
3. Elastic IP, EC2, ALB, NLB가 활용됨
4. 아무것도 Caching하지 않음
5. HTTP가 아닌 서비스에 유용

• Health Checks

1. Global Accelerator가 application에 대한 Health Check 진행
2. 특정 Region의 ALB에 대한 Health check에 실패하면, Global Accelerator의 정상 endpoint로 자동화된 장애조치 진행
   
   
   

• Global Accelerator vs CloudFront

• 실습 -> 생성된 Global Accelerator의 Listener로 테스트 시, 현재 위치와 가까운 Region의 Endpoint로 redirect 됨 (Global Accelerator의 Listener로 요청 -> 가장 가까운 edge location -> edge location에서 가까운 endpoint로 routing -> 해당 endpoint의 application에 접근)

1. Global Accelerator 생성
2. Listener 설정 (포트/TCP/UDP 등)
3. Listener를 통해 접근할 Endpoint group 설정 (Endpoint group은 Target application이 있는 Region)
4. Endpoint group의 Endpoint 설정(target application), Endpoint type은 ALB/NLB/EC2/Elastic IP 중 택 1

Object Encryption

• 암호화 종류

1. SSE (Server-Side Encryption)
   • SSE-S3 : Amazon S3에서 관리하는 키를 이용 (default)
   • SSE-KMS : KMS 키를 이용하여 암호화 키 관리
   • SSE-C : 고객이 제공한 키 사용 (client에서 키 제공)
2. CSE (Client-Side Encyption) : 클라이언트 측의 모든 걸 암호화한 다음에 S3에 업로드
   
   
   

• SSE-S3

1. AWS가 처리/관리/소유하는 키를 이용 (사용자가 접근할 수 없음)
2. Encryption Type : AES-256
3. request header에 "x-amz-server-side-encryption":"AES256" 설정 필요

• SSE-KMS

1. KMS (키 관리 서비스)를 이용해서 client가 자신의 키를 직접 관리 -> 사용자가 통제 가능 -> KMS에서 신규 키 생성 가능
2. CloudTail (AWS 로깅 서비스) 이용하여 키 사용을 검사할 수 있음
3. request header에 "x-amz-server-side-encryption":"aws:kms" 설정 필요

• SSE-KMS 제한사항
  • S3에 KMS키 활용 암호화된 Object를 업로드하고 다운로드하기 때문에 사용자가 직접 KMS키를 사용해야 함
  • 복호화 : KMS 키의 자체 API인 GenerateDataKey를 활용하여 Object를 복호화 함
  • 복호화 시, KMS API 호출 건은 초당 API 호출에 합산됨 (region마다 다르지만 초당 API 호출에 제한이 있음) -> 쓰로틀링 발생 가능성 있음

• SSE-C

1. 외부에서 관리되는 키 사용 (client가 서버로 해당 키 전송)
2. AWS에서는 해당 키를 저장하지 않음
3. 반드시 HTTPS를 이용하여 요청해야 함

• CSE (Client-Side Encryption)

1. 클라이언트가 직접 데이터를 암호화한 다음에 Amazon S3에 전송하는 방식 (복호화도 마찬가지)
2. 클라이언트측 암호화 라이브러리를 활용한다면 쉽게 구현 가능

• SSL/TLS (전송 중 암호화)

1. S3에는 HTTP/HTTPS 두 개의 endpoint 존재 (HTTPS endpoint에서 전송 중 암호화 제공)
2. HTTPS 권장
3. 강제화 방법 : Bucket 정책 활용
   • Bucket Policies를 활용하여 암호화를 강제하고 올바른 암호화 헤더가 없는 경우에는 S3 API호출을 거절할 수도 있음

CORS

• CORS : Cross-Origin Resource Sharing, 웹 브라우저 기반 보안 메커니즘
  
  
  

• 작동 원리

1. origin : scheme (protocol) + host (domain) + port (ex. https://www.example.com)
2. 메인 origin에서 다른 origin에 대한 요청을 허용하거나 거부
   • same origin : http://example.com/app1 = http://example.com/app2
   • defferent origin : http://www.example.com != http://other.example.com
3. 웹 브라우저가 main origin에 접속한 상태에서 다른 origin으로 요청해야하는 상황일 때, 다른 origin에서 CORS헤더(Access-Control-Allow-Origin) 허용을 하지 않는 이상 요청이 전달되지 않음 (ex. 웹 브라우저가 front 서버에 접속한 상태에서 back 서버에 요청을 보내야 할 때, front서버 origin != back서버 origin)
   
   
   

• 예제

1. 웹 브라우저가 https://www.example.co(main origin)에 요청하여 index.html을 받아옴
2. 받아온 index.html에서 https://www.other.com(cross origin)에 file을 요청
3. cross origin에 main origin 값을 실어 사전요청을 보냄
4. cross origin에서 CORS를 허용했다면, main origin으로부터 GET/PUT/DELETE 호출을 허용
5. 웹 브라우저에서 cross origin에 파일을 요청하여 받아옴

• S3에 적용한다면, S3는 cross origin으로서 CORS 허용 필요 (permissions - CORS 에서 JSON 형식으로 설정 가능)

MFA Delete

• MFA Delete : S3상에서 중요한 작업을 진행할 때, 특정 Device(ex. Google Authenticator, MFA Hardware Device 등)에서 생성한 코드를 통한 인증을 강제화 하는 것
  
  
  

• object의 특정 version을 삭제하거나, versioning 옵션을 중단할 때 두 가지 경우에 주로 사용됨

• MFA 활용을 위해서 Bucket Versioning을 활성화해야 함

• Bucket소유자(root 계정)만 활성화할 수 있음

• MFA Delete 활성화는 CLI를 통해서 가능

• MFA Delete가 활성화된 상태에서 객체 버전 삭제를 할 경우, CLI를 통해서 MFA Delete를 비활성화한 후에 삭제 진행해야 함
  
  
  

S3 Access Logs

• S3 Access Logs : S3 Bucket에 접근한 모든 case는 다른 S3 Bucket에 log로 저장
  
  
  

• Amazon Athena와 같은 데이터 분석 도구로 분석 가능

• logging bucket은 같은 region내에 있어야 함 -> 같은 region내에 Bucket 생성 후 logging되도록 설정하면 됨

• properties -> Server access logging 설정 -> Enable -> log가 저장될 bucket 선택 -> bucket 정책 자동 현행화
  
  
  

• 주의사항 : 로깅 버킷과 모니터링 버킷을 동일하게 설정x -> 로깅 loop가 생성되어 로깅이 무한반복됨

Pre-Signed URLs

• Pre-Signed URLs : URL에 private bucket의 특정 object에 public하게 접근할 수 있는 권한을 부여 -> URL을 받는 사용자는 생성한 사용자에게 GET/PUT권한을 상속받음 -> 외부의 사용자에게 특정 Object에 대한 권한을 부여해야할 때 사용
  
  
  

• Console, CLI, SDK에서 생성 가능

• Object actions -> share with presigned URL

• 만료시간

1. Console : 최대 12시간
2. CLI : 최대 168시간

• use cases

1. 로그인한 유저에게만 파일을 다운로드할 수 있게끔 함
2. 사용자 list가 계속 변하는 경우, url을 동적으로 생성하여 권한 부여 지속
3. 일시적으로 외부 사용자가 bukcet에 접근해야할 경우

Glacier Vault Lock

• Glacier Vault Lock : Worm(Write Once Read Many) 모델 적용을 위해 활용, 한번 Glacier Vault에 Object를 넣으면 수정/삭제가 불가하도록 lock을 걸어버림 (관리자나 그 누구도 삭제를 못함) -> 규정준수나 데이터 보존에 유용
  
  
  

• Glacier에 Vault lock policy 설정 -> 더이상 정책을 변경할 수 없도록 해당 정책을 lock
  
  
  

S3 Object Lock

• 특징

1. Bucket 전체 대상의 lock이 아닌 Bucket 내 Object에 개별적으로 lock 가능
2. 특정 Object의 특정 version이 특정 시간동안 삭제되는 것을 막을 수 있음
3. Object Lock 활성화를 위해서 Versioning 활성화 필요
4. Worm(Write Once Read Many) 모델 적용
5. 법적 보존 모드 설정을 통해 모든 Object를 무기한으로 보존 가능 -> s3:PutObjectLegalHold IAM 권한을 가진 사용자는 법적 보존 모드 설정 및 삭제 가능
   
   
   

• Retention mode

1. Compliance mode
   • Glacier Vault Lock과 유사
   • 사용자 그 누구도 수정/삭제 불가
   • Retention mode도 변경 불가
2. Governance mode
   • 좀 더 유연성이 필요할 때 사용
   • 대부분의 사용자가 수정/삭제 불가
   • IAM을 통해 권한을 부여받은 사용자는 Object의 보존기간을 변경하거나 바로 삭제할 수 있음

• 두 가지 모드 모두 Object 보존기간 설정 필요
  
  
  

S3 Access Points

• 사용자와 데이터가 많아질 수록 Bucket 정책 등 관리가 까다로워짐 -> Access Points 활용 -> S3 Bucket에 접근하기 위한 다양한 방법 정의

• 특정 S3 Bucket prefix에 대한 Access Points를 생성하고, 해당 point에 prefix에 맞는 Bucket policy 설정 (용도에 따라 단일 Access points에 다수의 prefix를 연결하는 policy 설정 등 가능)
  
  
  

• 특징

1. 각 Access Points는 각각 특정 DNS를 가짐
2. Access Point는 public 인터넷이나 private VPC에 연결될 수 있음

• private VPC -> S3 Access point : VPC에 endpoint를 생성하면 VPC 내부의 EC2 인스턴스는 해당 endpoint에 정의되어 있는 VPC policy에 맞게 S3 Access point로 접근하게 되고, 해당 Access point의 정책에 맞게 Bucket내 데이터에 접근할 수 있게된다. -> 결론적으로 VPC endpoint policy, S3 Access point policy, Bucket policy 세 가지 보안 정책 설정이 필요함

S3 Object Lambda

• S3 Object Lambda : S3 Bucket에 호출하여 Object를 받기 전에 해당 Object를 수정하려는 경우에 사용
  
  
  

• 특징

1. S3 Access point 사용 필요
2. S3 Bucket 외의 Access point를 생성하여 Lambda function에 연결될 수 있도록 설정 -> S3 Lambda Access point를 생성하여 특정 application으로 Lambda의 처리 결과본 전달 -> 결과적으로 특정 application은 Lambda access point를 통해 Lambda를 호출하여 S3 Access point를 통해 S3 객체를 가져오고, 해당 객체를 Lambda function이 수정하여 다시 Lambda access point를 통해 application으로 전달
3. Object 수정본을 위한 Bucket을 생성하여 별도의 버전을 관리할 필요 없음

Moving between Storage Classes

• 수동으로 Object의 Storage Class를 옮길 수 있지만, LifeCycle Rules에 의해 자동으로도 옮겨질 수 있음

LifeCycle Rules

• Transition Actions : 다른 Storage class로 이전하기 위한 Object 설정 (ex. 생성 60일 후에 Standard class로 이동)

• Expiration Actions : 객체 삭제를 위한 Object 설정 (ex. 일정 만료기간이 지나면 Object 삭제, 특정 버전 삭제, 로그 삭제, 불완전한 객체 삭제 등)

• 특정 경로나 Tag로 Object를 제한할 수 있음 (tag ex. 특정 부서의 object 등)
  
  
  

• Scenario 1

• Scenario 2

• Storage Class Analysis : 매일 S3 Bucket의 상태를 확인하여 Storage class 추천 및 통계를 담은 report를 생성
  • Standard 및 Standard IA는 호환되지 않음
  • report 확인까지 24~48시간 소요될 수 있음
  • report를 통해 합리적인 lifecycle rules를 설정할 수 있음

Requester Pays

• As-Is : S3 Bucket 소유자가 스토리지 및 데이터 전송에 대한 비용 모두 지불
• To-Be (Requester Pays) : S3 Bucket 소유자는 스토리지 비용을, 데이터 요청자가 데이터 전송 비용을 지불 -> 데이터를 다른 사용자 계정과 공유할 때 유용 (요청자가 익명이면 안됨, AWS 인증 필요)

Event Notifications

• Event : 객체 생성/삭제/복구, 복제 등과 같은 작업 (ex. S3 자체적 자동으로 image 썸네일 생성 등)

• Event Notifications는 filtering이 가능 (ex. *.jpg object의 이벤트만 알림으로 받고 싶다 등)

• Event Notifications의 대상은 설정 가능 (ex. SNS, SQS, Lambda Function 등)

• 알림은 몇 초면 전송되나 간혹 몇 분이 걸리는 경우도 있음

• properties - Event Notifications 에서 설정 가능
  
  
  

• IAM Permissions : 알림을 전송하기 위해 IAM 권한(SNS, SQS 등)이 있어야 함 -> S3 IAM Role을 사용하는 것이 아닌 Target Resource Policy에 정의함 -> 우리와 같은 사용자가 S3 Bucket에 접근할 때, S3 Bucket 정책에 기반하는 것과 비슷하다고 보면 됨 -> 보통 target이 policy 설정

• ex) S3 Event Notification을 SNS 토픽에 전송하기 위해 SNS Resource Policy를 할당해야 함 (SNS 토픽에 첨부하는 IAM Policy)

• Amazon EventBridge : S3의 모든 event Notification이 EventBridge로 전송됨 -> EventBridge에 설정된 규칙을 기반으로 다른 AWS 서비스에 Event 전송 -> 직접 Event Notification를 전송하는 것보다 다양한 filtering 옵션 등과 같은 기능을 활용할 수 있음

S3 Performance

• Amazon S3는 요청이 많으면 자동으로 확장됨 (지연시간 : 100~200ms)

• Amazon S3는 prefix 및 초당 3500개의 PUT/COPY/POST/DELETE 요청과 5500개의 GET/HEAD 요청을 지원 -> 고성능

• prefix 수에 제한이 없음 (prefix는 object의 path라 보면 됨) -> 4개의 prefix에 요청을 분산하면 초당 22000개의 GET/HEAD요청 처리 가능
  
  
  

• 최적화 방법

1. Multi-Part upload : 100MB넘는 파일 권장, 5GB넘는 파일은 필수 -> upload 병렬화 -> 전송속도 증가
2. Transfer Acceleration : 파일을 AWS 엣지 로케이션으로 전송, 데이터를 target region의 Bucket에 저장 -> 빠른 AWS 네트워크 활용을 통해 전송속도 증가
   • Multi-Part upload와 동시 사용 가능

3. Byte-Range Fetchs
   • 파일의 특정 바이트 범위를 가져와 GET 요청 병렬화 -> 실패의 경우 재시도 (복원력 높음) -> 다운로드 속도 증가
   • 파일의 첫 50바이트가 헤더라는 등 파일의 정보를 안다면, 파일에 대한 바이트 요청 범위를 설정할 수 있음

Select

• 파일 검색 시, 검색 후 필터링 하면 불필요하게 많은 데이터를 검색하게 됨 -> Select 기능 사용
• Select : SQL을 활용한 서버측 필터링 기능 -> 필요한 데이터만 필터링하여 조회 가능
• 데이터 검색 및 필터링에 드는 CPU 비용 절약 가능
• 적은 양의 데이터 전송에 따른 데이터 전송 속도 증가
  
  
  

S3 Batch Operations

• S3 Batch Operations : 단일 요청으로 S3 Object에서 대량 작업 수행
  
  
  

• Use cases

  1. 한 번에 많은 S3 Object의 메타데이터와 property 수정 가능
  2. S3 Bucket간 Object 복제 가능
  3. 암호화되지 않은 모든 Object를 암호화
  4. ACL(권한), tag 수정
  5. S3 Glacier에서 많은 object 복구
  6. Lambda 함수를 호출하여 S3 Batch Operations의 모든 객체에서 사용자 지정 작업 수행
     
     
     

• 파라미터 : 객체 list, 수행할 작업 -> 객체 list는 S3 Inventory 기능을 활용하여 가져옴

• S3 Inventory : S3 Select를 활용하여 적절히 객체를 filtering하여 전달해줌

• Why? Batch Operations
  1. retry 관리 가능
  2. 진행상황 추적 및 작업완료 알림 가능
  3. 보고서 생성 가능
     
     
     

S3 Storage Lens

• Storage Lens : 스토리지 이해/분석/최적화 하는 데 도움이 되는 서비스 -> 이상징후, 비용효율성 등 감지하여 전체 AWS조직을 보호 (30일 사용량 및 활용 메트릭 제공)

• 데이터 수집 범위

  1. AWS 조직
  2. AWS 특정 계정
  3. regions
  4. buckets
  5. prefixs
     
     
     

• 특징

1. Custom Dashboard 제작 가능
2. csv or parquet 형식으로 사용량과 메트릭에 관한 report를 S3 Bucket을 통해 받아볼 수 있음
3. use cases
   1. 가장 빠르게 성장하거나 사용하지 않는 bucket이나 prefix 식별 (storage 관점)
   2. multi-part 업로드에 실패한 객체가 있는 bucket이 무엇인지? (storage 관점)
   3. 어떤 object를 더 저렴한 storage class로 옮길 수 있는지? (비용 관점)
   4. 데이터 보호 사례를 따르지 않는 bucket 식별 (데이터 보호 관점)
   5. Bucket이 어떤 object에 대한 소유권 설정을 하고있는지? (Bucket 소유권 관점)

• Defualt Dashboard

1. 무료 및 고급 지표에 대한 요약된 인사이트와 트렌드 확인 가능
2. Multi-Region, Multi-Account의 모든 데이터 확인 가능
3. Amazon S3에 의해 사전 구성
4. 삭제는 불가하지만 비활성화는 가능

• Metrics

1. Summary Metrics : S3 Storage에 관한 insight
   • StorageBytes : Storage 및 Object의 크기를 파악 (모든 버전 포함 -> 실제로 차지하는 용량, 불완전한 multi-part object도 포함)
   • ObjectCount : Storage의 Object 수 파악
2. Cost-Optimization Metrics : 비용에 관한 insight
   • NonCurrentVersionStorageBytes, IncompleteMultipartUploadStorageBytes, etc...
3. Data-Protection Metrics : 데이터 보호에 관한 insight
   • VersioningEnableBucketCount : 버전관리 활성화 Bucket 수
   • MFADeleteEnableBucketCount, SSEKMSEnableBucketCount, CrossRegionReplicationRuleCount, etc...
4. Access-management Metrics : S3 Bucket 소유권에 관한 insight
   • ObjectOwnershipBucketOwnerEnforcedBucketCount, etc...
5. Event Metrics : S3 Event Notifications에 관한 insight
   • EventNotificationEnabledBucketCount : Event Notification이 구성된 Bucket의 수
6. Performance Metrics : Transfer Acceleration에 관한 insight
   • TransferAccelerationEnabledBucketCount : Transfer Acceleration이 활성화된 Bucket의 수
7. Activity Metircs
   • AllRequests, GetRequests, PutRequests, ListRequests, BytesDownloaded, etc...
8. Detailed Status Code Metrics : HTTP 상태 코드에 관한 insight
   • 200OKStatusCount, 403ForbiddenErrorCount, 404NotFoundErrorCount, etc...
     
     
     

• 무료 metric vs 유료 metric