학습주제
네트워크
CloudFront
학습내용
클라우드 프론트는 CDN서비스를
콘텐츠, 영상, 이미지를 좀 더 빨리 업로드해서 뷰나 처리속도를 빠르게 해줌
먼 거리의 서버까지 가지 않고 지근거리에서 캐싱의 개념으로 빠르게 서비스를 가져갈 수 있는 서비스.
실제 사용 상황에서는 CNAME 레코드를 DNS 설정에서 사용합니다. 다음은 간단한 예시입니다:
도메인을 가지고 있고, 이 도메인의 특정 서브도메인(예: blog.mywebsite.com)이 다른 서버나 서비스(예: myblog.someblogplatform.com)에 위치해 있을 때, 사용자가 blog.mywebsite.com을 방문하면 실제로는 myblog.someblogplatform.com의 컨텐츠를 보게 됩니다.
이를 위해 DNS 설정에서 CNAME 레코드를 만들어, blog.mywebsite.com을 myblog.someblogplatform.com에 매핑합니다.
이제 사용자가 웹 브라우저에 blog.mywebsite.com을 입력하면, DNS 시스템은 CNAME 레코드를 확인하고 사용자를 myblog.someblogplatform.com로 이동시킵니다.
이것이 CNAME 레코드의 실제 사용 예시입니다. 웹 호스팅 서비스나 클라우드 서비스를 사용하면서 자체 도메인을 사용하려는 경우에 흔히 이러한 방식을 사용합니다.
CNAME 레코드는 DNS 설정에서 관리되며, 각 도메인 등록업체나 DNS 서비스 제공업체에서 제공하는 도구를 사용하여 생성하고 관리합니다. Amazon Route 53, Google Domains, GoDaddy 등이 이에 해당합니다.
참고로, CNAME 레코드는 도메인의 특정 부분(서브도메인)만을 다른 도메인으로 리디렉션하는데 사용됩니다. 전체 도메인을 다른 IP 주소로 매핑하려면 A 레코드를 사용합니다.
Amazon Certificate Manager (ACM)는 SSL/TLS 인증서를 발급할 때, 해당 도메인이 사용자에게 속해있다는 것을 확인해야 합니다. 이를 위해 ACM은 '도메인 소유권 검증'이라는 과정을 거칩니다.
이 도메인 소유권 검증에서 ACM은 사용자에게 특정 CNAME 레코드를 DNS 설정에 추가하라는 지시를 합니다. 이 CNAME 레코드는 특정한 형태와 값을 가지며, 이는 ACM이 특정 도메인이 사용자에게 속해있음을 확인하는 데 사용됩니다.
예를 들어, 사용자가 'mywebsite.com' 도메인에 대한 SSL/TLS 인증서를 ACM으로부터 요청한다고 가정해봅시다. ACM은 사용자가 'mywebsite.com' 도메인의 소유자임을 확인하기 위해, 사용자에게 DNS 설정에 추가할 특정한 CNAME 레코드를 제공합니다.
이렇게 하면, ACM은 사용자가 이 CNAME 레코드를 'mywebsite.com'의 DNS 설정에 추가했다면, 사용자가 'mywebsite.com' 도메인의 소유자라는 것을 알 수 있습니다. 왜냐하면 DNS 설정을 변경할 수 있는 사람은 도메인의 소유자 또는 도메인의 소유자에게 권한을 부여받은 사람뿐이기 때문입니다.
따라서, 이 경우에 CNAME 레코드는 ACM이 사용자의 도메인 소유권을 확인하는 데 사용하는 도구입니다. 사용자는 ACM에서 제공한 CNAME 레코드를 자신의 DNS 설정(이 경우 Route 53)에 추가함으로써, 자신이 도메인의 소유자임을 증명하는 것입니다.
도메인 소유권 증명과정은 다음과 같이 이루어집니다.
사용자는 Amazon Certificate Manager (ACM)에 웹사이트 (예: mywebsite.com)에 대한 SSL/TLS 인증서를 요청합니다.
ACM은 이 요청을 받고, 사용자가 mywebsite.com의 소유자임을 확인하기 위해 '도메인 소유권 검증' 과정을 시작합니다.
ACM은 이 검증을 위해 특별한 CNAME 레코드를 생성하고 이 정보를 사용자에게 제공합니다. 이 CNAME 레코드는 사용자의 웹사이트와 ACM 서비스 사이를 연결하는 역할을 합니다.
사용자는 이 CNAME 레코드를 복사하여 자신의 DNS 설정에 추가합니다. 만약 DNS 서비스가 Amazon Route 53인 경우, Route 53 관리 콘솔에서 이 작업을 수행하게 됩니다.
이 CNAME 레코드를 DNS에 추가하는 것은 "내가 이 도메인의 소유자라는 것을 증명하는 행동"입니다. 왜냐하면, DNS 설정을 변경할 수 있는 사람은 도메인의 소유자나 그에게 권한을 부여받은 사람뿐이기 때문입니다.
CNAME 레코드가 DNS에 추가되면, ACM은 이를 확인하고 사용자가 mywebsite.com의 소유자임을 인증합니다. 이는 ACM이 생성한 CNAME 레코드가 DNS에 잘 추가되었다는 것을 확인함으로써 가능합니다.
마지막으로, 도메인 소유권이 확인되면 ACM은 SSL/TLS 인증서를 발급하고 사용자는 이를 웹사이트에 적용할 수 있게 됩니다.
대략적으로 이해한 것 같다.
강의를 듣고 나갈때 조금씩 용어가 생소한 경우가 있었다. 이럴 경우 간단하게 (너무 깊게는 말고, 하지만 필요시 깊게) 훑고 넘어가고, 그 정보를 기록해 다시 복습하는 식으로 채워나가는 것이 좋겠다. 강사님께서도 어느정도 알고 있다고 가정하고 넘어가는 경우가 종종 있음. 그대로 따라갈 수도 있지만 가볍게 배경지식을 알고 넘어가는게 왜 이렇게 동작하는지, 그리고 외우는데 도움이 될 것 같다.
- 캐싱, 동적 가속, 엣지 로직 계산
DNS 요청을 하게되면 CDN 서비스로 가게되고 이전에 받아놓은 컨텐츠가 있다고 하면 다이렉트로 서비스를 내려준다 원래 접속해야되는 서버까지 가지 않아도 된다.
이 CDN 서비스를 제공해주는게 AWS의 CloudFront이다.
Front를 구성해서 서비스를 한다고 하면, CDN 서비스를 붙여서 하게 된다.
클라우드 프론트로 들어가본다
배포 생성에 들어간다
원본 도메인을 선택하고
이 CDN 서비스를 받기위한 서비스를 선택해준다
프론트를 구성할 때는 S3로 구성하게 된다.
에를들어 내가 이 s3에 CDN을 구성하고 싶다라면 선택해준다.
일전 수업에선 HTTPS 기능 구현을 위해 data-hamster.click를 여기에 등록했었음.
이렇게 원본도메인을 선택해주면 다이렉트로 타겟한 s3으로 가기보단, CDN을 거쳐 S3로 가게된다.
프론트는 s3로 구성하게 된다.
이름은 자동 생성
기본 캐시동작 - 뷰어 프로토콜 정책
에서 선택해줄 수 있다. http로 도메인을 입력했을 때 자동적으로 https로 도메인이 변환되는 경우가 있었다 Redirect HTTP to HTTPS
설정 - AWS WAF라는 서비스가 있음
aws에서 WAF를 검색해보면
특정 IP 접속을 막을 수 있음
IP sets로 이동해 등록해주면
해당 IP는 접속하지 못함.
cloud front에서 waf 에 등록된 ip 등록
대체 도메인을 넣고 싶으면
앞어 certificate manager도 설정
그러나 CDN은 글로벌 서비스여서 만일 리전을 서울에서 인증서를 받았다면 해당 선택지가 안뜸
미국 동부 리전 한개 받아야함
-> 없다면 인증서 요청을 해 신규 등록을 하면 된다
해당 설정으로 cloudfront를 생성
하면 s3를 CDN 서비스로 이용
배포 되서 나가는건 빠르면 10분 이내
상태 - 활성화됨 이후 사용 가능
사용하길 원치 않으면 비활성화를 누르고 삭제
프론트, 도메인 구성이 끝난 후에 중간에 CDN을 구성하게 될 것임.
-> 실제 S3에 프론트가 구성되어 있다면 도메인 연결을 통해 구현도 가능할 것 같다.
- ACM에서 인증서 등록은 상당 시간이 걸림.
