[SAA] CloudFront 개요

AWS CloudFront

• 컨텐츠 전달 네트워크인 CDN으로 판독 능력을 향상시키는 것으로 컨텐츠가 엣지 로케이션에서 분배 및 캐시
• 전세계적으로 216개의 엣지 로케이션이 존재하며 지속적으로 새로운 지점이 추가되고 있음
  예1) 호주에서 S3 버킷이 있고 미국의 사용자가 여기로 액세스하려면
  미국에서 가까운 엣지 로케이션에 액세스한 뒤 네트워크가 사설 AWS 네트워크를 통해 S3 버킷까지 전송되고 콘텐츠가 캐시됨
  만약 미국에 이러한 사용자가 많아질수록 동일한 읽기를 원하는 사람들이 많아져
  미국에서 직접 제공되는 콘텐츠를 얻을 수 있게 됨 (콘텐츠가 미국에서 패치되고 제공되면 현지에서 캐시됨)
  예2) 아시아에 있는 다른 사용자가 아시아에서 가까운 엣지 로케이션으로 통신을 하면
  엣지 로케이션이 S3 버킷으로 트래픽을 지원하여 콘텐츠를 얻고 엣지에서 캐시
  
  클라우드 프론트는 이처럼 다양한 엣지 로케이션에 기반해 읽기를 전세계에 배포하여 메인 S3 버킷에서 지연 시간과 로드를 줄임
  
  

  

• 엣지에서의 캐싱 외에도 서비스 거부를 배포하는 공격으로 보호막과 웹 애플리케이션 방화벽을 제공하는 DDoS 보호도 제공
  그러므로 보안이 철저하고 애플리케이션을 전 세계적으로 배포하기에 좋은 프론트
• 인증서를 로드하여 외부 HTTPS 엔드 포인트를 노출하고 해당 트래픽을 암호화해야 하는 경우
  내부 HTTPS에서 애플리케이션에 내부적으로 통신하게끔 해줌

CloudFront – Origins

• S3 버킷
  S3 앞에서 클라우드 프론트를 사용하는 것은 전 세계에 파일을 배포하고 엣지에서 캐시할 때 흔히 볼 수 있는 패턴으로
  오지린 액세스 신분(Origin Access Identity : OAI)으로 클라우드 프론트와 S3 버킷 사이의 보안을 강화하므로
  이를 통해 S3 버킷이 오직 클라우드 프론트하고만 소통할 수 있게 해 줌
  또한 세계 어디서든 파일을 S3에 업로드할 입구처럼 클라우드 프론트를 사용할 수 있음
• 커스텀 오리진 (Custom Origin)
  이 때는 HTTP 엔드 포인트가 있어야 하며 HTTP 프로토콜을 준수하는 무엇이든 될 수 있음
  예) 로드 밸런서, EC2 인스턴스, 정적 S3 웹사이트로 버킷이 활성된 S3 웹사이트 등으로
  원하는 모든 HTTP 백엔드가 가능해져 사내에 있는 인프라 등에 사용할 수 있음
  

CloudFront at a high level

• 클라우드 프론트의 전반적인 작동 방식
  전세계 여러 곳에 엣지 로케이션이 있고 이들은 우리가 정의한 오리진으로 연결되어 잇음
  클라이언트가 클라우드 프론트 분산으로 액세스하려는 경우 클라이언트는 을라우드 프론트에 직접 HTTP 요청을 보냄
  이 때의 HTTP 요청은 URL과 쿼리 스트리 매개변수, 요청 헤더 등으로 이루어짐
  그러면 엣지 로케이션이 요청을 오리진으로 전달하고 오리진이 정의된 캐시 설정에 따라 엣지 로케이션에 회신 내용을 캐시
  그리고 다음 번에 다른 클라이언트가 비슷한 요청을 하면 엣지 로케이션은 요청을 오리진으로 전달하기 전에
  우선 캐시를 살펴 보게 되는데 이러한 작업이 바로 CDN의 목적
  
  

CloudFront – S3 as an Origin

• 오리진으로서의 S3
  클라우드가 있고 오리진인 S3 버킷이 있으며 엣지 로케이션은 로스엔젤레스에 있을 때
  엣지 로케이션으로부터 데이터를 읽으려하는 몇몇 사용자들이 있으면
  엣지 로케이션이 사설 AWS 네트워크를 통해 S3 버킷에서 데이터를 가져와서 해당 엣지 로케이션으로부터 결과를 제공
  이 때 S3 버킷에 액세스하려면 클라우드 프론트 오리진에 대한 IAM 역할인 오리진 액세스 신분(OAI)를 사용해야 하며
  이를 이용해 S3 버킷에 액세스한 뒤 버킷 정책이 이 역할의 액세스를 허용하면 파일을 클라우드 프론트로 전달하여
  전 세계의 모든 엣지 로케이션에 S3 버킷에 캐시된 콘텐츠를 제공하므로 CDN으로서 굉장히 유용
  
  

CloudFront – ALB or EC2 as an origin

