AWS Section 9. Route 53

📌 DNS 개요

• DNS (Domain Name System): 사람이 이해하기 쉬운 도메인 이름을 기계가 이해할 수 있는 IP 주소로 변환하는 시스템.
  • 예: www.google.com => 172.217.18.36
• 역할: 인터넷의 중추로, URL과 호스트 이름을 IP 주소로 변환해 웹사이트나 서버에 접속할 수 있게 해줌.
• DNS의 계층적 구조
  • .com, example.com, www.example.com, api.example.com처럼 도메인 이름이 점(.)을 기준으로 계층화됨.

 

✏️ DNS 용어 정리

• Domain Registrar: 도메인 이름을 등록하는 서비스, EX) Amazon Route 53, GoDaddy.
• DNS 레코드: A, AAAA, CNAME, NS 등 다양한 종류가 있으며, DNS 레코드를 통해 도메인과 IP 주소를 매핑.
• 존 파일(Zone File): 모든 DNS 레코드를 포함하는 파일.
• 이름 서버(Name Server): DNS 쿼리를 해결하는 서버. 권한이 있는 서버와 권한이 없는 서버로 나뉨.
• 최상위 도메인(TLD): 도메인의 최상위 부분인 .com, .us, .org 등을 나타냄.
• 2단계 도메인(SLD): amazon.com, google.com과 같이 최상위 도메인 아래에 위치한 도메인.

 

FQDN (Fully Qualified Domain Name) 예시

• http://api.www.example.com.
  • 마지막의 .은 루트 도메인
  • .com이 최상위 도메인(TLD),
  • example.com이 2단계 도메인(SLD),
  • www.example.com 서브 도메인
  • api.www.example.com는 도메인 이름
  • HTTP 부분은 사용하기를 원하는 프로토콜

>> 이 전체를 FQDN 이라고 하며 전체 주소 도메인 이름의 약자!!

 

 

🛠️ DNS 작동 방식

• 웹 브라우저가 example.com에 접속하려고 할 때, 로컬 DNS 서버에 먼저 질의.
• 로컬 DNS 서버는 ISP 또는 회사가 관리됨 또는 인터넷 서비스 제공자에 동적으로 할당되며, 이전에 캐싱된 정보가 있으면 바로 응답.
• 캐시가 없으면 루트 DNS 서버에 질의하여 .com 도메인 서버의 IP 주소를 알아냄.
  • “example.com 을 아시나요?”
  • “본 적은 없으나 .com은 알고 있습니다즉 .com 이름 서버의 IP가 1.2.3.4 라는 의미
  • .com NS(이름 서버) 1.2.3.4로 가세요”
• 이후 TLD DNS 서버로 요청을 보내 .com에 대한 정보를 획득.
  • “example.com 을 아시나요?”
  • “example.com NS(이름 서버) 5.6.7.8로 가세요”
• 최종적으로 SLD DNS 서버에 도달해 example.com의 IP 주소를 받아오고, 브라우저에 전달.
  • “example.com 을 아시나요?”
  • DNS 서버에는 example.com에 대한 항목이 있음!!
  • “example.com이 뭔지 알아용 A레코드이고 IP 9.10.11.12 임다”
  DNS는 이제 답을 알게됨. 누군가가 다시 example.com에 대해 물어본다면, 그 때는 바로 답변 가능💡
• 웹 브라우저는 받은 IP 주소를 통해 웹 서버에 접속하여 요청된 웹 페이지를 받아옴.

 

🗣️ DNS 구조도 설명

• 웹 브라우저: 사용자가 도메인(예: example.com)에 접속하려고 할 때, 첫 번째로 질의하는 곳.
• 로컬 DNS 서버: 사용자의 네트워크 또는 ISP에서 관리되며, 캐시된 DNS 정보를 제공.
• 루트 DNS 서버: 최상위 DNS 서버로, .com, .org와 같은 최상위 도메인의 이름 서버 정보를 관리.
• TLD DNS 서버: .com 도메인에 대한 이름 서버 정보를 제공.
• SLD DNS 서버: example.com과 같은 2단계 도메인에 대한 정보를 제공.
• 웹 서버: 최종적으로 IP 주소를 통해 연결되는 서버로, 실제 웹 페이지를 제공하는 서버.

 

 

Amazon Route 53

📌 Amazon Route 53 개요

• Route 53은 고가용성, 확장성, 완전히 관리되는 권한 있는 DNS 서비스
• 권한 있음(Authoritative): 사용자가 DNS 레코드를 직접 업데이트할 수 있다는 의미
• Route 53은 또한 도메인 레지스트라 역할도 함. 예를 들어 도메인 이름(example.com)을 등록할 수 있음!
• 100% SLA(서비스 가용성)를 제공하는 유일한 AWS 서비스
• Route 53의 이름은 전통적인 DNS 포트 53에서 따옴!

 

📌 Route 53 레코드

• 레코드는 트래픽을 도메인으로 라우팅하는 방법을 정의.
• 각 레코드는 다음과 같은 정보를 포함
  • 도메인/서브도메인 이름: EX) example.com.
  • 레코드 유형: A, AAAA 등.
  • 값: IP 주소 또는 호스트 이름.
  • 라우팅 정책: Route 53이 쿼리에 응답하는 방식.
  • TTL(Time To Live): DNS 리졸버에서 레코드가 캐싱되는 시간.
• Route 53이 지원하는 주요 DNS 레코드 유형
  • A, AAAA, CNAME, NS, 그리고 고급 유형(CAA, DS 등).

 

📌 Route 53 레코드 유형

