글쓰는 감자

보통 CloudFront는 S3와 같이 다니는 짝꿍이라고 생각하면 된다.

S3 안의 content를 캐시를 해주는 CDN 서비스 느낌?

어쨌든, 장점을 정리해보자!

• Static Content Delivery

아마 이게 제일 잘 알려진 장점일 것 같다.

위에서도 언급했듯 캐시를 활용해 빠르고 안전하게 정적 콘텐츠를 전송한다.

• Dynamic Content Delivery

이 경우는 아직까지도 잘 모르겠다.. 동적으로 사용되는 콘텐츠라 캐시가 의미가 없다.(TTL=0)

보통 전송 성능 향상된다고 하는데.. 

(전체 응답 시간: DNS Lookup + TCP Connection + Time To First Byte + Contents Download)

사용자와 Edge 간 연결 시 최적의 루트이고 Origin과의 지속적인 연결 유지, Gzip 압축 사용 등이 있다고 하긴 한다.

사실 나에겐 잘 와닿진 않는다! 😑

그래도 비용적인 측면에서 많은 도움이 된다. aws 리소스들과 cloudfront 연결 까지의 비용은 들지 않고 cloudfront와 사용자 간의 비용이 들기 때문에 비용 절감엔 도움이 될 듯...?

• Origin Selection

단일 배포에서 여러 Origin의 Contents를 경로 패턴으로 처리 가능하다.

멀티 오리진 사용할 때 비용 절감에 도움을 많이 줄 것 같다!(보통 alb(웹) + S3(이미지/동영상) 이렇게 많이들 사용하는듯?)

• Cross-Origin Resource Sharing(CORS)

원본 리소스 쉐어링을 통해 같은 도메인에서 서비스가 가능하다.

웹 브라우저에서 보안상의 이유로 도입되었다.

(사용자가 접속한 웹 애플리케이션이 다른 오리진에서 리소스를 불러올 때 해당 헤더를 보내주지 않으면 브라우저가 그 리소스를 거부하는 보안 정책)

참고로, Origin에도 CORS 설정 해주고, CloudFront에도 CORS 설정이 필요함.

• HTTPS Support

SSL 인증서를 활용해 HTTPS를 지원해준다.

사용자 입장에선 CloudFront 뒷단에서 어떻게 통신하는지 몰라도 되는 그런 느낌..

Browser - (HTTPS) - CloudFront - (HTTP) - Origin(ELB - EC2) 이런 느낌..!

• Signed URL, Signed Cookie

배포되는 Contents에 대한 보호 및 세부 제어 가능

유료 콘텐츠를 제공할 때 사용하면 괜찮음(인증된 사용자에게만 콘텐츠를 주는 느낌~, 유튜브 팬가입에 활용 가능)

• Origin 보호

사용자가 직접 오리진으로 접근하지 못하게 막아줌(CloudFront만 접근 가능)

S3의 경우 OAI(Origin Access Identify)를 사용해 접근을 막는다.

(OAI: S3 버킷에서 프라이빗 객체를 가져올 수 있는 CloudFront 배포 권한을 부여하는 데 사용되는 가상 사용자 ID, 퍼블릭 액세스를 막을 수 있음. 정적 웹 호스팅으로 하게 되면 퍼블릭으로 버킷이 열림.)

• WAF(Web Application Firewall)

해당 서비스와 통합되어 L7 의 공격으로부터 사이트 보호가 가능하다.

웹 ACL 연결해서 방어하는 느낌!

• Route 53 호스팅 영역에 레코드 생성

(현재 나는 aws 상에 호스팅 영역이 있다. 구매했었음.)

호스팅 영역에 들어가 레코드 생성을 해보자.

원하는대로 설정해준다..

나는 CloudFront로 해당 도메인을 사용해 정의할 예정이다.(CloudFront 배포를 이미 생성했음.)

• CloudFront 배포 설정

생성해둔 배포 설정으로 들어간다.

