[AWS] Route 53

DNS(Domain Name System)

• 사람이 이해할 수 있는 호스트 이름을 대상 서버 IP 주소로 변환하는 역할
• 계층적 네이밍 구조 사용

• TLD(Top Level Domain) : 최상위 도메인 -> ex) .com, .us, ..
• SLD(Second Level Domain) : -> ex) amazon.com, google.com ..

---

Amazon Route 53

AWS의 관리형 DNS 서비스

DNS가 사용하는 포트 번호가 53이어 Route 53이라고 이름을 지었다.

• 가용성이 높고, 확장 가능하며 완전히 관리되는 권위 있는 서비스 → 고객이 DNS 레코드를 업데이트 할 수 있음
• 리소스의 상태를 확인할 수 있는 기능 제공
• AWS에서 100% SLA 가용성을 제공하는 유일한 서비스 → 다운타임이 절대 없음

 

Records

: 도메인 이름으로 요청이 오면, 어디로 보낼지 라우팅 방법을 정의

 

레코드 구성 요소

1) 도메인/서브도메인 이름 : 어떤 도메인에 대한 레코드인지 지정

2) 레코드 타입(A, AAA 등)

3) 값 : 실제로 어디로 갈지 지정하는 정보

4) 라우팅 정책 : 여러 값이 있을 때 어떻게 선택할지

5) TTL(Time To Live) : 이 정보를 얼마나 오래 캐시할지 

 

레코드 타입

1) A 레코드

: 가장 기본적이고 많이 쓰는 레코드

: 웹 사이트, 서버 등 대부분 인터넷 리소스에서 사용

: 도메인 이름 → IPv4 주소로

 

2) AAAA 레코드

: A 레코드의 IPv6 버전

: 도메인 이름 → IPv6 주소로

 

3) CNAME 레코드

: 별칭 도메인 → 진짜 도메인

: 루트 도메인(= Zone Apex)에서는 사용 불가

: ex) example.com → other.com은 불가능 but www.example.com → example.com은 가능

 

4) NS 레코드

: 호스팅 존의 네임 서버

: example.com의 네임 서버는 ns-123.awsdns-12.com & ns-456.awsdns-34.net

 

Hosted Zone(호스팅 영역)

도메인 및 하위 도메인에 대한 트래픽 라우팅 방법을 정의하는 레코드를 포함하는 컨테이너

 

Public Hosted Zone(공개 호스팅 영역)

• 인터넷에서 접근 가능한 도메인 관리
• 전 세계 누구나 조회 가능
• 일반적 웹사이트, 앱 서비스에 사용
• 회사 웹사이트, API 엔드포인트, 이메일 서버 등

Private Hosted Zone

• VPC 내부에서만 접근 가능
• 인터넷에서는 조회 불가
• 회사 내부 시스템용
• 보안이 중요한 내부 리소스
• 내부 데이터베이스, 내부 API, 개발/테스트 환경 등

→ Hosted Zone당 월 $0.50

---

CNAME vs Alias

문제 상황

AWS 리소스는 이상하고 긴 호스트 이름을 가지고 있음 → lb1-1234.us-east-2.elb.amazonaws.com

사용자에게 이런 이름을 보여주고 싶지 않고 깔끔하게 바꾸고 싶음 → myapp.mydomain.com

이를 해결하기 위한 두가지 방법이 CNAME과 Alias

 

Alias 레코드

• AWS만의 특별한 기능
• 루트 도메인에도 사용 가능
• DNS 쿼리 비용 없음
• 자동 헬스 체크
• 자동 IP 업데이트
• TTL을 설정할 수 없음 → Route 53이 자동 관리
• 레코드 타입은 항상 A 또는 AAAA
• 연결 가능한 리소스 : ELB, CDN, API Gateway 등
• EC2 DNS 이름에 연결 불가능!

---

Route 53 Routing Polices

Route 53이 DNS 쿼리에 응답하는 방식 정의

1) Simple

• 가장 기본적 정책 → 하나 이상의 IP 반환
• 여러 IP를 반환하면 클라이언트가 랜덤으로 하나 선택
• Health Check 지원 안 함

2) Weighted(가중치)

• 트래픽을 비율로 분산
• 새 버전 점진적 배포에 사용
• Health Check 지원

3) Latency(지연 시간)

• 사용자와 제일 가까운 리전으로 라우팅 → 지연시간 낮게
• 글로벌 애플리케이션의 성능 최적화에 사용

4) Failover(장애 조치)

• Active-Passive 구성 → Primary/Secondary
• Primary 실패 시 자동으로 Secondary 전환
• 재해복구에 필수
• ex) 기본 사이트 장애 시 자동으로 백업 사이트로

5) Geolocation(지리적 위치)

• 사용자의 실제 위치에 따라 라우팅
• 콘텐츠 현지화나 지역별 규정 준수에 사용
• ex) 한국 사용자는 서울 리전으로, 미국 사용자는 버지니아로

6) Geoproximity(지리적 근접성)

• 사용자와 리소스의 지리적 거리 + 편향값(bias)으로 라우팅
• 해당 기능 사용을 위해서 Rout 53 Traffic Flow를 사용해야 함

7) Multi-Value Answer(다중 응답)

• 여러 개의 정상 리소스 IP 반환(최대 8개)
• Simple과 비슷하지만 Health Check 지원

 

---

Route 53 - Health Checks

• HTTP Health Checks는 공용 리소스에만 사용 가능
• Health Checks로 자동 DNS 장애 조치 가능

 

Health Check의 3가지 유형

1. 엔드포인트 모니터링

• 15개의 글로벌 헬스 체커가 전 세계에서 확인
• 18% 이상이 정상이면 Healthy
• 기본 간격은 30초(10초 설정 가능, 높은 비용 발생)
• 2xx, 3xx 상태코드만 정상으로 인정

2. Calculated Health Checks

• 여러 Health Checks를 조합해 하나의 결과로
• OR, AND, NOT 논리 연산 사용
• 최대 256개의 하위 상태 확인을 모니터링할 수 있음
• 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트 관리를 유지하도록 하는 경우사용

3. CloudWatch 알람 모니터링

• CloudWatch 알람의 상태 확인
• 프라이빗 리소스 모니터링의 핵심 방법

---

도메인 등록과 DNS 관리 분리

Domain Registar : 도메인 이름 등록

DNS Service : DNS 서비스 = 주소로 실제 어떻게 찾아가는지 안내

→ 3rd Padrty Registrar에서 도메인을 구입한 경우에도 Rout 53을 DNS 서비스 제공자로 사용할 수 있다.

어떻게 분리하는가?

1. Route 53에서 Hosted Zone 생성

-> Rout 53에서 example.com에 대한 Hosted Zone 생성

-> 4개의 Name Servce(NS) 주소를 받는다고 가정

 

2. Domain Registrar에서 NS 변경

-> GoDaddy에서 도메인을 구입했다고 가정했을 때, GoDaddy 설정에서 NS를 Route 53의 NS로 변경

 

3. 이제 DNS 레코드는 Route 53에서 관리

-> 기존 도메인을 다른 등록 대행사로 이전하는 것은 번거로움

-> NS만 바꾸면 Route 53의 모든 기능 사용 가능

 

 

 

→ 도메인 이전 ≠ DNS 서비스 변경

→ NS 레코드 변경만으로 DNS 서비스 교체 가능

→ Route 53 사용 = Hosted Zone 생성 + NS 변경Route 53

 

 

 

 

 

출처 : https://velog.io/@gagaeun/AWS-Route-53