서버리스 서비스 예제 - 04 [S3 정적 웹사이트에 https 적용하기]

S3에 생성한 정적 웹사이트는 http로 만들어진 endpoint로 접속이 가능합니다. 

 

사용자들의 보다 안전한 접속을 보장하기 위해 https를 적용하는 방법을 알아보겠습니다.

 

여담인데 S3에 있는 각각의 파일은 https로 접근이 됩니다.

 

 

 

 

그런데 정적 웹사이트는 https를 기본으로 지원되는지 않습니다. https에는 공급자에 대한 정보가 있어야 하지만 s3의 정적 웹 사이트는 사용자 도메인없이 제공되는 웹 사이트이기 때문에 제공되는 컨텐츠 자체의 책임 권한 문제 때문이지 않을까 생각됩니다. (혹시 정확히 아시는 분은 댓글 부탁드립니다.)

 

 

기존 사용하던 도메인의 서브 도메인이므로 기존 등록기관을 이용할 수 있을까 했는데 IP가 없고 endpoint만이 존재하기 때문에 불가합니다. 이를 위해 ACM(AWS Certificate Manager)을 이용해 인증서를 등록하고 CloudFront에 S3 파일들을 CDN에 올리고 SSL을 적용한 후 Custom Domain 을 설정하고 Route53에서 CloudFront에 배포한 웹호스팅 도메인과 Custom Domain을 연결하여 적용해야 합니다. 

 

이 글에서는 이미 발급된 도메인에 추가로 서브 도메인을 만들어 S3 정적 웹사이트를 https로 서비스하는 과정을 다룹니다. 도메인 발급과 S3 만으로 서비스를 하고 싶은 경우 이전 글을 참고하세요.

 

apex 도메인이 ACM에 등록된 경우가 아니라면 서브 도메인만 생성하여 사용할 수 있습니다. 다음은 AWS 메뉴얼의 내용입니다. 

"DNS 표준에 따라 IP 주소로 매핑되며 실뢰할 수 있는 (A)레코드가 apex 도메인(example.com)에 사용되어야 합니다. Route 53을 사용하는 경우에만 apex 도메인이 CloudFront 배포를 가리키도록 할 수 있습니다. 다른 DNS 공급자를 사용하는 경우 하위 도메인(www.example.com)을 사용해야 합니다." (출처 : 참고 링크 )

 

그럼 순서대로 하나씩 살펴보겠습니다. 

 

서브 도메인 SSL 인증서 생성하기

우선 ACM으로 들어갑니다. (서비스에서 ACM 혹은 Certificate Manager로 검색 가능합니다.)

ACM으로 들어가서 인증서 프로비저닝을 시작합니다. 

 

그리고 공인 인증서 요청을 선택합니다. ACM에서 생성하는 SSL 공인 인증서는 무료입니다.

ACM에서 인증서를 요청전에 꼭 리전을 us-east-1으로 설정해야 CloudFront의 Custom SSL Certificate에서 설정이 가능합니다. 관련해서는 이 링크를 참고하시기 바랍니다.

 

인증서 요청은 총 5단계로 진행됩니다. 

• 1단계: 도메인 이름 추가
• 2단계: 검증 방법 선택
• 3단계: 태그 추가
• 4단계: 검토 및 요청
• 5단계: 검증

우선 도메인을 추가합니다. 와일드 카드로 작성해도 되지만, 저는 다른 서브 도메인들과 구분을 위해 test.example.com 과 같은 서브 도메인을 전체 기입했습니다. 일반적으로는 *.example.com과 같이 서브 도메인 전체를 포함하는 이름을 입력하면 됩니다. 다음을 누르면 검증 방법을 선택할 수 있습니다.

이메일 검증은 시간이 너무 오래 걸리기 때문에(메일이 안옵니다.... 꽤... ), DNS 검증을 선택하면 CNAME에 등록해야 하는 이름을 출력합니다. 그걸 복사해서 도메인 관리 사이트에서 CNAME에 등록해주면 됩니다. 만약 자체 DNS를 운영하시면다면 이메일 검증이 더 빠를 수 있습니다. 담당자에게 메일의 승인 버튼을 눌러달라고 조르시면 됩니다. ^^

DNS 검증 과정은 약 5 ~ 10분 정도 혹은 그 미만으로 소요됩니다.

 

검토 요청 후 인증서의 상태는 "발급 보류"로 되어 있다가, 메인 링크로 검토 완료가 되면 "발급 완료"로 변경됩니다. 

 

