Cloudfront 대체 도메인 이름(Route 53)을 다른 Cloudfront 배포로 이동

1. 개요

기존에는 Next.js 앱을 serverless framework를 활용해 AWS Serverless 아키텍처로 배포했습니다. 하지만 Next.js 13부터 serverless framework가 더 이상 지원되지 않는 문제로 인해 새로운 배포 방식을 모색하게 되었고, 최근 프로젝트에서는 SST를 활용하여 CloudFront, Lambda, 그리고 Route 53으로 배포하는 방법을 사용했습니다. 대체 도메인 이름을 배포에 추가하려고 하지만 대체 도메인 이름이 다른 배포에서 이미 사용되고 있는 경우에는 CNAMEAlreadyExists 오류(입력한 하나 이상의 CNAME이 이미 다른 리소스와 연결되어 있음)가 발생합니다. 예를 들어 www.example.com 을 배포에 추가하려고 하는데 www.example.com 이 이미 다른 배포와 연결되어 있으면 이 오류가 발생합니다.

이번 포스트에서는 기존에 Route 53에 등록되어 있던 CloudFront의 대체 도메인(alternate domain name)을 SST를 사용해 배포한 새로운 CloudFront 배포로 이동하는 방법에 대해 다룹니다. 만약 기존 배포의 도메인을 단번에 해제하고 새 배포로 전환한다면, 짧은 시간 동안이라도 사용자 접속에 문제가 생길 수 있는 downtime이 발생할 수 있습니다. 이에 대한 문제를 최소화하면서 안전하게 이전하는 방법을 알아보겠습니다.

2. 해결방법 1/with downtime

예를들어 serverless framework를 살용하여 A프로젝트를 배포하고 대체 도메인을 등록했습니다. 배포환경이 바뀐다는 등의 이유로 A프로젝트 Cloudfront와 대체 도메인이 연결 되어있던걸 해제하고 새로운 B프로젝트를 배포하려고 합니다. 이때 B프로젝트를 sst,amplify 와 같은 배포서비스를 활용하여 새로운 Cloudfront 배포를 완료했다고 가정합니다. 이제 Route 53과 같은 DNS 서비스에서 기존 A프로젝트의 Cloudfront 도메인과 대체 도메인을 해제하고 새로운 B프로젝트의 Cloudfront 도메인과 대체 도메인을 등록합니다. 방법2에서 AWS Doc 에서 소개하는 방법을 사용하면 Downtime이 발생하지 않게 대체 도메인을 이동할 수 있습니다.

2. 해결방법 2/without downtime

Downtime이 발생하지 않는 방법을 알아보겠습니다. 설명을 들어가기전에 이하 기존배포를 소스 라 칭하고 새로운 배포를 타겟 이라 칭하겠습니다.

대체 도메인 이름을 이동하려면 다음을 수행합니다. 대상 배포를 설정합니다. 이 배포에는 이동 중인 대체 도메인 이름을 포함하는 SSL/TLS 인증서가 있어야 합니다. AWS Command Line Interface(AWS CLI)을(를) 사용해 대체 도메인 이름이 연결된 배포를 찾습니다.

2.1 타겟 대상 배포 설정

대체 도메인 이름을 이동하려면 먼저 타겟 배포(대체 도메인 이름을 이동할 배포)를 설정해야 합니다. 대상 배포를 설정하려면 다음을 수행합니다. 이동 중인 대체 도메인 이름이 포함된 SSL/TLS 인증서를 받습니다. 없는 경우 AWS Certificate Manager(ACM)에 요청하거나 다른 인증 기관(CA) 에서 가져온 다음 ACM으로 가져올 수 있습니다.

2.2 ACM 인증서 확인

AWS Certificate Manager(ACM) 콘솔 접속: AWS 콘솔에서 ACM으로 이동합니다.

• 인증서 상태 확인: 목록에서 www.example.com 도메인에 대해 요청한 인증서를 찾습니다. 인증서의 상태(Status)가 Issued(발급됨) 인지 확인합니다. 만약 상태가 Pending validation이라면, ACM이 도메인 소유권 검증을 기다리고 있는 상태입니다.
• 소유권 검증 방법: DNS 검증: 인증서 상세 정보를 클릭하면, ACM이 제공하는 CNAME 또는 TXT 레코드 값이 표시됩니다. 이 값을 복사해, 도메인을 관리하는 DNS 서비스(Route 53 또는 다른 DNS 제공업체)에 추가해야 합니다. ACM에서 인증서를 요청할 때, "완전히 정규화된 도메인 이름" 입력란에 사용하고자 하는 도메인 이름(예: www.example.com)을 입력하면 됩니다. 만약 www.example.com 뿐만 아니라 apex 도메인도 사용하려면, 둘 다 입력하거나 와일드카드(*)를 활용한 인증서를 요청할 수 있습니다.

ACM 인증서 발급 화면

