들어가며

개발자로 지내는 동안 aws 를 사용하여 프로젝트를 빌드해서 배포하고 서버와 함께 운영해 본 경험이 있었다. 우여곡절 끝에 어쩌다보니 실행이 됐다며 기뻐했던 기억이 나는데... 좋아만 하고 기록을 하지 않았더니 다시 aws 에 들어갔을 때 모든것이 새로워 보였다.

aws 는 러닝커브가 긴 만큼 기록을 하면서 사용법에 대한 노하우를 남겨 놓는 것이 중요하다고 생각한다. 때문에 이번 블로그는 'aws 를 이용해서 정적 웹 사이트를 도메인에 연결해주세요.' 라는 요청이 들어 왔을 때 막히지 않고 진행 할 수 있는 것을 목표로 작성하였다.

DNS

공식문서를 보면서 차근차근 진행을 해도 되지만 공식문서의 개발자 안내서에서 제시하는 방법 뿐 아니라 원리를 이해하고 있어야 생각지 못한 삽질(?) 을 최소화 할 수 있다.

우선 도메인을 연결하기 앞서서 DNS 에 대한 개념을 알고 있어야 한다. HTTP & Network 기초 에서 domain 과 DNS 에 대해서 설명을 한 적이 있다.

이를 이미지로 나타내면 위의 사진과 같다. 위 이미지에서 도메인은 Nesite.com 이 되며 이 도메인을 실제 호스팅 서버의 IP 로 찾아주는 것이 바로 DNS (domain name system) 서버 이다.

하지만 위의 이미지는 도메인과 DNS 를 이해하기 위해 간소화를 한 것이고 실제 브라우저가 도메인을 DNS 서버에 요청하여 IP 를 받아 호스팅 서버로 부터 리소스를 받아 내기 까지는 더 복잡한 과정을 거친다.

도메인의 수가 너무 많기 때문에 DNS 서버는 조금 더 계층화 되어 단계적으로 도메인을 관리한다. DNS 서버의 종류는 다음과 같다.

• Recursive DNS : 클라이언트와 최전방에 연결되어 있는 DNS 서버, 한 번 거친 후 얻은 데이터를 일정 기간(TTL/Time to Live) 동안 캐시라는 형태로 저장해 두는 서버. 대표적으로 KT 같은 ISP(통신사) DNS 서버가 있으며, 브라우저 우회 용도로 많이 쓰는 구글 DNS, 클라우드플레어와 같은 Public DNS 서버가 있다.

• Root DNS 서버 : ICANN 이 관리하는 서버, TLD DNS 서버 IP 들을 저장해두고 안내하는 역할을 한다.

  • TLD(최상위 도메인) DNS 서버 : 도메인 등록 기관이 관리하는 서버, Authoritative DNS 서버 주소를 저장해두고 안내하는 역할을 한다.

    • Authoritetive (권한) DNS 서버 : 실제 개인 도메인과 IP 주소의 관계가 기록/저장/변경되는 서버, 일반적으로 도메인/호스팅 업체의 ‘네임서버’ 를 말한다. 네임서버란 IP 주소와 도메인 주소를 연결해주는 역할을 한다.

정리하자면 Recursive DNS 서버는 도메인에 해당하는 IP 를 캐시를 통해 저장하여 반복적으로 사용하며 IP 가 캐싱되어 있지 않은 경우 계층적으로 Root DNS 서버 부터 Authoritetive DNS 서버 까지 순회하며 IP 를 받아온다.

Recursive DNS (ISP DNS) 서버는 결론적으로 IP 를 받아 클라이언트 (브라우저) 에 내려주며 IP 를 받은 클라이언트는 호스팅 서버에 IP 의 자원을 요청하고 호스팅 서버는 IP 에 해당하는 자원을 찾아 클라이언트에 보내준다.

이 과정을 그림으로 표현하면 다음과 같다.

클라이언트가 도메인을 통해 자원을 요청하는 과정

1. 브라우저에서 Nesite.com을 검색하고, 사용하고 있는 통신사인 KT DNS 서버에게 도메인 주소에 해당하는 IP 주소를 요청한다.
   (브라우저 기본 DNS 설정이 통신사 DNS 서버이기 때문이다.)
