Amazon CloudFront 알아보기

Amazon CloudFront 기초

Amazon CloudFront는 개발자 친화적 환경에서 짧은 지연 시간과 빠른 전송 속도로 데이터, 동영상, 애플리케이션 및 API를 전 세계 고객에게 안전하게 전송하는 고속 콘텐츠 전송 네트워크(CDN) 서비스이다.

 

웹페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱한 후 해당 컨텐츠에 대한 요청이 들어오면 캐싱해둔 컨텐츠를 제공한다.

컨텐츠를 제공하는 서버와 실제 요청 지점간의 지리적 거리가 매우 먼 경우, 요청 지점 근처의 CDN을 통해 빠르게 컨텐츠를 제공할 수 있다.

엣지 로케이션에서 데이터를 캐싱하기 때문에 원본이 변해도 캐싱이 만료되지 않는다면 유저가 보는 내용은 변하지 않는다.

 

정적 컨텐츠(이미지, 글 등 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠), 동적 컨텐츠(로그인이 필요한 내용 등 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠) 모두 호스팅이 가능하지만 캐싱은 정적 컨텐츠만 가능하다.

글로벌 서비스이지만 리전은 US-East-1로 취급하며, WAF를 CloudFront에 연결해 사용하기도 한다.

 

 

엣지 로케이션이란 AWS의 CloudFront(CDN) 등의 여러 서비스들을 가장 빠른 속도로 제공(캐싱)하기 위한 거점이다.

Global Accelerator와 유저를 연결하는 거점이기도 하다.

전 세계 여러 장소에 흩어져 있으며 리전보다 개수가 많다.

 

주요 용어는 다음과 같다:

• 원본(Origin): 실제 컨텐츠가 존재하는 서버(S3, EC2 등)
• 배포: CloudFront의 CDN 구분 단위로, 여러 엣지 로케이션으로 구성된 컨텐츠 제공 채널
• 동작: 프로토콜, 캐싱 정책, 로그 등 어떻게 컨텐츠를 전달할지 설정
• Edge Location(= POP): 데이터를 가장 빠른 속도로 제공(캐싱)하기 위한 거점
• Regional Edge Cache: Edge Location의 상위 단위로 좀 더 큰 캐싱 거점

 

CloudFront Origin

CloudFront의 원본(Origin)은 뷰어에게 보여줄 컨텐츠의 원본이 있는 거점을 말한다.

원본으로는 Amazon S3 혹은 Custom Origin(S3 외의 모든 서비스 - EC2, ELB, 온프레미스 및 다른 HTTP 소스)를 사용할 수 있다.

기본적으로 1개의 배포에는 최대 25개의 Origin을 가지며, 이 값은 변경 가능하다.

 

Amazon S3를 Origin으로 설정해 컨텐츠를 제공하는 경우를 S3 Origin이라고 부르며, 도메인 형식은 {S3bucketname}.s3.{region}.amazonaws.com이다.

S3를 사용하더라도 도메인 형식이 올바르지 않다면 Custom Origin으로 취급한다. S3 Static hosting은 http이므로 연결은 가능하지만 역시 Custom Origin으로 취급한다.

 

S3 Origin만의 추가 기능으로는 다음이 있다:

• S3의 접근 제한 가능(OAC)
• Post/Put 등으로 직접 S3에 컨텐츠 업데이트
• 기타 활용: S3 Object Lambda

S3를 제외한 모든 Origin을 Custom Origin이라고 부른다.

Custom Origin으로는 MediaStore, S3 Static Hosting, Lambda Function URL, ALB, EC2 or other HTTP Source 등이 포함된다.

여러 Origin을 Origin Group으로 묶어 Failover 시나리오에 대응할 수 있다. Origin Group은 Primary에서 HTTP 상태 코드가 500을 반환할 경우 Secondary에서 컨텐츠를 가져오는 방식으로 사용할 수 있다.

또한 HTTP/HTTPS로 접근할지 선택 가능하며 IP 주소는 사용 불가하고 도메인만 가능하다.

 

