AWS 네트워크 및 컨텐츠 전송

wjdghks95·2024년 8월 29일

aws

Amazon Route53

Amazon Route53은 높은 가용성과 확장성이 뛰어난 클라우드 Domain Name System(DNS) 웹 서비스입니다.

Amazon Route53 소개

Amazon Route53

AWS의 DNS 서비스
- DNS에서 사용하는 포트 숫자(53)에서 유래
- 도메인을 IP 어드레스 및 AWS의 리소스로 연결해주는 서비스
기본적으로 고가용성을 갖춘 글로벌 서비스(99.99% SLA)
주요 기능
- 도메인 관리(등록, 레코드 연결 등)
- Health Check 기능: 주기적으로 지정된 주소에서 정상적인 응답을 받는지 확인
- 다양한 라우팅 정책
- 기타 하이브리드 아키텍처 환경에서 내부 도메인의 활용을 지원
주요 비용: 호스팅 영역 / DNS 쿼리 / 기타 기능(Health Check 등)

Amazon Route53 기초

Amazon Route53 주요 개념

도메인: 대상의 IP 주소 등의 정보와 맵핑되는 사람이 알아볼 수 있는 문자열
- 서브 도메인: 도메인 중 스트링 앞에 추가 문자열이 붙은 도메인
  - 예) text.example.com
- APEX 도메인(Zone Apex, Root Domain ...): 도메인 중 앞에 추가 문자열이 없는 순수한 최상위 도메인
  - 예) example.com
레코드(DNS Record): 도메인이 어떤 방식으로 트래픽을 대상에게 전달하는지 정의하는 데이터
- 레코드 종류, 대상 IP 주소 등의 정보 포함
- 레코드 별 TTL: 얼마나 오랫동안 다른 DNS 서버들이 이 레코드를 캐싱할 지 결정 => TTL 값이 높다면 쿼리는 줄어들지만 배포 시간 증가
Hosted Zone: 레코드의 집합으로 특정 도메인과 서브 도메인의 레코드를 모은 컨테이너
- APEX 도메인과 같은 이름을 부여

레코드의 종류

A(Address) Record: 도메인을 IPv4 주소와 연결(예: example.com -> 192.33.11.2)
AAAA(IPv6 Address) Record: 도메인을 IPv6 주소와 연결
CNAME(Canonical Name) Record: 도메인을 다른 도메인과 연결
- 예) www.example.com -> example.com
- 규칙으로 APEX 도메인은 CNAME 사용 불가능
Alias(별칭) Record: AWS Route53에서만 지원하는 레코드 타입으로 도메인과 AWS 리소스를 연결
- 예) 도메인을 S3 / CloudFront / ALB 등과 연결
NS(Name Server) Record: 도메인을 Authoritive DNS 서버를 지정
MX(Mail Excahnge) Record: 도메인과 메일 서버를 연결
TXT(Text) Record: 도메인에 관련된 텍스트 기반 정보를 연결

Amazon Route53 사용과정

도메인 등록(Route53 or 다른 Domain Registrar)
- kr 등의 도메인은 Route53에서 등록 불가능
Hosting Zone 생성
- Route53에서 도메인을 등록하면 자동으로 Hosting Zone 생성
- 다른 Domain Registrar에서 등록했다면 수동으로 Hosting Zone 생성 후 DNS 연동 필요
레코드 생성
- AWS 리소스를 연결하려면 Alias Record
- 기타 필요에 따라 적절한 레코드 타입 생성
- DNS 캐시 등의 이유로 최대 하루 이상 소요

실습 - Route53에서 도메인을 등록

Route53에서 도메인을 등록해서 Route53에서 관리하도록 설정
다양한 레코드를 생성해서 AWS 리소스와 연결(EC2, S3, ALB)

※ S3의 경우 버킷명과 레코드 이름이 같아야함

※ APEX 도메인은 별칭 레코드 사용

실습 - 외부에서 도메인 구입

외부에서 도메인 구입 후 Route53에서 생성한 Hosted Zone의 NS 서버로 변경

Amazon Route53 Health Check

Amazon Route53 Health Check

Route53에서 설정한 리소스(웹 어플리케이션, 서버 등)의 상태를 모니터링 하는 기능
- Routing Policy에서 활용 / Amazon CloudWatch 경보 설정하여 알림 처리 가능
Latency 정보 확인 가능
- TCP Connection 연결 수립까지 걸린 시간
- HTTP/HTTPS First Byte를 받기까지 걸린 시간
  - SSL/TLS Handshake까지 걸린 시간
