AWS Route 53

Siyun·2025년 2월 18일

AWS

목록 보기

10/37

DNS(Domain Name System)

URL과 호스트 이름을 IP로 변환해줌
도메인 이름은 계층적 구조로 되어 있음.
Domain Registrar는 도메인 이름을 등록하는 곳. 3차 도메인을 관리함. (아마존 Route53, GoDaddy 등)

도메인 이름 계층

계층(Level)	예시	설명
루트 도메인	`.` (점)	도메인 계층의 최상위. 일반적으로 표시되지 않음.
최상위 도메인 (TLD)	`.com`, `.org`, `.net`, `.kr`	국가 코드(ccTLD) 또는 일반(gTLD) 도메인.
2차 도메인	`example.com`	기업, 기관, 개인이 소유하는 주요 도메인.
3차 도메인 (서브도메인)	`blog.example.com`	특정 서비스 또는 하위 사이트를 위한 서브도메인.
호스트명	`www.blog.example.com`	개별 서버나 서비스를 나타내는 이름.

FQDN(전체 주소 도메인 이름) = http://api.www.example.com.

Route 53

고가용성, 확장성을 갖춘, 완전히 관리되며 권한(고객이 DNS레코드를 업데이트할 수 있음)있는 DNS이다.
Domain Registrar로 도메인 이름을 등록할 수 있다.
100% SLA 가용성을 제공하는 유일한 AWS 서비스
53인 이유는 전통적인 DNS포트임.
Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의한다.
각 레코드가 포함하는 것
1) 도메인이나 서브도메인 이름과 같은 정보 (ex. example.com)
2) 레코드 타입(ex. A, AAAA)
3) 값 (ex. 123.456.789.123)
4) 라우팅 정책 : Route 53이 쿼리에 응답하는 방식
5) TTL(Time to live) : DNS resolver에서 레코드가 캐싱 되는 시간

레코드 타입	설명	예시
⭐A (Address)	도메인을 IPv4 주소로 매핑	`example.com → 192.168.1.1`
⭐AAAA (IPv6 Address)	도메인을 IPv6 주소로 매핑	`example.com → 2001:db8::1`
⭐CNAME (Canonical Name)	도메인을 다른 도메인으로 매핑	`www.example.com → example.com`
MX (Mail Exchange)	이메일 서버 지정	`example.com → mail.example.com`
TXT (Text)	도메인에 대한 텍스트 정보 저장 (SPF, DKIM 등에 사용)	`example.com → "v=spf1 include:_spf.google.com ~all"`
⭐NS (Name Server)	도메인의 네임서버 지정	`example.com → ns1.example.com, ns2.example.com`
PTR (Pointer)	IP 주소를 도메인으로 변환 (역방향 조회)	`192.168.1.1 → example.com`
SRV (Service)	특정 서비스에 대한 위치 정보 제공	`_sip._tcp.example.com → sipserver.example.com:5060`
SOA (Start of Authority)	도메인의 기본 정보 및 관리자 정보	`Primary NS: ns1.example.com`

Hosted Zone

레코드의 컨테이너
도메인과 서브도메인으로 가는 트래픽과 라우팅 방식을 정의함
퍼블릭, 프라이빗 호스팅 존으로 나뉨
ex. mypbdomain.com이 퍼블릭 도메인이라면 퍼블릭 호스팅존을 만들 수 있다. 퍼블릭 존은 누구든지 쿼리요청을 하면 도메인 이름 app1.mypbdomain.com의 ip가 무엇인지 알 수 있다.
프라이빗 호스팅 존은 공개되지 않는 도메인 이름을 지원한다. 가상 프라이빗 클라우드(VPC)만이 URL을 리졸브(IP주소로 변환)할 수 있다.
ex. app1.company.internal과 같이 사내 내트워크에서만 접근할 수 있는 URL
AWS 에서 만드는 어떤 호스팅 존이든 월에 50센트를 지불해야 한다. Route53은 무료가 아니다.

Route53 도메인 등록 실습

1. Route53 > Registered domains > Register domains 선택