• 오리진으로서의 ALB/EC2은 위와 달리 보안 부분이 조금 달라짐
  EC2 인스턴스는 HTTP를 통해 공용 액세스가 가능하게끔 공용(public)이어야 하며 
  전 세계에 있는 사용자들이 엣지 로케이션에 액세스하면 엣지 로케이션은 EC2 인스턴스로 액세스하며 보안 그룹을 지나치므로
  보안 그룹은 클라우드 프론트 엣지 로케이션의 IP를 EC2 인스턴스 내로 허용해야 함
  
  

  

  
  즉, 보안 그룹이 엣지 로케이션의 모든 공용 IP에 클라우드 프론트가 EC2 인스턴스로부터 컨텐츠를 가져갈 수 있게끔 허용 필요
  ALB는 해당 ALB에 대한 보안 그룹이 있고 클라우드 프론트가 액세스할 수 있도록 공용이어야 하지만 EC2는 사설이어도 가능함
  따라서 EC2 인스턴스에 대한 보안 그룹은 로드 밸런서의 보안 그룹을 허용해야 하며
  ALB의 경우 엣지 로케이션의 공용 IP를 허용하여 공용 로케이션인 엣지 로케이션을 액세스할 수 있도록 해야 함
  
  

CloudFront Geo Restriction

• CDN으로서의 클라우드 프론트는 지리적 제한 기능이 존재하며 분산으로의 액세스에 제한을 둘 수 있음
• 화이트리스트를 제공하여 이 리스트에 있는 허용된 국가의 사용자들만이 클라우드 프론트에 액세스 가능
• 혹은 블랙리스트를 만들어서 특정 국가의 사용자들이 분배에 액세스할 수 없도록 할 수 있음
• 제3자 회사의 지리적 IP 데이터베이스를 이용해 국가들의 허용 여부가 결정되며 수신되는 IP와 리스트를 비교하여 국가를 알아냄
• 특정 콘텐츠에 액세스를 제한하는 저작권법이 있을 때 이를 사용할 수 있음
  예) 미국의 콘텐츠에 프랑스로부터의 액세스를 제한하고 싶을 때 사용

CloudFront vs S3 Cross Region Replication

• 클라우드 프론트는 세계적인 엣지 네트워크를 사용하고 TTL에 맞춰 파일이 캐시되므로
  전세계에서 이용 가능해야 하는 정적인 콘텐츠에 적합하며 콘텐츠가 약간 오래되어도 괜찮은 경우에 사용
• S3 리전 간 복제는 복제가 일어나도록 할 각 리전에 설정되어야 하며 파일이 거의 실시간으로 업데이트되고 읽기 전용이므로
  읽기 성능이 좋아 적은 수의 리전에서 낮은 지연 시간으로 사용이 가능해야 하는 동적인 콘텐츠에 적합
• 즉, 전세계 대상 vs 선택된 리전 대상

<CloudFront with S3 실습>

• S3 버킷을 생성
  eu-west-1에 demo-cloudfront-stephane-v2라는 이름의 버킷을 모든 공용 액세스 차단을 선택하여 생성하여
  이 버킷은 웹 사이트를 호스트할 버킷이 됨
  
  index.html, beach.jpg, coffee.jpg 세 개의 파일을 버킷에 업로드한 후 파일에 액세스하는 방법에는 2가지가 존재
  객체 URL을 사용할 수도 있지만 버킷이 공용이 아니기 때문에 이 방법은 액세스 거부가 되며
  반면 Open을 누르면 미리 서명된 URL을 생성하여 접근할 수 있음
  
  이번 실습에서는 클라우드 프론트를 통해 파일로의 액세스를 허용하도록 함
• 클라우드 프론트 배포
  클라우드 프론트는 리전 선택이 필요없는 글로벌 서비스이므로 전세계에 배포됨
  첫 번째 배포를 만들고 오리진 도메인을 선택하는데 여기에는 다양한 옵션으로 S3, ElastiCache, 로드 밸런서 등이 존재하며
  오리진 도메인 이름을 넣어 커스텀 HTTP 오리진의 설정도 가능함
  이번 실습에는 S3를 사용하여 미리 만들어둔 버킷을 선택하면 오리진 이름이 지정되며 OAI(오리진 액세스 신분)를 생성하여
  클라우드 프론트가 이 신분을 사용해서 S3 버킷에 액세스할 수 있게 하며
  S3 버킷의 버킷 정책을 편집해서 OAI로의 읽기 액세스를 허용할 수 있음
  그리고 기본 루트 객체의 경우에는 루트 URL 사용에서 뷰어 요청에 반환할 파일 이름을 지정해야 하기 때문에
  index.html을 입력한 후 생성하여 배포
  
  

• 클라우드 프론트 배포 작동 확인
  생성된 분산 도메인 이름을 복사해 새로운 탭에 입력하면 메시지와 coffee.jpg 파일이 나오게 되며
  이는 클라우드 프론트 분산이 제대로 작동 중임을 보여줌
  현재 S3의 URL로는 여전히 파일에 직접 액세스가 불가능하므로 파일에 액세스할 유일한 방법을 클라우드 프론트
  
  이렇게 클라우드 프론트는 S3에 있는 콘텐츠를 배포하여 액세스할 수 있으며
  이러한 파일들이 캐시되어 있기 때문에 페이지는 S3에서 제공되는 것이 아니라 클라우드 프론트 엣지 로케이션에서 직접 제공됨
  그러므로 요청들이 S3로 전달될 필요 없이 클라우드 프론트 엣지 로케이션에 캐시되어 있는 상태임을 알 수 있음
  
  그리고 S3의 버킷 정책을 다시 살펴보게 되면 비어있던 부분이 채워져 있으며
  이를 통해 클라우드 프론트 오리진 액세스 신분 Principal로 S3 버킷 내의 모든 리소스에 대한 객체를 얻게끔 해줌을 알 수 있음
  이 신분은 클라우드 프론트가 S3 버킷에서 콘텐츠를 얻고 공용 URL로 분산이 가능하도록 허용