AWS Route53 Cloud Front S3 정적 웹사이트 배포

Jake·2024년 9월 4일

S3 aws cloudfront route53 배포

아래는 AWS기반으로 월 10원으로 내 포트폴리오 웹사이트 운영하기 영상 내용을 정리한 글입니다.

순서는 아래와 같습니다.

Route 53 가비아 연동
S3 버킷 생성 프론트 프로젝트 업로드
CloudFront 생성 및 Route 53 연동

아래 시스템 아키텍처는 최종 목표이며 이번 시간에 다루는 내용은 Client 의 일부분입니다. 이번 시간의 내용을 토대로 점진적으로 발전시켜나갈 계획입니다.

아키텍처

이번 시간에 다룰 서비스의 아키텍처는 대략 아래와 같습니다.

Route 53

먼저 가비아에서 구매한 도메인을 Route 53을 통해 적용해보도록 하겠습니다.

Route 53을 통해 클라이언트가 접속을 하기 때문에 접속 시 Name Server를 Route 53에서 설정을 해주어야 저희가 원하는 도메인 접속시 원하는 곳으로 라우팅을 해줄 수 있습니다.

그래서 Route 53 메뉴에서 호스팅 영역을 생성하게 되면 AWS에서 네임서버 4개를 주게 됩니다.

이 서버의 값들을 가비아에 등록해주면 해당 도메인으로 요청시 AWS의 네임서버로 라우팅이 되어 원하는 곳으로 요청이 가게 됩니다.

(단 네임서버 입력시 마지막 . 을 제거하고 입력해주어야 합니다.)

AWS Certificate Manager

Security 통신을 하기 위해 ACM 퍼블릭 cerfitication을 만들어야 합니다.

이때 버지니아 북부 us east 1 으로 리전을 변경 후에 등록을 해야합니다. 왜냐하면 Cloud Front의 메인 리전이 us east 1 리전이기 때문입니다.

이제 위와 같이 AWS Certificate Manager 인증서에서 퍼블릭 인증서 요청을 합니다.

그리고 가비아에서 등록한 도메인을 입력합니다.

아래 * 와 같이 와일드카드를 입력하여 설정합니다.

그리고

검증 방법은 DNS 검증 - 권장
키 알고리즘은 RSA 2048

로 설정하고 진행합니다.

이후 메뉴에서 Route 53 레코드를 생성합니다.

그렇게 되면 위와 같이 Route 53에서 등록한 도메인이 있을 경우 바로 나오게 됩니다. 이를 확인하고 레코드를 생성합니다.

레코드를 생성하게 되면 검증 대기중이 정상적으로 검증이 됩니다. 이때 시간이 소요되며 보통 1분 이내로 검증이 아래와 같이 완료됩니다.

S3 버킷 생성

React의 정적 파일을 S3에 업로드하고 정책을 설정하는 과정입니다.

S3 버킷을 생성합니다.

버킷 이름은 고유해야하며 가비아에서 구매하였던 도메인을 사용합니다.
그리고 정적파일이므로 저의 경우 앞의 prefix에는 static을 붙여주었습니다.

객체소유권같은 경우에는 ACL 비활성화로 해주었으며 모든 사용자들이 외부로부터 볼 수 있어야 하므로 퍼블릭 엑세스 차단을 해지하였습니다.

버킷 버전 관리는 비활성화로 기본설정으로 두고 기본 암호화는 S3 관리형 키로 버킷키는 비활성화 한 뒤 버킷을 생성합니다.

권한