이렇게 인증서 발급 절차는 완료되었습니다. 

 

이제 기존에 만들어진 S3를 CloudFront로 연결하기 전에 S3를 정적 웹사이트로 만드는 절차를 간단히 살펴보겠습니다. 

 

S3로 정적 웹사이트 만들기

예제-03에서 다루었지만, 간단히 다시 정리합니다. 

 

버킷 이름, 리전을 선택하고 생성합니다. 저는 이미 만들어진 버킷을 사용할 것이지만 생성 및 설정에서 주의할 사항이 있어 추가 정리하려 합니다.

 

웹 사이트로 사용할 버킷의 이름을 만들 때는 주의할 점이 있습니다. ( 참고 링크 )

• 버킷을 가상 호스팅 하기 위해서는 버킷 이름과 CNAME이 동일해야 합니다. 예를 들면, 버킷 이름과 도메인 이름이 test.example.com이라면 CNAME 레코드는 test.example.com.s3.amazonaws.com 이어야 합니다. ( 위 링크의 "Amazon S3 URL을 CNAME으로 사용자 지정" 부분을 참고하세요.) 이는 http만 지원하는 기능입니다.
• https로 서비스 할 경우 버킷의 이름에 period( . )을 사용하면 안됩니다. 그리고 가상 호스팅은 http만 지원하기 때문에 CloudFront와 Route53을 사용하여 구축해야 합니다. ( 위 링크의 영문 버전 문서에만 이 내용이 명시되어 있으니 참고하세요. - AWS 공식 문서인데 중요한 내용인데도 불구하고 한글 버전 문서가 정확하지 않은건 좀 아쉽네요. )

Virtual hosted URLs are supported for non-SSL (HTTP) requests only. When using virtual hosted–style buckets with SSL, the SSL wild-card certificate only matches buckets that do not contain periods. To work around this, use HTTP or write your own certificate verification logic.

이제 버킷을 하나 만들고 "Welcome!!"이라고 출력되는 index.html 파일을 만들어서 업로드 합니다. 

 

그리고 버킷의 속성에서 정적 웹 사이트 호스팅을 활성화 합니다.

그 후 엔드포인트로 접근하면 "403 Forbidden"에러를 볼 수 있습니다. 이 설정은 웹 사이트 호스팅을 위한 엔드포인트를 오픈하는 역할만 합니다. 하지만 버킷의 객체들에는 접근 권한이 없기 때문에 이런 에러가 발생합니다.

 

파일의 엔드포인트로 접근을 시도해도 아직은 "AccessDenied" 에러만 보게 됩니다. 

 

일반 유저가 접근할 수 있도록 하려면 두 가지 방법이 있습니다. 버킷의 "권한" -> "버킷 정책"에 모든 대상에게 Get 에 대한 권한을 허용하는 것과 특정 파일만 선택해서 퍼블릭으로 설정하는 방법입니다. 

 

index.html 파일을 선택하여 퍼블릭으로 설정해 보세요.

 

이 설정 후에는 파일의 엔드포인트 혹은 호스팅 엔드포인트 모두 접근이 가능합니다. 

 

