AWS SAA chapter 8. AWS Route 53

DNS란?

• Domain Name System의 약자로 사람에게 친숙한 호스트 이름을 대상 서버 IP 주소로 번역해준다.
• ex : www.google.com -> 172.217.18.36
• 인터넷의 중추 역할을 한다.
• URL과 호스트 이름을 IP로 변환한다.
• DNS에는 계층적 이름 구조가 존재한다.

DNS Terminologies

• Domain Registrar : 도메인 이름을 등록하는 곳
• DNS Records : A, AAAA, CNAME, NS 등등
• Zone File : 모든 DNS 레코드를 포함하는 것
  • 호스트 이름과 IP 또는 주소를 일치시키는 방법이다
• Name Server : resolves DNS queries
• Top Level Domain(TLD) : DNS 쿼리를 실제로 해결하는 서버이다.(.com, .us, .in 등등)
• Second Level Domain(SLD): google.com, amazon.com 등등

How DNS Works

AWS Route 53

• 고가용성과 확장성을 갖춘, fully managed, Authoritative DNS이다
  • Authoritative : 우리들이 DNS 레코드를 업데이트할 수 있다는 의미
• 위에서 언급했듯이 Route 53은 Domain Registrar이다.
• 또한 Route 53의 리소스 관련 상태 확인을 할 수 있다.
• 100% SLA 가용성을 제공하는 유일한 AWS 서비스이다.
• Route 53이라고 부르는 이유 : 53은 전통적인 DNS 포트이다.

Route 53 - Records

• 여러 DNS 레코드를 정의하고, 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의한다.
• 각 Record는 아래와 같은 것들을 포함한다
  • Domain/sub-domain name : e.g.,example.com
  • Record Type : e.g., A or AAAA
  • Value : e.g., 123.456.789.123
  • Routing Policy : Route 53이 쿼리에 응답하는 방식
  • TTL(Time To Live) : DNS resolver에서 레코드가 캐싱되는 기간
• Record 53에서 지원하는 DNS 레코드 종류는 많다
  • 그 중에서 반드시 알아야 하는 것들은 A / AAAA / CNAME / NS 이다 (시험용)
  • 고급 레코드 : CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, SRV(추가 정보용)

Route 53 - Record Types

• A : 호스트 이름과 IPv4 IP를 매핑한다.
• AAAA : 호스트 이름과 IPv6 IP를 매핑한다
• CNAME : 호스트 이름과 다른 호스트 이름을 매핑한다.
  • Target : A, AAAA
  • Route 53에서 DNS 이름 공간 또는 Zone Apex의 상위 노드에 대한 CNAME를 생성할 수 없다.
    • ex : example.com에 CNAME을 만들 수는 없지만 example.com에 대한 CNAME 레코드는 만들 수 있다.
• NS : 호스팅 존의 이름 서버이다. 서버의 DNS 이름 또는 IP주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있다.
  • 트래픽이 도메인으로 라우팅 되는 방식을 제어한다.

Route 53 - Hosted Zones

• 호스팅 존은 레코드의 컨테이너이다. 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다.
• 호스팅 존의 종류 두가지
  • Public Hosted Zoned
    • 퍼블릭 도메인 이름을 살 때마다 (mypublicdomain.com이 퍼블릭 도메인 이름이라면) 퍼블릭 호스팅 존을 만들 수 있다.
    • 퍼블릭 존은 쿼리에 도메인 이름 application1.mypublicdomain.com의 IP가 무엇인지 알 수 있다.
  • Private Hosted Zoned
    • 공개되지 않는 도메인 이름을 지원한다. 가상 프라이빗 클라우드(VPC)만이 URL을 리졸브 할 수 있다.
      • ex : application1.company.internal 처럼 사기업에는 때때로 회사 네트워크 내에서만 접근할 수 있는 URL이 있다.
• AWS에서 만드는 어떤 호스팅 존이든 월 0.5 달러를 지불해야한다.

Route 53 - Public vs Private Hosted Zones

Route 53 - Records TTL(TIme To Live)

• High TTL - e.g., 24hr
  • Less traffic on Route 53
  • 하지만 클라이언트가 오래된 레코드를 받을 수 있다.
• Low TTL - e.g., 60sec
  • DNS에 트래픽의 양이 많아져서 비용이 많이 들게 된다.
  • 하지만 오래된 레코드의 보관 시간은 짧아진다.
  • 따라서 레코드 변경이 빨라진다.
• TTL은 모든 레코드에 있어서 필수적이다.(하지만 Alias 레코드는 제외이다)