2. 사용하고 싶은 도메인 이름을 검색해 선택한다.

해당 도메인이 사용 가능하면 Exact match로 선택할 수 있게 된다. 해당 도메인은 1년에 14달러다. 원하는 도메인 이름을 선택하고 Selected > Proceed to checkout을 눌러준다.

사용할 기간과 자동갱신 여부를 선택하여 Next를 눌러준다.

3. 개인 정보 설정

정보를 설정해주고 개인정보가 인터넷에 공개되지 않도록 하기 위해 Privact protection을 활성화해준다.

4. 약관 확인 후 최종 생성

5. Route53 > Hosted zones에서 생성한 도메인의 레코드 확인

NS레코드와 SOA레코드가 있을 것이다.
NS레코드는 DNS쿼리에 응답하기 위해 AWS DNS를 사용해야 한다는 의미이다.

Route53 레코드 등록 실습

1. Route53 > Hosted zones에서 도메인을 선택하고 Create record 선택

2. 레코드 이름을 입력하고 레코드 타입(A)을 선택한다. 값에는 라우팅하고 싶은 인스턴스 IPv4를 넣어준다. 라우팅 정책은 우선 simple로 한다.

3. 레코드를 생성하고 아래 코드로 도메인-IP연결을 확인한다

예시로 새로 추가된 레코드 명: test.example.com
윈도우 명령어: nslookup test.example.com
맥: dig test.example.com
클라우드 쉘: sudo yum install -y bind-utils 을 입력해 nslookup과 dig명령을 클라우드쉘에 설치한 후 사용
코드를 입력하면 test.example.com이 입력한 IP로 연결되는 것을 확인할 수 있다.
코드로 확인 외에도 인스턴스가 웹서버를 실행중이라면 도메인 URL을 브라우저에서 들어가서 확인할 수도 있다.

Route53 EC2 연결 실습

세개의 리전(ex. 미국, 일본, 한국)에 EC2인스턴스를 생성한다.
하나의 리전(ex. 미국)에서 ALB를 생성해 미국 EC2를 대상그룹에 연결한다.
도메인에서 레코드 A를 추가해 EC2 인스턴스 중 하나의 Public IP를 연결한다.

ALB 도메인 이름 연결하기

도메인에서 레코드 CNAME을 추가해 값으로 ALB의 도메인 이름을 복사해서 연결한다.
도메인에서 레코드 A를 추가해 값으로 Alias버튼에 체크하고 선택지 중 Alias to Application Load Balancer를 선택한다. 리전도 선택하고 로드밸런서를 선택한다.(이 쿼리 처리는 무료)

가중치 기반 라우팅 정책 적용하기

새로운 레코드 A를 추가하고 Weighted 정책을 적용한 뒤 Weight값을 10으로 한다. 레코드 ID를 설정해준다(레코드 ID로 가중치 인스턴스 식별).
Add another record로 레코드 2를 추가해주고 같은 방식으로 가중치를 적용해서 레코드 3까지 만든다.
그러면 같은 도메인의 3개 Wighted레코드가 만들어지고 가중치대로 특정 리소스를 반환한다.

지연 시간 기반 라우팅 정책 적용하기

새로운 레코드 A를 추가하고 Latency를 정책으로 적용한다. 리전은 Value에 작성한 IP주소나 도메인의 리전을 선택한다.
Add another record로 다른 레코드도 추가해주면 끝.
vpn으로 위치를 바꿔 테스트해보면 가까운 위치의 리소스를 반환한다.

장애조치 정책 적용하기

호스팅존에서 레코드를 생성
A레코드를 선택하고 라우팅 정책은 장애조치로 한다. Failover record type에는 기본(Primary)과 보조(Secondary)를 정할 수 있는데 기본을 선택하고 상태확인과 연결한다.
Add another record로 보조 레코드도 추가. 보조 레코드는 상태확인을 연결하지 않아도 됨.

지리적 정책 적용하기

