AWS Route 53

Route 53

• 고가용성 확장성을 갖춘, 완전히 관리할 수 있고 권한있는 DNS 서비스
  • 권한이 있다는 말은 DNS를 완전히 제어할 수 있다는 뜻
• 도메인 Registrar로 도메인이름을 등록 가능
• 리소스 관련 상태 확인 가능
• 100% SLA 가용성을 제공하는 유일한 AWS 서비스
• 53은 DNS 서비스에서 사용하는 전통적인 포트

 

Records

• 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의
  • 각 레코드는 도메인과 서브 도메인 정보를 가짐
  • 레코드 타입: e.g. A or AAAA …
  • 레코드 값: e.g., 123.456.789.123
  • 라우팅 정책: Route53이 쿼리에 응답하는 방식
  • TTL: DNS Resolver에 레코드가 캐싱되는 시간
• 지원하는 레코드 타입
  • A, AAAA, CNAME, NS
  • (advanced) CAA / DS / MX / NAPTR / PTR / SOA / TXT / SPF / SRV\

 

Record Types ( 자주 출제됨 )

• A - 호스트 이름과 IPv4 Ip를 매핑함
• AAAA - 호스트이름과 IPv6 IP를 매핑
• CNAME - 호스트이름을 다른 호스트 이름과 매핑
  • A나 AAAA 레코드가 될 수 있음
  • DNS 네임스페이스의 탑 노드에 대한 CNAME 레코드는 생성할 수 없다
  • 예시) example.com에 대한 CNAME은 만들 수 없지만 www.example.com에 대한 CNAME 레코드는 만들 수 있다
• NS - 호스팅 존의 네임서버로 서버의 DNS 이름 또는 ip주소로 호스팅 존에 대한 dns 쿼리 응답 가능
  • 트래픽이 도메인으로 라우팅 되는 방식을 제어

 

Hosted Zones

• 레코드의 컨테이너로 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의
• 퍼블릭 호스팅존과 프라이빗 호스팅 존 ( 도메인이름이 공개됐느냐 그렇지 않느냐에 대한 차이 )
• Public Hosted Zone (공개 도메인 이름)
• Private Hosted Zone (비공개 도메인 이름)
  • 프라이빗 호스팅은 VPC(가상 사설 클라우드) 내부에서만 URL을 사용할 수 있다
  • 회사 네트워크 내부에서만 접근할 수 있는 URL이 있음 - 비공개 URL로 외부에서 접근 불가
• 어떤 호스트 존이든 달마다 0.5달러를 지불해야함

 

Route 53 - TTL ( Time To Live )

• DNS에게 응답을 받지 않아도 요청을 클라이언트에서 캐싱해서 직접 Web Server로 접근

 

High TTL - e.g. 24H

• Route53의 트래픽은 현저히 적어진다 (클라이언트가 요청을 적게 보냄 )
• 클라이언트가 가지는 레코드가 오래될 수도 있다

 

Low TTL - e.g. 60 sec

• Route 53에 더 많은 트래픽이 들어오고 비용이 많이 든다. (요청의 양에 따라 비용 청구)
• 레코드가 빨리 업데이트 되며 변경하기가 더 쉽다

TTL은 별칭(Alias) 레코드를 제외한 모든 레코드에서 필수적이다

 

 

CNAME vs Alias

• 로드밸런서를 만들면 로드밸런서에 DNS 이름이 생성되는데 이걸 보유한 도메인으로 호스티 이름을 매핑할 때 사용하는 방법이다

 

CNAME