• A 레코드: 호스트 이름을 IPv4 주소에 매핑.
• AAAA 레코드: 호스트 이름을 IPv6 주소에 매핑.
• CNAME 레코드: 하나의 도메인 이름(별칭, alias)을 다른 도메인 이름(정식 이름, canonical name)으로 매핑하는 DNS 레코드
  • 예를 들어, www.example.com을 example.com에 매핑하는 CNAME 레코드를 만들면, www.example.com에 접속하는 사용자는 사실상 example.com으로 리디렉션 되는 것!
  🚨 CNAME 레코드의 사용 제한 🚨
  • CNAME 레코드는 도메인의 상위 노드(root domain)에 적용할 수 없음
    • example.com 자체에 CNAME 레코드를 적용할 수 없음
      • www.example.com, blog.example.com과 같은 서브 도메인에는 CNAME 레코드를 적용할 수 있지만, 루트 도메인(즉, example.com)에는 불가능하다는 의미
• NS 레코드: 호스팅 존의 이름 서버를 정의하며, 도메인으로의 트래픽을 라우팅하는 방식을 제어. 어떤 도메인에 대한 처리를 다른 도메인 네임 서버에게 위임하는 기능을 가진 레코드

 

📌 Route 53 호스팅 존

• 호스팅 존은 도메인 및 서브도메인으로의 트래픽 라우팅 방식을 정의하는 레코드를 담고 있는 컨테이너
• 퍼블릭 호스팅 존
  • 퍼블릭 도메인 이름을 위한 레코드를 포함.
  • EX) application1.mypublicdomain.com.
  • 퍼블릭존은 쿼리에 메인 이름 application1.mypublicdomain.com 의 IP가 무엇인지 알 수 있음
• 프라이빗 호스팅 존
  • VPC 내에서 비공개 도메인 이름으로 트래픽을 라우팅하는 레코드를 포함
  • 가상 프라이빗 클라우드만(VPC )이 URL을 리졸브할 수 있음
  • EX) application1.company.internal.
• 호스팅 존은 월 $0.50의 비용이 발생

 

🆚 퍼블릭 vs 프라이빗 호스팅 존

• 퍼블릭 호스팅 존

• 퍼블릭 호스팅 존은 모든 공개된 클라이언트(인터넷 사용자)가 이 존에 접근할 수 있으며, 그에 따른 DNS 쿼리에 응답할 수 있음
  • 예를 들어, www.example.com에 대한 퍼블릭 호스팅 존을 설정하면, 누구든지 인터넷에서 www.example.com을 요청하여 해당 도메인의 IP 주소를 받을 수 있음
• 클라이언트는 Route 53을 통해 퍼블릭 IP(예: 54.22.33.44)로 연결됨

 

• 프라이빗 호스팅 존

• 반면, 프라이빗 호스팅 존의 경우 퍼블릭 인터넷에서 접근할 수 없으며, 해당 VPC 내에서만 DNS 쿼리에 응답할 수 있음
• 일반적으로 사내망이나 클라우드 네트워크 내부에서 DNS 레코드를 관리하는 데 사용됨

퍼블릭 호스팅 존은 모든 사용자가 도메인 레코드를 쿼리할 수 있는 반면,
프라이빗 호스팅 존은 VPC 내의 리소스에서만 쿼리할 수 있음

 

 

👩🏻‍💻 실습_ Route 53: 비용 지불이 되므로 따로 실습 진행X 👩🏻‍💻

: 비용 지불이 되므로 따로 실습 진행 X

• Route 53 도메인 등록
  • 도메인 등록을 위해 Registered domains 클릭.
  • 원하는 도메인 입력 후 가용성 확인 및 구매 진행 (1년에 약 $12~13).
  • Auto-renew 설정 여부 선택 (도메인 자동 갱신).
  • 개인 정보 보호(Privacy protection) 활성화.
• 도메인 등록 완료
  • 등록 후 Hosted zones에서 도메인 확인.
  • 기본적으로 NS 레코드와 SOA 레코드가 생성됨.

 

 

👩🏻‍💻 실습_ Route 53: 첫 번째 기록 생성 👩🏻‍💻

: 비용 지불이 되므로 따로 실습 진행 X

• 레코드 생성
  • Route 53 호스팅 존에서 A 레코드 생성.
  • 도메인 이름: EX) test.stephanetheteacher.com
  • IP 주소: 11.22.33.44 (예시로 입력, 실제 서버 IP는 나중에 설정).
  • TTL: 300초로 설정, 라우팅 정책은 Simple 선택.
• 레코드 확인
  • 명령줄(CloudShell 또는 터미널)에서 nslookup 및 dig 명령을 사용하여 도메인 쿼리.
  • 도메인 test.stephanetheteacher.com이 IP 11.22.33.44로 라우팅되는지 확인.
• 결과
  • 웹 브라우저에서는 해당 IP에 서버가 없어 동작하지 않음.
  • nslookup과 dig 명령을 통해 레코드가 정상적으로 생성된 것을 확인.

 

 

👩🏻‍💻 실습_ Route 53: EC2 설정 👩🏻‍💻

: 비용 지불이 되므로 따로 실습 진행 X

• EC2 인스턴스 설정
  • 3개의 리전에 EC2 인스턴스 생성
  • Amazon Linux 2, t2.micro, 키 페어 없이 실행.
  • SSH와 HTTP 허용, 사용자 데이터 스크립트 사용.
• Application Load Balancer (ALB) 설정
  • 프랑크푸르트 리전에서 ALB 생성.
  • HTTP 포트 80 설정, 3개의 서브넷 연결.
  • 새 대상 그룹 생성, EC2 인스턴스 등록.
• 작동 확인
  • 각 EC2 인스턴스의 퍼블릭 IP를 통해 Hello World 메시지 확인.
  • ALB를 통해 DNS 이름으로 연결 확인.

 

