AWS Certified Developer Associate 자격증을 준비하면서, 알게 된 내용을 정리했습니다.
DVA-C02 강의 > © 스테판 마렉 Udemy강의
1.DNS란?
- Domain Name System으로 사람에게 익숙한 호스트 이름을 IP주소로 바꿔줌
- www.google.com -> 172.217.18.36
- DNS는 인터넷의 기반이 되는 시스템
- 계층적인 네이밍 구조를 사용
용어
- Domain Registrar : Amazon Route 53 , GoDaddy ...
- DNS Records : A, AAAA, CNAME, NS ...
- Zone File : 모든 dns 레코드를 포함하는 파일
- Top Level Domain(TLD) 최상위 도메인 : .com , .us , .in , .gov , .org ...
- Second level Domain (SLD): amazon.com, google.com
- Sub Domain: www.amazon.com
- Domain Name: api.www.amazon.com
전체는 FQDN(Full Qualified Domain Name)
How DNS Works
도메인 이름을 DNS 서버에 등록 (example.com)
클라이언트 -> 웹서버 example.com 접근
Local DNS Server에 요청 및 확인
(없다면) ICANN에 의해 관리되는 Root DNS Server에 요청 및 확인
Root DNS Server가 example.com은 몰라도 .com은 알고 .com의 서버 이름(NS)의 IP인 1.2.3.4로 가보라고 함 (답에 가까운 것을 알려줌)
Local DNS server는 IANA에 의해 관리되는 TLD DNS Server(.com)에 방문해 다시 example.com 을 물어봄
TLD서버는 정확히 example.com은 모르지만 example.com의 서버 IP 5.6.7.8을 소개해줌
그리고 최종적인 서버인 SLD DNS Server에 물어봄
SLD DNS Server는 Domain Registrar 에 의해 관리되는 서버임
SLD에서 찾은 레코드 9.10.11.12를 로컬 서버에 반환해줌
로컬 서버는 9.10.11.12를 캐시해 저장하고 웹 브라우저에 반환함
2. Route 53 개요
- Route 53은 고가용성이 높고, 확장 가능하며, 완전히 관리되는 권위 (Authoritative) 있는 DNS 서비스.
• Authoritative = 고객이 DNS 레코드를 업데이트할 수 있다는 뜻 - Route 53은 Domain Registrar (도메인 등록대행자)로도 사용됨.
리소스의 상태를 확인할 수 있는 기능을 제공. - AWS에서 100% SLA 가용성을 제공하는 유일한 서비스.
- "53"은 전통적인 DNS 포트.
Records
- 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의.
• Domain / subdomain Name : e.g., example.com
• Record Type : e.g., A / AAAA, CNAME, NS
• Value: e.g., 123.456.123.123
• Routing Policy: Route53이 쿼리에 응답하는 방식
• TTL(Time To Live) : DNS Resolver에서 레코드가 캐싱되는 시간 - Route 53은 다음과 같은 DNS 레코드 유형을 지원함.
• (must know) A / AAAA / CNAME / NS
• (advanced) CAA / DS / MX / NAPTR / PTR / SOA / TXT / SPF / SRV
Record Types
- A : hostname 을 IPv4로 매핑
- AAAA : 호스트이름을 IPv6주소에 매핑
- CNMAE: 호스트 이름을 다른 호스트 이름에 매핑함
• 대상 호스트 이름은 A 혹은 AAAA가 될 수 있음 (마치 포인터처럼)
• DNS namespace(Zone Apex)의 최상위 노드에 CNAME을 만들 수 없다
• 예를 들어 example.com의 CNAME은 안돼도 www.example.com꺼는 만들 수 있다 - NS: 호스트 존에 대한 Name Server (서버의 DNS이름 혹은 IP주소).
• 트래픽이 도메인으로 라우팅 되는 방식을 제어함
Hosted Zones
- 레코드의 컨테이너로 트래픽을 도메인과 서브 도메인으로 연결하는 라우팅 방식을 정의함
- Public Hosted Zone: 인터넷에서 트래픽을 라우팅하는 방법을 지정하는 레코드를 포함. (공개 도메인 이름)
• application1.mypublicdomain.com - Private Hosted Zone: 하나 이상의 VPC 내에서 트래픽을 라우팅하는 방법을 지정하는 레코드를 포함. (비공개 도메인 이름)
• application1.company.internal - 호스팅 영역당 월별 비용은 $0.50
Public vs. Private Hosted Zones
Route 53 – Records TTL (Time To Live)
- High TTL (ex. 24 hr)
• Route 53에서의 트래픽이 적음
• 레코드가 업데이트되지 않은 경우가 발생할 수 있음 - Low TTL (ex. 60 sec)
• Route 53에서의 트래픽이 많음 ($$)
• 레코드가 업데이트되지 않은 기간이 짧음
• 레코드를 쉽게 변경할 수 있음 - 별칭 레코드를 제외한 모든 DNS 레코드에는 TTL이 필수.
CNAME & Alias
-
AWS Resources (Load Balancer, CloudFront, ...) 등이 AWS 호스트 이름으로 노출된다.
• lb1-1234.us-east-2.elb.amazonaws.com 으로 노출되므로 내가 원하는 도메인으로 바꾸고 싶을 때 이용. (myapp.mydomain.com) -
CNAME
• 호스트 이름이 다른 호스트 이름으로 향하도록 하는 것
app.mydomain.com -> blabla.anything.com
• 루트 도메인이 아닐 때 가능함 -
Alias
• 호스트 이름이 특정 AWS 리소스로 향하도록 하는 것
app.mydomain.com -> blabla.amazonaws.com
• 루트 도메인이든 루트가 아니던 동작함
• 무료이고 자체 health check가 가능함
Alias Records
- 호스트 이름을 AWS 리소스에 매핑함
- DNS 기능의 확장
- 리소스 IP 주소 변경을 자동으로 인식함
- CNAME과 달리 DNS 네임 스페이스 (Zone Apex)의 최상위 노드에 사용할 수 있음 ex. example.com
- AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA임 ( (IPv4 / IPv6)
- TTL을 설정할 수 없음 (Route 53에서 자동으로 설정)
Alias Records Targets
- Elastic Load Balancers
- 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 이름에 대해서는 ALIAS 레코드를 설정할 수 없다.
EC2 DNS 이름에 대해서는 ALIAS 레코드를 설정할 수 없다.
Route 53 - Routing 정책
- Route 53이 DNS 쿼리에 응답하는 방식을 정의한다.
- "라우팅"이라는 단어에 혼동하지 말 것.
• 트래픽을 라우팅하는 로드 밸런서의 라우팅과는 다르다.
• DNS는 트래픽을 라우팅하지 않으며, 단지 DNS 쿼리에 응답하는 역할을 한다. - Route 53은 다음과 같은 라우팅 정책을 지원한다.
• Simple (단순)
• Weighted (가중치 기반)
• Latency based (지연 시간)
• Failover (장애 조치)
• Geolocation (지리 위치)
• Geoproximity (지리 근접) - using Route 53 Traffic Flow feature
• IP-based (IP 기반)
• Multi-Value Answer (다중 응답)
Simple 정책
- 일반적으로 트래픽을 단일 리소스로 보내는 것
- 동일한 레코드에서 여러 값을 지정 가능
- 여러 값이 반환되면 클라이언트가 임의로 하나를 선택
- Alias가 활성화된 경우, 하나의 AWS 리소스만 지정
- Can’t be associated with Health Checks
Weighted 정책
- 각 특정 리소스로 전송되는 요청의 %를 제어한다.
- 각 레코드에 상대적인 가중치를 할당한다.
• traffic (%) = Weight for a specific record / Sum of all the weights • for all records
가중치의 합이 100이 될 필요는 없음 - DNS 레코드는 동일한 이름과 유형을 가져야 한다.
- Can be associated with Health Checks
- 사용 사례: 리전 간 로드 밸런싱, 새로운 애플리케이션 버전 테스트 등
- 리스로의 트래픽 전송을 중지하기 위해 레코드에 가중치 0을 할당
- 모든 레코드가 가중치 0을 가진 경우, 모든 레코드가 동일하게 반환
Latency-based정책
- 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리디렉션하는 정책
- 사용자의 지연시간이 우선 순위인 경우 매우 유용한 정책
- 지연 시간은 사용자와 AWS 지역 간의 트래픽을 기반으로 한다.
- 독일 사용자는 미국으로 리디렉션될 수 있다. (가장 낮은 지연 시간인 경우)
- Can be associated with Health Checks (has a failover capability)
Route53 - Health Checks
- HTTP 상태 확인은 공용으로만 사용됩니다
자원 - Health Checks => 자동화된 DNS 페일오버:
- 엔드포인트를 모니터링하는 상태 확인
(애플리케이션, 서버, 기타 AWS 리소스) - 다른 건강 상태를 모니터링하는 건강 확인
검사(계산된 건강 상태 검사) - CloudWatch를 모니터링하는 건강 확인
알람(완전 제어!!) - 예: 스로틀의
DynamoDB, RDS의 알람, 사용자 지정 지표,
… (개인 리소스용 helpful)
- 건강 점검은 CW와 통합됩니다
Health Checks – Monitor an Endpoint
- 전세계로부터 15개 정도의 글로벌 헬스 체커가 엔드포인트 상태를 확인한다.
• Healthy/UnhealthyThreshold - 3 (기본값)
• 간격 - 30초 (10초로 설정 가능 - 높은 비용 발생)
• 지원 프로토콜: HTTP, HTTPS 및 TCP
• 18% 이상이 엔드포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주한다. 그렇지 않으면 비정상으로 인식한다.
• Route 53에서 사용할 위치를 선택할 수 있음 - 상태 확인은 엔드포인트가 2xx 및 3xx 상태 코드로 응답할 때에만 통과
- 응답의 처음 5120바이트 내에서 텍스트를 기준으로 통과/실패 설정할 수 있음
- 상태 확인의 작동이 가능하려면 라우터/방화벽을 구성하여 Route 53 헬스 체커로부터의 수신 요청을 허용하도록 설정
Route 53 – Calculated Health Checks
- 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능
- OR, AND, 또는 NOT을 사용할 수 있음
- 최대 256개의 하위 상태 확인을 모니터링할 수 있음
- 상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있음
- 사용 사례: 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 관리 유지하도록 하는 경우
Health Checks – Private Hosted Zones
- Route 53 상태 확인은 VPC의 외부에 있기 때문에 프라이빗 엔드포인트 (프라이빗 VPC 또는 온프레미스 리소스)에 접근할 수 없다.
- 따라서 CloudWatch 메트릭을 생성하고 CloudWatch 경보를 연결한 다음, 경보를 확인하는 상태 확인을 생성할 수 있다.
Failover 정책 (Active-Passive)
재해 복구용 인스턴스 (Disaster Recovery) 를 두고 메인 인스턴스의 Health Check가 비정상일 때 보조 인스턴스로 돌리는 것
failover정책을 이용하는 Primary, Secondary 2개의 레코드를 만들면 됨
Geolocation 정책
- Different from Latency-based!
- 사용자 실제 위치를 기반으로 라우팅하는 방식
- 특정 대륙이나 국가, 혹은 사용자가 미국에 있는 경우에는 어떤 주에 있는지 지정하는 것. (겹치는 경우 가장 정확한 위치가 선택됨)
- Defalut 레코드를 생성하는 것이 좋음 (일치하는 위치가 없을 경우를 대비)
- 사용 사례: 웹 사이트 지역화, 콘텐츠 분산 제한, 로드 밸런싱 등
- Can be associated with Health Checks
Geoproximity 정책
- 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 라우팅
- 정의된 편향값(bias)에 따라 리소스로의 트래픽을 조절할 수 있음
- 지리적 영역의 크기를 변경하려면 편향값을 지정
• 확장 (1부터 99까지): 리소스로의 트래픽을 더 많이 유도
• 축소 (-1부터 -99까지): 리소스로의 트래픽을 줄임 - 리소스는 다음과 같을 수 있다.
• AWS 리소스 (특정 AWS 리전 지정)
• 비-AWS 리소스 (위도와 경도 지정) - 이 기능을 사용하기 위해서는 Route 53 Traffic Flow를 사용해야 함
IP-based Routing IP 기반 라우팅 정책
- 클라이언트의 IP 주소를 기반으로 라우팅하는 방식
- 클라이언트의 CIDR 목록과 해당 엔드포인트/위치(사용자 IP 대 엔드포인트 매핑)을 제공
- 사용 사례: 성능 최적화, 네트워크 비용 절감
- 예) 특정 ISP의 최종 사용자를 특정 엔드포인트로 라우팅
Multi-Value 다중 응답 라우팅 정책
- 트래픽을 다중 리소스로 라우팅할 때 사용
- Route 53은 다중 값/리소스를 반환
- Can be associated with Health Checks (return only values for healthy resources)
- 각각의 다중 값 쿼리에 대해 최대 8개의 정상 레코드가 반환됨
- Multi-Value is not a substitute for having an ELB
Domain Registar vs. DNS Service
- Domian Registra를 통해 도메인 이름을 구입하거나 등록하며, 이를 위해 연간 요금을 지불한다. (ex. GoDaddy, Amazon Registrar Inc., ...)
- Domain Registra는 DNS 레코드를 관리를 위한 DNS 서비스를 제공한다.
하지만 다른 DNS 서비스를 사용하여 DNS 레코드를 관리할 수 있다. - 예) GoDaddy에서 도메인을 구입하고 Route 53을 사용하여 DNS 레코드를 관리할 수 있다.
GoDaddy as Registar & Route 53 as DNS Service
3rd Party Registrar with Amazon Route 53
- 3rd Party Registrar에서 도메인을 구입한 경우에도 Route 53을 DNS 서비스 제공자로 사용할 수 있다.
- Route 53에서 공용 호스팅 영역을 생성
- 3rd party 웹 사이트에서 NS 레코드를 업데이트하여 Route 53 이름 서버를 사용
- Domian Registra != DNS Service
- But every Domain Registrar usually comes with some DNS features
profile
