CloudFront란?

• Content Distribution Network(CDN)이다.
• 읽기 능력을 향상시키기 위해 컨텐츠는 엣지에 캐시 된다.
• 대략 200개 이상의 엣지가 전세계적으로 분포되어 있다.
• 배포된 서비스를 거부하는 등의 공격으로부터 보호하기 위한 방화벽을 만들어 DDos 공격을 막는다.
• 인증서를 로드해 HTTPS 엔드포인트를 expose 해주며 해당 트래픽을 암호화 해야 하는 경우 내부적으로 HTTPS로 애플리케이션과 통신한다.

만약 미국의 사용자가 호주의 S3 버킷에 있는 컨텐츠를 로드하려 한다면, 미국에 사용자가 많을수록 로딩 시간이 짧아진다. 왜냐하면, 한 번 가져온 이후에 미국의 엣지에(로컬에) 해당 컨텐츠를 캐싱하기 때문이다. 따라서, 이후에 또 컨텐츠를 요청하면 로컬 엣지에서 사용자에게 캐싱된 컨텐츠를 제공한다.

CloudFront - Origins

다른 CloudFront의 종류들에는 어떤 것들이 있을까?

• S3 버킷
  - 파일을 분산시키고 엣지에서 캐시하기 위해 사용하기 좋다.
  - 즉, S3 앞 단에 CloudFront를 붙여 사용하는 것이다.
  - S3 버킷의 OAI(Origin Access Identity)를 통해 보안을 강화할 수 있다. 이를 이용하면 S3 버킷이 CloudFront를 통해서만 통신하도록 만들 수 있다.
  - CloudFront는 이 때 S3 버킷에 파일을 업로드 하기 위한 입구로 사용된다.
  

• Custom Origin(HTTP)(사용자 지정)
  - Application Load Balancer(ALB)
  - EC2 instance
  - S3 website(S3 버킷과는 다르며 이 경우 S3 버킷을 정적 웹사이트로 지정해야 한다)
  - 사용자가 원하는 백엔드(ex. 온프레미스 인프라)

Custom origin 자세히 보기: EC2 & ALB origin

CloudFront 지리적 제한

• 블랙리스트와 화이트리스트에 제한하고 싶은 국가를 지정해 원하는 나라에서 들어온 IP만 접근하도록 할 수 있다.
  - 이 때, "나라"는 Geo-IP 데이터베이스를 통해 IP 정보를 얻을 수 있다.
• 예를 들어, 저작권 법 상 다른 나라의 접근을 막아야 할 때가 있다. 따라서, 미국에 있는 정보를 프랑스에서 얻으려고 하면 이를 제한해야 하는 상황이 오는 것이다.

CloudFront vs S3 cross region replication

CloudFront

• CloudFront는 글로벌 엣지 네트워크를 사용한다.
• TTL에 따라 파일이 캐시된다(보통은 하루).
• 전세계적으로 접근 가능해야 하는 S3 정적 컨텐츠가 있을 때 사용하기 좋다.

S3 cross region replication

• 이는 사용자가 replication 하고 싶은 각 지역에 대한 설정이 필요하다.
• 파일은 거의 실시간으로 업데이트 된다.
• 읽기 전용이기 때문에 읽기 속도를 향상시키는 데 도움이 된다.
• 적은 수의 지역에서 latency가 짧아야 하는 동적 컨텐츠에 사용하기 좋다.

CloudFront 생성하기

아래와 같이 미리 만들어 놓은 bucket을 선택한다.
이 때, 도메인명은 원하는 대로 커스텀 할 수 있다.

그리고 OAI를 이용할 것이기 때문에 아래와 같은 설정을 한다.

• Create new OAI를 클릭해 원하는 도메인에 대한 OAI를 생성한 뒤 생성한 OAI를 선택한다.
• 그 다음, bucket에 해당 정책이 업데이트 될 수 있도록 Yes를 클릭한다.
  - 그러면 처음에는 내 S3 버킷에 OAI를 허용하는 policy가 없었지만 생성 이후에는 정책이 업데이트 될 것이다.

생성 이후 확인해 보면 아래와 같이 정책이 추가 되었다.