대체 도메인 이름에 아까 Route 53에서 생성했던 레코드를 넣어주고 해당 사용자 정의 SSL 인증서도 받아야 한다.

• AWS ACM 인증서 생성

AWS ACM을 통해 쉽게 생성이 가능하다. ACM을 생성할 땐 해당 인증서로 들어가서 인증서에 맞게 레코드 생성을 또 해줘야 한다.(Route 53 레코드에 해당 인증서에 대한 CNAME 레코드가 생성되어야 함.)

변경 사항을 저장하고 조금 더 기다린 뒤에 대체 도메인 이름을 사용해 들어가보자!

CloudFront + S3 배포

• S3 버킷 생성

버킷 이름만 정해주고 버킷을 생성한다.(다른 옵션들은 나중에 다뤄볼 것!)

test page를 작성해 객체 업로드(진짜 간단하게 작성해도 괜찮다.)

• CloudFront 배포 생성

해당 원본 도메인을 방금 생성한 버킷 도메인으로 설정한다.

다음으로 S3 버킷 액세스는 OAI를 사용할 수 있도록 체크하고 제어 설정 생성을 해준다.

(왜 갑자기 S3 버킷 정책을 수동으로 업데이트 하게 되는지 모르겠지만... aws가 업데이트가 되었나?)

CloudFront와 S3는 HTTP 연결을 하고 있고 우리가 할 최종 목표는 사용자와 CloudFront의 HTTPS 연결이니까 프로토콜을 Redirect로 해주자.(상황에 맞춰서 설정해주면 된다.)

기본값 루트 객체를 써 넣으면, 도메인 뒤에 따로 써주지 않아도 처음 들어갔을 때 해당 객체로 들어간다.

배포 생성을 누르면 아래와 같이 정책을 업데이트 하라고 뜨는데 해당 정책 복사를 클릭하고 업데이트 해주면 된다.

• S3 버킷 정책 업데이트

버킷 권한에서 버킷 정책을 편집하면 된다. 아까 복사해뒀던 정책을 넣어주자.

배포가 완전히 적용될 때 까지 잠깐 기다렸다가 생성한 배포 도메인을 복사해 붙여주면 원하는 test page를 확인할 수 있다.

CloudFront + EC2 배포

• EC2 생성

원하는 웹페이지나 테스트 페이지를 넣고 EC2에 올린다.(이거는 가볍게 apache 서버 올려서 테스트를 진행했다.)

보안 그룹이나 이런 것들도 잘 열어줘야 한다..(HTTP(80), HTTP(443), TCP(8080), SSH(22))

해당 인스턴스의 퍼블릭 IPv4 DNS를 복사해두자. (어차피 테스트 용으로 만든 거라 삭제 예정)

• CloudFront 배포 생성

S3와 같이 원본 도메인에 해당 복사해둔 퍼블릭 IPv4 DNS를 넣어주자.

(현재는 테스트라 ec2로 했는데 이중화를 원하거나 가용성을 원하면 ALB 구성이 필요하다.)

프로토콜 역시 원하는대로 선택하고 그냥 배포 생성하면 된다.

이것 또한 배포 도메인으로 웹 페이지를 확인할 수 있다.

CloudFront + EC2 + S3 (Multi Origin) 배포

아까 생성했던 CloudFront + EC2 배포에 추가 해보자.

해당 배포로 들어가 원본을 추가하자.

• 원본 생성

아까 설정했던 대로 S3 버킷 정책 업데이트까지 진행하자.

• 동작 생성

경로 패턴의 경우 아까 난 S3 버킷에 test.html 파일을 넣어두었기 때문에 해당 경로로 설정했다.

상황에 맞게 경로를 설정하자.

해당 설정까지 마치면 원본 2개, 동작 2개가 있어야 맞다.

조금 기다린 후 배포도메인만 사용하면 ec2의 화면이, 배포도메인/test.html 로 들어가면 s3의 화면이 나온다.