8. Route 53

 

 

DNS (Domain Name System)

 

 

개념

도메인 이름을 서버 IP 주소로 변환하는 시스템 : 브라우저에서 www.google.com 입력 시 IP를 찾아 웹 서버에 연결 : 인터넷의 중추 역할

 

구조

계층적 이름 구조 존재 : 최상위 도메인(TLD) = .com, .org, .gov 등 : 2단계 도메인 = example.com, google.com : 서브도메인 = www.example.com, api.example.com : 전체 도메인 이름 = FQDN(Fully Qualified Domain Name) → 끝에 . 루트 포함

 

용어

Registrar(도메인 등록 기관) = Route 53, GoDaddy 등 : DNS 레코드 = A, AAAA, CNAME, NS 등 다양한 타입 존재 : Zone File = 모든 레코드를 담은 파일 : Name Server = DNS 쿼리를 해결하는 서버

 

동작 과정

사용자가 브라우저에 example.com 입력 → 로컬 DNS 서버가 쿼리 확인 : 로컬 DNS가 모르면 루트 DNS 서버에 요청 → 루트 서버가 “.com 네임 서버로 가라”고 응답 : .com 네임 서버가 “example.com 네임 서버는 5.6.7.8”이라 응답 : 로컬 DNS가 example.com 네임 서버에 요청 → 최종적으로 A 레코드(IP=9.10.11.12) 반환 : 브라우저가 IP를 이용해 웹 서버 연결

 

특징

로컬 DNS는 결과를 캐싱 → 동일 요청 시 더 빠르게 응답 가능 : URL 입력 시마다 이 과정이 자동으로 수행됨

 

핵심 요약 : DNS = 도메인 → IP 변환 시스템 : 루트 → TLD → 도메인 네임 서버 → 최종 IP 응답 : 인터넷 접속 과정에서 항상 사용됨

 

 

---

 

 

Amazon Route 53

 

 

개념

AWS가 제공하는 완전 관리형 권한 있는 DNS 서비스 : 고가용성·확장성 제공 : 권한 있다는 의미 = 고객이 직접 DNS 레코드를 업데이트하고 제어 가능 : 100% SLA 가용성 제공하는 유일한 AWS 서비스 : 이름의 53은 DNS 전통 포트 번호에서 유래

 

동작 방식

클라이언트가 example.com 요청 → Route 53이 IP(예: 54.22.33.44) 찾아서 반환 → 클라이언트는 바로 EC2 인스턴스에 직접 연결 가능 : 도메인 등록도 가능 (예: example.com) : DNS 레코드와 라우팅 정책, TTL(Time to Live)을 통해 동작 정의

 

DNS 레코드 종류 (시험 필수)

• A : 호스트 이름을 IPv4 주소 매핑 : www.example.com → 192.0.2.1
• AAAA : 호스트 이름을 IPv6 주소 매핑 : www.example.com → 2001:db8::1
• CNAME : 호스트 이름을 다른 호스트 이름과 매핑 (단, Zone Apex : 최상위에는 불가) → www.example.com에는 가능, example.com 자체에는 불가 : www.example.com → example.net
• NS : 호스팅 존의 네임 서버 정보 제공, 쿼리에 응답 : example.com → ns1.exampledns.com, ns2.exampledns.com : "이 도메인을 관리하는 네임서버는 여기" 라는 의미

 

호스팅 존

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

• 퍼블릭 호스팅 존 : 누구든 접근 가능, 인터넷 공개용 (예: www.example.com)
• 프라이빗 호스팅 존 : 특정 VPC 내에서만 접근 가능, 내부 전용 (예: api.example.internal, db.example.internal)
• 비용? : 퍼블릭/프라이빗 호스팅 존 모두 월 0.50달러 부과 : 도메인 등록 비용 최소 연 12달러 이상

핵심 요약 : Route 53 = 권한 있는 관리형 DNS : A, AAAA, CNAME, NS 레코드 필수 암기 : 퍼블릭 존 = 외부 접근용, 프라이빗 존 = VPC 내부 전용

 

---

 

Route 53 도메인 등록 및 레코드 생성

 

 

