[AWS/SAA-03] Route 53

 

💝 Route 53

✅ DNS

✅ Route 53

✅ 레코드 / 레코드 종류 / 호스트 존 / 레코드 TTL / CNAME / 별칭 / 별칭레코드

✅ Route 53 라우팅 정책 (7가지)

✅ Route 53 상태 확인

✅ 도메인 등록 기관 vs DNS 서비스 vs 타사 등록 기관

 

 

 

🚨 DNS

✤ Domain Name System

✤ 사람들에게 친숙한 호스트 이름(예: www.amazon.com) 을 컴퓨터가 읽을 수 있는 대상 서버 IP 주소(예:  192.0.2.44) 로 번역하는 시스템

✤ www.google.com → 172.217.18.36

✤ DNS 는 인터넷의 중축이고, URL 과 호스트 이름을 IP 로 변환한 것

✤ DNS 는 계층적 이름구조를 사용한다

✤ 도메인 이름의 계층

  • .com

  • example.com

  • www.example.com 

  • api.example.com

✤ DNS 관련 용어

  • 도메인 이름 등록 (Domain Registrar) 

  • 도메인 레코드 (Domain Records) : 모든 DNS 레코드를 포함. 호스트 이름과 IP 주소를 일치시키는 방법

  • 영역 파일 (Zone File) : DNS 쿼리를 실제로 해결하는 서버

  • 이름 서버 (Name Server)

  • 최상위 도메인 (Top Level Domain(TLD))

  • 2단계 도메인 (Second Level Domain(SLD))

✤ 웹 브라우저에서 www.example.com 에 접근하면 Local DNS 서버에 물아본다 → 처음보는 쿼리라면 Root DNS 로

 

 

 

🚨 Route 53

✤ 확장 가능한 DNS 관리 시스템

✤ 고가용성, 확장성, 완벽한 관리 및 권한이 있는 DNS 이다

  • 권한있는, 권위있는(Authoritative) = 고객(여러분)이 DNS 레코드를 업데이트 할 수 있다 → DNS 제어 가능

✤ Route 53 은 도메인 Registrar 이다 → 도메인 이름을 example.com 으로 등록

✤ 리소스 관련 상태확인 가능

✤ 100% SLA 가용성을 제공하는 유일한 AWS 서비스

✤ DNS 서비스. 이름에 사용되는 전통적인 DNS 포트

 

 

 

🚨 Route 53 - 레코드 (Record)

✤ Route 53 에서 여러 DNS  레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법 정의

 

레코드에 포함되어 있는 것

  • 도메인/서브도메인 이름 (Domain/SubDomain Name) : example.com

     - 각 레코드는 도메인이나 서브도메인 이름과 같은 정보를 포함

  • 레코드 종류 (Record Type) : e.g, A, AAAA

  • 레코드 값 (Value) : 12.34.56.78

  • 라우팅 정책 (Routing Policy) : Route 53 쿼리에 응답하는 방식

  • TTL (TimeToLive) : DNS 리졸버에서 레코드가 캐싱되는 시간

 

Route 53 에서 지원하는 DNS 레코드 종류

  • A / AAAA / CNAME / NS

  • CAA / DS / MX / NAPTR / PTR / SOA / TXT / SPF / SRV

 

 

 

🚨 Route 53 - 레코드 종류 (Record Types)

✤ DNS 레코드를 통해 트래픽을 도메인에 라우팅하는 방식을 DNS 에 알려준다

✤ A

✤ AAAA

✤ CNAME

✤ NS

 

A

  • 호스트 이름과 IPv4 IP 를 매핑

 

AAAA

  • 호스트 이름과 IPv6 IP 를 매핑

 

CNAME

  • 호스트 이름을 다른 호스트 이름과 매핑

  • 대상 호스트 이름은 A 나 AAAA 가 될 수 있다

  • DNS 이름 공간 또는 Zone Apex 의 상위 노트에 대한 CNAME 을 생성할 수 없다

     - example.com → CNAME 생성 X / www.example.com → CNAME 생성 O

 

NS

  • 호스트 존의 이름 서버

  • 트래픽이 도메인으로 라우팅되는 방식을 제어

  • 서버의 DNS 이름 또는 IP 주소로, 호스팅 존에 대한 DNS 쿼리에 응답할 수 있다

 

 

 