CNAME vs Alias

• 로드 밸런서나 CloudFront 등 AWS의 리소스를 사용하는 경우 호스트 이름이 노출된다.
• 이를 보유한 도메인에 호스트 이름을 매핑하고 하고자 할 때 두가지 옵션이 존재한다

1. CNAME
   • 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있다
   • 이건 루트 도메인 이름이 아닌 경우에만 가능하다.
     • 예를 들어 루트 도메인이 mydomain.com 일 때 something.mydomain.com과 같이 앞에 뭔가가 붙어있는경우.
2. Alias
   • 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있다.
   • root domain과 non-root domain 모두에 작동한다.
   • 무료이다.
   • 자체적으로 상태 확인이 가능하다

Route 53 - Alias Records

• 이들은 AWS의 리소스에만 매핑되어 있다.
• DNS의 확장 기능이기 때문에 시중의 모든 DNS에서 가능하다
• 자동적으로 리소스의 IP 주소의 변경일 인식한다.
• CNAME과 달리, Zone Apex라는 DNS 네임스페이스의 상위 노드로 사용될 수 있다.
• AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA인데 리소스는 IPv4나 IPv6 중 하나이다.
• TTL을 설정할 필요 없이 Route 53에 의해 자동으로 설정된다.

Route 53 - Alias Records Targets

• Elastic Load Balancer
• CloudFront Distributions
• API Gateway
• Elastic Beanstalk environments
• S3 Websites(그냥 bucket은 안됨, bucket들이 웹사이트로 활성화될 시에 가능)
• VPC 인터페이스 엔드포인트
• Global Accelerator 가속기
• Route 53 record in the same hosted zone
• EC2의 DNS 이름에 대해서는 Alias Record를 설정할 수 없다

Route 53 - Routing Policies

• 라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 돕는다.
  • 여기서 말하는 라우팅은 DNS의 관점이다.(DNS는 트래픽을 라우팅하지 않는다. 트래픽은 DNS를 통과하지 않기 때문이다. DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리등을 어떻게 처리해야 하는지를 알 수 있게 되는 것이다.)
  • DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 돕는다.
• Route 53이 지원하는 라우팅 정책은 아래와 같다.
  • Simple
  • Weighted
  • Failover
  • Latency based
  • Geolocation
  • Multi-Value Answer
  • Geoproximity(using Route 53 Traffic Flow feature)

Routing Policies - Simple

• 일반적으로 트래픽을 단일 리소스로 보내는 방식이다.
• 동일한 레코드에 여러 개의 값을 지정하는 것도 가능하다
• DNS에 의해 다중 값을 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 된다.
• 단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있다.
• 상태 확인은 할 수 없다.

Routing Policies - Weighted

• 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능하다.
• 각 레코드에 상대적으로 가중치를 할당 받게 된다.
• 이러한 가중치는 \(traffic(\%) = 해당 레코드의 가중치 / 전체 가중치\) 로 계산될 수 있다.
• 이렇게 하려면 DNS 레코드들은 동일한 이름과 유형을 가져야 하며, 상태 확인과도 연관 된다.
• 가중치 기반 정책이 사용되는 경우
  • 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에도 사용한다.
• 가중치를 0으로 할당할 경우 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있다.
• 만약 모든 리소스 레코드 가중치의 값이 0인 경우에는 모든 레코드가 다시 동일한 가중치를 갖게 된다.

Routing Policies - Latency-based

• 지연 시간이 가장 짧은(즉, 가장 가까운) 리소스로 리다이렉팅 하는 정책이다.
• 지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우 유용한 정책이다.
  • 지연시간은 유저가 레코드로 가장 가깝게 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다.
• 상태 확인이 가증하다

Routing Polices - Failover(Active-Passive)

Routing Policies - Geolocation

• 지연 시간 기반의 정책과는 다르게 사용자의 실제 위치를 기반으로 한다.
• 사용자의 구체적인 위치를 기반으로 이뤄진다.
• 일치하는 위치가 없는 경우 기본 레코드를 생성한다
• 웹 사이트 현지화를 할 때 주로 사용된다.
• 편향 값을 조정하여 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다

Routing Polices - Geoproximity(지리 근접)

(편향값이 없는 경우)

(편향값이 있는 경우)

• 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 한다.
• 이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스에 대한 많은 트래픽을 이동하는 것이다.
• 따라서 지리적 위치를 변경하려면 편향값을 지정해야 한다. 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 된다.
  • 증가(1 ~ 99) : 리소스에 더 많은 트래픽이 주어짐
  • 감소(-1 ~ -99) : 리소스에 더 적은 트래픽이 주어짐