CloudWatch Metric으로 Health Check 상태 기록 / 알람 가능
- US-East-1 리전 전용

Health Check 모니터링 대상

특정 리소스
다른 Health Check
Amazon CloudWatch 경보
Route53 Application Recovery Controller

Health Check 모니터링 대상 - 리소스

IP 주소, 도메인에 주기적으로 요청을 보내 응답 여부를 확인하여 가용성을 확인
상태 확인 방법
- 전 세계의 다수의 Health Checker에서 정해진 프로토콜/주기로 요청을 보내서 상태 확인
- 주기: 10초(추가요금) or 30초(Checker 별 Sync 없음)
두 가지 지표를 기준으로 상태 판단
- 응답 속도(HTTP(연결 수립): 4초, TCP 10초, HTTP String Match: 2초 안에 값 확인)
- 응답 내용 및 지정한 실패 횟수를 연속으로 넘었는지 여부
해당 기준으로 전체 Health Checker의 18% 초과가 Healthy 상태를 유지해야 Health 상태로 판단
주의: AWS 바깥의 엔드포인트를 대상으로 할 경우 추가 요금 발생

Health Check 모니터링 대상 - 리소스 지정 가능 값

모드
- IP 주소: IPv4, IPv6(로컬/Private/Multicast 등은 체크 불가능)
  - HTTP/HTTPS -> Status 2xx,3xx
  - TCP
- 도메인
  - HTTP/HTTPS -> Status 2xx,3xx
  - IPv4만 지원. 즉, A Record 외에는 Fail 처리
매칭 문자열: 응답의 Body에 특정 문자열이 있는지 확인
Health Check Region: 최소 3개
기타: 포트 / 경로 / 주기 / SNI 지원 / Latency graphs / Inverse Check 등등

Health Check 모니터링 대상 - 다른 Health Check

다른 Health Check를 모니터링
- 예: 3개 이상의 설정한 Health Check의 상태 검사가 실패할 경우 경보 / FailOver 등
상태를 정하기 위한 Health Check 숫자 지정 가능
- 모든 Health Check 성공이면 성공
- 단 하나의 Health Check 성공이면 성공
- 지정한 Health Check 숫자 중 N개 이상이 성공이면 성공

Health Check 모니터링 대상 - CloudWatch 경보

CloudWatch 경보 상태를 모니터링
주의
- CloudWatch 경보의 경보 상태가 아닌 직접 데이터를 모니터링. 즉, CloudWatch 경보보다 조금 더 민감하게 반응
- Standard Resolution(60초마다 수집) 경보만 모니터링 가능
- Average, Minimum, Maximum, Sum, SampleCount만 모니터링 가능
- Math Metric 사용 불가능
- CloudWatch 경보가 변경되었을 경우 Route53 Health Check 수동으로 업데이트 필요
데이터가 충분하지 않을 경우(Insufficient Data 상태) 상태 지정 가능
- 예: Insufficient Data일 때 Healthy, Unhealthy, Last Known Status)

실습 - 리소스 Health Check 모니터링

EC2 인스턴스를 프로비전 하고 Route53 Health Check 구성
a. EC2 Health Check 구성

b. 상태 검사 구성 및 엔드포인트 모니터링 설정

c. 고급 구성 설정
EC2를 두 개 만들어 Health Check을 구성하고, 이 두 Health Check을 모아서 모니터링 하는 Check 생성
a. Health Check 모니터링 Health Check 생성
Health Check Fail 시 SNS를 통해 이메일 받아보기

Amazon Route53 Routing Policy

Amazon Route53 Routing Policy

도메인 레코드에 대상을 연결하는 방식을 다양한 방법으로 지원

Simple Routing Policy

가장 간단한 방식으로 하나의 레코드를 하나의 대상으로 라우팅 하는 방식
단일 서버, 단일 리소스 등의 라우팅을 위해 사용

Failover Routing Policy

평소에는 기본 대상(Primary)으로 라우팅 하고 기본 대상에 문제가 있을 때 보조 대상(Secondary)으로 라우팅 하는 정책
Health Check을 활용하여 상태를 확인
- 기본 대상의 Health Check이 Fail 상태일 경우 보조 대상으로 라우팅
주요 사용 사례
- Active-Passive Failover
- 기본 대상이 대부분의 요청을 처리하고, 기본 대상의 실패를 대비해 보조 대상이 준비만 하는 Failover 방식
- 즉, 평소에 대부분의 리소스를 기본 대상에 집중하고, 보조 대상은 최소한의 리소스로 장애를 준비

