Storage Service
: 데이터 저장, 엑세스, 보호 및 분석 기능을 갖춘 Amazon의 서비스
-
Block Storage
• 데이터를 일정 크기의 블록으로 나누어 저장
• 각 블록은 독립적인 주소를 가지며 이를 통해 랜덤 엑세스 가능
• Storage Area Network(SAN): 고성능의 전용 네트워크. 서버와 데이터 스토리지 시스템을 연결
• 빠른 입출력(I/O) 속도가 필요한 데이터베이스에 적합
• 높은 IOPS(초당 입출력 작업 수)와 낮은 지연 시간이 중요한 경우에 선택
• 운영 체제 또는 중요한 애플리케이션을 실행하는 데 사용됨 -
File Storage
• 데이터를 파일로 저장, 파일들은 폴더나 디렉토리에 조직
• 계층적인 파일 시스템 구조를 가짐
• Network Attached Storage(NAS): 네트워크에 연결돼 여러 사용자와 장치가 파일 기반의 데이터에 접근할 수 있게 해주는 전용 파일 스토리지
• 여러 서버나 사용자가 동일한 파일 시스템에 동시에 액세스해야 할 때 적합
• 파일과 디렉토리를 통해 데이터를 관리하고 싶을 때 유용
• 네트워크를 통한 파일 공유가 필요한 경우에 적합
- Object Storage
• REST 기반의 API 호출을 통해 데이터에 접근
• HTTP 프로토콜
• 대용량 미디어 파일, 이미지, 백업 등을 저장할 때 적합
• 정적 웹 컨텐츠(예: 이미지, 비디오, HTML 페이지)를 호스팅할 때 유용
• 저렴한 비용으로 데이터를 오래 보관해야 할 때 선택
• 전 세계 여러 데이터 센터에 걸쳐 데이터를 분산시켜야 할 때 효과적
Amazon S3
usecase: 백업 및 스토리지, 재해 복구, 아카이브, 하이브리드 클라우드 스토리지, 애플리케이션 스토리지, 미디어 호스팅, 데이터 레이크 및 대규모 데이터 분석, 소프트웨어 배포, 정적 웹사이트 호스팅
특징
Access 제어
객체 별 ACL을 통해 데이터에 접근 가능한 사용자 특정이 가능
(ACL: Access Control List)
데이터 저장
데이터는 객체 단위로 저장
내구성
99.999999999%의 내구성
데이터 저장 용량
Standard의 경우 객체 하나의 크기는 최대 5TB까지
구성
Bucket
- S3에 객체를 저장하게 해주는 시스템
- AWS 전역에서 단 한개만 존재: 리전과 관계 없이 전역적으로 Unique한 이름이 필요
- 리전 수준에서 정의: 데이터 저장 위치와 관련된 법률 및 규정 준수에 영향
Object
- 객체는 보통 파일을 의미 (img, html,.. )
- 객체는 키를 가짐 (키는 파일의 전체 경로)
- 객체 최대 크기는 5TB
- 한번에 5GB이상 업로드 불가능
S3 Versioning
버킷의 버전 관리를 활성화하여 여러 버전의 객체 보관 가능
실수로 삭제되거나 덮어써진 객체 복원 가능
한번 활성화하면 비활성화 불가. 대신 중단 상태로 전환 가능
S3 Replication
- 버킷 내의 객체를 자동으로 다른 버킷으로 복사하는 기능. 비동기적
- CRR(Cross Region Replication) - 재해 복구, 사용자에게 더 빠른 액세스 제공, 규정 요구사항 충족을 위해
- SRR(Same Region Repplication) - 엑세스 제어, 실수로 인한 삭제 손상 방지, 효율적 데이터 관리
S3 Encryption - 정적암호화
서버 측 암호화(SSE)
-
SSE-S3 (Server-Side Encryption with Amazon S3- Managed Key) :
각 객체마다 고유한 키를 사용하고, 추가 보안을 위해 이 키를 다른 마스터 키로 정기적으로 암호화.
사용자는 키 관리에 대해 걱정할 필요 없이 S3 에 의해 자동으로 처리됨. (default)
-
SSE-KMS (Server-Side Encryption with AWS Key Management Service) :
사용자가 키의 사용을 제어하고 접근을 감사할 수 있음. 또한, 사용자 정의 키 관리 및 암호화 키의 로테이션을 지원.
KMS-api 사용하므로 KMS 제한 사항에 영향을 받을 수 있음
-
SSE-C (Server-Side Encryption with Customer- Provided Keys) :
데이터를 업로드하거나 다운로드할 때마다 사용자는 자신의 암호화 키를 제공해야 함. 이 방법은 키 관리의 책임이 사용자에게 있음.
AWS로 키를 보내기 때문에 서버측 암호화 HTTP 요청마다 키를 헤더 제공해야하고, HTTPS 사용 필수
클라이언트 측 암호화 (CSE)
- CSE (Client-Side Encryption)
클라이언트 측에서 암호화하고, 암호화 된 데이터를 s3에 저장
암호화 키와 암호화 프로세스는 전적으로 사용자 측에서 관리
이는 보안을 높이지만, 키 관리 및 암호화 구현의 복잡성이 증가
(Amazon S3 Client-Side Encryption Library와 같은 클라이언트 라이브러리 사용)
S3 Encryption - 동적암호화
- 전송 중 암호화는 SSL 또는 TLS라고 함
- Amazon S3는 두 개의 엔드포인트가 있음
- HTTP 엔드포인트: 암호화되지 않음
- HTTPS 엔드포인트: 전송 중 암호화 - HTTPS가 권장됨
- SSE-C의 경우 HTTPS 프로토콜을 꼭 사용해야 함 대부분의 클라이언트는 기본적으로 HTTPS 엔드포인트를 사용함
S3 Security
- IAM
- 버킷 정책
- 접근 제어 목록 ACL
S3 Hosting
S3 버킷에 있는 파일을 이용해 정적 웹사이트 호스팅 가능
S3 CORS
CORS
요청 프로토콜의 일부로 다른 웹사이트에 요청을 보내야할 때 다른 오리진이 CORS Headers를 사용해서 요청을 허용하지 않는한 해당 요청은 이행되지 않음 (ex. Access-Control-Allow-Origin)
S3 CORS
- 만약 클라이언트가 S3 버킷에서 교차 출처 요청 (cross-origin request)을 보내는 경우, 정확한 CORS 헤더를 활성화해야 한다
- CORS 헤더를 설정함으로써 특정 출처를 허용하거나 * (모든 출처)를 허용할 수 있음
S3 Pre-Signed URLS
- S3 콘솔, AWS CLI 또는 SDK를 사용하여 생성할 수 있는 URL
- 미리 서명된 URL을 받은 사용자는 GET / PUT에 대한 권한을 URL을 생성한 사용자로 부터 상속받음
S3 Classes
S3에는 다양한 클래스가 존재 -> 내구성은 동일하지만 가용성이 클래스마다 다름
S3 수명 주기 규칙
수명 주기 규칙은 크게 전환(Transition), 만료(Expiration) 작업으로 구성 (기간 설정도 가능)
Amazon CloudFront
CDN
Content Delivery Network
지리적 제약 없이 전세계 사용자에게 빠르고 안전하게 콘텐츠를 전송할 수 있는 기술 
Edge Location
사용자에게 더 가까운 지리적 위치에 콘텐츠를 저장하는 데이터 센터
(Cloudfront에는 300개 이상의 엣지 로케이션)
Cloudfront Edge Location
Regional Edge Caches (REC)
- 오리진과 엣지 로케이션 사이에 존재하는 캐시 계층
- 글로벌하게 배포되어있는 CloudFront 위치
- 리전 엣지 캐시는 표준 에지 로케이션에서 캐시하지 않는 콘텐츠를 저장
- 에지 로케이션에서 캐시 미스(cache miss)가 발생했을 때, 오리진 서버 대신 리전 엣지 캐시로부터 콘텐츠를 검색하여 더 빠른 응답 시간을 제공
Origin Shield (2020.10 릴리즈)
- 2020년 10월에 발표된 새로운 기능으로, CloudFront에서 캐싱 계층을 하나 더 추가하여 사용자(클라이언트)와 엣지 서버간의 거리를 줄이는 기능.
- 캐시 적중률을 높이고 오리진 서버의 부하를 줄여주어 로드 속도를 향상시키는 효과가 있다.
Amazon Cloudfront
- AWS에서 제공하는 CDN (글로벌) 서비스
- Client의 콘텐츠 요청으로 서버에서 받아온 콘텐츠를 캐싱하고 이후 같은 요청이 왔을 때, 그 캐싱해 둔 것을 제공하는 서비스
- 성능 향상, 데이터 전송 속도 빨라짐, 보안성 향상, 안정성 및 가용성 향상
- Origin에서 HTTPS를 지원하지 않아도, CloudFront 내에서 HTTPS 통신 지원 가능
- Shield, AWS Web Application Firewall을 제공함으로써 DDoS로부터 보호 제공
- S3와 연동 시 => 캐싱을 지원하기 때문에 s3에 저장된 컨텐츠를 직접 접근하지 않아도 되므로 s3의 비용이 감소하며, 더 빠른 응답 지원
Amazon Cloudfront 동작 순서
- 사용자가 어플리케이션에 요청을 한다.
- DNS는 사용자에게 적합한 Edge Location으로 라우팅 한다.
- Edge Location에서 캐시를 확인하고 있으면 이것을 사용자에게 반환한다.
- 없으면 가장 가까운 REC로 캐시가 있는지 요청한다.
- 없으면 CloudFront는 오리진으로 요청을 전달한다.
- 오리진은 '오리진 > REC > Edge Location > CloudFront가 사용자에게 전달' 수순을 밟는다. (캐시도 추가된다)
- REC에 캐시가 있다면 REC는 콘텐츠를 요청한 Edge Location으로 반환한다.
- REC로부터 콘텐츠의 첫 번째 바이트가 도착하는 즉시 Edge Location은 이를 사용자에게 반환한다.
- Edge Location은 나중을 위해 이 콘텐츠 캐시를 저장한다.
Amazon Cloudfront Origin
콘텐츠는 TTL 값 동안 Edge Location에 캐싱되어 낮은 지연시간으로 콘텐츠를 요청
- 정적 콘텐츠
서버(EC2)가 필요하지 않음 이미지 등 - 동적 콘텐츠
서버가 필요한 콘텐츠들 (로그인 자료, 실시간으로 새롭게 추가되는 게시판 등)
이를 정적 캐싱하면 사용자는 TTL 시간동안 새롭게 추가 or 수정된 데이터를 볼 수 없게됨
Amazon Cloudfront 캐시 정책
- 목적:
캐시 정책은 CloudFront가 콘텐츠를 얼마나 오랫동안 캐시할 것인지, 어떤 HTTP 헤더, 쿼리 문자열 및 쿠키를 캐시에 포함할 것인지를 결정.
- 구성 요소: 캐시 정책 설정은 TTL(Time-To-Live) 값, 캐시할 헤더, 쿼리 문자열, 쿠키 등을 포함할 수 있음.
Amazon Cloudfront OAI
OAI (Origin Access Identity):
CloudFront가 S3에 저장된 Private 객체에 액세스 할 수 있도록 하는 특별한 식별자
외부 사용자가 S3 Endpoint를 통한 직접적인 요청이 아닌 CF의 배포를 통해 접근하도록 구성하고 싶다면 OAI를 고려할 수 있음
S3 Origin 보안 강화를 위해 요청을 식별하는 데 사용되는 S3만을 위한 CloudFront 서비스 (S3의 ‘Principal’을 통해 참조)
Amazon Cloudfront OAC
Amazon Cloudfront 응답 헤더 정책
CloudFront가 사용자에게 콘텐츠를 전달할 때 HTTP 응답에 추가할 헤더를 정의하는 기능
- 보안 헤더 추가: 보안 관련 HTTP 헤더를 응답에 자동으로 추가가능
- 사용자 정의 헤더: 특정 사용자 정의 헤더를 추가하여 응답을 더 유용하게 만들 수 있음 (애플리케이션 버전, 캐시 상태 등)
- 캐싱 동작 제어: Cache-Control 헤더를 통해 캐시 서버와 브라우저가 콘텐츠를 캐싱하는 방식을 제어할 수 있음 - CORS(Cross-Origin Resource Sharing) 설정: 다른 도메인의 웹 페이지에서 리소스를 요청할 수 있도록 허용하는 Access-Control-Allow-Origin과 같은 CORS 관련 헤더를 설정 가능
- 성능 최적화: 성능과 관련된 헤더를 추가하여 브라우저의 렌더링 성능을 개선할 수 있음
(Vary 헤더를 사용하여 다양한 장치 유형에 따라 적절한 콘텐츠를 제공)
Amazon Cloudfront 보안 Access 구성 및 제한
Signed Url
개별 파일에 대한 access 제공 (파일 하나당 하나의 url) 만료시간, IP주소 범위 등 지정
ex. 쿠키 구운 구독자에게만 웹툰을 제공
Signed Cookie
다수의 파일에 대한 access 제공 (다수의 파일에 하나의 signed cookie)
만료시간, IP주소 범위 등 지정
ex. 로그인 한 유료회원에게 콘텐츠를 제공
Amazon Cloudfront Pricing
- 서버 Edge Location마다 데이터 전송 비용이 다름
- 다양한 Price Class 존재
Price Class All
Price Class 200
Price Class 100