• 리소스가 될 수 있는 것들
  • AWS resources (예시 : AWS region)
  • Non - AWS resources(예시 : Latitude and Longitude)
• 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용한다.

Routing Policies - IP-based Routing

• 클라이언트 IP 주소를 기반으로 라우팅을 정의한다.
• Routing 53에서 CIDR 목록을 정의한다.
  • CIDR : 클라이언트의 IP범위
• CIDR에 따라 트래픽을 어느 로케이션에 보내야 하는지 정한다.
• 성능을 최적화하는 용도로 사용한다
• 예시 : 특정 인터넷 제공업체가 특정 IP 주소 셋을 사용한다는 정보를 알고 있으면, 특정 엔드포인트로 라우팅할 수 있다.

Routing Polices - Multi-Value

• 트래픽을 다중 리소스로 라우팅할 때 사용한다.
• Route 53은 다중 값과 리소스를 반환한다.
• Health Checks와 연결하려면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련있다.
• 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
• ELB와 유사해 보이지만 ELB를 대체할 수는 없다.
• 클라이언트 측면의 로드 밸런싱이다.
  • 최대 8개의 레코드를 가질 수 있으며 이중에서 Healthy한 인스턴스로 가게 된다.

Route 53 - Health Checks

• 상태 확인(Health-Check)은 주로 공용 리소스에 대한 상태를 확인하는 방법이다.
• Health Check -> Automated DNS Failover(DNS의 장애 조치를 자동화 하기 위한 작업이다)
• 세 가지의 상태 확인이 가능하다.
  • 공용 엔드 포인트(애플리케이션, 서버, 리소스)를 모니터링하는 것
  • 계산된 상태 확인(Calculated Health Checks)
  • CloudWatch 경보의 상태를 모니터링
• 이 상태 확인들은 각자의 메트릭을 사용한다.

Health Checks - Monitor an Endpoint

• 전 세계에서 온 15개의 상태 확인이 엔드 포인트의 상태를 확인하고 임계값을 정상 혹은 비정상으로 설정한다.
  • Health/Unhealthy Threshold - 3 (default)
  • Interval - 30 sec(10 sec로 설정할 수 있지만 비용이 더 많이 든다)
  • HTTP, HTTPS, TCP 등 많은 프로토콜을 지원한다.
  • 18 % 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주한다.
  • 상태 확인을 할 위치도 선택할 수 있다.
• 상태 확인은 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 된다.
• 텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5120 byte를 확인한다.(응답 자체에 해당 텍스트가 있는지 보기 위함)
• 상태 확인의 작동이 가능하려면 상태 확인이 사용자의 애플리케이션 밸런서나 엔드 포인트에 접근이 가능해야 한다.
  • 따라서 Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 한다.

Health Checks - Calculated Health Checks

• 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능이다.
• OR, AND, NOT 을 조합하여 그룹지을 수 있다
• Child Health Check을 256개까지 모니터링 할 수 있다.
• 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있다.

Health Checks - Private Hosted Zones

• 개인의 리소스를 모니터링 하는 것은 어려운 일이다.
  • 모든 Route 53의 상태 확인이 공용 웹에 있기 때문이다.(이들은 VPC 의 외부에 있다)
• 개인 엔드 포인트에 접근이 불가능하다.
• 그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있다.
  • CloudWatch 경보를 상태 확인에 할당할 수 있다.
  • CloudWatch Metric을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터하는 것이다.
  • 매트릭이 침해될 경우 CloudWatch 알람을 생성하는 방식
  • 이러한 알람이 Alarm 상태가 되면 상태 확인은 자동으로 비정상이 된다.

Domain Registrar vs DNS Service

• 대게 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공한다.
• 그래서 Amazon 호스트 이름으로 DNS를 등록했다면, DNS 레코드 관리를 위한 Route 53 호스팅 존을 가진다.
• 하지만 DNS 레코드로 AWS Route 53 등을 사용하지 않고, Amazon Registrar 또는 GoDaddy를 사용하여 example.com을 구매했을 때, DNS 레코드는 Amazon Route 53에서 관리하도록 하는 것이 가능하다.
• 즉, 도메인을 타사 등록 대행사에서 구매해도, DNS 서비스 제공자로 Route 53을 사용 가능하다
• 사용하기 위한 순서
  1. Create a Hosted Zone in Route 53
  2. Update NS Records on 3rd party website to use Route 53 Name Servers
• 비록 일부 DNS 기능을 제공하더라고 Domain Registrar != DNS Service이다.