CloudFront 정복

Sep 07,2015 | AWS

작성자_GS Neotek

다루는 내용

· CloudFront 기본 설정
· SSL Termination
· gzip compression
· Error response
· Signed URL
· Signed Cookies
· Data Upload
· Cross Origin Resource Sharing (CORS)
· Smooth Streaming
· CloudFront의 TTL

실습

기본 설정

1. 콘솔에서 CloudFront 클릭
2. Create Distribution 클릭
3. Select a delivery method for your content 페이지에서

1) Web섹션의 Get Started 클릭

4. Create Distribution 페이지에서

1) Origin Domain Name : arang.s3.amazonaws.com 입력
2) Create Distribution 클릭

· Origin Domain Name : 원본 도메인명. S3 버킷이나 ELB가 생성되어 있으면 드롭 다운 리스트에서 선택할 수 있다. 온프레미스 원본의 도메인도 입력하여 사용할 수 있다.
· Origin Path : 서비스 루트가 될 디렉토리명을 입력한다.
· Origin ID : 멀티 원본을 사용할 경우 원본을 구분하기 위해 사용된다.
· Restrict Bucket Access : S3를 원본으로 사용할 경우 S3에 직접 접속을 제한하기 위해 사용된다. signed URL이나 signed Cookies를 사용할 경우 필수 항목이다.

· Restrict Bucket Access를 Yes로 선택할 경우 확장되어 나온다.
· Origin Access Identity : 원본 접속 권한을 제한한 경우 ID이다. 새로 만들거나 기존에 만든 ID를 선택할 수 있으며, 콘솔에서 왼쪽 메뉴의 Origin Access Identity를 클릭하여 기존 ID를 확인 할 수 있다.
· Your Identities : Origin Access Identity 선택
· Grant Read Permissions on Bucker : Yes를 선택한 경우 S3 버킷 Policy를 자동으로 수정해 준다. No를 선택한 경우 수동으로 Policy를 수정하면 된다.

· Path Pattern : 서비스 할 컨텐츠의 패턴을 정의한다. Behaviors를 수정하여 추가할 수 있다.

· Viewer Protocol Policy : CloudFront와 Viewer사이의 프로토콜이다.
· Allowed HTTP Methods : CloudFront에 Request시에 사용 가능한 HTTP Method를 지정한다.
· Cached HTTP Methods : CloudFront가 캐싱할 HTTP Method를 지정한다.
· Forward Headers : CloudFront에서 요청 헤더를 오리진 서버로 전달하고 헤더의 값에 따라 객체를 캐싱할지 여부를 지정한다. S3를 원본으로 사용하는 경우 Access-Control-Request-Headers, Access-Control-Request-Method, Origin 3개의 헤더만 처리한다.
· Object Caching :
· Minimum TTL :
· Maximum TTL :
· Default TTL :
TTL 부분에서 상세하게 설명한다.
· Forward Cookies : CloudFront에서 쿠키를 오리진 서버로 전달할지 여부와 전달할 쿠키(전달하는 경우)를 지정한다. S3는 쿠키를 처리하지 않으므로 항상 None를 선택해야한다.
· Forward Query Strings : 쿼리스트링을 캐싱할 경우 사용한다.
· Smooth Streaming : Smooth Streaming 포맷으로 파일을 스트리밍할 수 있는 웹 서버를 원본으로 사용하거나 Microsoft Smooth Streaming 포맷으로 인코딩된 미디어 파일을 스트리밍 할 수 있다.
· Restrict Viewer Access (Use Signed URLs or Signed Cookies) : Signed URL이나 Signed Cookies를 사용할 경우 설정한다.
· Trusted Signers : 신뢰할 수 있는 서명자의 계정 번호를 입력한다. Singed URL이나 Signed Cookies 개발자 코드에 사용된다.