📌 TTL (Time To Live) 개요

• TTL은 DNS 레코드가 클라이언트의 캐시에 저장되는 시간을 의미
• 예를 들어, 클라이언트가 myapp.example.com에 대한 DNS 요청을 보내면, Route 53은 A 레코드와 IP 주소, 그리고 TTL 값을 응답으로 제공
• TTL이 설정된 시간 동안 클라이언트는 동일한 DNS 요청을 다시 보내지 않고, 캐시된 결과를 사용함
  • TTL 값이 있을 경우, 클라이언트는 동일한 도메인에 다시 접근할 때 DNS 서버에 쿼리를 보내지 않고 캐시된 결과를 사용. 이를 통해 불필요한 DNS 쿼리를 줄이고, 웹 서버에 더 빠르게 접근할 수 있음

 

🛠️ TTL의 동작 방식

• 클라이언트는 myapp.example.com에 대한 DNS 요청을 Route 53에 보냄
• Route 53은 A 레코드, IP 주소, 그리고 TTL 값을 응답으로 제공
• 예를 들어, TTL이 300초(5분)일 경우, 클라이언트는 이 시간 동안 응답을 캐시에 저장해 두고, 그동안 동일한 도메인에 다시 접속할 때는 새로운 DNS 요청을 보내지 않아도 됨
• TTL이 지나면 클라이언트는 다시 Route 53으로 새 DNS 요청을 보냄

 

📌 높은 TTL vs 낮은 TTL

• 높은 TTL (예: 24시간)
  • 장점
    • Route 53에 대한 트래픽이 적어져 비용이 줄어듦
  • 단점
    • 오래된 레코드가 캐시될 수 있으며,
    • 레코드를 변경하려면 모든 클라이언트의 캐시 갱신까지 최대 24시간이 걸릴 수 있음
• 낮은 TTL (예: 60초)
  • 장점
    • 레코드가 자주 업데이트되며, 변경 사항이 더 빠르게 적용됨
  • 단점
    • Route 53으로 들어오는 DNS 트래픽이 많아 비용이 증가할 수 있음

 

🧐 TTL 설정 전략

• 높은 TTL은 레코드가 자주 변경되지 않거나, 오래된 정보를 받아도 큰 문제가 없을 때 유용
• 낮은 TTL은 레코드 변경이 자주 필요하거나, 빠르게 업데이트해야 할 때 유용
• 💡변경 전략💡
  • 레코드를 변경해야 할 경우, 먼저 TTL을 낮게 설정해 모든 클라이언트가 빠르게 업데이트를 받도록 한 후, 변경이 완료되면 TTL을 다시 높게 설정하는 방식으로 변경 속도를 조절할 수 있음 !!

 

📌 TTL 예외 사항

• Alias 레코드는 TTL을 직접 설정할 수 없음🌟
• 그러나 대부분의 다른 DNS 레코드에서는 TTL 설정이 필수

 

👩🏻‍💻 실습_ TTL 작동 방식을 통해 캐시 갱신 과정 실습 👩🏻‍💻

: 비용 지불이 되므로 따로 실습 진행 X

1. 레코드 생성
   • demo.stephanetheteacher.com이라는 이름으로 A 레코드 생성.
   • EC2 인스턴스 IP를 값으로 입력하고, TTL을 2분(120초)으로 설정.
2. 레코드 검증
   • nslookup과 dig 명령을 사용해 레코드가 제대로 작동하는지 확인.
   • TTL 카운트다운 확인: 120초 동안 캐시된 응답을 사용하며, 시간이 지나면 새로운 IP로 갱신됨.
3. IP 변경
   • 기존 IP를 새 EC2 인스턴스 IP로 변경.
   • TTL 만료 후 클라이언트와 브라우저가 새 IP로 갱신되어 연결됨.

 

🆚 CNAME vs Alias

• CNAME Records
  • 루트가 아닌 도메인에서만 사용 가능 (e.g., app.mydomain.com).
  • 다른 호스트 이름으로 매핑 가능 (e.g., app.mydomain.com → blabla.anything.com).
  • 루트 도메인(mydomain.com)에는 사용 불가.
• Alias Records
  • 루트 및 루트가 아닌 도메인 모두에서 사용 가능 (e.g., mydomain.com → AWS 리소스).
  • AWS 리소스(로드 밸런서, CloudFront 등)로 호스트 이름을 매핑.
  • 무료이며, 자동으로 상태 확인 제공.
  • TTL 설정 불가 (Route 53에서 자동 관리).
• Alias Records의 특징
  • A/AAAA (IPv4/IPv6) 타입으로 사용.
  • DNS의 상위 노드(Zone Apex)에서도 사용 가능.
  • IP 변경 시 자동으로 인식.
  • TTL은 Route 53에서 자동으로 설정됨. (직접 설정할 수 없음)
• Alias 레코드 타겟
  • Elastic Load Balancers (ELB)
  • CloudFront 배포
  • API Gateway
  • Elastic Beanstalk 환경
  • S3 웹사이트
  • VPC Interface Endpoints
  • Global Accelerator
  • 동일 호스트 존 내의 Route 53 레코드

예외: EC2 인스턴스의 DNS 이름에는 Alias 레코드를 설정할 수 없음.

실습_

1. CNAME Records 생성
   • myapp.stephanetheteacher.com이라는 도메인을 생성하고, ALB의 DNS 이름을 CNAME 값으로 설정.
   • 웹 브라우저에서 해당 URL을 입력하면, ALB가 EC2 인스턴스로 트래픽을 보내고, Hello World 페이지가 정상적으로 표시됨.