Geolocation Routing Policy

DNS Query가 발생한 위치에 따라 다른 응답을 보낼 수 있는 Routing Policy
- 즉, 요청한 지점이 지리적으로 어디에 위치해 있는지에 따라 응답을 다르게 설정 가능
- 예: 동남아시아 지역에서 발생한 요청은 한국 리전, 유럽 지역에서 발생한 요청은 프랑크푸르트 리전으로
대륙, 나라 + 미국일 경우 주(State) 기준으로 설정 가능
- 겹치는 범위라면 더 작은 지역을 우선 적용
내가 지정한 지역의 요청은 내가 지정한 지역으로 라우팅
주요 사용 사례
- 언어별 라우팅
- 지역별 컨텐츠 제공 구분
- 예상 가능한 부하를 기반(인구 등)으로 인프라를 구축하고 유지

Geoproximity Routing Policy

DNS Query가 발생한 위치와 리소스의 위치에 따라 다른 응답을 보낼 수 있는 Routing Policy
- 요청이 발생한 지점에서 가장 가까운 위치의 리소스로 라우팅
- 즉, 요청한 지역과 리소스의 거리 기반
추가적으로 Bias를 지정해 지역 범위 조절 가능
- Bias: 특정 지역이 더 많은 범위 혹은 더 적은 범위를 커버하도록 조절하는 보정 값
주요 사용 사례
- 지역별 컨텐츠 제공 구분
- 최소 지연 속도로 라우팅

Latency-Based Routing Policy

유저 기준으로 가장 빠른 Latency(네트워크 지연시간)를 가진 레코드로 라우팅하는 정책
- 예: 도쿄 리전/버지니아 리전에 ALB가 있을 때 서울 리전에서 요청한 경우 서울 -> 도쿄, 서울 -> 버지니아를 비교하여 가장 빠른 리전으로 라우팅
주의: AWS 데이터 센터간의 Latency를 기준으로 하기 때문에 AWS 외부의 소스일 경우 정확도가 매우 떨어질 수 있음
주요 사용 사례
- 여러 리전간에 최적화된 유저 경험을 위한 라우팅
- Active-Active Failover

IP-based Routing Policy

IP 기반으로 라우팅을 조절하는 정책
- 기존의 Geolocation / Latency-Based 라우팅 등에 추가로 네트워크의 이해를 바탕으로 정교한 라우팅 정책 구성 가능
CIDR Block Range 별로 다른 라우팅 구성 가능
주요 사용 사례
- 특정 네트워크를 구분하여 라우팅
- 예: 특정 ISP 대역만 분리하여 라우팅 하고 싶은 경우
- 예: 회사 IP만 Dev 리전으로 라우팅

Multivalue Routing Policy

한번의 요청으로 다양한 값을 전달하는 정책
- Health Check과 연동하여 현재 원할한 상태인 값만 선별적으로 보내기 가능
주요 사용 사례
- 로드 밸런싱
- 간단한 Failover

Weighted Routing Policy

다수의 리소스를 하나의 도메인으로 묶어 각 리소스에 비중을 두고 분배하는 정책
- 같은 이름과 타입의 레코드를 만들어 비중(weight)을 부여
비중(Weight): 1~255의 값으로 높은 비중을 가진 레코드일수록 더 많은 트래픽을 분배
주요 사용 사례
- 로드 밸런싱
- A/B 테스트
- 카나리 릴리즈
- Active-Active Failover

실습 - Amazon Route53 Routing Policy 적용

Amazon CloudFront

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

Amazon CloudFront 기초

Amazon CloudFront

AWS에서 제공하는 Content Delivery Network(CDN)
- 웹페이지, 이미지, 동영상 등의 컨텐츠를 본래 서버에서 받아와 캐싱
- 해당 컨텐츠에 대한 요청이 들어오면 캐싱해둔 컨텐츠를 제공
- 컨텐츠를 제공하는 서버와 실제 요청 지점간의 지리적 거리가 매우 먼 경우, 요청 지점 근처의 CDN을 통해 빠르게 컨텐츠 제공 가능
엣지 로케이션에서 데이터를 캐싱
- 따라서 원본이 변해도 캐싱이 만료되지 않는다면 유저가 보는 내용은 변하지 않음
글로벌 서비스. 단, 리전은 US-East-1 취급
정적 컨텐츠, 동적 컨텐츠 모두 호스팅 가능