Route 53 콘솔에서 결제 및 제출(Submit)시 도메인 등록 확정 → 몇 분~몇 시간 소요될 수 있음 : 등록 후 Hosted zones 메뉴에서 도메인 확인 가능 : 기본적으로 2개 레코드 생성됨 (NS, SOA)

• NS : 해당 도메인의 네임 서버 정보 (AWS DNS 사용 지시)
• SOA : Start of Authority, 도메인의 기본 정보 제공
• 비용? : 도메인 등록 연간 최소 12달러 이상 : Hosted zone 유지 비용 월 0.50달러

레코드 설정

A 레코드를 설정하면 도메인 이름을 IPv4 주소로 라우팅하게 되는 것 : 값에 실제로 기관의 인스턴스 주소를 넣으면 인스턴스 서버로 라우팅이되는 것

 

---

 

 

Route 53 - TTL (Time To Live)

 

개념

TTL = DNS 레코드의 캐싱 시간 : 클라이언트가 DNS 쿼리 결과(A/AAAA/CNAME 등)를 일정 시간 동안 보관 : TTL이 만료되기 전까지는 새 DNS 조회 없이 캐시된 IP 사용

작동 방식

클라이언트가 myapp.example.com 요청 → DNS 응답 = A 레코드(IP) + TTL 값 : 예를 들어 TTL=300초라면, 300초 동안 캐시에 저장 : TTL 내 재요청 시 DNS 서버에 재쿼리하지 않고 캐시된 결과 사용 → 불필요한 DNS 요청 감소

극단적 설정 사례

• TTL을 길게(예: 24시간) → Route 53 트래픽 감소(클라이언트 요청 감소), 비용 절감 : 단점 = 레코드 변경 반영 지연(최대 24시간 대기 필요) : 즉, 레코드가 변경됐을 경우 클라이언트가 변경 전의 오래된 레코드를 받게되는 불상사 일어날 수 있음
• TTL을 짧게(예: 60초) → 변경 반영 빠름, 유연한 레코드 교체 가능 : 단점 = DNS 트래픽 증가, 비용 상승

전략

평소에는 긴 TTL 설정 → 트래픽 최소화 : 레코드 변경 전에는 TTL을 짧게 줄여 반영 속도 개선 : 변경 후 TTL을 다시 늘려 안정화

핵심 요약 : TTL = 캐시 만료 시간 : 길게 = 트래픽 적고 변경 느림 : 짧게 = 변경 빠르고 비용 증가 : 상황에 맞게 조정하는 것이 중요

 

---

 

Route 53 - CNAME vs Alias

CNAME 레코드