🚨 Route 53 - 호스트 존 (Hosted Zone)

✤ 레코드의 컨테이너

✤ 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의하는 레코드의 컨테이너

✤ 월 50센트($0.50) 지불해야 함

 

Public Hosted Zones

  • 퍼블릭 도메인 이름을 살 때마다 퍼블릭 호스트존을 만들 수 있다

  • 퍼블릭 존은 쿼리에 IP 가 무엇인지 알 수 O

  • 공개된 클라이언트로부터 온 쿼리에 응답할 수 있다

 

Private Hosted Zones

  • 공개되지 않은 도메인 이름 지원

  • 가상 프라이빗 클라우드(PVC) 만이 URL 리졸브 할 수 O

  • 해당 VPC 에서만 동작

  • 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있다

 

 

 

🚨 Route 53 - 레코드 TTL (Time To Live)

✤ 레코드에 관한 정보 및 결과를 캐싱하는 시간

✤ TTL 은 모든 레코드에 필수적이지만 별칭 레코드는 제외된다

✤ High TTL - e.g., 24hr

  • 적은 트래픽

  • 레코드 최신화 X

✤ Low TTL - e.g., 60 sec.

  • 많은 트래픽

  • 비용 ⬆️

  • 레코드 변경 많다

 

 

 

🚨 Route 53 - CNAME vs 별칭 (Alias)

✤ AWS 리소스(로드밸런서, CloudFront..) 는  AWS 의 호스트이름을 노출한다.

 

CNAME

  • 호스트 이릅이 다른 호스트 이름으로 향하도록 가능 (app.mydomain.com → bpp.anything.com)

  • 루트도메인이 아닌 도메인의 경우에만 해당

 

별칭 Alias

  • Route 53 에만 가능

  • 호스트 이름이 특정 AWS 리소스로 향하도록 가능

  • 루트도메인, 비루트도메인에 모두 작동함

  • 무료, 자체적 성능 확인 가능

 

 

 

🚨 Route 53 - 별칭 레코드 (Alias Records)

✤ AWS 리소스에만 매핑되어 있다

✤ DNS 확장 가능. 시중 모든 DNS 에서 가능

✤ 기반 ALB 에서 IP 가 바뀌면 별칭레코드는 이걸 바로 인식한다

✤ CNAME 과 다르게 DNS 네임스페이스의 최상위 노드에 사용 가능 (예: example.com)

✤ AWS 리소스에 대한 별칭레코드는 항상 A/AAAA 이다 (IPv4, IPV6 중 하나)

✤ 별칭레코드 사용 시 TTL 설정 불가

 

별칭 레코드 대상 (Alias Records Target)

  • ELB

  • CloudFront 배포

  • API 게이트웨이

  • Elastic 빈스톡 환경

  • S3 웹사이트(S3 버킷은 불가 - 버킷들이 웹사이트로 활성화 시 가능)

  • VPC 인터페이스 엔드포인트

  • Global Accelerator 가손기

  • 동일 호스트존의 Route 53

  • EC2 의 DNS 이름에 대해서는 별칭레코드 설정 불가

 

 

 

🚨 Route 53 - 라우팅 정책 (Routing Polices)

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

✤ DNS 관점의 "라우팅" 이다!

  • 트래픽을 라우팅하는 로드 밸런서 라우팅과 다르다

  • DNS 는 트래픽을 라우팅하지 않으며 DNS 쿼리에만 응답한다

✤ Route 53 이 지원하는 라우팅 정책

  • 단순 (Simple)

  • 가중치 기반 (Weighted)

  • 지연 시간 기반 (Latency based)

  • 지리적 위치 (Geolocation)

  • 지리 근접 라우팅 정책 (Geoproximity)

  • 다중응답 (Multi-Value Answer)

  • 장애조치 (Failover)

 