· Price Class : 사용할 CloudFront 엣지를 선택한다. 가격 등급이 달라진다.
· Alternate Domain Names (CNAMEs) : xxxxx.cloudfront.net이 아닌 커스텀 도메인을 사용하기 위해 CNAME을 지정한다. 지정된 도메인은 바로 서비스 되는 것이 아니라 DNS 서버에서 xxxxx.cloudfront.net으로 CNAME 해주어야한다.
· SSL Certificate : HTTPS로 서비스할 경우 정의한다. *.cloudfront.net 도메인에 대해서는 기본적으로 HTTPS 서비스가 가능하지만 커스텀 도메인을 HTTPS로 서비스하기 위해서는 IAM에 인증서를 등록해주어야한다.
· Default Root Object : 기본 객체를 지정한다. 예. index.html
· Logging : 로깅 여부를 지정한다.
· Bucket for Logs : 로그가 저장될 Bucket을 지정한다.
· Log Prefix : 로그 파일의 prefix를 지정한다.
· Cookie Logging : 로그에 쿠키를 포함한다. S3는 쿠키를 지원하지 않으므로 사용할 수 없다.
· Comment : CloudFront Distribution의 설명
· Distribution State : 배포가 완료되었을 때 활성화 또는 비활성화할지 여부를 나타낸다.

5. Distributions ID 클릭
6. General 탭

Edit 버튼을 클릭하여 일반정보를 수정할 수 있다.

7. Origins 탭

Create Origin 버튼을 클릭하여 원본을 추가할 수 있다.

8. Behaviors 탭

Create Behavior 버튼을 클릭하여 Behavior를 추가할 수 있다. Path Pattern별로 다른 원본을 참조하고, 다른 설정 값을 적용할 수 있다.

9. Error Pages 탭

Create Custom Error Response 버튼을 클릭하여 원본의 응답 에러 코드별로 Viewer에게 다른 응답을 할 수 있다.

10. Restrictions 탭

Edit 버튼을 클릭하여 Geo IP 기반으로 제한을 적용할 수 있다.

11. Invalidations 탭

Create Invalidation 버튼을 클릭하여 Invalidation을 실행 할 수 있다.

사례별 설정

SSL Termination

CloudFront는 AWS에서 제공하는 인증서로 HTTPS 서비스를 할 수 있다. 하지만 *.cloudfront.net 형식의 도메인을 사용하여야 한다. 다른 도메인을 사용하여 SSL을 적용하기 위해서는 인증서를 등록해 주어야 한다.

1. CLI를 이용하여 IAM에 인증서 업로드

1) aws iam upload-server-certificate 실행

–path /cloudfront/xxxx/ 옵션이 추가되어야 한다.

2. Default Cache Behavior Settings 섹션에서

1) Viewer Protocol Policy : HTTPS Only 선택

3. Distribution Settings 섹션

1) Alternate Domain Names : aws-arang.gscdn.com 입력
2) SSL Certificate : Custom SSL Certificate (ssl_cf_arang) 선택
3) Custom SSL Client Support : Only Clients that Support Server Name Indication (SNI) 선택

gzip compression

압축 전송은 HTML 표준이며 CloudFront는 압축 전송을 지원한다. CloudFront에서 별다른 설정 없이 사용 가능하다. 단, Origin에서 Request Header에 Accept-Encoding: gzip가 있을 경우 압축된 컨텐츠를 내려 주도록 설정되어 있어야 한다. 일반 원본 서버일 경우 개발이 필요한 부분이며, S3를 원본으로 사용할 경우 별도로 압축을 지원하지 않기 때문에 압축된 파일을 미리 업로드 해 두어야 한다. 최신 브라우져에서는 기본적으로 요청시 Accept-Encoding: gzip 헤더를 포함한다.

1. S3에 컨텐츠 업로드

1) test.html 파일
압축전의 html파일이며 테스트에서는 362132Bytes 크기이다. S3 콘솔을 통해 업로드 하면 메타데이타에 Content-Type이 자동으로 생성된다.

2) test.html.gz 파일
gzip으로 압축한 파일이며 크기는 67365Bytes이다. Content-Type을 text/html로 수정하고, Content-Encoding을 gzip으로 하여 추가한다.

2. 테스트 웹 사이트 구축

1) 간단한 링크로 웹 사이트 구축
각 파일을 요청하여 결과 값을 확인 해보도록 한다. 각 파일은 CloudFront를 통해 요청한다.

3. 응답 확인

1) text/html을 클릭하여 test.html 파일 요청

페이지가 정상적으로 노출되며, 응답한 Content-Length는 362132Bytes이다. 응답에 1.32s가 소요되었다.
2) compression을 클릭하여 test.html.gz 파일 요청

페이지가 정상적으로 노출되며, 응답한 Content-Length는 67365Bytes이다. 응답에 640ms가 소요되었다.

Error response

1. Error Pages 탭 클릭
2. Create Custom Error Response 클릭
3. Custom Error Response Settings 페이지에서