※ 정적 컨텐츠(Static Contents) vs 동적 컨텐츠(Dynamic Contents)

정적 컨텐츠
- 서버에 저장된 파일이 모든 사용자에게 동일하게 전달되는 컨텐츠
- 매번 서버에 요청할 필요 없이 캐싱 가능
- HTML/Javascript 등으로 구성
- 예: 이미지, 글, 뉴스 등
동적 컨텐츠
- 시간, 사용자, 입력 등에 따라 내용이 변경되는 컨텐츠
- 매번 서버에 요청하여 내용을 구성하고 전달 받아야함
- PHP, JSP, ASP, .net 등으로 서버 처리
- 예: 로그인이 필요한 내용, 게시판, 댓글 등

엣지 로케이션(Edge Location)

AWS의 CloudFront(CDN)등의 여러 서비스들을 가장 빠른 속도로 제공(캐싱)하기 위한 거점
Global Accelerator와 유저를 연결하는 거점
전 세계에 여러 장소에 흩어져 있음

* 용어 정리

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

Amazon CloudFront 원본(Origin)

원본(Origin)

뷰어에게 보여줄 컨텐츠의 원본이 있는 거점
두 가지 종류
- Amazon S3
- Custom Origin
  - EC2
  - ELB
  - 기타 EC2 및 다른 HTTP 소스
기본 최대 25/Distribution

S3 Origin

Amazon S3를 Origin으로 설정해 컨텐츠를 제공하는 경우
도메인 형식은 {bucketname}.s3.{region}.amazonaws.com
- 이렇게 설정하지 않을 경우 Custom Origin 취급
S3 Origin만의 추가 기능
- S3의 접근 제한 기능(OAC/OAI)
- Post/Put 등으로 직접 S3에 컨텐츠 업데이트 가능
기타 활용: S3 Object Lambda

Custom Origin

S3를 제외한 모든 Origin
- MediaStore
- S3 Static Hosting
- Lambda Function URL
- Application Load Balancer
- EC2 or other HTTP Source
Origin Group
- 여러 Origin을 그룹으로 묶어 Failover 시나리오에 대응 가능
- 예: Primary에서 HTTP status 500을 반환한 경우, Secondary에서 컨텐츠 가져오기
HTTP/HTTPS로 접근할 지 선택 가능
IP 주소는 사용불가(도메인만 가능)

Origin Group

Failover를 대비하여 Primary, Secondary 두 Origin을 그룹으로 묶어 관리 가능
Primary에서 실패한 경우 자동으로 Secondary에 요청
- 실패를 나타내는 HTTP 코드가 반환된 경우
  - 기본 10초(3번 시도)
  - 시도 횟수와 시간 조절 가능
- 요청의 응답이 늦어지는 경우
  - 기본 30초, 최대 60초 조절 가능
GET, HEAD, OPTION Method에만 적용
Primary/Secondary 모두 실패한 경우에 커스텀 에러페이지 생성 가능

Origin Custom Header

CloudFront에서 Origin에 요청 시 커스텀 헤더 추가 전달 가능
이미 요청에 포함되어 있으면 덮어씌움
최대 10개 (증가 요청 가능)
별도로 추가 불가능한 Header 존재
- 예: Host, Range, Connection, Cache-Control, X-Amz-* 등

실습 - CloudFront 배포

※ Origin Group 생성

Amazon CloudFront 캐싱(Caching)

CloudFront의 캐싱 티어

CloudFront의 캐싱은 2티어
요청 순서
- Edge Location
- Regional Edge Cache
- Origin

CloudFront의 Cache Key

요청에 따라 어떤 캐시 내용을 보여줄지를 결정하는 정보의 조합
- 각 오브젝트는 고유의 Cache Key 단위로 캐시됨
Cache Hit: 뷰어가 특정 Cache Key로 오브젝트를 요청하였을때, Edge Location에서 해당 Cache 오브젝트를 가지고 있어 원본에 요청 과정 없이 제공할 수 있는 상황
- Origin의 부하 감소
- 더 빠르게 컨텐츠 제공 가능
- 즉, CDN이 Cache Hit이 많을수록 더 좋은 퍼포먼스 제공 가능
주요 Cache Key 구성요소
- 경로(기본), QueryString, HTTP Header, Cookie

HTTP Header Based Cache