2. 별칭(Alias) Records 생성
   • myalias.stephanetheteacher.com이라는 도메인을 생성하고, ALB로 리다이렉팅되는 별칭 레코드를 설정.
   • 별칭 레코드로 쿼리 시 비용이 발생하지 않으며, 동일한 Hello World 페이지가 표시됨.
3. 도메인 Apex 설정
   • stephanetheteacher.com으로 ALB를 리다이렉트하려고 시도했으나, CNAME은 Apex 도메인에 허용되지 않음.
     • Apex 도메인은 최상위 도메인, 즉 stephanetheteacher.com처럼 도메인 이름 맨 앞에 서브도메인 없이 사용하는 형태
     • DNS는 Apex 도메인에 IP 주소를 반환하는 A 레코드나 AAAA 레코드만 허용하고, CNAME 레코드를 허용하지 않음
   • 별칭 레코드를 사용해 Apex 도메인에 적용, 정상적으로 리다이렉트 완료.

CNAME 레코드는 서브도메인(myapp.stephanetheteacher.com)에 사용하고, ALB로 트래픽을 보냄 별칭 레코드는 Apex 도메인(stephanetheteacher.com)에 적용해서 CNAME이 허용되지 않는 Apex 도메인에서도 ALB로 트래픽을 보낼 수 있음 즉, Apex 도메인에는 CNAME 레코드를 사용할 수 없기 때문에 별칭 레코드를 사용해야 함🌟

 

 

📌 Amazon Route 53 – 라우팅 정책

📌 라우팅 정책 개요

• Route 53은 DNS 쿼리에 대한 응답 방식을 정의.
• 라우팅이란 단어는 로드 밸런서가 트래픽을 백엔드로 라우팅하는 방식과는 다름.
• DNS는 트래픽을 직접 라우팅하지 않으며, DNS 쿼리에만 응답해 IP 주소를 반환.
• 지원하는 라우팅 정책
  • 단순(Simple): 단일 리소스로 트래픽을 라우팅. 다중 값 설정 시 클라이언트가 임의로 선택.
  • 가중치 기반(Weighted): 설정된 가중치에 따라 여러 리소스로 트래픽 분배.
  • 장애 조치(Failover): 주 리소스가 다운되면 보조 리소스로 트래픽을 전환.
  • 지연 시간 기반(Latency-based): 클라이언트의 지연 시간이 가장 낮은 리소스로 트래픽을 라우팅.
  • 지리적(Geolocation): 클라이언트의 위치에 따라 트래픽을 라우팅.
  • 다중 값 응답(Multi-Value Answer): 여러 IP 주소를 반환하며, 클라이언트가 임의로 선택.
  • 지리 근접(Geoproximity): 지리적 근접성을 고려해 트래픽을 라우팅 (Route 53 트래픽 플로우 사용).

 

📌 단순 라우팅(Simple Routing)

• 단일 리소스로 트래픽 라우팅이 일반적.

• 하나의 레코드에 다중 값을 지정 가능. 이 경우, 클라이언트가 무작위로 IP 주소를 선택.

• 별칭(Alias) 사용 시, 단일 AWS 리소스만 지정 가능.
• 상태 확인 불가: 단순 정책에서는 상태 확인(Health Check)을 사용할 수 없음.

 

👩🏻‍💻 실습_ 단순 라우팅 정책

단순 라우팅 정책에서 하나의 레코드에 여러 값을 설정하고, 클라이언트가 무작위로 IP를 선택하는 방식을 실습

레코드 생성

• A타입 레코드로 생성.
• 이름: "simple"을 포함한 도메인명.
• 값: ap-southeast-1 인스턴스의 IP.
• TTL: 20초로 설정.
• 라우팅 정책: 단순(Simple) 라우팅 선택.

레코드 편집

• 기존 레코드에 여러 IP 주소 추가 (ap-southeast-1, us-east-1).
• 변경 후, TTL 만료 시 두 개의 IP 중 하나를 클라이언트가 무작위로 선택.

dig 명령어 검증

• TTL이 20초인 A 레코드 확인.
• 여러 IP가 반환되며, 클라이언트가 무작위로 선택해 접속.

 

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

 

📌 가중치 기반 라우팅 정책 개요

• 각 리소스에 가중치(weight)를 할당해, 특정 리소스로 전달되는 트래픽의 비율을 제어.
• 예시: 가중치 70, 20, 10이 할당된 세 개의 리소스가 있을 때, 각각 70%, 20%, 10%의 요청이 각 리소스로 라우팅됨.

 

📌 가중치 계산 방식

• 트래픽(%) = (해당 레코드의 가중치) / (모든 레코드의 가중치 합).
• 가중치의 합이 반드시 100일 필요는 없음🌟
• 동일한 이름과 유형을 가진 DNS 레코드들끼리만 적용 가능.

 

📌 활용 사례

• 로드 밸런싱: 여러 지역의 리소스에 트래픽을 분배.
• 새 애플리케이션 테스트: 적은 양의 트래픽을 새로운 애플리케이션에 보내 테스트 가능.

 

📌 가중치 0의 의미

• 가중치 0
  • 해당 리소스로 트래픽을 보내지 않음.
• 모든 리소스에 가중치 0이 설정되면, 모든 리소스가 동일한 가중치로 취급.

 

👩🏻‍💻 실습_ 가중치 기반 라우팅 정책

가중치에 따른 트래픽 분배 방식과 그 결과를 확인

레코드 생성

• A 레코드 3개 생성, 도메인명에 "weighted" 추가.
• ap-southeast-1: 가중치 10, TTL 3초.
• us-east-1: 가중치 70, TTL 3초.
• eu-central-1: 가중치 20, TTL 3초.

가중치에 따른 트래픽 분배