2. ISP 서버에선 캐시 데이터가 없다는 걸 확인하고 루트 DNS 서버에게 어디로 가야 하는지 요청한다. (캐시가 있다면 8 로 건너 뛴다.)
3. 루트 서버는 TLD DNS 서버 주소만 관리하기 때문에, ***.com 도메인을 보고는 COM 최상위 도메인을 관리하는 TLD DNS 서버 주소를 안내한다.
4. ISP 서버는 COM 서버에게 어디로 가야 하는지 다시 요청한다.
5. COM 서버는 가비아 DNS 서버에서 해당 도메인이 관리되고 있는 걸 확인하고 안내한다.
6. ISP 서버는 가비아 서버에게 또 다시 요청한다.
7. 가비아 서버는 “Nesite.com = 12.123.123.123”이라는 정보를 확인하고 이 IP를 알려줌. 동시에 ISP 서버는 해당 정보를 캐시로 기록해 둔다.
8. ISP 서버는 브라우저에게 힘들게 알아 낸 12.123.123.123 주소를 안내한다.
9. 브라우저는 12.123.123.123 IP 주소를 갖고 있는 호스팅 서버에게 웹사이트를 출력하라고 요청한다.
10. 사용자는 브라우저에 전달 된 자원들을 보게 된다.

지금 까지 과정에서 route53 은 Authoritative DNS 서버에 해당한다.

지금부터 aws 의 s3 와 route53 을 이용하여 도메인과 정적 웹 사이트를 연결해 보자.

도메인 연결 과정

1. s3 에 정적 웹 사이트 호스팅을 하여 IP 를 생성한다.
2. route53 을 사용하여 도메인을 구입한다.
3. 구입한 도메인이 트래픽을 라우팅하여 해당 IP 를 찾게 하기 위해 route53 의 호스팅 영역을 생성한다.
4. 생성된 호스팅 영역의 네임서버와 도메인이 바라보는 네임서버를 일치 시켜 도메인이 생성된 호스팅 영역을 통해 트래픽을 라우팅하여 IP 를 찾게 만든다.
   (이 과정은 보통 24시간 정도가 소요된다고 합니다. 만약 도메인을 타 사이트를 통해 구매했다면 적용되는데 하루가 필했을 거 같은데 도메인과 호스팅을 모두 route53 을 통해 구현해서 그런지 저는 10분정도 소요 되었습니다. )
5. 호스팅 영역이 트래픽을 라우팅하여 s3 를 통해 생성 된 정적 웹 사이트의 IP 를 가르키도록 관련 된 레코드를 생성한다.

참고로 모든 과정은 예시이며 과정에 대한 설명없이 작성하였습니다.

s3 정적 웹 사이트 호스팅

s3 에 접속하여 버킷 만들기를 누른다.

버킷 이름을 작성한다. 버킷 이름은 다른 버킷과 중복되지 않는 고유한 이름이여야 한다. 구매하고자 하는 도메인을 지금부터 example.com 이라고 하자. 버킷의 이름은 www.example.com 으로 작성한다.

AWS 리전은 ap-northeast-2 로 선택한다.

퍼블릭 엑세스 차단을 해제하여 접근을 허용하고 버킷 생성하기를 클릭한다.

버킷이 생성되면 파일을 빌드하여 업로드 해준다.

속성 탭 - 정적 웹 사이트 호스팅에서 편집을 누른다.

다음과 같이 정적 웹 사이트 호스팅을 활성화 하고 인덱스 문서와 오류 문서에 index.html 을 입력한 후 변경 사항 저장을 눌러 정적 웹 사이트 호스팅을 활성화 한다.

버킷 웹 사이트 엔드포인트를 클릭하여 정적 사이트가 잘 나오는지 확인한다.

권한 탭 - 버킷 정책 에서 편집을 누릅니다.

버킷 ARN 을 복사하고 정책 생성기를 누릅니다.