호스팅존에서 레코드를 생성
A레코드를 선택하고 라우팅 정책은 Geolocation으로 한다. Location은 원하는 지역(아시아)을 선택해준다.
Add another record로 새 Geolocation 레코드를 생성하고 이번엔 미국으로 지역을 설정하고 값에 원하는 IP를 입력한다.
Add another record을 하고 Geolocation으로 이번엔 지역을 Default로 하면 아시아와 미국이 아닌 지역은 디폴트 레코드의 값으로 이동한다.
세 레코드의 이름(Record name)은 다 똑같다. Record ID는 다 다르다(레코드 식별자)

다중 값 정책 적용하기

호스팅존에서 레코드를 생성
A레코드를 선택하고 라우팅 정책은 Multivalue answer로 하고 상태확인을 지정한다.
Add another record로 Multivalue answer정책의 레코드를 추가하고 1과 다른 값(IP주소나 DNS)를 입력한다. 상태확인도 해당 리소스의 상태확인을 선택한다.
같은 방식으로 레코드를 추가해서 3개의 레코드네임이 같으면서 값이 다른 다중 값 정책의 레코드를 만들면 각 리소스마다 상태확인을 해서 정상 레코드들을 클라이언트에게 반환하게 된다.
클라우드쉘에서 dig로 해당 도메인으로 테스트하면 한번 쿼리에 세개의 레코드를 반환받는 것을 확인할 수 있다.

Records TTL(Time To Live)

클라이언트가 DNS에 URL로 요청을 보내면 회신내용으로 A레코드와 IP주소, TTL을 받는다.
TTL은 클라이언트에게 결과를 캐시하도록 요청하고 정해진 시간(ex. 300초)동안 클라이언트는 결과를 캐시한다.
클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우 클라이언트는 DNS 시스템에 쿼리를 보내지 않고 캐시에서 확인한다.
캐시에도 시간이 소요되니 캐시 TTL이 발생한다.
TTL이 너무 길면(ex. 24시간) Route 53으로 트래픽은 현저히 적겠지만 클라이언트는 오래된 레코드를 받을 수 있다.
TTL이 너무 짧으면 Route53으로의 트래픽 양이 많아지지만 레코드 변경은 빨라진다. Route53은 요청의 양에 따라 요금이 책정되기 때문에 비용이 많이 든다.
캐시의 시간이 만료되어야만 다시 Route53으로 쿼리하여 레코드값을 묻게된다.

CNAME vs Alias

로드밸런서나 CloudFront등 AWS의 리소스를 사용하는 경우 호스트의 이름이 노출된다.
보유한 도메인에 호스트 이름을 매핑하고자 할 수 있다.
예를들어 myapp.mydomain.com에 로드밸런서를 맵핑하고자 할 때 두가지 옵션이 있다.
1) CNAME레코드 : 호스트 이름이 다른 호스트 이름으로 향하도록 할수 있다. 루트도메인에서는 안되고 mydomain.com 앞에 뭔가 붙여야 한다.
2) 별칭(Alias)레코드 : 호스트 이름이 특정 AWS 리소스로 향하게 할수 있다. 루트(mydomain.com)/비루트 도메인 모두에 작동한다. 무료이다. 자체적으로 상태확인이 가능하다. 이들은 AWS의 리소스에만 매핑이 되어 있다. AWS 리소스를 위한 Alias 레코드의 타입은 항상 A 또는 AAAA이다. 별칭레코드를 사용하면 TTL을 설정할 수 없으며 Route 53에 의해 자동으로 설정된다. 별칭레코드의 대상은 ELB, CloudFront, API Gateway, Elastic Beanstalk, S3 Websites, VPC Interface Endpoints, Global Accelerator 가속기, 동일 호스트존의 Route53이 가능하다. EC2의 DNS이름에 대해서는 별칭레코드를 설정할 수 없다.

Route53의 라우팅 정책