Origin Group은 Failover를 대비하여 Origin들을 Primary, Secondary의 두 그룹으로 묶어 관리하는 것이다.

Primary에서 요청이 실패하는 경우 자동으로 Secondary에 요청하므로 고가용성 구조를 가진다.

Secondary로 요청이 가는 경우는 실패를 나타내는 HTTP 코드가 반환된 경우, 타임아웃 등으로 Primary에 통신을 할 수 없는 경우가 있다.

기본적으로 Primary에 10초 요청을 3번 시도한 뒤 Secondary로 요청이 이동하며, 시도 횟수와 시간은 조절 가능하다.

요청의 응답이 늦어지는 경우 기본 30초, 최대 60초까지 조절 가능하다.

Origin Group은 GET, HEAD, OPTION Method에만 적용 가능하다. (PUT, POST 사용 X)

Primary와 Secondary 요청에 모두 실패한 경우 커스텀 에러페이지를 생성할 수 있다.

 

출처: https://www.youtube.com/watch?v=Vq7DFKZIllI&t=20s

 

CloudFront에서 Origin에 요청할 시 Origin Custom Header를 추가로 전달할 수 있다.

Secret 헤더를 추가해 Origin에서 CloudFront로부터 오는 요청만 처리하거나, Application 헤더를 추가해 여러 개의 CloudFront 중 요청이 오는 CloudFront를 확인하는 로깅 기능으로 사용하는 등 다양한 사용 방법이 있다.

이미 요청에 포함되어 있다면 덮어씌우며, 최대 10개까지 커스텀 헤더를 추가할 수 있다. (증가 요청 가능)

별도로 추가 불가능한 Header(Host, Range, Connection, Cache-Control 등)이 있으며 전체 목록은 아래 링크에서 확인할 수 있다.

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/add-origin-custom-headers.html

사용자 지정 헤더를 오리진 요청에 추가 - Amazon CloudFront

 

 

CloudFront의 캐싱

 

CloudFront의 캐싱은 2티어로 이루어진다.

사용자의 뷰어가 CloudFront로 요청을 하면 먼저 Edge Location(1티어)에 캐싱이 있는지 살펴보고, 없다면 Regional edge cache(2티어)에 요청한다. Regional edge cache에도 없다면 origin에 요청해 데이터를 전달한다.

Regional edge cache는 edge location보다 TTL이 길다.

 

출처: https://www.youtube.com/watch?v=oa-6f8QyFyo&t=13s

 

CloudFront의 Cache Key는 요청에 따라 어떤 캐시 내용을 보여줄지를 결정하는 정보의 조합을 말한다. 각 오브젝트는 고유의 Cache Key 단위로 캐시된다.

CloudFront의 Cache Hit는 뷰어가 특정 Cache Key로 오브젝트를 요청하였을 때, Edge Location에서 해당 Cache 오브젝트를 가지고 있어 원본에 요청 과정 없이 제공할 수 있는 상황을 말한다.

Cache Hit이 발생하면 Origin의 부하 경감이 가능하고, 더 빠르게 컨텐츠를 제공할 수 있다.

 

주요 Cache Key의 구성 요소는 경로(기본), query string, HTTP Header, Cookie 등으로 구성할 수 있다.

Cache Key에는 불필요한 값이 들어가지 않는 것이 중요하다. 또한 User-agent는 다양한 조합에 비해 컨텐츠 생성에는 영향이 거의 없어 Cache Key로 들어가면 Cache Hit 값이 너무 낮아질 수 있으므로 Cache Key에 넣지 않는 편이 좋다.

 

Cache Key 중 HTTP Header를 사용하면 언어별 캐싱, 디바이스 타입별로 캐싱(CloudFront에서 User-agent 기반으로 전용 헤더 생성), 지역별 캐싱을 할 수 있다.

헤더 명은 대소문자를 구분하지 않지만 실제 값은 대소문자를 구분한다.

 

Cookie를 기반으로 컨텐츠 내용을 캐시할 수도 있다.

이 경우 Cookie를 사용하지 않는 HTTP 서버 혹은 S3에서 사용할 경우 퍼포먼스만 저하될 수 있으니 유의해야 한다.

 