Cache Key 중 HTTP Header를 활용
활용 사례
- 언어별 캐싱
- Device Type 별로 캐싱
  - CloudFront에서 별도로 User-Agent를 기반으로 전용 헤더 생성
  - CloudFront-Is-Desktop-Viewer / CloudFront-Is-Mobile-Viewer / CloudFront-Is-SmartTV-Viewer 등
- 지역별 캐싱
  - CloudFront에서 전용 헤더 생성
  - CloudFront-Viewer-Country
헤더명은 대소문자를 구분하지 않지만, 값은 구분

Cookie Based Cache

Cookie를 기반으로 컨텐츠 내용을 캐시
- Cookie를 활용하지 않는 HTTP 서버 혹은 S3에서 사용할 경우 퍼포먼스만 저하 될 수 있음

Cache 만료

캐시된 Object는 일정기간(TTL, Time To Live) 이후 만료
- 그 다음 요청이 올 경우 CloudFront는 Origin에 Object 갱신 여부를 확인
- Origin이 304 Not Modified를 줄 경우 갱신 필요 없음
- 200 ok와 파일을 줄 경우 갱신

Cache TTL

TTL(Time To Live): Cache Object를 얼마나 오래 보관할지에 관할 설정
- 기본 24시간
- 모든 CloudFront의 Object에 적용
- 파일 단위에서는 Origin에서 Cache-Control 헤더 혹은 Expires 헤더를 포함해서 조절 가능
TTL의 종류
- Minimum TTL: 최소 TTL. 즉, 파일 단위 컨트롤에서 줄 수 있는 최소 TTL
- Maximum TTL: 최대 TTL. 즉, 파일 단위 컨트롤에서 줄 수 있는 최대 TTL
- Default TTL: 별도의 설정이 없을 경우 부여되는 기본 TTL

Cache TTL 컨트롤

파일 단위에서는 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와 브라우저 영향
CloudFront의 Min/Max TTL 범위 안에서만 설정 가능

Cache Policy

캐싱과 관련된 내용을 정책으로 정의하여 CloudFront에 적용 가능
주요 설정
- 어떤 키(HTTP Header, 쿠키, QueryString 등)으로 컨텐츠를 캐시하는지
- 얼마나 오래 캐시하는지(TTL)
- 컨텐츠 압축 저장 관련 설정
두 가지 종류
- Managed: AWS에서 직접 생성한 Policy로 다양한 상황을 위해 미리 준비된 Policy
- Custom: 직접 설정

Amazon CloudFront 동작(Behavior)

Cache Behavior

CloudFront의 요청이 어떻게 처리되는지 정의하는 다양한 설정의 모음
경로 패턴 단위로 Behavior를 구성
- 예: files/, files/.png, *.png
- 경로 패턴 목록 중 처음으로 매칭된 패턴의 동작을 적용
- 신규 생성 시 *로 고정
주요 구성 내용
- Origin
- 뷰어 설정

Viewer 설정

Viewer 프로토콜
- CloudFront에 접근하는 프로토콜
- HTTP and HTTPS
- Redirect HTTP to HTTPS
- HTTPS Only
HTTP Method
- GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
뷰어 액세스를 제한: Presigned URL / presigned Cookie로만 접근 가능하도록 할 지 여부

Policy 설정

Cache Policy
- 어떤 키(HTTP Header, 쿠키, QueryString 등)으로 컨텐츠를 캐시하는지
- 얼마나 오래 캐시하는지(TTL)
- 컨텐츠 압축 저장 관련
Origin Request Policy
- Origin에 컨텐츠를 요청할 때 어떤 내용을 전달할 것인지(HTTP Header, QueryString 등)
- Cache Key로 사용할지 여부와 독립적으로 설정 가능
Response Headers Policy
- 응답 과정에서 어떤 HTTP Header를 제거하거나 더할지 설정
- 최대 10개
- Authorization Header만 따로 불가능
기타 설정
- Field Level Encryption: CloudFront의 컨텐츠를 보호하는 방법
- Lambda@Edge

Amazon CloudFront 파일 관리

CloudFront의 파일 관리

CloudFront의 파일은 크게 두 가지로 관리
- 싱글 파일: 파일명을 유지한 체로 캐시 만료 처리, 업데이트 등을 처리
  - 별도로 클라이언트 업데이트 필요 없음
  - 캐시 만료 전 제공 파일을 업데이트 하려면 Invaildation 필요
