woongs dogfoot

CloudFront

• CloudFront : CDN (Content Delivery Network), 웹사이트의 컨텐츠들을 서로 다른 edge location에 캐싱하여 읽기 성능을 높임
  
  
  

• 특징

1. 전세계 216개의 edge location 활용
2. 컨텐츠가 여러 location에 분산되어 있어 DDoS(동시에 모든 서버가 공격받는 방식) 공격에서 보호받을 수 있음
   
   
   

• 미국의 사용자는 주변 edge location에 호주에 있는 S3 Object를 요청하면, edge location을 통해 호주의 S3 Bucket에 접근함 -> 그후 해당 컨텐츠는 edge location에 캐싱되어 다른 미국 사용자가 바로 받아올 수 있음
  
  
  

• Origin(AWS 인스턴스를 말하는 듯) 제공 방식

1. S3 Bucket으로 CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 설정 (CloudFront를 생성하면서 origin 선택) -> S3 Bucket에는 CloudFront만 접근할 수 있게 설정 -> OAC (Origin Access Control) 활용 (Legacy OAI (Origin Access Identity) 대체) -> CloudFront의 접근권한은 S3 Bucket 권한에 따름 -> CloudFront에서 OAC 활성화 후, CloudFront를 허용하는 S3 Bucket policy를 선택해주면 됨
2. Ingress : CloudFront를 통해 S3 Bucket으로 데이터를 보낼 수 있음
3. S3 Bucket 말고도 Load Balancer, EC2 등의 HTTP Origin을 제공받을 수 있음
   
   
   

• CloudFront 동작방식 : client가 Edge location에 get 요청을 보내면, edge location의 CloudFront는 해당 객체가 캐싱되어 있는지 먼저 확인 -> 캐싱되어 있지 않는 경우, 원본 origin으로 가서 객체를 가져옴 -> 가져온 객체는 캐싱됨

• Origin이 CloudFront에 의해 Object를 전달할 경우, 해당 origin은 OAS(Origin Access Control)에 의해 관리되고, S3 Bucket policy와 같은 개별 origin policy에 의해 접근을 제어

• CloudFront (정적 컨텐츠) vs S3 Cross Region Replication (동적 컨텐츠도 포함)

ALB or EC2 as an Origin

• EC2 : public EC2 필수, edge location의 public ip가 EC2에 접근할 수 있도록 Security Group을 설정해줘야 함

• ALB : private EC2 가능 (public ALB와 연결 가능), public ALB 필수, edge location의 public ip가 ALB에 접근할 수 있도록 Security Group을 설정해줘야 함

Geo Restriction

• Geo Restriction : 지역에 따라 Object 접근을 제한하는 기능 -> 접근이 가능한(Allow List) 또는 불가능한(Block List) 지역 list를 만드는 방식
  
  
  

• Use cases : 컨텐츠 저작권법으로 인한 제한이 필요할 때 등

• CloudFront의 Geographic restrictions에서 설정 가능
  
  
  

Pricing

• Edge Location마다 데이터 전송 비용이 상이
• Price Classes (global Edge location 수를 줄이는 방식으로 가격 절감)

1. Price Class All : 모든 region 대상
2. Price Class 200 : 가장 비싼 region을 제외한 대부분의 region 대상
3. Price Class 100 : 저렴한 region 100개만 대상

Cache Invalidations (무효화)

• Cache Invalidations : 전체 또는 일부의 cache를 새로고침하여 캐시의 TTL을 모두 삭제하는 기능 (특정 Object 대상 전달 필요)
• CloudFront는 백엔드의 업데이트 사항을 인지하지 못함 -> TTL로 캐시가 만료되기 전까진 백엔드의 업데이트 사항을 못받음 -> Cache Invalidations 활용

Global Accelerator

• 문제 상황

1. global application을 global 사용자들이 접근함
2. application은 하나의 region에만 배포되어 있음
3. 하나의 region에만 있기 때문에 전세계 사용자가 해당 ALB로 public internet을 통해 접근하게 되면 상당한 지연시간 발생
4. public internet으로 인한 지연시간을 최소화하기 위해 AWS Network 활용 필요 -> Global Accelerator 활용

• Unicast vs Anycast

1. Unicast : 하나의 client 한 개의 Server IP일 때, 해당 IP로 접근하게 되면 해당 Server로 접근
2. Anycast : 하나의 client 한 개의 Server IP이고, 여러 서버가 한 개의 Server IP를 공유할 때, client가 해당 ip로 접근하게 되면 동일 ip를 공유하는 다수의 Server중 client로부터 가장 가까운 서버로 접근하게 됨 -> Global Accelerator의 원리
   
   
   

• Global Accelerator

1. 두 개의 고정 ip 제공 -> 보안성 확보
2. 두 개의 고정 ip에 요청 시, Anycast원리대로 edge location을 통해 AWS 네트워크를 거쳐 application에 요청이 전달됨
3. Elastic IP, EC2, ALB, NLB가 활용됨
4. 아무것도 Caching하지 않음
5. HTTP가 아닌 서비스에 유용

• Health Checks

1. Global Accelerator가 application에 대한 Health Check 진행
2. 특정 Region의 ALB에 대한 Health check에 실패하면, Global Accelerator의 정상 endpoint로 자동화된 장애조치 진행
   
   
   

• Global Accelerator vs CloudFront

• 실습 -> 생성된 Global Accelerator의 Listener로 테스트 시, 현재 위치와 가까운 Region의 Endpoint로 redirect 됨 (Global Accelerator의 Listener로 요청 -> 가장 가까운 edge location -> edge location에서 가까운 endpoint로 routing -> 해당 endpoint의 application에 접근)

1. Global Accelerator 생성
2. Listener 설정 (포트/TCP/UDP 등)
3. Listener를 통해 접근할 Endpoint group 설정 (Endpoint group은 Target application이 있는 Region)
4. Endpoint group의 Endpoint 설정(target application), Endpoint type은 ALB/NLB/EC2/Elastic IP 중 택 1