• 트래픽의 70%는 us-east-1, 20%는 eu-central-1, 10%는 ap-southeast-1로 분배.
• TTL이 3초여서 브라우저에서 새로고침하면 가중치에 따라 다른 리소스에서 응답이 옴.

dig 명령어 확인

• dig 명령어로 TTL과 IP 주소 확인.
• 대부분의 응답은 가중치가 큰 us-east-1에서 오지만, 가끔 eu-central-1과 ap-southeast-1도 응답.

 

 

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

 

📌 정의

• 지연 시간(latency)이 가장 짧은 리소스로 트래픽을 리다이렉팅하는 정책.
• 사용자가 AWS 리전과 통신할 때 걸리는 시간을 기반으로 지연 시간을 측정.

 

📌 활용 사례

• 지연 시간에 민감한 웹사이트나 애플리케이션에서 유용.
• 사용자에게 가장 빠른 응답 시간을 제공하는 리소스로 트래픽을 분배.

 

📌 작동 원리

• 예를 들어, 독일에 있는 사용자가 미국 리전의 리소스와 더 짧은 지연 시간을 가질 경우, 그 사용자는 미국 리전으로 리다이렉팅됨.
• 사용자가 가까운 리전으로만 연결되지 않고, 지연 시간이 짧은 리전으로 연결됨.

 

📌 상태 확인(Health Checks)

• 이 정책은 상태 확인과 연결할 수 있어, 리소스 장애 시 장애 조치(failover)를 지원.

이 정책은 지리적 위치와 상관없이 사용자에게 가장 짧은 응답 시간을 제공할 수 있도록 트래픽을 배분하는 데 유용💡

 

📌 상태 확인 (Health Checks) 개요

• HTTP 상태 확인은 공용 리소스만을 대상으로 함.
• 자동 DNS 장애 조치(Failover)를 지원
  1. 엔드포인트 모니터링: 애플리케이션, 서버 또는 AWS 리소스 모니터링.
  2. 계산된 상태 확인: 다른 상태 확인을 모니터링하여 결과를 조합.
  3. CloudWatch 경보를 모니터링하여 개인 리소스에도 상태 확인 적용 가능.

상태 확인을 통한 자동 장애 조치 설정 (us-east-1, eu-west-1에 상태 확인 설정).

 

📌 엔드포인트 모니터링

• 15개 글로벌 헬스체커가 엔드포인트 상태를 점검.
  • 정상 상태: 2xx, 3xx 응답 코드.
  • 비정상 상태: 18% 이상의 헬스체커가 비정상이라고 판단 시.
• 30초 또는 10초 간격으로 상태 확인 가능.
• 프로토콜: HTTP, HTTPS, TCP 지원.
• 네트워크 설정 필요: Route 53 상태 확인의 IP 범위를 허용해야 함.

 

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

• 여러 상태 확인 결과를 AND, OR, NOT 조건으로 조합.
• 최대 256개의 하위 상태 확인을 모니터링할 수 있음.
• 유지 관리 시 상태 확인이 모두 실패하지 않도록 사용 가능.

엔드포인트 모니터링 의 작동 방식과 설정 방법 설명 (15개의 글로벌 헬스체커).

계산된 상태 확인 을 통해 여러 상태 확인을 조합하는 방법

 

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

• Route 53 헬스체커는 VPC 외부에 있어 개인 엔드포인트 접근 불가.
• 해결 방법: CloudWatch Metric과 CloudWatch Alarm을 생성하고, 이를 상태 확인에 연동해 비공개 리소스를 모니터링.

Private Hosted Zones 에서 CloudWatch Alarm을 사용하여 개인 리소스를 모니터링하는 방법.

 

👩🏻‍💻 실습_ 상태 확인(Health Check)

 

다양한 상태 확인 생성 및 장애 발생 시 이를 모니터링하고, 계산된 상태 확인으로 복합적인 상태 확인 방법 실습

상태 확인 생성

• 첫 번째 상태 확인:
  • us-east-1 인스턴스의 IP 주소로 상태 확인 생성.
  • 포트: HTTP 80번, 간격 30초.
  • 고급 구성에서 기본값 사용.
• 두 번째 상태 확인:
  • ap-southeast-1 인스턴스의 IP 주소로 상태 확인 생성.
• 세 번째 상태 확인:
  • eu-central-1 인스턴스의 IP 주소로 상태 확인 생성.

상태 확인 테스트

• ap-southeast-1 인스턴스의 80번 포트를 차단하여 상태 확인 실패 유도.
• 상태 확인이 비정상으로 변경됨을 확인 (방화벽 규칙으로 인한 연결 시간 초과).

계산된 상태 확인 생성

• Calculated Health Check: 3개의 상태 확인 중 모두 정상(AND)일 때만 정상으로 간주하도록 설정.
• 계산된 상태 확인 생성 후, 상태 확인 하나가 비정상일 경우 계산된 상태 확인도 비정상으로 보고됨.

CloudWatch 알람을 통한 상태 확인

• CloudWatch 알람을 이용해 개인 리소스 상태를 모니터링하는 상태 확인 생성 가능 (실습에서는 알람이 없어 생성하지 않음).

 

 

📌 장애 조치 라우팅 정책(Failover Routing Policy)

Route 53이 클라이언트의 DNS 요청을 처리하며, 기본 인스턴스가 비정상일 경우 장애 조치 를 통해 보조 인스턴스 로 트래픽을 자동으로 전환하는 구조

 

📌 장애 조치 라우팅 정책 (Failover Routing Policy) 개요

• Active-Passive 구조로 구성.
  • Primary (기본): 주 인스턴스, 기본 리소스.
  • Secondary (보조): 재해 복구용 인스턴스.

 