• Principal(CloudFront OAI)에 해당하는 서비스가 Resource(S3 버킷)에 어떤 Action(Get Object)하는 것이 Effect(Allow) 되었다 라고 해석하면 된다.

CloudFront signed URL / Signed cookies

• 전세계적으로 프리미엄 유저만 특정 URL에 접근하도록 하고 싶을 때 설정할 수 있다.
• 아래의 정책을 추가하여 만들 수 있으며 정책에는 아래 내용이 들어가야 한다.
  - 쿠키 또는 URL이 만료되는 시점
  - 허용할 IP 범위
  - 신뢰할 수 있는 서명자(trusted signers): 서명된 URL을 생성할 수 있는 AWS 계정 명시
• signed URL은 얼마 동안 유효해야 할까?
  - 공유 컨텐츠(영화, 음악): 몇 분 정도로 짧게 설정
  - 개인 컨텐츠: 수년간 유효하도록 설정
• signed URL와 cookies의 차이
  - Signed URL: 개별 파일에 대한 액세스를 제공한다. 즉, 파일 하나 당 하나의 URL을 얻는다.
  - Signed Cookies: 여러 개의 파일에 액세스 할 수 있으며 재사용이 가능하다.

아래와 같은 구조로 Signed URL을 생성하고 사용하며 이는 Signed Cookies에서도 마찬가지이다.

Signed URL vs S3 Pre-signed URL

Signed URL

• Signed URL은 origin으로 S3 버킷 뿐만 아니라 HTTP, 백엔드 등 원하는 것을 사용할 수 있다.
• 이는 계정을 기반으로 한 key-pair이기 때문에 루트 계정만이 관리할 수 있다.
• IP, path, 날짜, 만료일 등을 통해 필터링 할 수 있다.
• 모든 캐싱 기능을 사용할 수 있다.

S3 pre-signed URL

• S3 pre-signed URL을 발급 받은 사람의 자격으로 요청을 발행한다.
• 만약 내가 나의 IAM principal을 이용해 URL에 서명하고 또한 이를 위해 나의 IAM key를 이용한다면 해당 pre-signed URL을 가진 사람은 나와 같은 권한을 갖게 된다.
• 제한된 수명을 갖는다.
• 클라이언트가 pre-signed URL을 이용해 S3 버킷에 직접 액세스할 수 있다.
  - Cognito를 이용해야 한다는 어려움이 있을 수는 있다.

Pricing

• 위치당 데이터 출력 비용은 다양하다.
• 전송되는 데이터 용량이 클수록 비용은 절감된다.

Price classes

• 비용을 줄이기 위해 엣지 로케이션 수를 줄일 수 있다.
• 3가지 가격 등급이 있다.

1. Price Class All
   • 모든 리전에서 사용 가능
   • 가장 높은 성능
     
2. Price Class 200
   • 대부분의 리전에서 사용 가능
   • 가장 비싼 리전들(ex. 인도) 제외
3. Price Class 100
   • 가격이 가장 싼 리전들만 사용 가능

Multiple Origin

• 컨텐츠 타입에 따라 서로 다른 origin으로 라우팅 되도록 설정할 수 있다.
• 아래와 같이 path 패턴에 따라 라우팅 할 수 있다.
  

Origin Groups

• 이는 가용성을 높이기 위한 방법으로, 하나의 origin이 실패한 경우 장애 조치를 수행할 수 있다.
• Origin Groups는 Primary Origin과 Secondary Origin으로 그룹을 나눌 수 있다.
  - 만약 Primary Origin에 장애가 생기면 CloudFront는 Secondary Origin으로 장애 조치를 시도한다.
  - S3 버킷이 Origin인 경우 Primary와 Secondary 간에 replication 설정을 할 수 있다. 이 덕분에 Primary에 장애가 나면 Secondary에 요청해서 같은 결과를 얻을 수 있다.
• CloudFront에서 무료로 Grouping을 할 수 있다.

Field-level Encryption

• 이는 application stack을 이용해 민감 정보를 보호하기 위한 방법이다.
• HTTPS와 더불어 Field level Encryption을 통해 보안을 높일 수 있다.
• 민감 정보가 전송 되는 경우 엣지 로케이션이 이를 암호화 할 것이다.
  - 해당 정보는 private key에 접근해야만 복호화가 가능하다.
  - 암호화에는 비대칭 암호화가 이용된다.