2.3 TXT 레코드 생성

CloudFront 별칭 이동을 위해서는 도메인 소유권을 확인할 수 있도록 Route 53에서 TXT 레코드를 생성해야 합니다. 예시:

1. TXT 레코드 생성

• 레코드 유형: TXT
• 레코드 이름: 도메인 이름 앞에 언더스코어(_)를 붙여서 생성합니다.
• 예: _www.example.com
• 레코드 값: 대상 배포의 CloudFront 도메인 이름을 입력합니다.
• 예: (https 제외) abcd1234567.cloudfront.net

2. DNS 서비스(Route 53)에서 등록

• Route53 콘솔에 접속하여, kwangmin-nam.com 호스팅 영역 내에 위 TXT 레코드를 생성하세요.

3. 전파 확인

• 생성 후 명령어를 사용해 TXT 레코드가 올바르게 등록되었는지 확인합니다.

dig TXT _www.example.com 또는 nslookup -type=TXT _www.example.com

TXT 레코드 생성 화면

3.CLI로 대체 도메인 이동

아래 명령어를 사용해 대체 도메인 이름을 이동합니다.

aws cloudfront associate-alias --alias "ROUTE53_DOMAIN" --target-distribution-id "CF_ID" --profile "PROFILE_NAME"

• --alias _www.example.com이동하려는 사용자 정의 도메인(별칭)입니다.
• --target-distribution-id E1FLUF8QS5FENJ
별칭을 이동할 대상 CloudFront 배포의 ID입니다.
• 이 명령어를 실행하면 AWS는 소스 배포에서 해당 별칭을 제거하고 대상 배포에 추가하는 작업을 수행합니다. 배포 업데이트가 완료되기까지 몇 분 정도 소요될 수 있습니다.

아래 명령어를 사용하여 타겟 배포가 대체도메인이 이동이 잘 돼있는지 확인할 수 있습니다.

aws cloudfront get-distribution-config --id "CF_ID"> --profile "PROFILE_NAME"

1. 출력 결과를 보면 Aliases": { "Quantity": 1, "Items": [ "www.example.com" ] } 로 되어 있으므로, 대상 배포에 www.example.com 별칭이 성공적으로 등록되었음을 의미합니다.

2. 추가로 확인할 수 있는

• CloudFront 콘솔 확인:

• AWS Management Console에서 타겟 배포(CF_ID)를 열어 Alternate Domain Names 항목에 www.example.com이 표시되는지 확인합니다.

• DNS 확인: 터미널에서 dig www.example.com 명령어를 실행하여, 해당 도메인이 대상 배포의 CloudFront 도메인(예: abcd1234567.cloudfront.net)을 가리키는지 확인할 수 있습니다.

4. Trouble Shooting

• 이 오류는 현재 사용 중인 IAM 사용자가 cloudfront:ListConflictingAliases 작업을 수행할 권한이 없다는 의미입니다. 이를 해결하기 위해서는 IAM 콘솔에서 cloudfront 관련 권한을 사용자에게 부여해야 합니다.

• 이 오류는 타겟 배포에 Rotue53 을 연결하기 위해 CloudFront가 도메인 소유권을 확인하는 DNS TXT 레코드가 누락되었거나 올바르지 않음을 의미합니다.

5. 결론

이번 포스트에서는 기존 CloudFront 배포에서 사용 중인 대체 도메인(Alternate Domain Name)을 다른 배포로 이동하는 방법에 대해 단계별로 알아보았습니다. ACM을 통한 SSL 인증서 발급, DNS를 통한 도메인 소유권 검증, CLI를 활용한 별칭 이동, 그리고 Route 53에서 Alias 레코드를 업데이트하는 전체 과정을 통해 Downtime 없이 도메인을 안전하게 전환할 수 있음을 확인했습니다.

특히 TTL(Time to Live) 은 DNS 레코드 변경 사항이 전파되는 속도에 큰 영향을 미칩니다.

• 짧은 TTL: 변경 사항이 빠르게 반영되어 테스트나 긴급 상황에 유리합니다.
• 긴 TTL: 변경 반영에 다소 시간이 걸릴 수 있으므로, 운영 환경에서는 미리 충분한 전파 시간을 고려해야 합니다.

또한, TXT 레코드는 왜 필요한가 하면, CloudFront와 같은 서비스가 도메인 소유권을 검증하는 중요한 수단이기 때문입니다.

• 도메인 소유권 확인 TXT 레코드를 통해 실제 도메인 관리자가 해당 도메인을 소유하고 있다는 것을 증명할 수 있습니다.

이를 통해 무단으로 도메인이 다른 리소스에 연결되는 것을 방지하여, 보안성을 높일 수 있습니다. 이처럼 각 단계와 관련 설정과 CloudFront 배포 간 도메인 이동 시 발생할 수 있는 다운타임 문제를 해결할 수 있습니다