• 개념 : 도메인 이름 → 다른 도메인 이름으로 매핑 : 예) app.mydomain.com → blabla.anything.com : 루트 도메인(apex)에는 사용 불가 (mydomain.com 불가, http://www.mydomain.com은 가능)
• 특징 : 전통적인 DNS 표준 방식 : AWS 리소스가 아닌 외부 도메인에도 매핑 가능 : 사용 시 TTL 직접 설정 필요 : apex에선 제한 → 실습에서 자주 막히는 부분
• 사용 사례 : http://www.example.com을 ALB 도메인 이름에 연결 : 도메인 하위 이름을 다른 호스트로 리디렉션
  
  

별칭(Alias) 레코드

• 개념 : Route 53 전용 기능 : 도메인 이름을 AWS 리소스로 매핑 (ALB, NLB, CloudFront, API Gateway, Elastic Beanstalk, S3 웹사이트, VPC 엔드포인트, Global Accelerator 등) : apex와 서브도메인 모두 지원 (example.com 바로 매핑 가능)
• 특징 : TTL 직접 설정 불가 → Route 53이 자동 관리 : DNS 쿼리 무료 : 상태 확인(health check) 자동 지원 : IP 변경 시 자동 반영 → 관리 편리 : 타입은 A(IPv4) / AAAA(IPv6)만 사용 가능
• 제약 : EC2 인스턴스의 DNS 이름에는 별칭 불가 → 시험 포인트
• 사용 사례 : example.com을 ALB에 바로 연결 : myalias.mydomain.com을 CloudFront 배포로 연결

비교 요약
CNAME : 표준 DNS 기능 : apex 불가 : 외부 도메인 매핑 가능
Alias : Route 53 전용 기능 : apex 가능 : AWS 리소스 전용, 무료, 상태 확인 제공

포인트 : apex에서 도메인 연결 시 = CNAME 불가, Alias 사용해야 함 : EC2 DNS 이름 = Alias 대상 불가

 

---

 

 

Route 53 라우팅 정책 – 단순(Simple)

 

개념

기본적으로 DNS 쿼리에 대해 하나의(단일) 리소스를 반환하는 가장 기본 정책 : foo.example.com 요청 시 Route 53이 지정된 IP(A 레코드)를 응답 : 즉, 별칭(Alias) 레코드 사용시에도 하나의 AWS 리소스만 지정 가능하겠지

특징

상태 확인(Health Check) 불가 → 단순히 DNS 응답만 수행 : 동일한 레코드에 여러 IP 값 지정 가능 → 클라이언트가 무작위로 선택하여 접속 : TTL에 따라 캐싱 후 일정 시간 뒤 새 레코드 반영

동작 예시

simple.example.com을 생성해 A 레코드 값으로 ap-southeast-1 인스턴스 IP 등록 → TTL 20초 설정 → 브라우저 접속 시 Hello World 출력 → 동일 레코드에 us-east-1 IP 추가 시, TTL 만료 후 dig 실행하면 다중 IP 응답 → 클라이언트가 랜덤으로 선택해 접속

포인트 : 단순(Simple) 정책 = 단일 리소스 매핑 : 여러 값 지정 시 클라이언트 무작위 선택 : 상태 확인 지원 X

 

---

 

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

 

개념

여러 리소스에 가중치 값을 부여하여 비율대로 트래픽을 분배하는 정책 : 즉, 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능하게 됨 : 각 레코드는 동일한 이름과 유형을 가져야 함 : 가중치 합이 꼭 100일 필요는 없음 (비율만 중요)

특징

70, 20, 10 → 각각 70%, 20%, 10% 트래픽 분배 : 상태 확인(Health Check)과 연계 가능 : 가중치 0 = 특정 리소스로 트래픽 중단 : 모든 가중치가 0이면 → 모든 레코드 동일 가중치 취급

사용 사례

다중 리전에 걸쳐 트래픽 분배 : 새 애플리케이션 버전에 일부 트래픽만 전송 : 예를 들면 가중치 5%, 10% 등의 트래픽만 해당 환경에 다이렉트 하고 싶을 때 : 점진적 트래픽 이전 시 활용 

포인트 : Weighted Routing = 트래픽 분배 제어용 정책 : 동일 이름·유형의 레코드 필요 : 가중치 0 → 특정 리소스 제외 가능 : 상태 확인과 결합해 더욱 유용

 

---

 

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

 

개념

사용자의 지연 시간이 가장 짧은 리전으로 트래픽을 보내는 정책 : 지연 시간 = 사용자가 특정 리전의 리소스에 연결하기까지 걸리는 시간 : 지연 시간에 민감한 애플리케이션·웹사이트에 적합

특징

사용자의 위치에 따라 Route 53이 가장 빠른 리전을 선택 : 레코드 생성 시 반드시 리전을 지정해야 함 (IP만으로는 위치 알 수 없음) : 상태 확인(Health Check)과 연계 가능 : 항상 하나의 값만 반환 (클라이언트는 가장 짧은 지연 시간 리전으로 연결됨)

사용 사례

글로벌 서비스 운영 시 유저를 가장 가까운 리전으로 자동 연결 : 지연 시간에 민감한 금융, 게임, 미디어 스트리밍 서비스 최적화 : VPN이나 지역별 접속 테스트 시 효과 확인 가능 : 예를 들면, 두 리전에 호스팅된 애플리케이션이 있는데, 사용자에게 '응답 시간을 최소화'시켜주는게 목표면 이때 사용

포인트 : Latency-based Routing = 지연 시간 최소화 목적 : 레코드 생성 시 리전 반드시 지정 : 하나의 DNS 쿼리 결과만 반환

 

---

 

Route 53 상태 확인 (Health Check)

 

 

개념

Route 53이 리소스 상태를 모니터링하는 기능 : 주로 퍼블릭 리소스(ALB, 웹서버 등)에 사용 : 프라이빗 리소스는 CloudWatch 알람과 연동해 모니터링

 

세 가지 상태 확인이 가능

• 엔드포인트 상태 확인 → ALB, 서버, 애플리케이션 등 공용 엔드포인트 직접 체크
• 계산된 상태 확인(다른 상태 확인) → 여러 하위 상태 확인을 AND/OR/NOT 조건으로 조합
• CloudWatch 알람 기반 확인 → 프라이빗 리소스(VPC 내부, 온프레미스) 모니터링 가능

엔드포인트 상태 확인 - 작동 방식

ALB에 대한 eu-wers-1의 상태 확인을 한다고 하면 : 여러 AWS 리전(전 세계 체크포인트)에서 동시에 요청을 보내 상태 확인을 할 것 : 즉, Route 53의 상태 확인 IP 주소 범위는 모든 요청을 허용해야함

• 전 세계 약 15개 위치에서 요청 전송 → 2xx/3xx 코드(200 OK 코드 등) 응답 시 정상으로 간주
• 기본 주기 30초, 빠른 체크 시 10초(비용↑)
• HTTP, HTTPS, TCP 지원
• 텍스트 기반 응답? → 응답 5120바이트 내 특정 문자열 확인
• 전체 응답 중 18% 이상이 정상? → Route 53도 정상으로 판단 : 아니면 비정상으로 인식하는 것

구성 예시

• 다중 리전에 배포된 ALB → 각 리전에 상태 확인 생성 → DNS 레코드와 연결
• 한 리전 장애 발생 시 Route 53이 자동으로 트래픽을 정상 리전으로 전환

계산된 상태 확인 - 작동 방식

• EC2 인스턴스 세 개 각각 상태 확인 생성 → 상위 상태 확인에서 “3개 모두 정상(AND)” 또는 “하나라도 정상(OR)” 조건 정의 가능
• 최대 256개 하위 상태 확인 조합 가능

프라이빗 리소스 상태 확인 - 작동 방식

• Route 53의 상태 확인이 공용 웹에 있음 : 즉, 퍼블릭에서 접근 불가 → CloudWatch 메트릭과 알람을 활용해야함
• CloudWatch 알람이 ALARM 상태? → 이 말은 즉슨 Route 53 상태 확인 비정상으로 전환

시험 포인트

• 퍼블릭 엔드포인트 = 직접 상태 확인
• 프라이빗 리소스 = CloudWatch 알람 연동
• 빠른 체크 = 10초 간격 (비용↑)
• 상태 확인 통과 기준 = 전 세계 다수 위치 중 18% 이상 정상

---

 

Route 53 라우팅 정책 - 장애 조치(Failover Routing)

 

개념

Primary(기본) 리소스와 Secondary(보조) 리소스를 설정해 장애 발생 시 자동으로 보조 리소스로 전환하는 정책 : 고가용성(HA)과 재해 복구(DR)를 위한 Route 53 라우팅 방식

특징

Primary 레코드와 반드시 상태 확인(Health Check)을 연결해야 함 : Primary 정상 시 → 해당 리소스 IP 반환 : Primary 비정상 시 → Secondary 리소스 IP 반환 : Secondary는 상태 확인 연결 선택 가능 : TTL이 짧을수록 전환이 빨라짐 (실습에서는 60초 사용)

사용 사례

재해 복구(Disaster Recovery) 구성 : 한 리전 장애 시 다른 리전으로 자동 연결 : 미션 크리티컬 애플리케이션 고가용성 확보

포인트 : Failover Routing = Primary/Secondary 구조 필수 : Primary는 반드시 상태 확인 필요 : Secondary는 선택적 : DNS 응답은 항상 “정상으로 판정된 리소스” IP만 반환

 

---

 

Route 53 라우팅 정책 - 지리적 위치

 

개념

사용자의 실제 위치(대륙·국가·미국 주 단위)를 기반으로 특정 리소스로 트래픽을 보내는 정책 : 사용자의 가장 정확한 위치가 선택되어 그 IP로 라우팅 되는 것 : 지연 시간 기반 라우팅과 달리 물리적 위치 기준으로 동작 : 지정된 위치가 없으면 기본(Default) 레코드로 연결됨

특징

국가·대륙·주 단위 지정 가능 : 기본 레코드 필수 (일치하지 않는 요청 처리) : 상태 확인(Health Check) 연계 가능 : 동일 이름·타입의 레코드들로 구성됨

사용 사례

지역별 현지화된 콘텐츠 제공 (예: 독일어 버전 vs 프랑스어 버전 앱) : 특정 국가에 맞춘 웹사이트 경험 제공 : 규제·정책에 따른 콘텐츠 분산 제한 : 즉, 특정 국가의 사람들만 웹사이트로 엑세스하게 등 : 글로벌 서비스에서 국가별 트래픽 제어

포인트 : Geolocation Routing = 사용자 “위치” 기반 정책 : 지정 위치 없을 경우 Default 레코드 필요 : 상태 확인 연계 가능 : Latency-based Routing과 혼동 주의 (지리 위치 ≠ 지연 시간)

 

---

 

Route 53 라우팅 정책 - 지리적 접근성

 

 

개념

사용자와 리소스의 지리적 위치를 기반으로 트래픽을 라우팅하는 정책 : 편향(Bias)값을 활용해 특정 리소스로 더 많은 트래픽을 유도 가능 : AWS 리소스(리전) or 온프레미스 리소스(위도·경도 지정) 모두 지원

 

특징

기본적으로 사용자는 가장 가까운 리전에 연결됨 : 편향값 +로 설정 → 특정 리전에 더 많은 트래픽 유입 : 편향값 -로 설정 → 특정 리전에 덜 가도록 제어 : AWS Route 53 트래픽 플로우(고급 기능)에서 설정 가능

 

실습/도식 예시

us-west-1과 us-east-1에 리소스 존재 : 편향 0,0 → 편향이 없기에 미국을 절반으로 나누어 각각 가장 가까운 리전에 연결됨 : 하지만 동일한 설정에서 us-east-1 편향 +50? → 분할선이 왼쪽으로 이동(=오른쪽이 넓어짐), 더 많은 사용자가 us-east-1로 라우팅 : 편향값 조정으로 트래픽 분배 비율 제어 가능

 

왜 이렇게 할까? : 예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 : 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 되는 것

 

사용 사례

특정 리전에 더 많은 사용자 유입 유도 (마케팅·서비스 최적화) : 온프레미스와 AWS 간 트래픽 제어 : 리전 간 트래픽 불균형 조정 (예: 동부 리전에 더 많은 리소스 투입 시)

 

포인트 : Geoproximity Routing = 지리적 거리 + 편향값 기반 정책 : Bias 값 증가 → 특정 리전에 더 많은 트래픽 : Bias 값 감소 → 특정 리전에 적은 트래픽 : 지리 위치(Geolocation)와 구분 (Geolocation은 국가·대륙 지정, Geoproximity는 거리+Bias 기반)

 

---

 

Route 53 라우팅 정책 - IP 기반

 

 

개념

클라이언트의 IP 주소 범위를 기반으로 트래픽을 라우팅하는 정책 : Route 53에서 CIDR 블록을 정의하고, 각 블록별로 다른 리소스로 트래픽을 전달 : 네트워크 비용 절감 및 성능 최적화 가능

 

특징

클라이언트의 실제 IP 기반 → 특정 ISP나 네트워크 구간에 맞춤 라우팅 가능 : 각 CIDR 블록을 특정 엔드포인트(EC2·ALB 등)와 연결 : DNS 응답이 사용자의 IP 위치에 따라 달라짐

 

실습 예시

Route 53에 두 CIDR 블록 정의 (예: 203.x.x.x, 200.x.x.x) : 203대역 → EC2 인스턴스 #1 (IP 1,2,3,4)로 응답 : 200대역 → EC2 인스턴스 #2 (IP 5,6,7,8)로 응답 : 사용자 A(IP가 203대역) → EC2 #1로 연결 : 사용자 B(IP가 200대역) → EC2 #2로 연결

 

사용 사례

특정 IP 사용자들을 가까운 엣지 서버로 연결 : 네트워크 비용 절감 (특정 구간 트래픽 최적화) : B2B 환경에서 특정 파트너사 IP를 전용 리소스로 라우팅

 

포인트 : IP-based Routing = 클라이언트 IP 범위를 기반으로 한 맞춤 라우팅 : CIDR 블록별로 트래픽 경로를 분리 가능 : 다른 라우팅 정책(지연 시간·지리 위치 등)과 혼동 주의

 

---

 

Route 53 라우팅 정책 - 다중 값

 

 

개념
트래픽(example.com에 접속하려는 요청)을 다중 리소스(여러 개의 서버 즉, IP 주소)로 라우팅할 때 사용 : Route 53은 여러 개의 리소스(IP)를 반환 : 상태 확인(Health Check)과 연결하면 정상 리소스만 반환됨 : 사용자가 DNS 요청을 보내면 Route 53이 최대 8개의 “정상 서버 IP”를 돌려줌 : ELB와 유사하지만 대체 불가 → 클라이언트 측 로드 밸런싱 방식

 

 

특징
단순 라우팅(Simple Routing)과 비교 : 단순 라우팅은 상태 확인 불가 → 비정상 리소스가 반환될 수 있음 : 다중 값 라우팅은 상태 확인을 지원 → 반환되는 레코드가 정상임을 보장 : TTL 설정 가능 (예: 60초) : 클라이언트가 여러 IP 중 하나를 선택해 트래픽 분산

 

실습 예시
도메인 : example.com → 다중 A 레코드 등록

1. us-east-1 Region : 라우팅 정책 = 다중 값 : 상태 확인 = us-east-1 : 레코드 ID = US : TTL = 60초
2. ap-southeast-1 Region : 라우팅 정책 = 다중 값 : 상태 확인 = ap-southeast-1 : 레코드 ID = Asia : TTL = 60초
3. eu-central-1 Region : 라우팅 정책 = 다중 값 : 상태 확인 = eu-central-1 : 레코드 ID = EU : TTL = 60초

CloudShell 테스트

dig 명령어 실행 시 3개의 IP 주소 반환 : 모든 상태 확인이 정상 → 3개 모두 응답됨 : eu-central-1을 비정상으로 변경 후 테스트 → 2개의 정상 IP만 반환됨 : 다시 정상으로 반전하면 원래대로 3개 응답

 

포인트 : 다중 값 라우팅 = 최대 8개의 정상 레코드 반환 : 반드시 상태 확인(Health Check)과 결합해야 “정상 리소스만” 반환 : ELB와 유사하지만 클라이언트 단 로드 밸런싱 → ELB 대체 불가 : 단순 라우팅과 달리 상태 확인을 지원

 

 

---

 

 

타사 도메인 및 Route 53

 

 

개념

도메인 이름 레지스트라 : 원하는 도메인을 구매하는 곳 : 매년 비용 지불 필요 : Amazon Route 53 콘솔에서 Amazon 레지스트라 사용 가능 : GoDaddy, Google Domains 같은 타사 레지스트라도 가능 : DNS 서비스? : 도메인을 등록하면 보통 레지스트라가 DNS 관리 서비스도 제공 : 하지만 원한다면 다른 DNS 서비스(Route 53 등)를 사용할 수 있음

 

조합 가능
예1) GoDaddy에서 도메인 구매 + Amazon Route 53에서 DNS 레코드 관리 : 완벽히 허용되는 조합
예2) Amazon에서 도메인 구매 + GoDaddy DNS 관리도 가능

 

예1의 경우 : 설정 방법

1. Amazon Route 53에서 원하는 도메인의 공용 호스팅 영역 생성
2. 생성된 호스팅 영역에서 NS(Name Server) 레코드 4개 확인(타사 레지스트라 NS 레코드를 업데이트하기 위함)
3. 도메인을 구매한 타사 레지스트라(예: GoDaddy) 사이트에서 사용자 정의 이름 서버 설정
4. NS 레코드를 Amazon Route 53 이름 서버로 업데이트
   → 이후 도메인에 대한 DNS 관리는 Route 53에서 직접 가능

핵심 요약
도메인 이름 레지스트라 = 도메인 구매처 (Amazon, GoDaddy, Google 등)
DNS 서비스 = 도메인 레코드 관리 (Route 53, 타사 DNS 서비스 등)
도메인은 한 곳에서 사고, DNS는 다른 곳에서 관리 가능 : NS 레코드만 올바르게 업데이트하면 됨

 

포인트 : 도메인 구매(레지스트라)와 DNS 관리(서비스)는 구분해야 함 : 타사에서 구매해도 AWS Route 53으로 DNS 관리 가능 : 핵심은 NS(Name Server) 업데이트