• 예를 들어, 만약 POST 요청이 CloudFront로 들어 오면 암호화 해야 하는 필드가 존재하며 해당 필드는 최대 10개까지 존재할 수 있다(ex. 신용카드).
  • CloudFront는 공개 키를 이용해 암호화를 진행한다.

아래의 그림은 신용 카드 정보 웹 서버로 보내는 과정을 도식화 한 것이다.

• CloudFront는 public key를 가지며 이를 통해 암호화를 진행한다.
• 웹 서버는 private key를 가지며 이를 이용해 복호화 해 신용카드 번호를 조회할 수 있다.

AWS Global Accelerator

Global Accelerator는 Anicast IP를 사용한다.

Unicast IP vs Anicast IP

Unicast IP

• 아래와 같이 한 서버는 하나의 IP 주소를 가지며 클라이언트는 IP 주소에 따라 서버에 요청을 보낸다.

Anicast IP

• Anicast의 경우 각 서버는 동일한 IP를 가지며 클라이언트의 요청은 가장 가까운 서버로 라우팅 된다.

AWS Global Accelerator란?

• 사용자의 application으로 라우팅 하기 위해서 AWS 내부의 네트워크를 사용할 수 있다.
• 사용자의 application을 위해서 2개의 Anycast IP가 생성 된다.
• 이렇게 생성된 Anycast IP는 사용자와 가장 가까운 엣지 로케이션으로 트래픽을 전송한다.
  - 그러면 엣지 로케이션은 해당 트래픽을 사용자의 application으로 전송한다.
  - 이후 안정적인 private AWS network를 통해 전송되며 더 낮은 지연시간을 갖게 된다.
• AWS Global Accelerator는 두 개의 고정 IP를 전세계 유저에게 제공한다.

AWS Global Accelerator 특징

• AWS Global Accelerator를 함께 사용할 수 있는 서비스:
  - Elastic IP, EC2, ALB, NLB, private 또는 public
• 일관된 성능을 지님
  - 지연 시간이 낮은 곳으로 지능적으로 라우팅을 한다.
  - 장애 발생시 빠른 대응이 가능하다.
• Anycast IP는 변경되지 않기 때문에 클라이언트 캐시에 대한 문제가 없다.
• 엣지 로케이션을 향하는 AWS 내부 네트워크이다.
• 헬스 체크 기능이 있다.
  - 앱이 글로벌 하게 작동할 수 있도록 도와 준다.
  - 만약 하나의 ALB와 하나의 리전에 장애가 있다면 1분 이내에 정상 엔드 포인트로 라우팅 된다.
• 보안이 우수하다.
  - 2개의 외부 IP만 whitelist에 추가되기 때문이다.
  - AWS shield를 통해 DDos 공격으로부터 보호할 수 있다.

Global Accelerator vs CloudFront

공통점

• 둘 다 AWS 글로벌 네트워크와 전세계의 엣지 로케이션을 사용한다.
• 둘 다 AWS shield와 통합해 DDos 공격으로부터 보호한다.

차이점

1. CloudFront

   • 캐시 가능한 정적 컨텐츠 뿐만 아니라 동적 컨텐츠(API 가속화 및 동적 사이트 제공)에 대한 성능을 향상시키는 기능을 한다.
   • 컨텐츠가 엣지에서 제공된다.
     - 가끔씩 엣지 로케이션은 origin에서 컨텐츠를 가져오지만 대부분은 캐시된 데이터를 제공한다.
     • 따라서 유저 역시 엣지 로케이션에서 컨텐츠를 가져오게 된다.

2. Global Accelerator(새로운 개념)

   • TCP 또는 UDP를 통해 광범위한 앱들의 성능을 향상시킨다.
   • 하나 이상의 AWS 리전에서 실행되는 애플리케이션으로 엣지에서 패킷을 프록시(대리) 한다.
     - 따라서, 사용 가능한 캐싱 기능이 없다.
   • HTTP가 아닌 경우 즉, 게임, IoT, Voice over IP와 같은 것들에 이용하기 좋다.
   • 전세계적으로 고정 IP가 필요한 HTTP에 사용하는 것도 좋다.
   • 빠른 장애 조치를 위해 사용할 수도 있다.

오답노트