- 버저닝: 파일 이름에 다양한 방법으로 버전을 두어서 관리
  - 별도로 Invaildation 필요 없음
  - 파일 업데이트 시 클라이언트 업데이트 필요

* Invalidation

캐시 만료 전 파일을 갱신
버저닝이 아닌 형태로 파일을 제공할 경우 캐시 만료 전 새 파일을 제공하고 싶다면 Invalidation 필요
경로 기반
- 예: /img/img1.png, /img/, /img/img
한번에 최대 3000 파일까지 Invalidation 가능
- 예: 100개씩 30 Invalidations or 1000개씩 3 Invalidations
한 달에 1000 path Invalidations는 무료(계정 전체 Distribution 통합), 이후 한번 경로 당 $0.005

Amazon CloudFront 컨텐츠 보호(1)

컨텐츠 접근 제한

CloudFront에서 컨텐츠에 대한 접근 제한
CloudFront Origin에 대한 직접 접근 제한

CloudFront에서 컨텐츠 접근 제한

CloudFront에서 컨텐츠 접근 제한
- 예: 프리미엄 티어용 영상, 유저 전용 다운로드 이미지 등
두 가지 방법
- SignedURL: 권한 정보가 담긴 임시 URL을 발급하여 뷰어에게 전달하여 컨텐츠를 다운로드 할 수 있도록 허용
  - URL당 하나의 파일만 사용 가능
- Signed Cookie: 뷰어가 권한을 행사해 다운로드 할 수 있도록 컨텐츠 접근 권한을 가진 Cookie를 발급해 뷰어에 전달
  - 다수의 파일에 사용 가능
만료 기간 설정 가능

Signer

Signed URL/Cookie를 만들 권한을 가진 주체
두 가지 종류
- Trusted Key Group(추천): CloudFront에 Public/Private Key Pair 중 Public Key를 등록하고 가지고 있는 Private Key로 Presigned URL/Cookie를 생성하는 방식
- AWS Account(비추천): Root 사용자(IAM 사용자 불가능)로 계정의 CloudFront Key Pair를 다운받아 활용
  - AWS Root 사용자를 활용해야 하고, API를 사용할 수 없고, IAM을 통한 권한제어가 불가능함
CloudFront URL을 만들 때 Distribution 단위로 등록된 Key Group을 활용
- Key Group: Private/Public Key로 이루어진 키쌍의 집합으로 CloudFront에 업로드 하는 하나 이상의 Public Key로 구성

Presigned 정책

Presigned URL/Cookie를 만들 때 URL/Cookie의 권한을 설정하기 위한 정책
두 가지 종류
- Canned(미리 준비된) Policy: 간단한 버전, 만료 시간만 설정 가능. 단, URL이 짧아짐
- Custom Policy: 모든 제약사항 설정 가능
  - 정책으로 Presigned URL/Cookie의 동작 범위(만료 시간, IP 제한 등) 설정 가능

실습 - CloudFront 컨텐츠 보호: Presigned URL

Public/Private Key Pair 생성
openssl genrsa -out private_key.pem 2048
openssl rsa -pubout -in private_key.pem -out public_key.pem
CloudFront에서 Public Key 등록 후 Key Group 생성
.env 파일 PUBLIC_KEY_ID, KEYGROUP_ID에 각각 public key id, KeyGroup ID 등록
node18이상 설치
yarn 설치
npm install yarn -g
aws cli 설치 / aws configure
배포
yarn deploy --aws-profile [자신의 프로파일 명]
Systems Manager Parameter Store (Default 경로: /demo-cf-preigned-url/dev/private_key/1 )에 private key 내용 등록
Chrom창에 {endpoint}?path={S3 이미지 경로}&expire_in={만료시간} 입력

CloudFront 컨텐츠 보호(2)

Origin Access Control(OAC)

OAI와 함께 CloudFront를 거치지 않은 S3에 접근을 방지하기 위한 기능
- Origin Access Identity(OAI): 예전 방식, OAC를 권장
OAC는 일종의 Identity: IAM 사용자 혹은 IAM 역할과 비슷한 Identity
- 즉, S3에서 해당 OAC의 접근을 허용하고 CloudFront에서 OAC를 활용해서 S3와 소통
- S3에서 기본적으로 모든 접근을 차단하고 OAC의 접근만 허용
OAC는 Lambda Function URL에도 사용가능

Origin Access Control(OAC)의 세 가지 Sign 방법

