S3 & Cloudfront

Cloud Storage

를 통해서 사용자는 데이터와 파일을 인터넷에 저장하고 엑세스할 수 있다. 

이를 통해, 비용을 효율적으로 사용/민첩성 향상/더 빠른 배포/ 효율적 데이터 관리를 할 수 있다. 

 

종류는 Block storage, File storage, Object storage가 있다. 

 

1.Block storage

데이터를 블록 형태로 저장하여 빠른 검색 및 저장을 위해서 블록에 고유한 식별자를 부여하여 지연시간이 짧다.

종류로는 DAN, SAN, Amazon EBS가 있다. 

 

 

2. File storage

데이터를 파일 및 폴더의 계층 구조로 저장하며, 어플리케이션에 가장 널리 사용된다. 

네트워크 환경에서의 해당 storage는 NAS기술을 사용하며, 로컬디스크와 유사한 방식으로 엑세스한다.

종류로는 Amazon EFS가 있다. 

 

 

3. Object storage 

대용량 미디어, 이미지, 백업 등의 비정형 데이터를 저장하며, 전송된 형식 그대로 객체 데이터에 저장한다. 

객체는 보안 버킷이라는 저장공간에 저장되며, HTTP 프로토콜 기반 REST API호출을 통해 접근한다. 

이를 통해, 정적 웹서비스(이미지, HTML, 비디오)등을 호스팅하거나, 전 세계 여러 데이터센터에 데이터를 분산시켜 저장하기도 한다. 또한, 저렴하게 데이터를 오래 보관할 수 있다. 

종류로는 Amazon S3가 있다. 

 

 

Amazon S3

데이터를 버킷 내 객체로 저장하는 object storage 서비스이며, 확장성, 데이터 보호, 비율 효율성을 보장한다. 

특징

■  엑세스 제어

객체별 ACL(access control list)를 통해 접근 가능한 사용자 관리

■  높은 내구성 및 객제 단위 데이터 저장

 

 

구성

Amazon S3는 버킷과 객체로 구성되어있는데

버킷은 S3에 저장된 객체에 대한 컨테이너로 최상위 root개념이며,

하나의 버킷에는 무한의 객체를 넣을 수 있으나, 한 계정당 버킷은 100개가 최대다. 

 

객체는 S3 버킷에 저장되는 기본 개체로,

객체데이터(byte sequence)-메타데이터(이름-값 set)가 name-value집합으로 구성되어있다.

■ 키

버킷 내 겍체에 대한 고유한 식별자

■  버전 ID

버킷에 객체 추가시, S3가 생성하는 문자열

키 + 버전ID을 통해 버킷에서 객체를 고유하게 식별하며, 버킷+키+버전ID를 통해 모든 객체는 식별

■ 태그

저장된 객체를 분류

■ 엑세스 제어 정보

저장하는 객체에 대한 엑세스를 제어

https://ex-bucket.s3.us-west-2.amazonaws.com/photos/hungry.jpg
// 버킷 - 리젼 - 객체 키로 접근

 

 

보안 - 데이터 암호화

■ SSE 서버 사이드 암호화

AWS 데이터 센터에서 객체 데이터 암호화 후, 사용자 접근 시 암호를 해독하여 반환해준다. 

현재 기본적으로 서버측 암호화(SSE-S3)를 기본 수준으로 적용

 

■ CSE 클라이언트 사이드 암호화

전송 시, 보안을 보장하기 위해 로컬에서 데이터 암호화 (AWS 포함 제 3자 노출 방지)

S3 암호화 클라이언트를 사용하여 객체를 암호화하고 버킷에 업로드를 하여 보안성은 높으나, 구현/관리가 복잡

 

 

보안 - 엑세스 제어 

■  리소스 기반 정책

리소스에 접근위한 필요 권한 정의한 정책 문서

→ S3버킷 자체와 같은 리소스에 붙는 정책

 

■  사용자 기반 정책

IAM 사용자(그룹, 역할)이 무슨 작업을 어느 리소스/조건에서 수행할 수 있는 지를 제어하는 정책

→ 대상자 사용자에 붙는 정책

 

- 관리형 정책 : 다수 사용자/그룹/역할에 정책 연결

- 인라인 정책 : 단일 사용자/그룹/역할에 1:1 연결

 

■  CORS (Cross-Origin Resource Sharing)