📌 상태 확인 필수 (Health Check Mandatory)

• 상태 확인은 기본 리소스(Primary)에 필수적으로 연결되어야 함.
• 기본 리소스의 상태 확인이 비정상일 때, **자동으로 보조 리소스(Secondary)**로 장애 조치.

 

📌 동작 방식

• 정상 상태: 클라이언트가 DNS 요청을 보내면, Route 53은 기본 리소스가 정상 상태일 경우 해당 리소스로 응답.
• 비정상 상태: 기본 리소스가 비정상일 때, 자동으로 보조 리소스로 장애 조치하여 트래픽이 재해 복구 리소스로 전환됨.

 

👩🏻‍💻 실습_ 장애 조치 레코드 👩🏻‍💻

장애 조치 레코드를 설정하고 장애 발생 시 자동으로 보조 리소스로 전환되는 과정을 확인

기본(Primary) 레코드 생성

• A 레코드: 도메인 이름에 failover 추가.
• 값: eu-central-1 인스턴스 IP(3.70.14.253).
• 라우팅 정책: 장애 조치(Failover).
• TTL: 60초로 설정.
• 유형: 기본(Primary).
• 상태 확인: eu-central-1 인스턴스와 연결.

보조(Secondary) 레코드 생성

• A 레코드: 도메인 이름에 failover 추가.
• 값: us-east-1 인스턴스 IP.
• 라우팅 정책: 장애 조치(Failover).
• TTL: 60초로 설정.
• 유형: 보조(Secondary).
• 상태 확인과 연결하지 않음.

장애 조치 테스트

• eu-central-1 인스턴스의 80번 포트를 차단해 상태 확인을 비정상으로 만듦.
• 비정상 상태 확인을 감지하고, us-east-1 인스턴스로 자동 장애 조치가 실행됨.
• 페이지 새로고침 시, us-east-1 인스턴스가 응답.

복구

• 보안 그룹 규칙을 복구하여 eu-central-1 인스턴스의 상태 확인이 다시 정상으로 전환.
• 기본 인스턴스로 트래픽이 다시 장애 조치됨.

 

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

 

📌 지리 위치 기반 라우팅 정의

• 지연 시간 기반 라우팅과 달리, 사용자의 실제 위치에 기반해 트래픽을 라우팅함.
• 사용자의 위치를 대륙, 국가, 또는 미국 내 주 단위로 지정 가능.
• 가장 정확한 위치가 선택되어 그에 맞는 IP로 라우팅됨.

 

📌 기본(Default) 레코드 필요

• 지정한 위치와 일치하지 않는 사용자를 위해 기본 레코드를 생성해야 함.
  • 예: 특정 국가 또는 주에 대한 레코드가 없을 경우 기본 IP로 연결.

 

📌 사용 사례

• 웹사이트 현지화: 국가별로 다른 언어 버전의 웹사이트를 제공.
• 콘텐츠 분배 제한: 특정 국가에만 콘텐츠 제공.
• 로드 밸런싱: 각 국가 또는 지역에 맞는 서버로 트래픽을 분배.

 

📌 상태 확인(Health Check)과 연동 가능

• 지리 위치 라우팅의 예
  • 독일에 있는 사용자는 독일어 버전의 앱이 포함된 IP로 연결.
  • 프랑스에 있는 사용자는 프랑스어 버전의 앱이 포함된 IP로 연결.
  • 기본 레코드로 설정된 IP는 나머지 사용자들에게 제공됨 (예: 영어 버전의 앱).

 

👩🏻‍💻 실습_ 지리 위치(Geolocation) 라우팅 정책👩🏻‍💻

지리 위치 라우팅 정책을 사용해 사용자의 위치에 맞게 트래픽을 분배하는 방법

첫 번째 지리 위치 레코드 생성

• A 레코드: 이름에 geo 입력.
• 값: ap-southeast-1의 IP 연결.
• 라우팅 정책: 지리 위치(Geolocation) 선택.
• 위치: 아시아 전체로 설정.
• 상태 확인과 레코드 ID 설정 후 생성.

두 번째 지리 위치 레코드 생성

• A 레코드: us-east-1의 IP 연결.
• 라우팅 정책: 지리 위치 선택.
• 위치: 미국으로 설정.
• 레코드 ID: US로 설정 후 생성.

세 번째 레코드 (기본 레코드) 생성

• A 레코드: eu-central-1의 IP 연결.
• 라우팅 정책: 기본(Default) 설정.
• 레코드 ID: Default EU로 설정 후 생성.

테스트

• 기본적으로 유럽(EU)에서 페이지를 새로고침하면 eu-central-1 리전으로 연결됨.
• VPN을 이용해 인도(아시아)로 접속 시 ap-southeast-1 리전으로 연결됨.
• 미국으로 설정 후 접속 시 us-east-1 리전으로 연결됨.
• 미국이 아닌 멕시코로 접속 시, 지리 위치 레코드에 없는 국가이므로 eu-central-1로 연결됨 (기본 레코드).

보안 그룹 수정

• HTTP 규칙 삭제로 인해 상태 확인 실패 후, HTTP 규칙 복구하여 정상 작동 확인.

 

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

 

📌 지리 근접 라우팅 정의

• 사용자와 리소스의 지리적 위치를 기준으로 트래픽을 라우팅함.
• 편향(Bias) 값을 사용해 특정 리소스에 더 많은 트래픽을 유도할 수 있음.

 

📌 편향(Bias) 값 조정

• 양수 값(1~99): 지정된 리소스에 더 많은 트래픽을 보내기 위해 지리적 영역을 확장.
• 음수 값(-1~-99): 리소스로 가는 트래픽을 줄이기 위해 지리적 영역을 축소.

 

