aws route53(hosted zone) 생성하기(feat.가비아)

 

 

 

 

https://orange-makiyato.tistory.com/131

가비아에서 도메인 구매하기(aws route53 비싸서)

 

저는 도메인 등록 업체(가비아)에서 이미 도메인을 구매했기 때문에 3. Create hosted zones (호스팅된 존 생성) 으로 진행하겠습니다.

 

hosted zone 이란 구매한 도메인 1개당 DNS 레코드를 관리하는 단위입니다. 구매한 도메인에 대해서 A 레코드, CNAME 레코드, MX 레코드 등 각 레코드를 관리할 수 있습니다.

 

프리티어인 경우 한개의 hosted zone 은 무료입니다. 그 이후 추가되는 새로운 도메인에 대한 hosted zone 부터 $0.5/월의 요금이 부과됩니다. 또한 월 1억 건의 DNS 요청이 제공되며 넘어갈 경우 요금이 부과됩니다. 하지만 프리티어여도 route53을 통한 도메인 구매는 요금이 부과됩니다. (.com 기준 연 12달러)

1. Register a domain (도메인 등록)

AWS Route 53을 통해 새로운 도메인을 직접 구매하는 옵션.

 

2. Transfer domain (도메인 이전)

다른 도메인 등록 업체(가비아, GoDaddy, Namecheap 등)에서 구매한 도메인을 Route 53으로 이전하는 옵션.

Route 53이 해당 도메인의 새로운 관리자가 됨.

Route 53로 도메인을 이전하면, 최소 1년 치 등록 비용을 내야 함.

현재 가비아에서 example.com을 6개월 남기고 Route 53으로 이전하면 Route 53에서 1년을 추가 등록해주어 총 1년 6개월로 연장됨.

이전 비용은 도메인 확장자 (.com, .net, .io 등)에 따라 다름. .com 기준 12달러.

도메인 등록 업체에서 구매한 도메인의 확장자가 aws에서 지원하는 것이어야지만 이전 가능.

 

3. Create hosted zones (호스팅된 존 생성)

Route 53에서 도메인의 DNS 설정을 관리하는 공간을 생성하는 옵션.

도메인 등록 업체에서 도메인을 구매했다면, Route 53에서 Hosted Zone을 만든 후 네임서버(NS) 설정을 변경해야 사용 가능.

 

4. Configure health checks (헬스 체크 설정)

특정 웹 서버, 애플리케이션, 또는 리소스가 정상적으로 작동하는지 감시하는 기능.

여러 개의 서버(멀티 리전 또는 다중 가용 영역)를 운영하면서 장애 감지를 자동화하고 싶을 때 사용.

또는 로드밸런서(ALB) 없이도 특정 서버의 상태를 감시하고 싶을 때 사용.

ex)

웹 서버 A가 다운되면, B로 트래픽을 자동으로 보내는 설정 가능.
글로벌 서비스 운영 시, 가장 가까운 지역의 정상적인 서버로 연결 가능.

 

5. Configure traffic flow (트래픽 라우팅 설정)

복잡한 트래픽 분산 정책을 설정할 수 있는 기능.

가용성(HA, High Availability)을 극대화하기 위해 다중 서버를 운영할 때 사용.

ex)

사용자의 지역(한국, 미국, 유럽)에 따라 다른 서버로 트래픽을 보내기
특정 조건(서버 부하율, 응답 속도)에 따라 다른 서버로 트래픽을 우회

 

6. Configure resolvers (DNS 해석기 설정)

VPC 내부의 DNS 쿼리를 관리하는 서비스.

온프레미스 (자체 데이터센터)와 AWS 간의 DNS 연동이 필요할 때 사용.

ex)

회사 내부망에서만 특정 도메인을 사용해야 할 때
온프레미스와 AWS를 연결하는 하이브리드 클라우드 환경에서 DNS 요청을 제어하고 싶을 때

 

 

 

Domain name

도메인 등록 업체에서 구매한 도메인을 써줍니다.

 

Type

저는 VPC 내부용이 아닌 향후 cloudfront와 연결할 것이기 때문에 Public hosted zone 으로 선택했습니다.

Private hosted zone는 private ec2 끼리 통신같은 상황에서 사용합니다. private ec2 는 ip만 존재하는데 서로 ip로 호출하면 불편하기도 하고 재배포시 바뀔 수 있기 때문에 도메인네임으로 호출하고자 할때 사용합니다.

 

생성된 hosted zone 을 보면 records 가 생긴 것을 알 수 있습니다.

저는 처음에 레코드가 뭐지? 왜 레코드라고 하지? 하며 그게 도대체 뭔지 이해가 가지 않았습니다.

 

이를 이해하기 위해서는 레코드 개념의 히스토리를 알아야합니다.

 

19세기 후반 ~ 20세기 초반에는 종이에 물리적으로 기록(record) 하였습니다. 그 시절에는 DNS(도메인 네임 시스템)을 관리하기 위해 HOSTS.TXT 라는 문서에 수기로 한줄한줄 작성하였다고 합니다.

이런식으로요

 

그리고 1960년대에 컴퓨터가 도입되면서 데이터를 저장하는 방식이 파일 시스템(file system) 으로 발전했습니다. 이때부터 파일 안의 개별 데이터 단위를 "레코드(record)"라고 부르기 시작했습니다.

