# Route 53

## Route 53

* 고가용성, 확장 가능성을 갖춘 fully managed DNS 서비스이다.
* 사용자가 DNS 레코드를 업데이트할 수 있다.
* 도메인 레지스트리이다.
* 리소스의 상태를 확인할 수 있다.
* 100% SLA 가용성을 제공한다.

### 레코드

* Route 53에서 여러 DNS 레코드를 정의하고, 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의한다.
* 도메인/서브도메인 이름, 레코드 타입, 값, 라우팅 정책, DNS 캐시 TTL 정보가 레코드에 포함된다.
* DNS 레코드 타입으로는 A, AAAA, CNAME, NS 등 다양하게 지원한다.
  * A 레코드
    * 호스트 이름과 IPv4 IP를 매핑
  * AAAA
    * 호스트 이름을 IPv6 주소에 매핑
  * CNAME
    * 호스트 이름을 다른 호스트 이름과 매핑
    * 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있다.
    * DNS namespace 또는 Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없다. 예를 들어 example.com에 CNAME을 만들 수는 없지만 www.example.com에 대한 CNAME 레코드는 만들 수 있다.
  * NS
    * Hosted Zone의 이름 서버
    * 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있다.
    * 트래픽이 도메인으로 라우팅 되는 방식을 제어한다.
* Hosted Zones
  * 레코드의 컨테이너
  * 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다.
  * AWS에서 만드는 어떤 호스팅 존이든 월에 50센트를 지불해야 한다.
  * 퍼블릭 호스팅 존
    * 퍼블릭 도메인 이름을 사면 만들어진다.
    * 도메인 이름에 매핑되는 공인 IP를 알 수 있다.
  * 프라이빗 호스팅 존
    * 공개되지 않는 도메인 이름을 지원한다.
    * VPC만이 도메인 이름을 리졸브할 수 있다.
    * 비공개 도메인 이름에 해당되는 프라이빗 리소스의 IP를 획득할 수 있다.
* TTL
  * TTL 값이 작으면 Route 53으로 들어오는 요청이 많아지므로 요금이 더 부과되지만 레코드를 변경해도 문제가 거의 발생하지 않는다.
  * TTL 값이 크면 변경 전 레코드 값을 그대로 사용하는 문제가 발생할 수 있다.
  * 별칭 레코드를 제외한 모든 레코드에 TTL을 지정해야 한다.
* CNAME / Alias
  * CNAME
    * 호스트 이름이 다른 호스트 이름으로 향하도록 한다.
    * 예를 들어 app.mydomain.com이 blabla.anything.com으로 향하게 할 수 있다.
    * 루트 도메인 이름이 아닌 경우에만 가능하다.
  * 별칭 레코드
    * Route 53에 한정적인 레코드이다.
    * 실제 레코드의 타입은 A 또는 AAAA이고, 값을 AWS 리소스로 쉽게 매핑할 수 있도록 해주는 기능이다.
    * 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있다.
    * 별칭 레코드는 **루트 및 비루트 도메인에 모두 작동**한다. Zone Apex라는 DNS 네임스페이스의 상위 노드로 사용될 수 있다.
    * 무료이고, 자체적으로 상태 확인이 가능하다.
    * 도메인 이름에 대한 별칭 레코드에 ALB를 등록하면, 만약 기반 ALB의 IP가 바뀌면 별칭 레코드가 바로 인식한다.
    * TTL은 Route 53에 의해 자동으로 설정된다.
    * 별칭 레코드의 대상으로는 ELB, CloudFront 배포, API Gateway, 일래스틱 빈스톡 환경, S3 웹사이트, VPC 인터페이스 엔드포인트, Global Accelerator 가속기, 동일 호스트 존의 Route 53 가 될 수 있다.
    * **EC2의 DNS 이름에 대해서는 별칭 레코드를 설정할 수 없다.**

### **타사 도메인 연결**

* 타사에서 도메인을 구매한 후 Route 53과 연동도 가능하다.
* 이 때에는 Route 53을 DNS Service Provider로 이용하게 된다.
* Route 53에 Hosted Zone을 만들고, 타사 도메인에 NS 레코드를 생성해 Route 53 Name Server를 값으로 입력하면 된다.

## 라우팅 정책

### 단순

* 트래픽을 단일 리소스에 보내는 방식이다.
* 동일 레코드에 여러 값을 지정할 수 있다.
* DNS Lookup을 통해 다중 값을 얻었다면 클라이언트가 무작위로 하나를 골라 사용하게 된다.
* 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있다. 이 때 상태 확인은 불가능하다.