그리고 권한으로 들어가 아래와 같이 버킷정책을 수립합니다.
아래 버킷 정책은 읽기 권한을 모든 사용자에게 허용하는 설정입니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::static.rivkode.com/*"
        }
    ]
}

Statement는 정책 내의 규칙을 정의하는 부분입니다.
"Sid"는 Statement ID를 의미합니다. 이는 정책 내의 각 규칙에 대한 고유 식별자로, 정책을 구분하기 위해 사용됩니다. 여기서는 Statement1이라는 이름으로 규칙을 식별하고 있습니다.

"Effect"는 해당 규칙이 허용(Allow)인지 거부(Deny)인지를 지정합니다.

"Principal"은 이 규칙이 적용되는 사용자나 엔터티를 지정합니다.
"*"는 모든 사용자를 의미합니다.

"Action"은 이 규칙에서 허용 또는 거부되는 행동을 정의합니다.
"s3:GetObject"는 S3 버킷에서 객체(파일)를 읽는 작업을 의미합니다. 따라서, 이 규칙은 해당 S3 버킷 내의 파일에 대한 읽기 권한을 허용합니다.

"Resource"는 이 규칙이 적용되는 AWS 리소스를 지정합니다.
"arn:aws:s3:::static.rivkode.com/"는 특정 S3 버킷(static.rivkode.com) 내의 모든 객체(파일)를 나타냅니다.
/는 버킷 내의 모든 파일 및 디렉토리를 의미합니다

위와 같이 설정하여 정책을 저장합니다.

정적 웹 사이트 호스팅

그리고 정적 웹 사이트 호스팅 편집에서 기본 설정값을 유지하고

위와 같이 인덱스 문서, 오류 문서의 html 파일을 index.html 파일로 설정합니다.

객체 업로드

그리고 객체를 업로드 합니다.

저는 vite 로 빌드하여 /dist 폴더 내에 아래 빌드된 정적 파일들이 있어 업로드 하였습니다.

업로드가 완료되면 정적 웹사이트 호스팅에 등록하였던 url로 접속시 아래와 같이 화면이 나오게 됩니다.

(저는 로그인하지 않을 경우 로그인 화면이 바로 나오도록 하였습니다.)

현재는 url이 너무 지저분합니다. 이 url을 변경하기 위해 Route 53 의 호스팅 영역에서 레코드를 생성합니다.

레코드 생성시 레코드 이름은 S3의 이름과 반드시 동일해야합니다.

저는 static을 포함하여 설정하였기 때문에 static.rivkode.com 으로 입력하였습니다.

그리고 별칭을 활성화하여 위와 같이 설정합니다.

그렇게 생성을 하면 위와 같이 레코드가 생성됩니다.

레코드가 생성되면static.rivkode.com 으로 접속이 가능하며 이전과 동일한 Resource로 라우팅을 하게 됩니다.

Cloud Front

이제는 Https 통신과 앞의 static 이 아닌 rivkode.com 으로 접속 시 웹 페이지를 보기 위해서 Cloud Front 를 생성하겠습니다.

배포 생성시 Origin domain은 S3에서 정적 웹 사이트 호스팅 주소의 버킷 웹 사이트 엔드포인트를 입력합니다.

S3 엔드포인트 정보 (S3 서비스 페이지)

Cloud Front는 외부로부터 Https 통신을 하며 내부적으로 S3와는 Http 통신을 하게 됩니다. 따라서 뷰어 프로토콜정책은 Redirect HTTP to HTTPS 로 설정합니다.

그리고 위와 같이 프로토콜은 그대로 두고 기본 캐시 동작에서 저는 캐싱을 하지 않기 위해 캐시 키 및 원본 요청 메뉴에서 Legacy cache settings로 하고 객체 캐싱은 기본 TTL을 0으로 세팅합니다.
TTL을 0으로 세팅한다는 것은 캐싱을 하지 않겠다는 의미입니다.

그리고 설정탭에서 대체 도메인 이름을 입력하는데 이전에 S3에서의 도메인을 입력합니다.

SSL 설정은 이전에 생성하였던 AWS Certificate manager 인증서를 연결합니다. 이때 안내된 내용대로 반드시 인증서는 미국 버지니아 북부 리전이어야 합니다.

그리고 생성을 합니다.

Cloud Front 의 경우에는 모든 엣지 로케이션에 배포가 되어야지만 배포가 완료되었다고 선언을 하기 때문에 시간이 조금 걸리게 됩니다.

기존의 시스템 아키텍처는 Route 53에서 바로 S3로 요청이 가도록 되어있었지만 이제는 Route 53이 Cloud Front 를 거쳐서 S3 로 요청이 가도록 변경하려고 합니다. 그러기 위해서는 Route 53이 Cloud Front 로 요청이 가도록 도메인을 바꿔줘야 합니다.