이 글은 24년 하반기 AWS Certified Solutions Architect - Associate(이하 AWS SAA-C03) 자격증 취득을 위해서 아래 유데미 강의를 보고, 공부한 내용을 정리하였습니다.
https://www.udemy.com/course/best-aws-certified-solutions-architect-associate
DNS란
DNS(Domain Name System) 호스트 이름을 대상 서버 IP 주소로 번역해줌
DNS에는 계층적 이름과 구조가 있음
.com - example.com - www.example.com - api.example.com
DNS 관련 용어
도메인 레지스트라(Registrar) : 도메인 이름을 등록하는 곳.. AWS Route53, GoDaddy... etc
DNS 레코드 : ex) A, AAAA, CNAME, NS ...
존 파일(Zone file) : 모든 DNS 레코드를 포함함, 호스트 이름과 IP 또는 주소를 일치시키는 방법
네임 서버 : DNS 쿼리를 실제로 해결하는 서버
최상위 도메인(TLD) : .com, .us, .gov, .org ...
2단계 도메인(SLD) : example.com, google.com ...
ex) http://api.www.example.com.
. : Root
.com : TLD
.example : SLD
.www : 서브 도메인
api.www.example.com : 도메인 이름
http : 프로토콜
전체 : FQDN, 전체 주소 도메인 이름
DNS 동작 방식
사용자(브라우저)가 example.com에 접속하려고 함
-> local DNS Server에 질의
-> 로컬에서 모르면 ICANN에 의해 관리되는 루트 DNS 서버에 질의
-> Root DNS 서버도 example.com은 모르지만 .com은 안다고 답변. (*.com은 네임서버(NS) 레코드로 공인 IP로 가보라고 알려줌)
-> 로컬 DNS 서버는 다시 IANA에 의해 관리되는 TLD DNS 서버에 질의
-> TLD DNS 서버도 example.com이 무엇인지는 모르지만 example.com 서버는 알고있음(NS레코드 답변)
-> 로컬 DNS 서버는 도메인 레지스트라에 의해 관리되는 SLD DNS 서버에 질의
-> SLD DNS 서버는 example.com이 뭔지 알기 때문에 A레코드로 해당 서버의 공용 IP를 답변
-> 로컬 DNS 서버는 Cache 해두고, 브라우저에 답변을 해줌
-> 브라우저는 이 IP 주소를 이용해 웹 서버에 접속 성공
Route53
- 고가용성, 확장성을 갖춘 완전히 관리되며 권한있는 DNS
* 권한있다 == DNS 레코드를 우리가 직접 업데이트 할 수 있음
- Route53 역시 '도메인 레지스트라'로 도메인을 등록해서 쓸 수 있음
- Route53의 리소스 관련 상태 확인이 가능함
- 100% SLA 가용성을 제공하는 유일한 AWS 서비스
레코드
- 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의함
- 각 레코드는 도메인/서브도메인 이름과 같은 정보 포함
- 레코드 타입 ex) (필수) A, AAAA, CNAME, NS / (고급) CAA, DS, MX, NAPTR, PTR, SOA, TXT, SPF, SRV
- 레코드 값 ex) 123.345.456.567
- 라우팅 정책 : Route53이 쿼리에 응답하는 방식
- TTL : 레코드가 캐싱되는 시간
`레코드 타입
- A : 호스트네임과 IPv4를 맵핑
- AAAA - 호스트네임과 IPv6 맵핑
- CNAME - 호스트네임을 다른 호스트네임과 맵핑
- 대상 호스트네임은 A나 AAAA 레코드가 될 수 있음
- Route53에서 DNS 네임스페이스 (또는 Zone Apex)의 상위 노드에 대한 CNAME을 생성할 수 없음
ex) example.com에 CNAME은 만들 수 없지만, www.example.com에 대한 CNAME레코드는 가능
- NS 호스트 존의 네임서버로, 서버의 DNS 이름 또는 IP 주소로 호스트 존에 대한 DNS 쿼리에 응답 가능
- 트래픽이 도메인으로 라우팅되는 방식을 제어함
호스트 존(Hosted Zones)
레코드의 컨테이너로 도메인/서브도메인으로 가는 트래픽의 라우팅 방식을 정의함
종류
퍼블릭 호스팅 존 : 퍼블릭 도메인 이름을 살 때마다 퍼블릭 호스팅 존을 만들 수 있음
프라이빗 호스팅 존 : 공개되지 않는 도메인명을 지원함.. VPC만이 URL을 리졸브 할 수 있음
어떤 호스트 존이든 0.5$/m 를 지불해야 함
TTL(Time To Live)
클라이언트가 Route53에 DNS request를 날렸을 때, 레코드타입, IP주소와 함께 TTL을 알려줌.
TTL은 클라이언트에게 이 결과를 N 초만큼 캐싱하라고 알려주는 것.
TTL이 높으면 : Route53에 트래픽이 적어질 것, 하지만 클라이언트가 오래된 레코드를 받을 수 있음
TTL이 낮으면 : Route53에 들어오는 트래픽이 많아지고, 비용으로 연결됨, 레코드 변경이 빨라짐
TTL전략
레코드 변경 전 TTL을 낮게 설정해 클라이언트가 변경된 레코드를 빠르게 캐시에 반영하도록 한 뒤, 레코드를 바꿔서 모든 클라이언트가 레코드가 업데이트 된 걸 확인하고, TTL을 높게 설정해서 트래픽을 줄이는 전략
* TTL은 필수적이나 별칭 레코드에서는 제외됨
`CNAME vs Alias(별칭)
로드밸런서나 클라우드프론트를 사용하면 AWS 호스트네임이 노출됨.. 보유한 도메인에 호스트 이름을 매핑하고자할 때 두가지 옵션이 있음
1. CNAME : 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있음
- 루트 도메인이 아닌 경우에만 가능해서 mydomain.com 앞에 뭔가를 붙여야함
** Apex 도메인을 CNAME 레코드에 쓰지못하는 이유 : https://www.zodaland.com/tip/73
2. Alias : Route53에만 가능, 호스트이름이 특정 AWS 리소스로 향하게 할 수 있음
- 별칭은 루트/비루트 모두 동작함
- 무료이고, 자체적으로 상태 확인이 가능
- A, AAAA 레코드 타입을 쓰면되고, 콘솔에서 Route 대상에 Alias 체크해주면 됨
Alias Record
대상 : ELB / CloudFront / API Gateway / Elastic Beanstalk / S3 Websites / VPC Interface Endpoint / Global Accelerator / 동일 호스트 존의 Route53
`* EC2의 DNS이름에 대해서는 별칭 레코드 설정 불가
상태확인
Route53의 상태확인은 공용(public) 리소스에 대한 상태를 확인하는 방법
DNS의 장애 조치를 자동화하기 위한 작업으로 DNS에 연결된 대상(ALB 등..)의 상태확인을 함
종류
1. public 엔드 포인트를 모니터링.. 서버, 애플리케이션
- 전 세계에서 온 15개의 상태 확인이 엔드 포인트의 상태를 확인하고 반환함, 비용에 따라 인터벌도 조정가능
- HTTP/HTTPS/TCP 프로토콜을 지원
- 18% 이상 정상이라고 판단하면 Route53도 정상이라고 판단함
- 상태 확인에 사용될 위치도 선택 가능
- 2xx, 3xx를 응답으로 받아야 통과
- 텍스트 기반일 경우 상태확인은 처음 5,120바이트를 확인함
- 상태 확인(Health Checker)가 엔드포인트에 접근가능해야함(public)
2. 계산된 상태 확인
- 여러개의 상태확인을 하나로 합쳐 줌
- OR AND NOT으로 하위 상태 확인을 256개까지 합칠 수 있고, 상위 상태확인이 통과하기 위한 몇 개의 상태확인이 통과해야하는지 정할 수 있음
- 사례 : 상태확인이 실패하는 일 없이, 상위 상태 확인이 웹사이트를 관리 유지하도록 하는 경우
3. CloudWatch의 모니터링
- 개인 리소스를 모니터링 하려면? CloudWatch 메트릭(지표)/경보를 할당하는 식으로 해결
- CloudWatch 경보를 개인 서브넷 안에 있는 EC2에 걸고, CloudWatch를 상태확인 하는 방식
라우팅정책
라우팅정책은 Route53이 DNS 쿼리에 응답하는걸 도움
Route53이 지원하는 라우팅 정책
- 단순 / 가중치 기반 / 장애 조치 지연 시간 기반 / 지리적 / 다중 값 응답 / 지리 근접 정책
1. 단순 라우팅 정책
- 일반적으로 트래픽을 단일 리소스로 보내는 방식
- 동일 레코드에 여러개 값 저장 가능.. 여러 값 받으면 클라이언트에서 무작위 하나를 고름
- 별칭 레코드는 하나의 AWS 리소스만 대상으로 지정
- 상태확인 X
2. 가중치 정책
- 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보낼 수 있음(합이 100일 필요는 없음)
- DNS 레코드는 동일 이름과 유형을 가져야함
- 상태 확인 가능
- 서로 다른 지역에 로드 밸런싱
- 하나가 0이면 그쪽으로는 트래픽을 보내지 않지만, 다 0이면 동일 가중치로 받음
3. 지연 시간 기반
- 지연시간이 가장 짧은, 가장 가까운 리소스로 리다이렉팅
- 지연시간에 민감한 애플리케이션일 때 유용함
- 유저가 가까운 AWS 리전에 연결하기까지 걸리는 시간으로 측정
- 상태 확인 가능
4. 장애 조치 기반 (액티브-패시브)
- 필수적으로 Primary EC2의 상태확인과 레코드를 연결함, 상태확인이 비정상이면 Secondary로 넘겨줌
- 기본과 보조가 각각 하나씩만 있을 수 있음
5. 지리적 위치 기반
- 사용자의 실제 위치를 기반으로 함
- Default 레코드를 무조건 만들어야함(매칭되는 로케이션이 없을 경우를 대비)
- 사례 : 콘텐츠 분산을 제한, 로드밸런싱, 웹사이트 현지화
- 상태 확인과 연결 가능
6. 지리 근접 라우팅
- 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅함
- 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동
- 특정 리소스에 더 많은 트래픽을 보내려면, 편향값을 증가시켜 확장할 수 있음
- AWS 리소스면 AWS 리전으로 특정, 온프레미스 데이터 센터라면 위도 경도를 지정해야함
- 편향 활용을 위해 고급 Route53 트래픽 플로우를 사용해야함
`- 지리 근접 라우팅은 편향을 증가시켜, 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용함
7. IP 기반 라우팅
- Route53에서 CIDR 목록을 정의함(클라이언트의 IP 범위)
- CIDR에 따라 트래픽을 보낼 로케이션을 정함
- 장점 : IP를 미리 알고 있어 성능을 최적화할 수 있음, IP가 어디서 오는지 알기에 네트워크 비용을 줄일 수 있음
8. 다중 값
- 트래픽을 다중 리소스로 라우팅할 때 사용.. Route53은 다중 값과 리소스를 반환함
- 상태확인과 연결하면, 정상 리소스에서만 값들을 받아오게됨
- 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됨
- ELB와 유사하지만 ELB를 대체할 수는 없다... 이건 클라이언트 측면의 로드밸런싱인 것
도메인 레지스트라 VS DNS Service
- 도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구입할 수 있음
- 타사에서 도메인을 구입하고, Route53으로 DNS records를 관리할 수도 있음
- AWS Route53에서 호스팅존을 만들고, 네임서버를 타사 옵션에서 변경해주면 관리가능