'홍길동 ㅇㅇ부서 사원번호 123' 과 같은 개별 단위입니다.

 

1970년대에 관계형 데이터베이스(RDB) 등장하면서 현재 우리가 쓰는 행(row)과 열(column) 개념이 생겼지만 당시에도 한 행(row)을 "레코드(record)"라고 불렀습니다.

 

1980년대 이후 오라클(Oracle), IBM DB2, MySQL 같은 관계형 데이터베이스 관리 시스템(RDBMS)이 나오면서 "레코드(record) = 한 개의 행(row)" 이라는 개념이 완전히 자리 잡게됨으로서, 지금 흔히 행(row) 라고 부르는 것입니다.

 

즉, 예전에는 데이터 한줄을 레코드라고 불렀다~ 가 되는 것입니다. row, column 만 알던 현대의 꼬맹이여서 이해가 안갔던 거였습니다. 이래서 히스토리가 중요합니다.

 

하지만 여전히 레거시 시스템(COBOL, IBM 메인프레임 등)에서는 레코드 라는 용어를 쓴다고 합니다.

 

 

DNS 레코드(A 레코드, AAAA 레코드, CNAME 레코드, CAA 레코드 등 다양한 유형의 레코드 총칭) 는 여러가지 종류가 있는데요, 여기에 각각에 대한 설명이 잘 되어 있으니 궁금하면 한번씩 둘러보세요.

https://www.ibm.com/kr-ko/topics/dns-records

DNS 레코드란 무엇인가요? | IBM

 

 

 

 

다시 돌아와서!

hosted zone 을 생성했더니 NS 레코드와 SOA 레코드가 자동으로 생겼습니다.

 

NS (Name Server) 레코드

(select * from dns_info_table where type = 'NS' 의 결과 데이터라고 이해하시면 됩니다)

내 도메인을 관리하는 네임서버의 주소 정보입니다.

인터넷 사용자의 요청이 어느 네임서버로 가야 하는지 알려줍니다.

사용자가 example.com에 접속하면 브라우저는 NS 레코드를 조회하여 해당 네임서버로 질의(Query)를 보냅니다.

 

Route 53 은 기본적으로 4개의 네임서버를 추가합니다. AWS는 수백 개의 리전에서 수천 대의 네임서버를 운영하고 있습니다. 그 중에서 지리적 분산, 부하 분산, 장애 대응을 고려하여 자동으로 4개를 할당하여 고가용성을 유지합니다.

저의 경우는

ns-1572.awsdns-04.co.uk.
ns-1390.awsdns-45.org.
ns-473.awsdns-59.com.
ns-772.awsdns-32.net.

이렇게 4개가 추가가 되었습니다. co.uk 네임서버는 영국이나 유럽 리전에 위치할 가능성이 높고, .org는 미국 리전일 가능성이 큽니다. 이런 식으로 전 세계 여러 지역에 분산되어 있는 네임서버들을 제공하여, 글로벌 트래픽에 대해 빠르고 안정적인 응답을 제공합니다.

 

 

SOA (Start of Authority) 레코드

내 도메인을 관리하는 네임서버 정보 및 관리 정보입니다.

사실 route53에서는 실질적으로 필요하지 않지만, DNS 표준(RFC 1035)을 준수하기 위해 유지하고 있습니다. 네임서버를 클라우드가 아닌 직접 운영하는 곳은 Primary, Secondary 라는 개념이 있는데 aws는 내부시스템으로 일괄 관리하기 때문에 필요 없는 레코드이긴 합니다. DNS 표준(RFC 1035)에 SOA 레코드가 필수라고 명시되어 있기 때문에 유지하는 것뿐입니다.

 

Route 53의 4개의 네임서버는 Primary, Secondary 구분 없이 모두 동등한 역할을 합니다. DNS 데이터 변경은 AWS 내부 시스템에서 관리하므로, SOA의 serial 값이 따로 필요 없고, 네임서버 간 수동 동기화가 필요 없으므로, refresh, retry, expire 같은 값도 의미가 없습니다. 아래 내용은 참고용으로 봐주세요.

 

내용

example.com.  900  IN  SOA  ns-1572.awsdns-04.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

ns-1572.awsdns-04.co.uk.	내 도메인을 관리하는 기본 네임서버
awsdns-hostmaster.amazon.com.	관리자의 이메일 주소. hostmaster@example.com을 의미
1	Serial. SOA 레코드가 변경될 때마다 증가하는 숫자. 네임서버 간 데이터 동기화 시 사용
7200 (초)	Refresh. Secondary 네임서버가 Primary 네임서버에서 데이터를 다시 가져오는 주기
900 (초)	Retry. Primary 네임서버 응답이 없을 때 다시 시도하는 주기
1209600 (초)	Expire. Primary 네임서버가 오래 응답하지 않으면 Secondary 네임서버가 데이터를 폐기하는 시간
86400 (초)	Minimum TTL. 캐싱된 데이터가 유지되는 최소 시간

 

 

 

 

이제 다시 가비아로 가서 NS레코드에 있는 4개의 네임서버를 등록해줍니다.

도메인 관리에서 네임서버 설정을 눌러줍니다.

기존 것을 지우고 aws route53의 네임서버 4개를 입력해줍니다. 맨 뒤의 . 은 제거하고 입력합니다.

 

 

cloudfront 생성

 

 

route53에서 create recode 누르고 레코드 생성