CloudFront가 S3와 소통하기 위한 요청에 Sign 방법을 정의 가능
3가지 종류
- Sign Requests: CloudFront IAM Principle이 S3에 요청할 때 SigV4로 Sign
  - 즉, 요청에 자격증명을 활용해 필요한 정보로 Authorization Header를 구성 -> S3에서 해당 내용을 검증해서 자격이 있는 요청인지 확인 -> 요청 처리 or 거부
- Do not override authorization header: 클라이언트 Header가 있다면 사용, 없으면 새로 Sign
- Do not sign requests: Authorization Header를 사용하지 않음
  - 클라이언트가 항상 Sign을 통해 요청하거나 컨텐츠가 퍼블릭인 경우

지리적 배포 제한(Geo Restriction)

두 가지 접근 방법
- CloudFront 지리 배포 제한
  - Whitelist 혹은 Blacklist -> 나라별 기준
  - 모든 배포에 제한 사항 포함. 즉, 일부만 제한 걸기 불가능
    - IP 주소의 정확도는 99.8%
- 3rd Party 지리적 위치 서비스 사용
  - 커스터마이징 가능(예: 브라우저별, 쿠키별 등등)

Field-Level Encryption

CloudFront를 활용하여 실제 데이터를 처리하는 주체까지 데이터를 암호화해서 전달할 수 있는 방법
- HTTPS 통신과는 별도의 개념
Edge Location에서 받은 데이터 중 특정 데이터를 주어진 퍼블릭 Key로 암호화
이후 데이터를 처리하는 측에서 프라이빗 Key로 복호화하여 사용

실습 - CloudFront OAC 설정

실습 - Custom Origin 보호

방법1: Custom Header 활용
- CloudFront에서 Header 생성 -> Origin에서 해당 Header가 없으면 거부
방법2: Origin에서 CloudFront IP를 제외한 모든 트래픽을 차단

EC2 생성
CloudFront IP로 접근 가능한 보안그룹 생성
EC2에 새로 만든 보안그룹 적용
CloudFront 배포

Amazon CloudFront 모니터링

Amazon CloudFront 모니터링

CloudFront는 다양한 방법으로 모니터링 가능
- CloudWatch 지표(Metric)
- Access Log/Real Time Log

Amazon CloudFront CloudWatch 지표

CloudWatch를 통해서 다양한 지표(Metric) 제공
기본 지표와 추가 비용으로 활성화 가능한 지표
- 기본 지표
  - 요청 숫자 / Byte Downloaded / Byte Uploaded / 4xx,5xx,total error rate
- 추가 지표
  - Cache Hit Rate / Origin Latency / Error rate by Status Code{401,403,404,502,503,504}
- 추가 지표 비용은 고정이며 활성화 지표별로 한달에 한번 발생(per Distribution)
버지니아 리전(US-East-1)에서 확인

Amazon CloudFront Access Log

Access Log(Standard Log)
- S3 버킷을 지정해서 모든 유저의 요청을 로깅
- 실시간이 아니며 지연시간 발생
- Distribution 단위로 요청 받은 Edge Location에서 지속적으로 Log 파일을 만들어 S3 버킷을 Flush
- 시간 단위로 여러번 Flush
  - 최대 24시간 지연 가능
  - 심지어 아예 전송되지 않고 누락될 수 있음
  - 헤더와 쿠키의 크기가 20KB가 넘거나 URL이 8192bytes가 넘어갈 경우 CloudFront에서 요청을 별도로 parse하지 않고 처리. (즉, 이경우 로깅이 되지 않음. body는 문제 없음)

Real Time Log
- 약 초 단위의 지연시간으로 요청을 실시간으로 로깅
- CloudFront의 요청 로그를 실시간으로 처리할 수 있는 기능
  - Kinesis Data Stream으로 처리
  - 추후 Firehose 등으로 S3에 로그로 저장, RedShify/OpenSearch 등으로 분석 가능
- 추가 비용 발생
- 로그의 지연시간이 발생하거나 누락될 수 있음
- 설정 값
  - Smapling Rate: 요청 중 얼마만큼을(퍼센트) 받아볼 것인지에 관한 설정(1~100)
  - Fields: 로그 내용 중 실시간으로 받아볼 필드(Timestamp, client IP, Time to First Byte, Status Code, Host, Edge Location, Time Taken 등)
  - Cache 동작: 실시간 로그를 받아볼 패턴 단위의 동작(Behavior)
- Kinesis Stream 권한 설정에 IAM 역할 필요

실습 - CloudFront 로깅 확인