캐시된 Object는 TTL 이후 만료된다.

그 다음 요청이 올 경우 CloudFront는 Origin에 Object 갱신 여부를 확인한다. 304 Not Modified를 줄 경우 갱신이 필요 없으나, 200 OK와 파일을 줄 경우 캐시를 갱신한다.

TTL의 종류로는 최소 TTL, 최대 TTL, 기본 TTL이 있다. TTL은 기본 24시간이며, 기본 TTL은 모든 CloudFront의 Object에 적용된다.

 

파일 단위에서는 Origin에서 Cache-Control 헤더 혹은 Expires 헤더를 포함해서 조절할 수 있다. Cache-Control이란 얼마나 오래 Object를 Cache하는지 기간을 설정하는 것이다.

max-age로 설정하면 CloudFront와 브라우저 둘 다 영향을 받으며, s-maxage로 설정하면 CloudFront만 영향을 받는다.

no-cache 혹은 no-store는 캐싱을 하지 않는다는 의미이다. 이때 Min TTL이 0 이상일 경우 Min TTL로 최저 설정된다.

Expires는 Cache가 만료되는 정확한 시각을 설정하는 것이며, CloudFront와 브라우저 둘 다 영향을 받는다.

Cache-Control과 Expires는 전부 CloudFront의 Min/Max TTL 범위 안에서만 설정이 가능하다.

 

캐싱에 관련된 내용은 Cache Policy 정책으로 정의하여 CloudFront에 적용할 수 있다.

주요 설정으로는 Cache Key, TTL, 압축 저장 관련 설정이 있다.

AWS에서 미리 준비한 Managed Policy와 직접 설정하는 Custom의 2가지 종류가 있다.

 

CloudFront Cache Behavior

Cache Behavior: CloudFront의 요청이 어떻게 처리되는지 정의하는 다양한 설정의 모음