다른 도메인에서 요청한 S3 버킷의 리소스에 접근할 수 있도록 허용하는 정책

브라우저의 preflight요청을 받으면, 버킷의 CORS 정책을 바탕으로 허용

→ example.com에서 내 S3버킷의 이미지를 표시할 수 있도록 허용

 

■ pre-signed URLS

미리 서명된 URL(일회성)을 사용하면, 버킷 정책업데이트없이 S3 객체 엑세스 가능

→ 이 URL을 가진 사람은 일시적인 시간동안 S3 파일 다운로드 가능

 

 

관리

버전복원가능(기본), 객체 복제를 통한 백업

버킷의 다양한 storage클래스가 정의 (각 클래스가 제공하는 가진 접근 시간/기간/비용 등의 특징이 상이)

 

 

CDN

■ CDN(content delivery network)

웹사이트의 원래 서버 A가 아닌, 더 가까이에 있는 서버로부터 컨텐츠를 배포 →  사용자는 더 가까이에서 사용가능

 

■  Edge location

사용자에게 더 지리적으로 가까운 콘텐츠를 저장하는 데이터 센터로, 콘텐츠가 캐싱되어 제공

 

■ REC(regional edge caches)

Origin과 Edge 사이에 존재하는 캐시 계층으로, 

표준 Edge location에서 캐시하지 않는 데이터를 저장하거나, edge에서 캐시미스가 났을 떄 대신 콘텐츠를 제공해준다.

 

Cloudfront

Amzon이 제공하는 CDN 서비스로, edge location 데이터센터를 통해서

서버에서 받아온 콘텐츠를 캐싱하고 이후 같은 요청이 왔을 때, 그 캐싱해 둔 것을 제공한다. 

 

cloudfront 를 사용해야 edge location을 사용할 수 있으며, 기본적으로 Ec2나 s3를 배포한다고 생성되는 것은 아니다.

이를 통해서 공격벡터가 더 많아진다고 생각할 수 있지만, 리소스의 앞단에서 접속을 제어하기에 보안 필터 역할을 해줄 수 있고 다양한 보안 서비스를 제공하기에 더 안전하고 효율적으로 자원을 사용할 수 있다. 

 

기능

■ HTTPS 지원 (origin에서 지원을 하지 않아도 내부에서 https통신이 가능하도록 구성)

■ 특정 지역 컨텐츠 접근 제한 가능

■ signed url 기능 제공

개별 파일에 대한 access(파일 하나당 하나의 url)를 제공하며, 만료시간/IP 주소 범위 등을 지정할 수 있다.

→ 쿠키를 구운 독자만 웹툰을 미리 볼 수 있도록 URL을 제공

■ signed cookie

다수 파일에 대한 access 제공 (다수파일에 하나의 signed cookie)

→ ID/PW를 입력해 로그인 한 유료 회원에게 유료 콘텐츠를 모두 제공하는 상황

 

 

동작 흐름

사용자가 어플리케이션 요청 → DNS는 edge location으로 라우팅 → Edge location에서 캐시 확인 및 반환

(edge에 없는 경우) →  가까운 REC으로 캐시 확인 및 반환

(REC에 없는 경우) →  origin 서버로 요청 →  캐시 추가하며 반환 (origin →  REC →  Edge →  Cloudfront →  사용자) 

 

 

Cloudfront Origin

원본 서버로, 정적/동적 모두 처리가능

■ 정적 콘텐츠	■ 동적 컨텐츠
EC2가 필요없는 컨텐츠	EC2, ELB 등의  서버가 필요한 콘텐츠
S3 bucket	동적 컨텐츠를 정적 캐싱 시, TTL 동안 사용자는 새로 추가된 데이터를 볼 수 없다

 

 

OAI (origin access identity)

S3 전용 기능으로

OAI 사용 시, 허용된 인가자에 대해서만 cloudfront 를 통해서 S3에 접근이 가능하며, S3를 URL을 통해 접근 하는 것을 차단한다. 

■ 적용

Cloudfront 배포 시, OAI 생성 및 선택 >> 해당 OAI를 통해 S3 버킷 정책 업데이트

 

 

OAC (origin access control)

지정된 배포에만 접근을 허용함으로써 S3 오리진을 보호한다. (S3뿐만 아니라 다른 origin도 지원!)

OAI에 비해 더 세밀한 제어가 가능하다.