• Select Type of Policy : S3 Bucket Policy
• Effect : Allow
• Principal : *
• Acttions : GetObject
• ARN : 복사한 버킷 ARN 붙여넣기 (url 끝에 /* 추가해주세요.)

후에 Add Statement 를 클릭, Generate Policy 클릭

내용을 복사하여 버킷 정책에 붙여넣고 변경 사항 저장을 누른다.

생성한 버킷에 엑세스가 퍼블릭으로 되어 있는지 확인한다.

route53 도메인 구매

route53 에 접속하여 대시보드-도메인 버튼을 클릭하여 등록된 도메인으로 이동한다.

도메인 등록 버튼을 누른다.

도메인 검색에 도메인을 검색하여 중복여부를 확인하고 TLD 를 선택하여 결제 진행 버튼을 누른다.

.com TLD 의 경우에는 한화 약 18,000 원 정도가 1년 단위로 지불 된다. 다음 버튼을 누른다.

연락처 정보를 입력한다. 이 때 이메일은 본인 확인 및 도메인 구매에 대한 진행상황을 체크할 수 있는 수단이므로 정확하게 기입해야 한다. 다음 버튼을 눌러 결제를 진행을 완료한다.

도메인 등록은 약 1~2시간 정도가 소요되며 이메일을 통해서 다음과 같은 내용을 받았다면 도메인 등록에 대한 조치를 추가적으로 할 필요가 없음을 알 수 있다.

Dear AWS customer,
We successfully registered the domain. We also created a hosted zone for the domain.
Your next step is to add records to the hosted zone. These records contain information about how to route traffic for your domain and any subdomains. To learn how to add records to your hosted zone, see Working with Records.

도메인 등록이 잘 등록이 되어있는지 확인하기 위해서 route53-도메인-요청 탭을 클릭한다.

최종적으로 다음과 같이 등록요청을 한 도메인이 생성 상태가 되어있다면 도메인 등록이 성공적으로 실행 된 것이다.

route53 호스팅 영역 생성

route53-대시보드 에서 호스팅 영역을 클릭한다.

호스팅 영역 생성 버튼을 눌러 호스팅 영역 생성 창으로 이동한다.

도메인 이름에 구매한 도메인의 이름을 입력한 후 호스팅 영역 생성 버튼을 누른다.

다음과 같이 호스팅 영역 이름이 구매한 도메인의 이름인 호스팅 영역이 생성 되어 있다면 성공이다.

호스팅 영역으로 들어가면 기본으로 생성된 레코드 NS 와 SOA 를 확인할 수 있다.

NS

네임서버 레코드로 도메인에 대한 네임서버의 권한을 가지고 있는지 알려주는 레코드
예를 들어 naver.com의 NS레코드는 e-ns.naver.com, ns1.naver.com, ns2.naver.com 이다.

SOA

도메인의 정보를 가지고 있는 레코드.
naver의 경우 ns1.naver.com webmaster.naver.com 2021012809 21600 1800 1209600 180 이렇게 보여주고 있는데,
각각 마스터 네임서버, 존 관리자 연락처, 존 데이터 동기화 시간, 갱신주기, 시도, 만료 등 정보를 나타내고 있다.

NS (네임서버) 의 값 총 4개는 다음 과정에서 사용된다.

도메인 네임서버를 호스팅 영역의 네임서버로 변경

route53-등록한 도메인 에서 구매한 도메인에 진입한 후 도메인의 네임서버를 호스팅 영역 네임서버로 변경한다. 작업을 누르고 이름 서버 편집 버튼을 누른다.

호스팅 영역의 네임서버로 도메인 이름서버를 수정한 후 변경 사항 저장을 누른다. 변경 사항 저장 후 약 10~20분 후 네임서버의 적용이 완료되었으며 도메인의 네임서버가 변경 되었다는 메일도 별도로 받을 수 있다.
(타 업체의 도메인 네임 서버를 aws 호스팅 영역의 네임서버로 변경한 경우 적용되는데 보통 24시간이 필요하다고 합니다.)

S3 레코드 생성

route53-호스팅 영역에서 생성한 호스팅 영역으로 들어가면 다음과 같은 화면이 나온다. 레코드 생성 버튼을 눌러 레코드 생성 페이지로 이동한다.

단순 라우팅을 선택하고 다음을 누른다.

단순 라우팅을 선택하고 다음을 누른다.

단순 레코드 정의 항목을 구성한다.

• 레코드 이름 : 트래픽을 www 로 작성한다.
• 레코드 유형 : A 선택
• 값/트래픽 라우팅 대상 : S3 웹 사이트 엔드포인트에 대한 별칭
• 리전 : 아시아 태평양(서울) [ap-northeast-2]
• S3 : S3 의 이름을 www.[도메인이름] 으로 구성한 이유이다. 생성한 S3 버킷의 이름과 레코드의 이름이 일치할 경우 목록에 나타난다.
• 대상 상태 평가 : 예

를 입력하고 단순 레코드 정의 버튼을 클릭한다.

호스팅 영역에 추가할 단순 라우팅 레코드를 최종적으로 생성하기 위해 레코드 생성 버튼을 누른다.

다음과 같이 추가한 레코드가 잘 생성되었다면 잘 완료된 것이다.

이제 생성한 도메인으로 접속하여 접속이 잘 되는지 확인한다.

마치며

원리를 이해하며 route53 과 s3를 이용하여 정적페이지와 도메인을 연결 하였다. 다음 블로그에서는 route53 을 이용하여 vercel 의 도메인을 변경해 보자.

참조

공식문서
DNS란 뭐고, 네임서버란 뭔지 개념정리
[AWS] 📚 Route53 개념 원리 & 사용 세팅 💯 정리