• 호스트 이름이 다른 호스트 이름으로 향할 수 있음
• 루트 도메인이 아닌 경우에만 가능 (example.com이라는 도메인을 소유할 경우 → test.example.com 등으로 변경해서 등록해야 가능하다

 

Alias

• Route 53에 한정되지만 호스트 이름이 특정 AWS 리소스로 갈 수 있음 (example.com → test.amazonaws.com)
• 루트 및 비루트 도메인도 연결 가능 (루트 도메인도 aws 리소스로 연결 가능)
• 무료이며 자체적인 상태 확인이 가능

 

Route 53 - Alias Records

• 호스트 이름을 AWS 리소스로 매핑
• 모든 DNS에서 가능
• DNS 네임스페이스의 탑 노드로 사용될 수 있음 ( example.com )
• 별칭 레코드의 타입은 항상 A/AAAA이다
• TTL은 설정할 수 없고 Route 53에 의해 자동 설정

 

Alias Records Targets

• ELB
• CloudFront Distributions
• API Gateway
• Elastic Beanstalk environments
• S3 Websites
• VPC Interface Endpoints
• Global Accelerator accelerator
• Route 53 record in the same hosted zone

EC2 DNS 이름은 별칭레코드를 설정할 수 없다

 

Routing Policies

• Route 53이 DNS 쿼리에 응답하는 것을 정의하는 것으로 이전에 배웠던 Routing과는 조금 다름
• 네트워크 라우팅과 혼동하면 안된다
  • DNS는 어떤 트래픽도 라우팅하지 않으며, 오로지 DNS 쿼리에 대해서만 반응한다
  • DNS는 호스트 이름들을 클라이언트가 실제 사용가능한 엔드포인트로 변환하는 것을 돕는다
• Route 53은 다음과 같은 라우팅 정책을 지원한다
  • Simple - 단순
  • Weighted - 가중치 기반
  • Failover - 장애 조치
  • Latency based - 지연 시간 기반
  • Geolocation - 지리적
  • Multi-Value Answer - 다중 응답
  • Geoproximity - 지리 근접

 

Simple Routing Policies

• 단일 리소스에 대한 트래픽 처리로 일반적인 DNS 레코드 처리 방식이다
• 같은 레코드에 여러 값으로 넣을 수 있다
  • 이 경우 클라이언트는 랜덤한 한개의 값을 받는다
• Alias를 사용하는 경우 하나의 특정 AWS 리소스만 등록 가능
• 상태 확인은 불가능하다

 

Weighted 라우팅 정책 (가중치 기반)

• 요청의 일부를 가중치에 따라 특정 리소스로 보내는 것이 가능
  • 가중치가 높으면 더 많은 트래픽이 들어감
• DNS 레코드끼리 같은 이름과 같은 타입을 가져야한다
• 상태 확인도 가능하다
• 사용 사례
  • 리전간 로드밸런싱 할때, 새 어플리케이션을 테스트하는 경우
• 가중치 0이라면 트래픽 보내기를 중단
• 모든 리소스 레코드가 0이라면, 모든 레코드가 동일한 가중치로 초기화
• 가중치가 가장 큰 곳으로 대부분의 DNS 쿼리를 리다이렉팅

 

Latency-based 라우팅 정책

• 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉트
• 유저가 가장 가까운 AWS 리전으로 연결하기까지 걸리는 시간을 기반으로 측정
• 독일에 있는 유저가 가장 가까운 리전이 미국이라면 미국으로 리다이렉트 된다
  • 사진으로 이해하면 쉽다

 

Route 53 - Health Checks (상태확인)

• 공용 리소스에 대한 상태를 확인
• 고가용성, DNS의 장애 조치를 자동화하기 위한 작업으로 세가지 방법이 있다
  • 공용 엔드 포인트를 모니터링
  • 다른 상태 확인을 모니터링 (계산된 상태 확인 )
  • CloudWatch 경보의 상태를 모니터링하는 상태 확인도 있다 - 제어가 쉽고 개인리소스 유용

Health Checks - Monitor an Endpoint

• 상태 확인이 가능하려면 애플리케이션 밸런서나 엔드 포인트에 접근이 가능해야함
  • Healthy/UnhealthyThreshold (3) → 비정상 요청이 3번 들어오면 해당 레코드를 비정상으로 간주
  • 간격 → Default / Fast (30초 / 10초) Fast가 더 비쌈
  • HTTP HTTPS TCP 지원
• 다양한 옵션으로 정상 상태를 확인할 수 있음 → HTTP 응답, 5120의 처음 응답 텍스트
• Health Checker 응답이 가능하도록 연결하거나 보안 그룹을 설정해야 한다

 

계산된 상태 확인

• 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
• OR AND로 결합하여 상태 확인 가능

 

개인 리소스의 상태 확인

• 개인 엔드포인트에 접근이 어렵다. 따라서 CloudWatch 알람을 활용하여 인스턴스를 모니터
• 메트릭이 침해되는 경우 알람을 생성하고 헬스 체커가 비정상을 확인함

 

Failover(Active-Passive) 라우팅 정책

• 메인 인스턴스에 장애가 발생할 경우 재해 복구용 보조 인스턴스로 DNS 요청을 라우팅
• 기본 인스턴스가 정상이면 Route 53도 기본 레코드로 응답하다가 상태 확인이 비정상으로 확인되면 두 번째 레코드의 응답을 자동으로 얻게됨
• 메인 레코드는 상태 확인이 필수이지만 보조 레코드는 선택

 

Geolocation 라우팅 정책

• 지연시간 기반과는 엄연히 다르며 사용자의 실제 위치를 기반으로 한다
• 특정 국가, 특정 주로 정확한 위치가 선택되어 라우팅된다
• 일치하는 위치가 없다면 기본 레코드를 생성해야한다
• 콘텐츠 분산, 로드 밸린싱 등을 실행하는 웹사이트 현지화
  • 클라이언트가 독일에 있는 경우 독일 레코드로 간다

 

Geoproximity 라우팅 정책

• 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 함
• 정의된 편향값을 기반으로 더 많은 트래픽을 특정 리소스로 옮길 수 있다
• 지리적 위치를 변경하려면 편향값을 지정해야한다
  • 리소스에 트래픽을 늘리기 위해선 편향값을 증가시켜 확장하면 된다
  • 리로스에 트래픽을 줄이기 위해선 편향값을 감소시켜 축소하면 된다
• 리소스는 AWS의 리소스로 특정 리전을 등록하면 자동으로 올바른 라우팅을 계산
• AWS 리소스가 아닌 온프레미스인 경우 위도와 경도를 지정하여 AWS가 위치를 특정해야 함
• 고급 Route 53 트래픽 플로우를 사용해야 함

 

Multi-Value 라우팅 정책

• 트래픽을 다중 리소스로 라우팅 할때 사용
• Route 53은 다중 값과 리소스를 반환
• 상태 확인과 연결하면 반환되는 하나의 인스턴스만 정상 상태 확인과 관련이 있다
• 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환
• ELB와 유사해보이지만 전혀 다르고 대체될 수 없다
• 레코드 하나만 정상 상태를 가지면 그것을 클라이언트에게 전달할 수 있다
  • Simple 라우팅 정책과는 다르게 Simple은 상태 확인이 불가능하며 비정상일 가능성이 존재

 

Domain Registar vs DNS Service

• 도메인 이름을 도메인 Registar를 통해 구매할 수 있고 매년 비용을 지불해야 한다
  • GoDaddy, Amazon Registrar, google Domain
• 대게 레지스트라를 통해 구매하면 DNS 레코드 관리할 수 있다.
• GoDaddy에서 도메인을 구매하고 Route 53으로 레코드를 관리할 수 있다
  • Nameserver(NS)를 아마존 name servers로 변경하면 된다
• 따라서 도메인 레지스트라와 DNS 서비스를 같다고 보면 안된다
  • 도메인 레지스트라가 일부 DNS 서비스를 지원해도 같지 않다