여기서 라우팅은 DNS관점이다. DNS는 트래픽을 라우팅하지 않는다. DNS는 DNS쿼리에 응답만 하고 클라이언트는 이를통해 HTTP쿼리를 어떻게 처리해야할지 알게된다.
Route53이 지원하는 라우팅 정책
1) 단순(Simple) : 트래픽을 단일 리소스로 보내는 방식. 동일한 레코드에 여러 개의 값을 지정 가능. DNS에게서 다중 값을 받은 클라이언트는 그 중 하나를 무작위로 고르게 됨. 상태 확인 불가(별칭 레코드는 가능)
2) 가중치 기반(Weighted) : 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식으로 제어 가능. 예를 들어 EC2인스턴스 세 개를 각 70,20,10의 가중치로 할당하면 Route53에서 DNS 응답의 70%가 첫번째 인스턴스로 리다이렉팅 된다. 가중치 합이 100이 아니어도 된다. 서로 다른 지역들에 걸쳐 로드밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에 사용된다. 가중치를 0으로 만들어 특정 리소스로 트래픽 전송을 중단할 수도 있다. 모든 레코드 가중치가 0인 경우 모든 레코드가 동일한 가중치를 갖게 된다.
3) 지연 시간 기반(Latency based) : 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책. 지연시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 유용하다. 만약 유저가 독일에 있고 미국에 있는 리소스의 지연시간이 가장 짧다면, 해당 유저는 미국 리전으로 리다이렉팅 된다.
4) 장애조치(Failover) : 주EC2인스턴스에는 필수로 상태확인을 연결하고 그 결과 비정상이면 자동으로 보조EC2인스턴스로 장애조치하여 결과를 보내기 시작한다.
5) 지리적 (Geolocation) : 사용자의 실제 위치를 기반으로 한다. 사용자가 어떤 대륙이나 국가 혹은 주에 있는지 지정하는 것이고 가장 정확한 위치가 선택되어 그 IP로 라우팅 된다.
6) 지리 근접(Geoproximity) : 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 함. 리소스마다 편향값(bias)을 지정함. 사용자의 위치에 가까운 리소스로 가되 편향값의 영향을 받아 라우팅이 결정됨. 특정 리소스에 더 많은 트래픽을 보내려면 편향값 증가, 줄이려면 편향값을 음수로 축소. AWS리소스면 속한 특정 리전을 지정하면 자동으로 올바른 라우팅을 계산, 온프레미스 데이터센터 리소스면 위도/경도를 지정해서 AWS가 위치를 파악하도록 해야함. Route53 Traffic Flow(Advanced)를 사용함.
7) IP 기반 (IP-based) : 클라이언트 IP주소를 기반으로 라우팅 정의. CIDR에 따라 트래픽을 어느 로케이션으로 보내야 할 지 정한다. IP를 미리 알고 있으니 성능이 최적화됨. Route53에서 CIDR 컬렉션을 정의해서 CIDR 블럭과 로케이션 쌍을 지정하고 레코드의 IP-based에서 로케이션을 지정하면 클라이언트 IP에 따라 로케이션에 연결된 레코드의 값(리소스 주소)을 반환받는다.

CIDR(Classless Inter-Domain Routing)은 IP 주소를 효율적으로 할당하고 라우팅하기 위한 표기법.
예시: 192.168.1.0/24에서 /24는 서브넷 마스크(255.255.255.0)를 의미하며, 네트워크 부분이 24비트라는 뜻.

8) 다중 값 응답(Multi-Value Answer) : 트래픽을 다중 리소스로 라우팅할 때 사용된다. 상태확인과 연결하면 정상 상태 리소스만 반환된다. 하나의 쿼리에 최대 8개의 정상 레코드가 반환된다. 클라이언트쪽에서 반환된 레코드들 중 하나를 선택해서 리소스로 접근한다.

Route53의 상태 확인(Health Checks)