단순 라우팅 정책 (Simple)

  • 일반적으로, 트래픽을 단일 리소스로 보내는 방식

  • 도메인 이름 → IP 주소로 라우팅

  • 동일한 레코드에 여러 개의 값을 지정 가능

  • DNS 에 의해 다중값을 받은 경우, 클라이언트에서 그 중 하나를 무작위로 고른다 (랜덤하게 라우팅)

  • 단순 라우팅정책에 별칭레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있다

  • 상태 확인 불가

 

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

  • 접속자가 요청하는 횟수의 가중치(%) 를 기준으로 라우팅하는 방식

  • 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어 기능

  • 각각 레코드에 상대적으로 가중치를 할당하게 되는 것

     - [각 레코드로 보내지는 트래픽 양 (%) = 해당 레코드 가중치/조치 가중치] → 전체 중 일부 퍼센트

  • DNS 레코드들은 동일한 이름과 유형을 가져야 함

  • 상태 확인과 관련 O

  • 가중치값 0을 보내면 트래픽에 보내기를 중단해 가중치를 바꿀 수 있다

  • 모든 리소스 레코드 가중치 값이 0인 경우, 모든 레코드가 0인 경우, 모든 레코드가 모두 동일한 가중치를 갖게 됨

  • 트래픽을 분산하거나 버전이 다른 애플리케이션을 테스트 하는 경우 유용

  • 가중기반 정책이 사용되는 이유 

     - 서로 다른 지역들에 걸쳐 로드 밸런싱할 때

     - 적은 양의 트래픽을 보내 새 애플리케이션 테스트하는 경우

 

지연 시간 기반 라우팅 정책 (Latency-based)

  • 지연 시간이 짧은, 즉 가장 가까운 리소스로 리다이렉트 하는 방식

  • 지연 시간에 민감한 웹사이트나 애플리케이션에 유용

  • 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기 까지 걸리는 시간을 기반으로 측정

  • 독일 사용자는 미국으로 연결될 수 있다 (지연 시간이 가장 짧은 경우)

  • 상태 확인과 관련 O

 

지리적 위치 라우팅 정책(Geolocation)

  • 지연시간 기반의 정책과 매우 다름 (지연시간 기반 라우팅 정책은 사용자와 가까운 AWS 리전으로 라우팅)

  • 사용자의 실제 위치를 기반으로 함

  • 사용자가 속한 대륙이나 국가를 기준으로 라우팅하는 방식

  • 대륙, 국가 또는 미국 주별로 위치 지정 (중복되는 경우 가장 정확한 위치 선택)

  • 일치하는 위치가 없는 경우, 기본 레코드를 생성해야 한다

  • 트래픽을 지정된 서버 IP 로 라우팅 가능

  • 사용 사례 : 콘텐츠 분산 제한, 로드밸런싱 등을 실행하는 웹사이트 현지화, ..

  • 상태확인과 연관 X

 

지리 근접 라우팅 정책 (Geoproximity)

  • 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하는 방식

  • 편향값(bias) 을 사용해 특정 위치를 기반으로 더 많은 트래픽을 리소스로 전환 가능

  • 지리적 위치를 변경하려면 편향값(bias) 을 지정해야 함

     - 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜 확장

     - 특정 리소스에 트래픽을 줄이려면 편향값을 음수로 축소

  • 리소스에 속한 특정 리전을 지정하기

     - AWS 리소스 → AWS 지역 지정

     - AWS 리소스가 아닌 경우 → 위도 / 경도 지정

     - AWS 리소스에 속한 특정 리전을 지정하면 목록에서 자동으로 올바른 라우팅을 계산하거나 AWS 리소스가 아닌 온프레미스 센터인 경우 위도/경도를 지정해서 AWS 가 위치를 파악하도록 함

  • 기능을 선택할 때 편향 활용을 위해 고급 Route 53 트래픽 흐름을 사용해야 한다

 

다중값 라우팅 정책 (Multi-Value)

  • 트래픽을 다중 리로스를 라우팅할 때 사용

  • 사용자가 요청 시 Route 53 DNS 에서 다수의 값과 리소스를 반환하는 라우팅 방식

  • 상태확인과 연관 가능

  • 다중값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련있다

  • 각각의 다중값 쿼리에 최대 8개의 정상 레코드가 반환된다

  • ELB 와 유사해 보이지만 ELB 를 대체할 수 X → 클라이언트 측면의 로드밸런싱인 것

  • 다중값이 있는 다중 라우팅인 경우, 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있다 → 다중값이 조금 더 강력한 레코드이다

 

장애 조치 라우팅 정책 (Failover (Active-Passive) )

  • 기본 라우팅이 실패하면 보조 EC2 인스턴스로 자동 라우팅 되는 방식

  • 상태 확인 은 기본/보조 1개씩만 가능

 

 

 