혹은 버킷 정책에 아래와 같이 입력하면 버킷 전체가 퍼블릭으로 설정되어 버킷 내 어떤 파일이든 접근이 가능합니다. 

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::your_bucket_name/*"
        }
    ]
}

 

Hosting 할 S3 버킷을 준비했으니 이제 도메인의 네임서버를 AWS 로 변경하여 본격적으로 AWS에 서비스를 연동해 보겠습니다. 

 

ACM에서 SSL Certificate 발급하기

보다 안전한 서비스를 위해 AWS Certification Manager에서 SSL 인증서를 발급 신청합니다. 발급 신청 전 서비스 지역을 us-east-1 (미국 동부 (버지니아 북부)로 세팅하세요. CloudFront에서 인증서는 us-east-1에 등록된 인증서만 세팅이 가능합니다. 

ACM console에서 "공인 인증서 요청" -> "도메인 이름 추가" 에서 소유한 도메인과 서브 도메인 이름들을 추가합니다. 서브 도메인 사용을 위해 입력시 *.example.com 과 같이 입력해 두세요. 검증방법은 DNS로 설정 후 "확인 및 요청"을 선택하면 검증을 위한 값이 화면에 출력됩니다. 이 값을 기존 도메인 등록기관에서 CNAME으로 등록한 후 몇 분이 지나면 검증이 완료됩니다. 

* ACM의 인증서 화면에서 상태가 "검증 대기 중"으로 변경되면 "인증서 ID"를 클릭해 상세 정보 화면으로 전환하고 "도메인" 세션에서 "Route 53에서 레코드 생성" 버튼을 눌러 "레코드 생성" 버튼을 누릅니다. 이후 "DNS" 레코드를 성공적으로 생성했습니다." 라는 안내문과 같이 화면 전환이 되고 일정 시간이 지난 후 완료됩니다. 

* 만약 실패할 경우 "ACM이 사용자를 위해 CNAME 값을 생성한 시각으로부터 72시간 내에 도메인 이름을 검증할 수 없는 경우, ACM은 인증서 상태를 [검증 시간 초과(Validation timed out)]로 변경합니다. 이러한 결과가 발생하는 가장 큰 이유는 ACM이 생성한 값으로 DNS 구성을 성공적으로 업데이트하지 않았기 때문입니다. 이 문제를 해결하려면 CNAME 지침을 검토한 후 새 인증서를 요청해야 합니다." 라고 문서에는 안내되어 있지만 아직 경험해보지 못해서 일단 관련 문구만 남겨둡니다.

CloudFront에 S3 버킷 배포하고 SSL Certificate 설정하기

우선 CloudFront에서 Origin Domain Name에서 배포할 버킷을 선택하세요.

만약 버킷의 이름이 버킷의 이름이 도메인명과 동일하지 않다면 S3 버킷의 endpoint를 복사해서 넣으시기 바랍니다. 

그리고 CNAMEs에는 사용할 도메인들을 입력합니다.

Default Root Object는 index.html 혹은 필요한 파일을 지정하세요.

그리고 Custom SSL Certificate를 선택 후 인증서를 선택합니다. (ACM us-east-1 리전의 인증서 리스트만 선택할 수 있습니다.)

이제 Create Distribution 버튼을 눌러 배포를 선택합니다. 배포 완료까지는 약 20분 가량 소요된다고 했는데, 저는 50분 이 소요되었습니다.

Route 53에 도메인 연동하기

기존 도메인을 Route 53으로 이동해야 하는 이유는 서브 도메인을 관리하기 용이하기 때문입니다. 사실 도메인을 여기서 생성하면 더 저렴하긴한데, 이미 다른 곳에서 등록하는 바람에 -_-a

 

저처럼 기존 도메인이 AWS가 아닌 다른 도메인 등록기관에서 등록한 경우 (저는 whois.co.kr에서 등록했습니다.) 네임 서버를 AWS로 돌려두면 이후 세팅들이 편리합니다. 물론 예제-03에서 언급한 것처럼 포워딩 세팅만으로도 가능하지만 https를 위한 인증서 서비스나 서브 도메인 관리를 위해서는 Route 53을 사용하는게 더 좋습니다. 

 

이제 Route 53으로 가서 "호스팅 영역 생성"을 시도합니다. 

소유하고 있는 도메인 이름을 입력하고 생성을 하면 NS와 SOA 유형의 두 값이 등록된 것을 확인할 수 있습니다. 

 

그럼 기존 등록기관에서 네임서버를 위 NS 영역의 네 주소로 변경합니다. 변경된 네임서버가 적용되기까지는 꽤 오랜 시간이 소요될 수 있습니다. 로컬의 경우 수십분에서 1시간 정도, 전 세계에 모두 적용되려면 2~3일의 시간이 소요될 수 있으니, 현재 서비스 중인 도메인의 네임서버 변경은 신중이 결정되어야 합니다.

이제 도메인의 IPv4 주소를 입력합니다. IP가 별도로 존재하지 않기 때문에 CloudFront에 등록된 endpoint를 복사하여 등록합니다. "레코드 세트 생성"을 선택 후 "A-IPv4 주소" 유형을 선택, "별칭"을 "예"로 선택 후 CloudFront의 도메인 endpoint를 입력 후 "레코드 세트 저장"을 눌러줍니다. 

이제 http와 https로 일정 시간이 지난 후 정상적으로 접속되는 것을 확인할 수 있습니다. 일반적으로 www 서브 도메인은 도메인 주소로 연결이 되므로 CNAME 유형으로 등록합니다. "별칭"은 "아니오"로 선택 후 값에는 CloudFront의 도메인의 endpoint를 입력해주시면 됩니다. 

이상입니다. 

(* 2022/10 일부 미진한 내용이 있어 내용 수정/추가했습니다.)