### 가중치

* 가중치를 활용해 요청의 일정 비율을 특정 리소스로 보낼 수 있다.
* 예를 들어 여러 A 레코드들에 대해 가중치를 적용하면, 특정 IP는 70% 비중으로 얻게 되고 특정 IP는 30% 비중으로 얻게 될 수 있다.
* 트래픽 비율은 `(특정 레코드의 가중치) / (모든 레코드들의 가중치의 합)`이 된다.
* 동일한 이름과 타입을 가진 DNS 레코드들을 정의하여 각각 가중치를 부여해야 한다.
* 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에 사용한다.
* 가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다. 모든 리소스 레코드 가중치의 값이 0인 경우에는 모든 레코드가 다시 동일한 가중치를 갖게 된다.

### 지연 시간

* 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다.
* 상태 확인과 연결이 가능하다.

> **상태 확인**
>
> * 고가용성을 위해 특정 레코드에 매핑된 값의 상태가 정상적이지 않다면, 해당 레코드 정보를 반환하지 않는 것
> * 상태 정보를 확인하는 방법
>   * 엔드포인트 모니터링
>     * 15개의 헬스 체커들이 기본적으로 30초마다 상태 체크를 한다. HTTP, HTTPS, TCP 프로토콜을 지원하며, 18% 이상의 엔드포인트가 정상이여야 Route 53은 정상이라고 판별한다.
>     * 2xx, 3xx 상태 코드가 오거나 응답 텍스트를 분 석해 상태를 확인한다.
>     * 상태 확인 대상이 되는 AWS 리소스는 헬스 체커로부터 들어오는 트래픽을 허용해주어야 한다.
>   * 응답 값을 계산해 판별
>     * 여러 개의 상태 확인 결과를 OR와 AND 또는 NOT을 통해 하나로 합쳐준다.
>     * 하위 상태 확인을 256개까지 모니터링할 수 있다.
>     * 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있다.
>   * CloudWatch 알람 모니터링
>     * 모든 Route 53의 상태 확인이 public 웹에 있기 때문에, private 리소스 엔드 포인트에 접근이 불가능할 수 있다. 따라서 이 경우에는 CloudWatch 지표를 만들고 CloudWatch 알람을 할당해야 한다.

* Route 53는 지연 시간을 측정하여, 가장 낮은 지연시간을 가진 리전의 레코드를 반환해준다.

### Failover

* DNS 요청이 들어왔을 때 기본 레코드의 상태 확인이 정상이면 해당 레코드를 사용하고, 비정상이면 보조(secondary) 레코드 중 하나를 사용하여 응답을 보낸다.

### 지리적 위치

* 지역과 레코드를 매핑해, 특정 지역으로부터 온 요청이 특정 레코드에 매핑되도록 한다.
* 지정하지 않은 지역에 대해 처리하기 위해 기본 레코드를 생성해두어야 한다. &#x20;

### 지리적 근접성

* 특정 리전의 편향(bias) 값을 증가(1 \~ 99)시켜 특정 레코드를 더 많이 사용하도록 할 수 있다.
* **각 리전의 트래픽을 세밀하게 조정할 때 유용**하다.
* 특정 리전에 매핑된 리소스로의 트래픽을 줄이려면 편향 값을 음수(-1 \~ -99)로 축소시키면 된다.
* Route 53 Traffic Flow 기능을 통해서만 사용 가능하다.
  * 복잡한 라우팅 의사 결정 트리를 UI를 통해 설정할 수 있는 툴이다.
  * 트래픽 플로우 정책 단위로 저장 가능하며 버전 관리, 호스팅 영역 적용 등의 기능을 제공한다.

<figure><img src="https://946524419-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FZqOTWctN1y9hEXEl4sKd%2Fuploads%2FaMhY99cxn5DMmwGTvvBC%2Fimage.png?alt=media&#x26;token=79471e87-c047-4ff1-9aae-98020e1016f7" alt=""><figcaption></figcaption></figure>

### IP

* 클라이언트의 IP를 기반으로 라우팅한다. CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지 정한다.
* 성능을 최적화하고 네트워크 비용을 줄일 수 있다.

### 다중 값

* 트래픽을 다중 리소스로 라우팅할 때 사용한다.
* 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
* 다중 값 정책이 ELB를 대체할 수는 없다.
* 단순 라우팅 정책은 상태 확인이 불가능하므로 반환되는 리소스 중 하나가 비정상일 가능성이 존재한다. 다중 값 라우팅 정책을 사용할 경우 정상인 리소스만 반환한다.