🚨 Route 53 - 상태 확인 (Health Checks)

✤ HTTP 상태확인은 공개 리소스에만 해당된다

✤ 상태 확인 → 자동화된 DNS 장애 조치

  • 엔드포인트를 모니터링하는 상태 확인 (애플리케이션, 서버, 기타 AWS 리소스)

  • 다른 상태 확인을 모니터링하는 상태 확인 (계산된 상태 확인)

  • CloudWatch 경보를 모니터링하는 상태 확인 (완전한 제어)

✤ 상태 확인은 CW 메트릭과 통합된다

 

엔드포인트를 모니터링하는 상태 확인 (Monitor an Endpoint)

  • 상태확인이 특정 엔드포인트에 어떻게 작동하는지 확인

  • 전 세계에서 온 15개의 상태확인이 엔드포인트의 상태를 확인한다

     - 임계값을 정상/비정상으로 설정

     - 간격 설정 가능

     -  많은 프로토콜 지원

     -  상태 검사기의 18% 이상이 엔드포인트가 정상이라고 판단하면 Route 53 은 이를 정상으로 간주. 그렇지 않으면 건강에 좋지 않다

     -  상태확인에 사용될 위치 선택 가능

  • 엔드포인트가 로드밸런서로부터 2xx 및 3xx 의 상태 코드를 응답받는 경우에만 상태 확인이 통과된다

  • 응답의 처음 5120 바이트에 있는 텍스트 기반으로 상태 확인을 통과/실패로 설정 할 수 있다

     -  응답의 처음 5120 바이트를 확인 응답 자체가 해당 텍스트가 있는지 보기 위함 

  • Route 53 상태 검사기에서 들어오는 요청을 허용하도록 라우터/방화벽을 구성한다

  • 네트워크 관점에서 아주 중요한 부분 → 상태 확인의 작동이 가능하려면 상태확인이 여러분의 애플리케이션 밸런서나 엔트포인트에 접근가능 해야함

 

계산된 상태 확인 (Calculated Health Checks)

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

  • OR, AND, NOT 을 사용 가능

  • 하위 상태 확인을 최대 256개까지 모니터링 가능

  • 상위 상태 확인을 통과하기 위해 통과해야 하는 상태 확인 수를 지정 가능

  • 사용법 : 모든 상태 확인에 실패하지 않고 웹사이트를 유지 관리를 수행한다

 

개인리소스의 상태 확인 (Private Hosted Zones)

  • 개인 리소스를 모니터링하는 것

  • 모든 Route 53 상태 확인이 공용 웹에 있기 때문에 이들은 VPC 의 외부에 있다

  • 개인 엔드포인트에 접근 불가 (개인 VPC 나 온프레미스 리소스인 경우)

  • CloudWatch 지표를 만들어 CloudWatch 알림을 할당하는 식으로 알림 자체를 확인하는 상태 확인을 생성할 수 있다

     -  CloudWatch 경보를 상태확인에 할당 가능

     -  CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터링 하는 것

 

 

 

🚨 도메인 등록 기관 (Domain Registar) vs DNS 서비스

✤ 일반적으로 연간 요금을 지불하여 도메인 등록 기관에 도메인 이름을 구입하거나 등록한다

✤ 도메인 등록 기관을 통해 도메인 이름을 구매하면 일반적으로 DNS 레코드를 관리하기 위한 DNS 서비스를 제공

✤ 그러나 다른 DNS 서비스를 사용하여 DNS 레코드 관리 가능

✤ (DNS 레코드로 AWS Route 53 등을 사용하지 않고 Amazon 등록기관을 사용하거나 반대로 GoDobby 로 도메인 등록해도 된다)

 

 

 

🚨 Amazon Route 53 을 사용하는 타사 등록 기관 (3rd Party Registrar with Amazon Route 53)

✤ 도메인을 타사 등록 대행사에서 구매해도, DNS 서비스 제공자로 Route 53 을 계속 사용 할 수 있다

✤ Route 53 에서 공동 호스팅 영역 생성

✤ 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 사용할 수 있다

✤ 도메인 등록 기관 != DNS 서비스

✤ 도메인 등록 기관과 DNS 서비스는 같지 않지만, 그러나 모든 도메인 이름 등록 기관이 일부 DNS 기능을 제공한다