1) HTTP Error Code : 403: Forbidden 선택
2) Error Caching Minimum TTL : 300 입력
3) Customize Error Response : Yes 선택
4) Response Page Path : /login.php 입력
5) HTTP Response Code : 200: OK 선택
6) Create 클릭

Signed URL

프라이빗 컨텐츠를 안전하게 제공하기 위한 방법 중 Sigend URL 사용에 대해 알아본다.

1. Origin Settings

1) Restrict Bucket Access : Yes 선택
2) Origin Access Identity : Create a New Identity 선택
3) Grant Read Permissions on Bucket : Yes, Update Bucket Policy 선택

2. Origin Access Identity

1) 왼쪽 메뉴에서 Origin Access Identity 클릭

생성된 Origin Access Identity를 확인할 수 있다.

3. S3 Bucket Policy

1) CloudFront 원본의 S3 버킷 Policy 확인

지정된 Origin Access Identity를 사용하는 CloudFront에서만 GetObject 가능하다.

4. CloudFront Behavior

1) Restrict Viewer Access(Use Signed URLs or Signed Cookies) : Yes 선택
2) Trusted Signers : Self 선택

5. Signed URL 생성 코드

1) Perl, PHP, C#, Java 예제 코드를 제공한다.
http://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/PrivateCFSignatureCodeAndExamples.html
2) node.js 코드

3) 결과

4) CloudFront Key pair
CloudFront key pair는 AWS key pair와 다르다. 관리자 계정에서 생성할 수 있으며, 소스에 사용되는 pem은 private key이다.

Signed Cookies

Signed URL은 URL의 형태가 Hash되어 변경된다. 또한, 단일 파일에 대해서만 적용이 가능하다. Signed Cookies는 이러한 단점을 보완하기 위해 사용된다. 특히 HLS 처럼 여러 ts파일로 분할되어 있는 경우 모든 파일에 Signed URL을 적용하기 어려우므로 서버에서 클라이언트에 쿠키를 쓰고 클라이언트는 쿠키를 가지고 컨텐츠를 요청하게 된다.

1. CloudFront 설정

CloudFront의 설정은 Signed URL과 동일하다. 단, 도메인 쿠키값 적용을 위해 CNAME을 적용한다. (cf.aws.idunbiz.com)

2. Signed Cookie 생성 코드

1) scookie.js

2) 실행

3) cookie.php

4) 결과

3. HLS 실행하기

1) cookieWithPlayer.php

2) HLS Player
오픈소스 Player 중 Hosted 형식으로 사용 가능한 Flowplayer를 사용한다.
https://github.com/mangui/flashls/releases
3) 크로스도메인
플레이어에서 사용할 crossdomain.xml 파일을 만들어 CloudFront의 원본(S3)에 업로드 한다.

4) 실행

∗ AWS 매뉴얼에서 ‘미리 준비된 정책을 사용하여 서명된 쿠키 설정’ 부분을 보면 CloudFront-Expires, CloudFront-Signature, CloudFront-Key-Pair-Id를 사용하라고 되어 있으나 CloudFront-Policy가 없으면 안된다.
∗ Set-Cookie 하지 않고, Client에서 Cookie 헤더로 요청하기

· Cookie: 띄어쓰기에 유의한다.
· 각 키-값은 세미콜론(;)으로 구분한다.

Data Upload

1. Default Cache Behavior Settings 섹션에서

1) Allowed HTTP Methods : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE 선택

2. curl 명령어로 PUT method 실행

2) curl -v -X PUT -T “index.html” http://d1uo7fissvbhky.cloudfront.net

Cross Origin Resource Sharing (CORS)

웹 어플리케이션에서 자바스크립트을 사용할 때 동일 출처 정책(same origin policy) 보안 규칙에 의해 도메인이 다른 리소스를 요청하면 접근이 안 된다. 해결 방법으로는 여러가지가 있지만 최근에는 표준이된 CORS(Cross Orogin Resource Sharing) 방식을 사용한다.

CORS 동작 방식

1. 동일 도메인 호출

1) EC2 인스턴스를 웹 서버로 설정하고 소스 파일을 작성한다.
2) a.html

3) b.html

4) 브라우져에서 http://cors.aws.idunbiz.com/a.html 요청

5) 결과

동일 도메인으로 요청하였으므로 정상적으로 결과를 보여 준다.

2. 다른 도메인 호출

1) b.html

2) S3 버킷을 생성하고 b.html 파일을 업로드 한다.
3) b.html을 파일을 Public으로 만든다.

