S3 정적 웹 페이지(Static Web Page)란❓❔
정적 웹 페이지는 언제 접속해도 같은 응답을 보내준다. 즉, 웹 서버가 정적 웹 페이지에 대한 요청을 받은 경우 서버는 추가적인 처리 과정없이 클라이언트에게 응답을 보낸다.
예를 들어 회사나 개인의 소개 페이지가 정적 웹 페이지의 좋은 예시이다.
헷갈리지 않게 버킷 이름에는 실제 도메인의 이름을 넣어준다.
퍼블릭 액세스 차단을 비활성화해주고 맨 아래 체크를 해준다.
*S3를 통해 직접적으로 버킷에 접근하지 않고, CloudFront를 통해 접근할 것이라면 퍼블릭 액세스를 차단해준다.
그리고 버킷 만들기를 해준다.
방금 만들었던 버킷을 클릭하고 권한탭에 들어가서
편집을 누른 뒤 버킷 정책에 아래 코드를 작성해준다.
버킷을 퍼블릭으로 설정하기 위한 과정이다.
정책 생성기를 써도 되고, 아래 코드에서 버킷 ARN만 바꿔서 사용해도 된다.
{
"Version": "2012-10-17",
"Id": "Policy1608529503037",
"Statement": [
{
"Sid": "Stmt1608529502358",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example.com/*"
}
]
}
속성탭 - 정적 웹 사이트 호스팅 - 편집을 눌러 위와 같이 호스팅 유형과 기본 인덱스, 오류 문서를 설정해준다.
작업한 모든 파일을 업로드 해주면 기본적인 정적 웹 사이트 호스팅은 완성됐다.
방금 설정해줬던 정적 웹 사이트 호스팅 맨 아래에 긴 외계어같은 도메인이 만들어졌다!
주소창에 생성된 도메인을 복붙하면 성공적으로 연결됐음을 확인할 수 있다.
Route53 - 호스팅 영역 - 호스팅 영역 생성
Route53으로 도메인을 매핑하는 작업이다. 방금 만들었던 버킷 이름처럼 도메인 이름에는 실제 서비스할 도메인 이름을 적어주면 된다.
호스팅 영역을 설정하면 아래 유형 NS, 값/트래픽 라우팅 대상에 4개의 네임 서버가 나온다. 이 네임서버는 구입한 도메인에 네임서버 목록에 적어주면 된다. (버킷 등록 전 가비아로 미리 도메인을 구입했다.)
가비아의 경우 My가비아 - 도메인 통합 관리툴에서 네임서버를 설정해줄 수 있다.
호스팅 영역을 설정하고 받은 4개의 네임서버를 하나씩 복붙 후 적어주면 된다. (마지막 .은 빼준다.)
aws console창에 certificate manager를 검색해서 이동해준다.
도메인 이름은 실제 도메인을 써주고, 다른 이름 추가를 눌러 www가 붙은 서브 도메인 이름까지 총 두개 써준다.
그리고 DNS 검증을 선택해주고 요청을 눌러주면 된다.
방금 생성된 인증서ID를 타고 들어가면 Route 53에서 레코드 생성이라는 버튼이 보일 것이다. 눌러서 레코드를 생성해준다.
도메인을 구입한 사이트로 가서 DNS 레코드를 수정한다.
ACM 검증 단계에서 나온 두개의 CNAME을 입력해준다. 호스트명은 어떻게 해도 상관없다.
위 단계까지 마치고 난 후 시간이 지나면 ACM 상태가 검증 대기중에서 발급 완료로 바뀔 것이다.
(걸리는 시간은 다 다르다. 짧게는 몇 분에서 길게는 하루 이틀도 걸린다고 한다.)
cloudFront는 정적, 동적 웹페이지를 빠르게 응답하기 위한 캐시 기능을 제공하는 CDN 서비스이다. 캐싱을 지원하기 때문에 S3에 저장된 컨텐츠에 직접 접근하지 않아도 되므로 S3의 비용이 감소하며, 더 빠른 응답을 지원하므로 함게 적용해주는 것이 좋다.
만약 지금까지 진행했던 정적 웹 페이지를 글로벌 서비스로 배포해야하는 상황이라면 멀리 있는 리전에서 서비스할 경우 사이트가 매우 늦게 뜰 것이다. 그러면 서비스하는 나라의 가까운 리전마다 S3버킷을 생성해준다면 만만찮은 비용이 들 것이다. 이 때, 사용할 수 있는게 CloudFront이다!
CloudFront는 전 세계 곳곳에 Edge Server(Location)을 두고 Client에 가장 가까운 Edge Server를 찾아 Latency를 최소화시켜 데이터를 빠르게 제공한다.
aws console창에 cloudFront를 검색해서 이동해준다.
오른쪽 배포생성을 눌러 형광표시한 항목들을 채워준다
S3 버킷 액세스에 예를 체크해주면 원본 액세스 ID항목이 뜬다. 고르려고 하다보면 내 OAI가 없을텐데, 당황하지 않고 새 OAI 생성을 눌러 생성해주면 된다.
OAI 설정을 해주면 우리가 만든 S3 버킷을 CloudFront를 통해서만 접근할 수 있게 된다.
즉, S3와 CloudFront를 연결해준 것이다.
이제 사용자들은 CloudFront에서 제공하는 URL을 통해서만 S3에 올려둔 파일을 조회할 수 있다.
기본 캐시 동작에서는 다른 값은 기본값으로, 뷰어 프로토콜 정책은 Redirect HTTP to HTTPS로 선택해준다.
Origin Shield를 활성화하면 네트워크 성능이 개선되고 캐싱을 도와준다. Origin에 대한 모든 요청이 Origin Shield를 통과하므로 캐시 적중 가능성도 높아지고, 동시 요청의 수도 줄여준다.
Cloudfront는 기본 24시간동안의 웹 컨텐츠를 캐싱할 수 있다. 이 말인즉슨 배포를 한 번 하고 하루가 지나지 않았는데 또 배포를 한다면 변경사항이 바로 적용되지 않고, 24시간 후에 적용된다.
그렇기 때문에 만약 변경사항을 바로바로 확인해야한다면, Caching Optimized가 아닌 Caching Disabled option을 설정하면 된다.
설정에서는 대체 도메인 이름(CNAME)에서 실제 도메인과 www가 붙은 서브 도메인 이름을 입력해준다.
사용자 정의 SSL 인증서는 방금 우리가 발급 받았던 인증서를 선택해 인증서 요청을 해주면 된다.
마지막으로 기본값 루트 객체에 메인 파일을 기입해주고 배포 생성을 눌러주면
배포가 완료된다.
그리고 마지막으로 CloudFront 도메인을 다시 Route53을 이용해 실제 서비스 도메인으로 매핑해주면 된다.
다시 Route53으로 돌아가서 호스팅 영역에 레코드 생성을 하나 더 해준다.
레코드 유형은 A, 별칭을 누른 뒤 CloudFront 베포에 대한 별칭을 선택해준다.
그리고 CloudFront에 도메인 이름칸에 생성된 도메인 이름을 복붙해준다.
마지막 순서에 위치한 www서브 도메인 레코드를 수정해준다.
레코드 이름을 앞에 이상한거 다 지우고 www만 쓰고 값에 cloudFrount 도메인을 입력해주고 저장해준다.
주소앞에 자물쇠도🔒 잘 뜨고, https도 잘 뜨는걸 확인할 수 있다!
시간이 좀 지난 후에 도메인 주소와 www서브 도메인 주소를 입력해보면 연결이 잘 된다!