📌 리소스 종류

• AWS 리소스: 특정 AWS 리전을 지정.
• 비AWS 리소스: 위도와 경도를 지정해 위치를 계산함.
• Route 53 트래픽 플로우를 사용해 이 기능을 활성화해야 함.

 

기본적으로 편향값이 0으로 설정된 상태에서 사용자는 자신의 위치에 가장 가까운 리전으로 트래픽이 라우팅됨. us-west-1과 us-east-1의 경우, 미국을 두 개의 영역으로 나눠 사용자들이 각각 가까운 리전으로 연결됨.

 

 

• us-east-1의 편향값을 50으로 설정하면, 더 많은 트래픽이 us-east-1으로 유도됨. 이로 인해 경계선이 서쪽으로 이동해 us-east-1으로 더 많은 사용자가 연결됨.

 

사용 사례

• 특정 리전에 더 많은 트래픽을 보내야 하는 경우, 편향값을 조정해 지정된 리소스에 더 많은 트래픽을 유도할 수 있음.

 

📌 Route 53 - Traffic Flow

 

이 기능은 복잡한 DNS 및 트래픽 관리가 필요한 대규모 인프라에서 매우 유용하며, 시각적인 관리와 정책 적용을 통해 효율적으로 트래픽을 제어할 수 있음

 

Traffic Flow 정의

• 복잡한 레코드와 설정을 간편하게 생성하고 관리하는 기능.
• 시각적인 비주얼 에디터를 통해 복잡한 라우팅 의사 결정 트리를 관리할 수 있음.

주요 기능

• Visual editor를 사용하여 복잡한 설정을 쉽게 관리.
• 지리 근접성, 트래픽 분산 등을 설정 가능.
• 복잡한 라우팅 규칙들을 쉽게 관리하는 UI로, 각 규칙을 시각적으로 조정할 수 있음.

Traffic Flow Policy

• 설정을 Traffic Flow Policy로 저장할 수 있음.
• 버전 관리를 지원하며, 다양한 Route 53 호스팅 영역(다른 도메인 이름)에 적용할 수 있음.
• 설정을 쉽게 저장, 적용, 변경 가능.

 

• 지리 근접성 규칙을 설정.
• 각 리전별로 편향값을 지정하여, 트래픽을 어느 리소스로 더 많이 보낼지 조정 가능.
• 비주얼 에디터를 통해 트래픽 흐름을 시각적으로 설정하고 관리할 수 있으며, Health chexk를 활성화하여 리소스의 상태에 따라 트래픽을 유동적으로 관리할 수 있음.

 

📌 Routing Policies – IP-based Routing

클라이언트의 IP 주소를 기반으로 트래픽을 특정 리소스로 라우팅하는 방식

• 라우팅의 기준: 클라이언트의 IP 주소가 기반
• CIDR 리스트 제공: 클라이언트의 IP 범위를 CIDR 형식(IP 주소와 서브넷 마스크를 결합ㅎ)으로 정의하고, 해당 범위에 따라 특정 리소스(예: 서버)로 트래픽을 보냄
• 사용 사례
  • 성능 최적화: 클라이언트의 위치나 네트워크를 알고, 가장 적합한 리소스로 라우팅함으로써 성능을 높일 수 있음
  • 네트워크 비용 절감: 특정 IP 범위를 미리 알고 있다면, 해당 IP 범위를 사용하는 클라이언트를 더 비용 효율적인 리소스로 라우팅할 수 있음

예시 설명

1. 두 개의 CIDR 범위를 정의
   • Location 1: CIDR 블록 203.0.113.0/24
   • Location 2: CIDR 블록 200.5.4.0/24
2. 이 CIDR 범위에 따라 각각의 로케이션을 라우팅 설정에 연결
   • example.com에 대해 Location 1의 IP 주소 1.2.3.4를 EC2 인스턴스로 연결.
   • example.com에 대해 Location 2의 IP 주소 5.6.7.8을 EC2 인스턴스로 연결.

 

동작 예시

• User A: IP 203.0.113.56을 사용하는 경우, 해당 IP는 Location 1에 속하므로, EC2 인스턴스의 IP 주소 1.2.3.4로 트래픽이 전달됨
• User B: IP 200.5.4.100을 사용하는 경우, Location 2에 속하며, EC2 인스턴스의 IP 주소 5.6.7.8로 트래픽이 라우팅됨

• 좌측에 사용자 A와 사용자 B가 각각 다른 IP 주소를 사용하여 Route 53으로 DNS 요청을 보냄
• CIDR 블록에 맞는 로케이션을 정의하고, 각각의 로케이션에 대한 IP 주소를 설정
• 사용자 A는 Location 1로, 사용자 B는 Location 2로 라우팅되어 다른 리소스에 접근하게 됨

>> IP 기반 라우팅은 이런식으로 클라이언트의 IP 주소를 기준으로 각기 다른 리소스로 트래픽을 유도하는 기능

 

 

📌 Routing Policies – Multi-Value

다중 값 라우팅 정책(Multi-Value Routing Policy)은 트래픽을 여러 리소스로 라우팅할 때 사용됨

• 사용 목적: 다중 리소스로 트래픽을 보내야 할 때 사용되며, Route 53이 여러 개의 값(리소스)을 반환함
• 상태 확인과 연결 가능: 리소스의 상태를 확인하여, 정상 상태로 보고된 리소스만 반환되도록 할 수 있음
• 최대 8개의 레코드 반환: 각 다중 값 쿼리에서 최대 8개의 정상 리소스 레코드가 반환
• ELB와 비교: 이 기능은 로드 밸런싱과 유사해 보이지만, ELB(Elastic Load Balancer)를 대체하지는 않으며, 클라이언트 측에서 로드 밸런싱이 이루어짐

