S3를 이용한 도메인 리다이렉트 (feat. Cloudfront+ACM)

Cloud/AWS

S3를 이용한 도메인 리다이렉트 (feat. Cloudfront+ACM)

Omoknooni 2024. 2. 21. 13:03

도메인을 리다이렉트해달라는 내용을 요청받았다.

자세히 이야기하자면, www.before.com과 같은 도메인으로 들어온 요청을 www.after.com과 같은 다른 도메인으로 리다이렉트하도록 설정을 해달라는 내용이였다.

이러한 예시는 실제로 종종 볼 수 있다. 예를 들어 어떤 서비스의 도메인이 완전히 바뀌어서, 이전 도메인으로 접속하는 트래픽을 신규 도메인으로 리다이렉션해주는 상황이 있을 수 있다.

이외에도 회사의 브랜드나 서비스 등을 사칭하는 사례의 방지를 위해 관련된 도메인들을 구매하고 정식 서비스로 리다이렉트 시켜버리는 등의 예시도 생각 할 수는 있다.

(도메인 사칭방지와 관련된 LG전자의 실제 예시에서 이같은 방법을 고려해볼 수 있을 것이다. 다만, 도메인을 모오두 사들이는 돈은 있어야겠지만...)

LG전자, ‘BEST’ 등 도메인 58개 구입...“브랜드 사칭 극성, 피싱 사이트 방지 사활” - 녹색경제

LG전자가 최근 극성을 부리는 온라인 ‘브랜드 사칭’ 사기를 방지하기 위해 두 팔 걷고 나섰다.타 업체가 자사 브랜드를 사용할 수 없도록 LG전자를 연상시킬 수 있는 도메인을 사들이는 등 위

www.greened.kr

URL Redirection은 CNAME 레코드를 이용하면 해결할 수 있다. 하지만, 한 apex 도메인(ex. before.com)에서 다른 apex 도메인(ex. after.com)으로 리다이렉트는 DNS 구조상 설정할 수 없다.

apex 도메인 : 서브도메인이 붙지 않은 도메인, Root domain 혹은 naked domain으로 불린다.

route53에서 apex 도메인에 CNAME 레코드를 설정할 경우, 다음과 같이 에러가 발생하며 CNAME 레코드 설정을 할 수 없다.

Why can't a CNAME record be used at the apex (aka root) of a domain?

This is a Canonical Question about CNAMEs at the apices (or roots) of zones It's relatively common knowledge that CNAME records at the apex of a domain are a taboo practice. Example: example.com. IN

serverfault.com

예시로 apex 도메인을 리다이렉트하는 상황을 구성해본다. (이전 도메인에서 새로운 도메인으로 이전한다고 가정)

이전 도메인 : Route53에 호스팅 영역이 존재
새로운 도메인 : apex 도메인에 연결된 인스턴스가 있음

S3 정적 호스팅을 이용한 도메인 리다이렉트

먼저 이전 도메인 이름의 S3 버킷을 생성해준다. 단, 생성되는 버킷의 리전은 리다이렉트될 대상의 리전과 동일하게 설정해줘야한다.

다음으로 버킷 속성에서 '정적 웹 호스팅'을 활성화 시킨다.

이때 호스팅 유형은 '객체에 대한 요청 리다이렉션'으로 지정한 뒤 리다이렉트 될 새로운 도메인 주소로 지정해준다.

리다이렉트되는 새로운 도메인이 HTTPS를 지원하면 HTTPS로 리다이렉트되도록 프로토콜을 선택할 수 있다.

이렇게 정적 호스팅 설정을 완료하고 이전 도메인의 호스팅 영역에서 이 S3로 연결되도록 A 레코드를 설정해준다.

설정하면 이전 도메인으로 HTTP로 접속하면 새로운 도메인으로 리다이렉트가 되는 것을 볼 수 있다.

Cloudfront+ACM도 이용한 도메인 리다이렉트

S3 정적 호스팅을 이용한 도메인 리다이렉트는 HTTP로 접근했을때만 리다이렉트해준다는 구멍이 있다.

이를 위해 로드밸런서를 이용하거나 Cloudfront를 이용해 HTTPS도 정상적으로 리다이렉트시켜줄 수 있다.

먼저 ACM을 통해 Cloudfront에서 사용할 SSL 인증서를 생성해준다

Cloudfront에 연결할 것이기 때문에 인증서는 반드시 us-east-1 리전에서 생성해주어야한다.

다음으로 cloudfront 배포를 생성한다.

원본으로는 생성해줬던 정적호스팅된 S3 버킷을 지정한다.

뷰어에는 HTTP and HTTPS나 Redirect HTTP to HTTPS로 설정해준다.

마지막으로 하단의 대체도메인(CNAME)에 리다이렉트될 이전 도메인 주소를 설정 후, SSL 인증서에 방금 생성한 인증서를 설정한다.

이렇게 cloudfront를 배포하고, 해당 배포 도메인을 이전 도메인의 A 레코드로 연결해주면, HTTPS로 들어온 트래픽도 정상적으로 새로운 도메인으로 리다이렉트시켜줄 수 있다.

로드밸런서를 이용한 도메인 리다이렉트

Cloudfront 이외에도 로드밸런서의 리스너 설정을 통해 도메인 리다이렉트를 설정할 수도 있다.

이전 도메인에 연결할 로드밸런서를 만들어주어야한다. 먼저 로드밸런서에 연결할 대상그룹을 하나 생성한다.

이 대상그룹은 로드밸런서를 생성을 위해 연결을 해준 것이므로 대상 값이 비어있는 상태로 생성해도 무방하다.

이어서 ALB를 하나 생성한다. 생성위치는 public, 가용영역 매핑도 임의의 값으로 설정해도 무방하다.

ALB를 생성하면 리스너를 다음과 같이 수정해준다.

HTTP : HTTPS 리스너로 리다이렉트
HTTPS : host 헤더값이 이전 도메인 주소인 경우, https://[새로운 도메인 주소]로 리다이렉트(301 or 302)

리스너 설정 후, 이 ALB를 이전 도메인 주소의 A 레코드로 연결해주면 cloudfront 때와 마찬가지로 새로운 도메인 주소로 리다이렉트되는 것을 볼 수 있다.

이런 잡기술이 실제로 쓰일지는 잘 모르겠으나, cloudfront와 ALB 리스너 동작을 조금 더 알 수 있는 계기가 된 듯 하다

티스토리