CloudFront + S3 Origin + OAC 프로비전 (S3 Static Hosting)
S3 버킷 생성, Kinesis 데이터 스트림, Firehose 스트림 생성
버킷 ACL 활성화 (버킷 -> 객체 소유권 -> 편집)
표준 로그 활성화
실시간 로그 활성화
요청을 보내고 확인

Amazon CloudFront 기타 기능

Staging Distribution

CloudFront의 업데이트 전에 Stage Distribution을 만들어 테스트/카나리 적용 가능
워크플로우
- 원본 Distribution에서 파생된 Stage Distribution을 생성
- Stage Distribution으로 Header/Weight 기반으로 트래픽 라우팅
- 검수가 완료되면 Stage Distribution을 원본으로 승격
Stage Distribution은 원본과 다른 설정 가능(중간 변경 가능)
- Cache 정책, Origin 설정, 에러 설정, 지역별 제한 등
- S3의 경우 OAC 설정 별도로 추가 필요
Stage Distribution과 원본은 별도로 캐시 관리
CloudFront 서비스에서 로드가 많을 경우 모든 요청을 Primary로 보내는 경우 발생 가능

WebSocket

별도의 설정 없이 기본적으로 WebSocket 프로토콜 지원
- Origin 서버의 지원 필요
다음 HTTP Header를 Origin으로 전달 필요
- Sec-WebSocket-Key
- Sec-WebSocket-Version
- Sec-WebSocket-Protocol
- Sec-WebSocket-Accept
- Sec-WebSocket-Extensions

실습 - AWS 인프라를 활용하여 인증서 없이 HTTPS 구현하기

일반적인 순서

HTTPS 인증서 구매/발급($10불 정도)
인증서 병합 및 설정
웹 서버에 인증서 설치
웹 서버 설정 변경
- HTTPS 적용
- HTTP 리다이렉션 등

AWS 인프라를 활용한 HTTPS 구현

AWS 인프라(CloudWatch, ALB)를 활용하여 HTTPS 연결을 제공하는 방식
- 둘 다 Route53 혹은 다른 방법의 도메인 제공 및 인증 필요
장점
- 인증서 비용 무료
- 여러 웹사이트에 적용 가능하며 대상/Origin 변경 등에 영향 없이 제공 가능
- 인증서 자동 갱신 등 관리가 쉬움
알아둘 점
- 조금의 추가 비용 발생
- 경우에 따라 HTTP 통신이 Public에 노출될 수 있음
기본적으로 배포 생성 시 CloudFront의 아이디가 포함된 도메인 제공
별도로 보유한 도메인을 부여해 CloudFront와 연결 가능
- Route53 / 다른 Registrar에서 도메인 보유 필요
- 이때 선택적으로 HTTPS를 사용해서 CloudFront에 접근하도록 설정 가능 (3가지 모드 가능)
  - HTTP/HTTPS 사용
  - HTTP를 HTTPS로 Redirect
  - HTTPS만 사용
사용 사례
- S3 Static Hosting 웹사이트의 HTTPS 제공
- 단순한 웹사이트 등의 HTTPS 혹은 ALB 등의 Origin을 둘 때 HTTPS를 CloudFront에서 받고 싶은 경우

CloudFront의 HTTPS 프로토콜 활용

ACM에서 SSL 인증서 발급 or Import 필요(US-EAST-1)
비용이 조금 더 비쌈
두 가지 모드
- SNI 지원 클라이언트만 지원: 무료. 단, 예전 브라우저의 경우 지원하지 않을 수 있음
- All Client: 모든 클라이언트를 지원하지만 CloudFront에 전용 IP 주소 부여 필요

Application Load Balancer를 활용한 HTTPS 제공

Application Load Balancer의 리스너에서 443 포트를 받아 처리
- HTTPS 통신을 ALB에서 받아 HTTP 프로토콜로 타겟 그룹에 전달하는 형식
ACM으로 SSL 인증서 Import 필요 (ALB가 있는 리전), 혹은 원한다면 자신이 보유한 인증서 Import 가능

주의할 점

인프라에서 Target/Origin까지 HTTP로 연결
- ALB는 Private 통신이 가능하기에 크게 문제는 없으나 CloudFront의 경우 Public 인터넷 통과
실제 Origin/Target 입장에서는 HTTP로 받기 때문에 HTTPS로 리다이렉션 등의 설정이 있는 경우 무한 리다이렉트 발생 등의 문제 발생