주로 공용 리소스에 대한 상태를 확인하는 방법이지만 개인 리소스의 상태 확인도 가능
예를들어 지연 시간 기반 라우팅에서 미국의 유저가 DNS쿼리를 보냈는데 미국 리전의 인스턴스가 사용불가능 상태면 유저를 보내지 않아야 한다. 이를 위해 상태확인이 필요함.
레코드에 상태 확인을 활성화하면 DNS의 장애 조치를 자동화 할 수 있다.
CloudWatch 경보의 상태를 모니터링하는 상태 확인도 있다.
AWS의 상태 확인의 간격을 30초 혹은 10초로 선택할 수 있다. 10초가 더 많은 비용이 든다.
상태 확인은 HTTP,HTTPS,TCP 등 많은 프로토콜을 지원한다.
18% 이상의 상태확인(Health Checker)이 엔드 포인트를 정상이라고 판단하면 Route53도 이를 정상이라고 간주한다.
상태 확인은 로드밸런서로부터 2xx나 3xx의 코드를 받아야만 통과된다.
상태 확인이 텍스트 기반 응답일 경우 응답의 처음 5,120바이트를 확인한다.
Health Checker가 애플리케이션의 로드밸런서나 엔드 포인트에 접근이 가능해야 한다. 따라서 상태확인(Health Checker) IP주소 범위에서 들어오는 요청을 허용해야 한다.
https://ip-ranges.amazonaws.com/ip-ranges.json 링크에서 IP주소범위 확인 가능
Calculated Health Checks는 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능을 제공함. 3개 EC2인스턴스를 체크하는 상태 확인이 3개 있으면 그 3개를 바탕으로 상위 상태 확인 하나를 정의할 수 있음. 3개의 상태 확인들을 합치기 위한 조건은 OR, AND, NOT이 있음. 하위 상태 확인을 256개까지 모니터링 할 수 있다. 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있다.
모든 Route53의 상태 확인은 공용 웹, 즉 VPC 외부에 있기 때문에 개인 VPC나 온프레미스 리소스의 개인 엔드포인트에 접근이 불가하다. 그래서 CloudWatch 지표로 알람을 할당하는 식으로 해결 가능하다. 알람이 ALARM상태가 되면 상태 확인은 자동으로 비정상이 되어 장애조치를 하게 된다.

Route53 상태확인 실습

1. Route53 > Health checks > Create health check선택

상태확인 이름이랑 리소스를 설정한다.
리소스에서
1) 엔드포인트를 하면 어떤 인스턴스나 ALB등의 엔드포인트에 상태확인을 한다.
2) Calculated를 선택하면 다른 상태 확인의 상태를 확인한다.(n개중 m개가 정상일 때 보고를 받도록 지정할 수도 있다)
3) CloudWatch alarm을 선택하면 알람이 발생할 리전을 지정해야 한다. 개인 EC2인스턴스의 상태확인을 Route53 상태확인에 연결하는 것이다.

IP는 상태확인 할 인스턴스의 IP를 입력한다. 경로는 /health가 일반적

Advanced configuration을 설정한다.

상태확인 생성을 완료하면 상태확인 결과와 최근 확인시간, Unhealthy 사유 등을 확인할 수 있다.

Domain Registar와 DNS Service

도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있고 매년 비용을 지불해야 한다.
Route53 콘솔을 통한 Amazon레지스트라를 이용하지 않아도 괜찮다.
대게 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공한다.
아마존이 아닌 레지스트라를 통해 도메인을 구매하고 DNS 레코드 관리를 Route53에서 할 수도 있다.

아마존이 아닌 레지스트라의 레코드를 Route53에서 관리 실습

1. 레지스트라에서 도메인을 등록하면 Name servers 옵션이 생겨서 사용자 정의 네임서버를 지정할 수 있다.

2. Amazon Route53에서 원하는 도메인의 Public Hosted zone을 생성한다.

3. 생성된 호스팅 영역 상세의 오른쪽 부분에서 Name servers를 찾는다.

4. Route53의 Name servers 4개를 복사해서 타 레지스트라의 기존 Name servers에 붙여넣어 수정해준다.

그러면 타 레지스트라에서 나의 도메인의 네임서버가 어디냐는 쿼리에 Route53의 네임서버를 응답해주게 된다.

Siyun

공부 기록

이전 포스트

AWS RDS, Aurora, ElastiCache

다음 포스트