4) a.html 파일을 수정한다.

a.html 페이지가 호출되면서 가져오는 파일을 S3 버킷의 b.html로 변경하였다.
5) 브라우져에서 http://cors.aws.idunbiz.com/a.html 요청

b.html 페이지를 요청하였지만, 정상적으로 가져오지 못 하였다.
6) S3에서 CORS 설정
· 버킷 à Properties à Permissions à Add CORS Configuration 클릭

· Save 클릭
· Close 클릭
7) 브라우져에서 http://cors.aws.idunbiz.com/a.html 요청

8) 확인

다른 도메인 원본 서버(S3)에서 Access-Control-Allow-Origin : * 으로 설정되어 있으므로 Cross Domain 호출이 가능하다.

3. S3의 CORS Configuration

1) AllowedOrigin

특정 도메인에 대해서만 허용할 경우 AllowedOrigin 부분에 추가하면 된다. 단, http://(혹은 https://)를 반드시 추가해주어야 한다.
2) AllowedMethod
CORS 요청에 허용할 Method를 명시해준다.
3) MaxAgeSeconds
브라우져가 리소스, HTTP 메소드, 오리진으로 식별되는 preflight 요청에 대한 응답을 캐싱하는 시간을 지정한다.
4) AllowedHeader
Access-Control-Request-Headers 헤더를 통해 preflight 요청에 허용되는 헤더를 지정한다. Access-Control-Request-Headers 헤더의 각 헤더 이름은 규칙의 해당 항목과 일치해야 한다. Amazon S3는 요청된 응답에서 허용된 헤더만을 보낸다.

4. CloudFront 설정

1) 원본이 arang-tmp.s3.amazonaws.com인 CloudFront Distribution을 만든다.

2) 브라우져에서 http://cors.aws.idunbiz.com/a.html 요청

b.html은 arang-tmp.s3에서 가져와 cloudfront에서 서비스 된다.
요청 Method가 GET인 경우 CloudFront의 별다른 설정없이 서비스 된다.

5. PUT 요청

S3에 POST, DELETE, PUT등의 요청을 하기 위해서는 REST API를 이용해야한다. REST API를 사용하기 위해서는 권한증명이 필요하다.
권한 증명을 할 수 있는 방법은 3가지가 있다.
• Authorization Header를 이용하는 방법

일반적으로 사용하는 방법이며, GET, PUT, HEAD, DELETE 메소드를 사용할 수 있다.

• 쿼리 파라미터를 이용하는 방법

• POST 요청 (policy를 이용하는 방법)
policy document로 policy와 signature를 만들어 요청하는 방법으로 실습에서는 이 방법으로 진행한다.
1) policy.js

위 코드는 node.js로 작성되었다. secret key와 policy를 조합하여 signature를 생성한다.
웹 브라우져에서 요청할 때 policy와 조건이 맞아야만 한다.
2) a.html

3) S3의 Bucket Policy와 CORS Configuration
· Bucket Policy

PutObject를 허용해야한다. 허용하지 않을 경우 403 Forbidden 코드를 응답한다.
· CORS Configuration

AllowedMethod에 PUT을 추가해준다.
AllowedHeader에 허용할 헤더를 추가해 준다. 브라우져가 S3에 OPTION 메소드로 preflight 요청을 하게 되는데, 허용하지 않으면 403 코드를 응답하고 PUT은 진행되지 않는다.

4) 브라우저 요청
http://cors.aws.idunbiz.com/a.html 요청 후 로컬 파일을 선택하고 PUT 한다.

먼저 OPTIONS 요청에 200코드 응답한다.

PUT 요청에도 200코드를 응답한다.
S3 버킷에는 업로드한 파일이 저장된다.

6. CloudFront 설정

1) arang-tmp를 원본으로 참조하는 CloudFront Distribution을 만든다.
2) a.html을 수정한다.

S3에 직접 PUT하지 않고, CloudFront를 통해서 PUT한다.
3) 브라우져에서 http://cors.aws.idunbiz.com/a.html 요청

4) Allowed HTTP Methods 수정
Default Cache Behavior Settings 섹션에서
Allowed HTTP Methods : GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE 선택

정상적으로 서비스된다.
· 매뉴얼에는 CloudFront의 Forward Headers 기능을 활성화하여 Origin, Access-Control-Request-Headers, Access-Control-Request-Method 헤더를 전달해주어야 한다고 되어 있으나 테스트 결과 None으로 해도 전달된다.