예시 설명

• www.example.com의 A 레코드가 3개 설정되어 있음
  • 각 레코드의 IP 주소는 192.0.2.2, 198.51.100.2, 203.0.113.2
  • 각 레코드는 상태 확인과 연결되어 있음. 예를 들어, Web1은 상태 확인 A와 연결되어 있고, Web2는 상태 확인 B, Web3는 상태 확인 C와 연결되어 있음
• 동작 방식
  1. 클라이언트가 www.example.com에 대해 쿼리를 실행하면, Route 53은 최대 8개의 레코드를 반환
  2. 클라이언트는 반환된 레코드 중 하나를 선택해 리소스에 접속
  3. 만약 상태 확인이 활성화되어 있으면, 비정상으로 보고된 리소스는 제외되고, 정상 상태의 리소스들만 반환됨
• 단순 라우팅과의 차이점: 단순 라우팅 정책은 상태 확인을 지원하지 않으므로, 비정상 상태인 리소스도 반환될 수 있음. 반면, 다중 값 라우팅은 상태 확인을 통해 정상 상태의 리소스만 반환

 

• 표의 예시
  • Name: www.example.com에 대해 3개의 A 레코드가 존재.
  • Value: 각 레코드의 IP 주소는 192.0.2.2, 198.51.100.2, 203.0.113.2.
  • TTL: 각 레코드의 Time to Live (TTL)는 60초.
  • Set ID: Web1, Web2, Web3로 구분.
  • Health Check: 각 레코드는 상태 확인 A, B, C와 연결되어 있어, 정상 상태의 리소스만 반환

>> 이 기능을 사용하면 여러 리소스로 트래픽을 분산시키면서, 정상 상태의 리소스만 반환할 수 있어 더 안정적이고 유연한 트래픽 분산이 가능함

 

👩🏻‍💻 실습_ 다중 값 레코드 👩🏻‍💻

 

다중 값 라우팅이 정상적으로 작동하는지 확인

 

다중 값 레코드 생성

• 세 개의 레코드를 생성
• 첫 번째 레코드
  • 이름: multi
  • 값: us-east-1 리전
  • 라우팅 정책: 다중 값
  • 상태 확인: us-east-1
  • 레코드 ID: US
  • TTL: 60초
• 두 번째 레코드
  • 이름: multi
  • 값: ap-southeast-1 리전
  • 라우팅 정책: 다중 값
  • 상태 확인: ap-southeast-1
  • 레코드 ID: Asia
  • TTL: 60초
• 세 번째 레코드
  • 이름: multi
  • 값: eu-central-1 리전
  • 라우팅 정책: 다중 값
  • 상태 확인: eu-central-1
  • 레코드 ID: EU
  • TTL: 60초

레코드 테스트

• CloudShell을 사용해 레코드 상태를 확인
• dig 명령어를 사용하여 3개의 IP 주소가 반환되는지 확인
• 상태 확인이 정상일 때 3개의 응답이 나ㅇㅁ

상태 확인 반전 테스트

• eu-central-1 상태 확인을 비정상으로 설정해 테스트
• 상태 확인이 비정상일 경우, dig 명령어 실행 시 2개의 IP 주소만 반환됨
• 상태 확인 반전 후, 다시 3개의 IP 주소가 반환됨

💡 핵심 💡

• 다중 값 라우팅은 여러 리소스에 트래픽을 분산시킬 때 사용되며, 상태 확인을 통해 정상 상태의 리소스만 반환하도록 설정할 수 있음
• CloudShell을 통해 레코드를 테스트하여 상태 확인이 잘 동작하는지 확인할 수 있음

 

🆚 Domain Registar vs. DNS Service

 

Domain Registar

• 도메인 레지스트라 (Domain Registrar)는 사용자가 도메인 이름을 구매하고 등록할 수 있는 서비스 (ex- GoDaddy나 Amazon Registrar.
• 도메인을 구매하면 매년 요금을 지불하게 되며, 해당 도메인 이름을 소유하게 됨

DNS 서비스 (DNS Service)

• 도메인이 어디로 라우팅될지 관리
• 대부분의 도메인 레지스트라는 DNS 관리 서비스를 함께 제공하지만, 사용자는 다른 DNS 서비스를 사용할 수 있음
  • 예를 들어, GoDaddy에서 도메인을 구입했지만 DNS 관리는 AWS Route 53을 통해 할 수 있음

GoDaddy와 Route 53의 조합

• 도메인을 GoDaddy에서 구매한 후, DNS 관리를 위해 Route 53의 호스팅 존을 생성할 수 있음
• Route 53에서 네임서버(NS) 정보를 복사해 GoDaddy 네임서버 설정에 입력하면, GoDaddy에서 구매한 도메인이 Route 53을 통해 DNS 레코드를 관리하게 됨

3rd Party Registrar + Route 53

• 제3자 레지스트라(예: GoDaddy)를 통해 도메인을 구매하고도 Route 53을 DNS 서비스로 사용할 수 있음
• 먼저 Route 53에서 호스팅 존을 생성하고, NS(네임 서버) 레코드를 제3자 레지스트라의 설정에서 Route 53 네임 서버로 업데이트하면 됨

 

- 도메인 레지스트라는 도메인 이름을 판매하고 등록하는 곳
- DNS 서비스는 해당 도메인의 트래픽을 어디로 보낼지 설정하는 서비스
- 도메인을 한 서비스에서 구입하고, DNS 관리는 다른 서비스에서 할 수 있음
- 예를 들어 GoDaddy에서 도메인을 구입하고, Route 53을 DNS 관리에 사용할 수 있음