경로 패턴 단위(files/*, files/*.png, *.png)로 Behavior를 구성한다. 경로 패턴 목록 중 처음으로 매칭된 패턴의 동작을 적용한다.

신규 생성 시에는 경로 패턴이 *로 구성되고 동작을 추가해야 하는 방식이다.

주요 구성 내용으로는 Origin, 뷰어 설정, Cache Policy, Viewer Response Policy, Lambda@Edge 연결 등이 있다.

 

Viewer란 CloudFront에 요청하는 클라이언트를 말한다.

Viewer 프로토콜이란 Viewer가 CloudFront에 접근하는 프로토콜로 HTTP, HTTPS, Redirect HTTP to HTTPS, HTTPS only가 있다. 이에 맞게 HTTP Method(GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE) 중 무엇을 허용할지도 선택할 수 있다.

또한 Presigned URL/Presigned Cookie로만 뷰어 액세스를 제한할지도 선택할 수 있다.

 

Cache Policy에서는 어떤 키(HTTP Header, cookie, querystring 등)로 컨텐츠를 캐시하는지, 얼마나 오래 캐시하는지(TTL), 컨텐츠를 압축 저장 관련 설정은 어떻게 할 것인지를 결정할 수 있다.

 

Origin Request Policy는 Origin에 컨텐츠를 요청할 때 어떤 내용을 전달할 것인지(HTTP Header, querystring 등)를 결정할 수 있다. Origin에 전달하지만 Cache Key로는 사용하고 싶지 않은 요소들을 Origin Request Policy에 넣는다. Cache Key는 필수적으로 들어간다.

 

Response Header Policy는 응답 과정에서 어떤 HTTP Header를 제거하거나 더할지를 설정한다. 대표적으로 S3 Metadata 제거를 선택하면 CloudFront에서 S3 Metadata를 가져오지 않아 민감한 정보를 지킬 수 있다.

최대 10개까지 설정 가능하며, Authorization header만 설정할 수 없다.

 

그 외의 요소로는 CloudFront의 컨텐츠를 보호하는 방법인 Field Level Encryption, Lambda와 연결되는 Lambda@Edge 등이 있다.

 

CloudFront 파일 관리

CloudFront의 파일 관리 방식은 크게 2가지로 나눌 수 있다.

 

싱글 파일 방식은 파일명을 유지한 채로 캐시 만료나 업데이트 등을 처리하는 방식이다.

별도로 클라이언트 업데이트가 필요 없으며 캐시 만료 전 제공 파일을 업데이트하려면 Invalidation이 필요하다.

 

버저닝 방식은 파일 이름에 다양한 방법으로 버전을 두어서 관리하는 방식이다.

별도로 Invalidation이 필요 없으나 파일 업데이트 시 클라이언트 업데이트가 필요하다.

 

Invalidation이란 캐시 만료 전 파일을 갱신하는 것을 말한다.

버저닝이 아닌 형태로 파일을 제공할 경우 캐시 만료 전 새 파일을 제공하고 싶을 때 Invalidation이 필요하다.

경로 기반 Invalidation(/img/img1.png, /img/* 등)이 가능하며 한 번에 최대 3000파일까지 Invalidation이 가능하다.

계정 전체에 대해 한 달에 1000 path Invalidationds는 무료이며, 이후 한 번 경로당 $0.005가 부과된다.

 

CloudFront 컨텐츠 보호

CloudFront는 권한이 있는 주체들만 컨텐츠에 접근할 수 있도록 컨텐츠에 대한 접근 제한을 지정할 수 있다.

 

출처: https://www.youtube.com/watch?v=RnWKcEdfUSk

 

먼저 권한 정보가 담긴 임시 URL인 Signed URL을 발급하여 뷰어에게 전달하여 컨텐츠를 다운로드 할 수 있는 방법이 있다. Signed URL의 경우 URL당 하나의 파일만 사용이 가능하다.

 

두번째로 뷰어가 권한을 행사해 다운로드 할 수 있도록 컨텐츠 접근 권한을 가진 Cookie를 발급해 뷰어에게 전달하는 Signed Cookie 방법이 있다. Signed Cookie의 경우 다수의 파일에 사용할 수 있다.

두 방법 모두 만료 기간을 설정할 수 있다. 

 

출처: https://www.youtube.com/watch?v=RnWKcEdfUSk

 

이를 전체로 확장시켜서 생각해보자.

1. 관리자가 Key 페어를 만든다. Private Key로 서명을 하면 Public Key로 서명이 온전한지를 확인할 수 있다.

2. Public Key를 CloudFront에 등록한다. 추후 Private Key로 만들어진 서명이 도착하면 CloudFront는 등록된 키로 검증할 수 있다.

3. Private Key를 어플리케이션에 등록한다. 추후  Private Key를 사용해서 Presigned URL을 생성한다.

4. 유저가 url 요청을 하면 유저의 권한을 확인하고, Private Key로 Signed URL/Cookie를 생성해 유저에게 Presigned URL을 전달한다.

5. 유저는 Presigned URL로 CloudFront에 접근한다. CloudFront는 저장된 Public Key로 서명을 확인한 뒤 검증되면 S3에서 파일을 제공한다.

 

이를 위해서는 Signed URL/Cookie를 만들 권한을 가진 주체인 Signer가 필요하다. 여기에는 두 가지 종류가 있다.

• Trusted Key Group: CloudFront에 Public Key를 등록하고 가지고 있는 Private Key로 Presigned URL/Cookie를 생성하는 방식(추천)
• AWS Account: Root 사용자로 계정의 CloudFront Key Pair를 다운받아서 활용한다. 해당 방식은 Root를 활용해야 하고, API를 사용할 수 없고, IAM을 통한 권한 제어가 불가능하기 때문에 비추천한다.

 

Presigned URL/Cookie를 만들 때 URL/Cookie의 권한을 설정하기 위한 정책을 넣을 수 있다. 여기에도 두 가지 종류가 있다.

• Canned(미리 준비된) Policy: 간단한 버전, 만료 시간만 설정 가능, URL 짧음
• Custom Policy: 모든 제약사항 설정 가능, 정책 재사용 가능, URL 긺

 

CloudFront Origin 접근 제한

CloudFront Origin에 대한 직접 접근을 제한할 수 있다. 이 경우 CloudFront를 거치지 않고 직접 Origin에 접근을 막고 싶은 경우 사용할 수 있다.

 

CloudFront S3 Origin 접근 제한

 

먼저 Origin Access Control(OAC)를 사용할 수 있다. OAC는 Origin Access Identity(OAI)와 함께 CloudFront를 거치지 않은 S3에 접근을 방지하기 위한 기능이다. OAI는 이전 방식이고, OAC를 사용하는 것을 추천한다.

 

OAC는 IAM 사용자 혹은 IAM 역할과 비슷한 일종의 Identity이다.

S3에서는 기본적으로 모든 접근을 차단하고 OAC의 접근만 허용한다. S3에서 해당 OAC의 접근을 허용하고, CloudFront에서 OAC를 활용하여 S3와 소통한다. 

OAC에는 Lambda Function URL에도 사용 가능하다.

 

CloudFront가 S3와 소통하기 위한 요청에 Sign 방법을 정의할 수 있다. 즉, OAC가 Authorization Header에 들어가는 방법이다. 여기에는 세 가지 종류가 있다.

 

먼저 Signed Requests 방식이 있다.

이는 CloudFront IAM Principle이 S3에 요청할 때 SigV4로 서명하는 방법이다.

요청에 자격 증명을 활용해 필요한 정보로 Authorization Header를 구성한다. S3에서 해당 내용을 검증해서 자격이 있는 요청인지 확인하고 요청을 처리하거나 거부한다.

클라이언트가 Sign한 헤더가 있다면 덮어씌운다.

 

덮어씌우기를 원하지 않는다면 Do not override aythorization header로 클라이언트가 Sign한 헤더가 있다면 그대로 사용하고, 없다면 새로 Sign하는 방법을 사용할 수 있다.

 

아예 Do not sign requests로 Authorization Header를 사용하지 않는 경우도 있다. 해당 방식은 클라이언트가 항상 Sign을 통해 요청하거나, 컨텐츠가 퍼블릭인 경우 사용한다.

 

CloudFront Custom Origin 접근 제한

그렇다면 Custom Origin은 어떻게 보호할까?

 

먼저 Custom Header를 활용하는 방법이 있다.

CloudFront에서 Header를 생성하고, Origin에서 해당 Header가 없으면 거부하는 방식이다.

 

두 번째 방법은 Origin에서 CloudFront IP를 제외한 모든 트래픽을 차단하는 방법이 있다.

CloudFront IP를 알 수 있다면 방화벽이나 보안 그룹을 이용해 다른 IP는 차단할 수 있다.

AWS 관리형 접두사 목록(AWS에서 직접 관리하는 IP 범위)으로 제한해서 인증된 IP만 사용하는 방법도 있다.

 

또한 CloudFront에 허용된 방법으로만 접근 가능하도록 설정하는 뷰어 액세스 제한 방법도 있다.

Signed URL로 하나의 파일만 접근하거나, Signed Cookie로 다수의 파일에 접근 가능하다.

해당 방식은 위의 "CloudFront 컨텐츠 보호" 항목에서 다뤘으므로 이만 생략하겠다.

 

그리고 특정 지역의 트래픽만 허용하고 싶다면 지리적 배포 제한(Geo Restriction)을 사용할 수 있다.

CloudFront의 지리 배포 제한 기능을 사용해 나라별로 Whitelist 혹은 Blacklist를 작성해 제한할 수 있다. 이 경우 모든 배포에 제한 사항이 포함된다.

혹은 서드 파티의 지리적 위치 서비스를 사용할 수 있다. 브리우저 별, 쿠키 별로 커스터미아징이 가능하며 Signed URL 기반 방식이다.

 

마지막으로 CloudFront를 활용하여 실제 데이터를 처리하는 주체까지 데이터를 암호화해서 전달하는 방법인 Field-Level Encryption이 있다.

HTTPS 통신과는 별도의 개념이다. Edge Location에서 받은 데이터 중 특정 데이터를 Public Key로 암호화하고, 데이터를 처리하는 측에서 Private Key로 복호화하여 사용한다.

 

Lambda@Edge

Lambda@Edge는 Lambda의 확장 기능으로 CloudFront의 Edge Locaiton에 Lambda를 배포하여 연동하는 서비스이다.

Lambda@Edge를 이용해 CloudFront의 요청과 응답 내용을 원하는 대로 조정할 수 있다.

Edge Location에서 실행되고, US-EAST-1 리전에서만 생성할 수 있다. 리전은 US-EAST-1이지만, 실제 수행된 Edge Location에 로그가 생성되므로 유의해야 한다.

Node.js와 Python Runtime만 지원하며, Lambda 서비스에 비해 매우 적은 수행시간/메모리/payload만 사용할 수 있다.

Lambda 버저닝이 필수이며 Lambda Edge가 사용하는 역할에는 edgelambda.amazonaws.com.principle이 사용할 수 있도록 설정이 필요하다.

 

Lambda@Edge는 4가지 종류가 있다.

출처: https://www.youtube.com/watch?v=spuQlVk7vD8

• Viewer Request: Viewer가 CloudFront에 요청하는 시점에 수행되는 Lambda Edge
• Origin Request: CloudFront가 Origin에 요청하는 시점에 수행되는 Lambda Edge
• Origin Response: Origin이 CloudFront에 응답하는 시점에 수행되는 Lambda Edge
• Viewer Response: CloudFront가 Viewer에 응답하는 시점에 수행되는 Lambda Edge

Viewer Request/Response는 128mb 메모리 제한, 5초 실행시간(cold start 포함), 응답 payload(body+header) 40kb, 함수와 라이브러리를 합해 1mb의 제한이 있다.

Origin Request/Response는 메모리 제한은 일반 Lambda와 동일, 30초 실행시간(cold start 포함), 응답 payload(body+header) 1mb, 함수와 라이브러리를 합해 50mb의 제한이 있다.

 

Lambda Edge별 동작 사례는 다음과 같다:

• 캐시 미스에 대해 동작: Origin
• 모든 요청에 대해 동작: Viewer
• 요청(URL/Cookie/Header)의 변경/검증 필요: Viewer
• Origin을 조건에 따라 선택: Origin Request
• Origin에 전달되는 URL 등 변경: Origin Request
• 캐시 되기 전에 Origin의 응답 변경: Origin Response

Lambda@Edge 커스텀 Response in Request를 이용해 Request 단계에서 미리 Response를 설정할 수 있다.

이 경우 CloudFront에서 Origin을 거치지 않고 바로 유저에게 응답을 전달한다.

대표적인 사용 사례로는 302 Redirection/401 Unauthorized, 유저 검증, A/B 테스트, 미리 준비된 페이지, 이미지 리사이징 등이 있다.

 

 

참고 자료

[AWS 완전기초.12] Cache(캐쉬)란 무엇일까요? 개념부터 알아봅니다!

https://www.youtube.com/watch?v=YNOhbWoAc6I

 

AWS를 이해하기 위한 기초지식 : 캐싱

https://www.youtube.com/watch?v=s_DeP80QUnE

 

(LV.300)Amazon CloudFront 완벽 정리 (1) : CloudFront 소개

https://www.youtube.com/watch?v=-r_S_kweXlk

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (2) : CloudFront Origin(원본)

https://www.youtube.com/watch?v=Vq7DFKZIllI

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (3) : CloudFront Caching(캐싱)

https://www.youtube.com/watch?v=oa-6f8QyFyo

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (4) : CloudFront Behavior(동작)

https://www.youtube.com/watch?v=Z3lxE9rUsZo

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (5) : CloudFront 파일 관리

https://www.youtube.com/watch?v=6cekSiRVxDo

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (6) : CloudFront 컨텐츠 보호(1)

https://www.youtube.com/watch?v=RnWKcEdfUSk

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (7) : CloudFront 컨텐츠 보호(2)

https://www.youtube.com/watch?v=xHqHg8o7pyM

 

(LV.300)Amazon CloudFront 완벽 정리 정리 (8) : Lambda@Edge

https://www.youtube.com/watch?v=spuQlVk7vD8