99. DNS란 무엇일까요?
Route 53을 이야기하기 전에 DNS가 무엇인지 알아봅시다. 본 강의는 기초 수준이지만 여러분은 DNS의 동작 방식을 이해할 수 있게 될 겁니다. 일상에서 매일 사용되지만 이것에 대해 정확히 잘 모릅니다. 같이 살펴보겠습니다
- DNS은 Domain Name System으로 사람에게 친숙한 호스트 이름을 대상 서버 IP 주소로 번역해 줍니다
- 예를 들어, 웹 브라우저에 www.google.com을 입력하면 IP 주소를 주고 웹 브라우저가 이면에서 여기에 접근하여 구글로부터 데이터를 얻습니다.
- DNS는 인터넷의 중추로 URL과 호스트 이름을 IP로 변환하는 것을 여러분이 이해할 수 있는 방법입니다
- DNS에는 계층적 이름 구조가 있습니다 www.google.com의 근원에는 .com이 있고 좀 더 정확하게 example.com이 있습니다. 그리고 www.example.com 또는 api.example.com이 있죠 이 모든 것이 도메인 이름의 계층입니다
다음으로 DNS 관련 용어를 살펴보겠습니다.
- 도메인 레지스트라(registrar)가 있습니다. 여러분의 도메인 이름을 등록하는 곳입니다. 아마존 Route 53 또는 GoDaddy가 될 수도 있고 온라인에서 찾을 수 있는 다른 레지스트라들도 있죠
- DNS 레코드에는 여러 종류가 있는데 이번 섹션에서 자세히 다뤄볼 것입니다. A, AAAA, CNAME, NS 등등이 있습니다. 이번 섹션에서 배울 것이니 걱정하지 마세요.
- 모든 DNS 레코드를 포함하는 존 파일(zone file)도 있습니다. 호스트 이름과 IP 또는 주소를 일치시키는 방법입니다. 이름 서버는 DNS 쿼리를 실제로 해결하는 서버입니다. 마찬가지로 이번 섹션에서 살펴볼 것입니다
- 최상위 도메인으로는 .com, .us, .in, .gov, .org 등이 있어요.
- 2단계 도메인은 amazon.com, google.com입니다. 단어 사이에 '.'이 있는 것을 볼 수 있는데요.
FQDN 또는 전체 주소 도메인 이름을 예시로 살펴보면 http://api.www.example.com.이 있습니다. 마지막 .을 루트라고 합니다. 전체 도메인 이름의 루트죠. 그리고 있는 .com은 TLD입니다. 바로 최상위 도메인입니다
example.com이 2단계 도메인이고
www.example.com이 서브 도메인입니다
api.www.example.com이 도메인 이름입니다
HTTP 부분은 사용하기를 원하는 프로토콜입니다
전체를 FQDN이라고 하는데 전체 주소 도메인 이름의 약자입니다(Fully Qualified Domain Name)
이제 용어를 살펴보았으니DNS가 어떻게 동작하는지 알아보겠습니다.
웹 서버가 있습니다
예를 들어 공인 IP가 있고 쉬운 예시로 9.10.11.12라고 하겠습니다. 도메인 이름 example.com을 이용해서 접근하고자 합니다. example.com이란 도메인 이름을 DNS용 서버를 등록해야 합니다. 여러분의 컴퓨터, 웹 서버가 어떻게 접근하고 응답을 받는지 살펴보겠습니다.
웹 브라우저가 example.com에 접근하기 위해서는 로컬 DNS 서버에 물어볼 것입니다 'example.com을 아십니까?' 로컬 DNS 서버는 보통 회사에 의해 할당되고 관리됩니다. 또는 인터넷 서비스 제공자에 동적으로 할당됩니다. 로컬 DNS 서버가 이 쿼리를 전에 본 적이 없다면 먼저 ICANN에 의해 관리된 DNS 서버의 루트에 물어볼 것입니다. ICANN 조직이 'example.com을 아십니까?'라고 물어봅니다. 가장 먼저 요청되는 서버인 루트 DNS 서버는 '본 적 없어요, 그러나 .com은 알고 있습니다'라고 말합니다. .com은 이름 서버(NS) 레코드로 공인 IP 1.2.3.4로 가보라고 알려줍니다.
로컬 DNS에 대답하길, 답을 갖고 있진 않지만 답에 좀 더 가까운 것을 알려줍니다. 왜냐하면 .com 도메인을 알고 있고 .com 도메인의 이름 서버의 IP는 1.2.3.4이기 때문입니다. 로컬 DNS 서비스는 '좋아요, 최상단 도메인에 물어보겠습니다'라고 합니다.
따라서 1.2.3.4.에 있는 .com 도메인 서버에게 쿼리의 답을 요청할 것입니다. IANA에 의해 관리되는 또 다른 도메인입니다. 이 DNS 서버에 example.com을 다시 물어보게 됩니다. 'example.com을 아십니까?' DNS 서버는 example.com이 무엇인지 몰라서 쿼리에 당장 답할 수가 없습니다. 어떤 레코드인지 모르죠. 그러나 example.com이라는 서버는 알고 있습니다. 5.6.7.8에 있습니다. 다음 질문을 할 공용 IP입니다
로컬 DNS 서버는 최종 서버로 서브도메인의 DNS 서버입니다. 이는 도메인 이름 레지스트라에 의해 관리되는 서버입니다. 예를 들어 아마존 Route 53 등등입니다. DNS 서버는 'example.com을 아십니까?'라고 물어보고 DNS 서버에는 example.com에 대한 항목이 있습니다. 'example.com이 무엇인지 알고 있죠'라고 하고 example.com은 A 레코드이고 이것의 결과로 IP 9.10.11.12를 얻습니다. DNS 서버가 이제 답을 알고 있습니다
DNS 서버에 반복적으로 물어보며 가장 구체적인 것을 찾았습니다. '이제 답변을 바로 드리겠습니다' 라고 합니다. 만약 누군가가 다시 example.com을 물어본다면 바로 답변을 줄 수 있습니다. 따라서 답변을 웹 브라우저에 보내고 브라우저는 답변을 받습니다. 이 IP 주소를 이용하여 웹 서버에 접근할 수 있습니다 DNS의 동작 방식은 이렇습니다 즉, 여러분은 지금까지 이면에서는 항상 DNS를 사용해왔습니다. 예를 들어 www.google.com나 어떤 웹사이트에 접근할 때 DNS를 사용하죠. 여러분은 DNS 쿼리가 동작하는 법을 보았습니다. 이것은 배경지식입니다. 이제 Route 53으로 넘어가 자체적으로 DNS를 관리하는 법을 배울 것이기 때문입니다.
100. Route53 개요
이제 DNS가 무엇인지 알았으니 아마존 Route 53을 살펴보겠습니다
- 고가용성, 확장성을 갖춘, 완전히 관리되며 권한있는 DNS입니다. 권한이 있다는 것이 무슨 뜻일까요? 고객인 여러분이 DNS 레코드를 업데이트할 수 있다는 것입니다. 즉, DNS에 대한 완전히 제어할 수 있습니다
-- 클라이언트가 있고 그들이 여러분의 EC2 인스턴스 example.com에 접근하고자 하죠. 그러나 지금 EC2 인스턴스에는 오직 퍼블릭 IP만 있습니다. 이때 무슨 일이 벌어지냐면
DNS 레코드를 아마존 Route 53의 호스팅 존에 쓰려고 합니다. 클라이언트가 example.com을 요청하면 Route 53 서비스가 IP 54.22.33.44를 찾고 있다고 응답합니다. 그러면 클라이언트는 바로 EC2 인스턴스에 접근합니다.
- Route 53 역시 도메인 이름 레지스트라로 도메인 이름을 example.com으로 등록합니다. 이 서비스를 시작할 수 있도록 작업을 직접 해볼 것입니다.
- 또한 Route 53의 리소스 관련 상태 확인을 확인할 수 있습니다. 이 섹션에서 다룰 예정이죠.
- 100% SLA 가용성을 제공하는 유일한 AWS 서비스입니다.
- 마지막으로 왜 Route 53이라고 할까요? 53은 DNS 서비스, 즉, 이름에서 사용되는 전통적인 DNS 포트입니다.
- Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의합니다
- 각 레코드는 도메인이나 example.com과 같은 서브도메인 이름과 같은 정보를 포함합니다
-- 레코드 종류를 살펴볼 건데 예를 들어 A나 AAAA가 있습니다
-- 레코드의 값은 예를 들어 123.456.789.123인데
-- 라우팅 정책은 Route 53이 쿼리에 응답하는 방식입니다
-- TTL은 DNS 리졸버(resolver)에서 레코드가 캐싱 되는 시간입니다. 타임 투 리브(TTL)라고도 합니다
- Route 53에서 지원하는 DNS 레코드 종류는 많은데
-- 반드시 알아야 하는 것은 A, AAAA, CNAME, 그리고 NS입니다 실습 때 살펴볼 것이고 설정할 수 있는 고급 레코드도 살펴보죠. 그러나 시험 대비 목적으로는 여기 적은 것만 알고 있으면 됩니다
따라서 시험에서 중요한 레코드 종류를 배워보겠습니다
- A 레코드는 간단합니다. 호스트 이름과 IPv4 IP를 매핑하죠. 예를 들어 example.com은 1.2.3.4로 바로 연결됩니다
- AAAA은 A와 비슷한 아이디어입니다. 이번에는 호스트 이름을 IPv6 주소에 매핑합니다.
- CNAME은 호스트 이름을 다른 호스트 이름과 매핑합니다.
-- 물론 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있죠.
-- Route 53에서 DNS 이름 공간 또는 Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없습니다. 나중 강의에서 이들이 어떻게 동작하는지 살펴볼 것입니다.
-- 예를 들어 example.com에 CNAME을 만들 수는 없지만 www.example.com에 대한 CNAME 레코드는 만들 수 있습니다. 나중 강의에서 어떻게 처리하는지 살펴보겠습니다.
- 마지막으로 NS는 호스팅 존의 이름 서버입니다. 서버의 DNS 이름 또는 IP 주소로 호스팅 존에 대한 DNS 쿼리에 응답할 수 있습니다.
-- 또한 트래픽이 도메인으로 라우팅 되는 방식을 제어합니다.
호스팅 존을 살펴보겠습니다
- 호스팅 존은 레코드의 컨테이너입니다. 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의합니다.
호스팅 존에 두 종류가 있는데 퍼블릭 호스팅 존과 프라이빗 호스팅 존이 있습니다
- 퍼블릭 도메인 이름을 살 때마다 mypublicdomain.com이 퍼블릭 도메인 이름이라면 퍼블릭 호스팅 존을 만들 수 있습니다. 퍼블릭 존은 쿼리에 도메인 이름 application1.mypublicdomainname.com의 IP가 무엇인지 알 수 있습니다.
- 또한 프라이빗 호스팅 존이 있는데 공개되지 않는 도메인 이름을 지원하죠. 가상 프라이빗 클라우드(VPC)만이 URL을 리졸브 할 수 있습니다. application1.company.internal 같은 경우죠. 사기업에서 일하시는 분들은 본 적 있을 거예요. 사기업에는 때때로 회사 네트워크 내에서만 접근할 수 있는 URL이 있습니다. 비공개 URL이기 때문에 비공개되어 있습니다. 이면에는 프라이빗 DNS 레코드가 있고
- AWS에서 만드는 어떤 호스팅 존이든월에 50센트를 지불해야 합니다. Route 53 사용은 무료가 아닙니다. 실습에서처럼 도메인 이름을 등록하면 일 년에 최소 12달러를 지불해야 합니다. 참고로, 이 섹션 또한 무료가 아니겠죠.
호스팅 존에 대한 여러분의 이해를 돕도록 하죠. 퍼블릭 호스팅 존은 공개된 클라이언트로부터 온 쿼리에 응답할 수 있습니다. 웹 브라우저에서 example.com을 요청하면 IP를 반환합니다.
반면, 프라이빗 호스팅 존의 경우 해당 VPC에서만 동작합니다. 비공개 도메인 이름의 프라이빗 리소스를 식별할 수 있게 하죠. 예를 들어 EC2 인스턴스 1개가 있고 webapp.example.internal을 식별하고자 합니다. 또 다른 EC2 인스턴스에서는 api.example.internal을 식별하기 원하고 데이터베이스에서는 db.example.internal을 식별하고자 합니다. 프라이빗 호스팅 존에 등록하려고 하는데 첫 번째 EC2 인스턴스가 api.example.internal을 요청하는 경우 프라이빗 호스팅 존은 프라이빗 IP 10.0.0.10이라는 답을 갖고 있습니다. EC2 인스턴스는 데이터베이스에 연결이 필요할 수도 있는 두 번째 EC2 인스턴스에 연결하죠. database.example.internal가 무엇인지 물어보면 프라이빗 호스팅 존은 프라이빗 IP를 알려줍니다. EC2 인스턴스는 데이터베이스에 직접적으로 연결할 수 있고
퍼블릭 호스팅 존은 프라이빗 호스팅 존과 똑같이 동작합니다만 퍼블릭 호스팅 존은 누구든 여러분의 레코드를 쿼리 할 수 있습니다. 퍼블릭 레코드를 위한 호스팅 존이죠. 프라이빗 호스팅 존은 오직 프라이빗 리소스, 예컨대, VPC에서만 쿼리 할 수 있습니다.
101. Route 53 - 도메인 등록(실습)
102. Route 53 - 첫 번째 기록 생성(실습)
103. Route 53 - EC2 설정(실습)
104. Route 53 - TTL + 실습
이번에는 TTL에 대해 알아봅시다.
레코드 TTL은 Time To Live의 약자입니다. 예시에서 클라이언트가 DNS route 53와 웹 서버에 접속한다고 해봅시다. myapp.example.com에서 DNS 요청을 보내면 DNS로부터 회신을 받는데요. 회신 내용으로는 A 레코드와 IP 주소 그리고 TTL이 있으며 TTL은 300초 정도 된다고 합시다. TTL은 클라이언트에게 이 결과를 캐시하도록 요청합니다. 300초의 TTL 동안 말이죠. 300초 동안 클라이언트는 결과를 캐시합니다. 이 말인즉슨, 클라이언트가 재요청을 보내거나 같은 호스트 이름으로 접속할 경우 클라이언트는 DNS 시스템에게 쿼리를 보내지 않아도 된다는 의미죠. 이미 답변을 캐시에 저장했기 때문에 답을 알고 있으니까요. 하지만 캐시에도 시간이 소요되니 캐시 TTL이 발생합니다. DNS 요청 쿼리를 계속해서 자주 보내는 상황을 원치 않는 겁니다. 레코드는 그렇게 자주 바뀌지 않거든요. 이미 저장된 답변을 이용함으로써 웹 서버에 접속이 가능하며 HTTP 요청 및 회신을 보낼 수 있겠죠.
두 가지의 극단적인 경우를 봅시다. 예를 들어 TTL을 24시간으로 높게 설정한다면
- Route 53의 트래픽은 현저히 적겠죠. 결과가 24시간 동안 캐시될 테니
- 클라이언트는 요청을 적게 보낼 겁니다. 하지만 클라이언트가 오래된 레코드를 받을 가능성도 있죠. 따라서 만약 레코드를 바꾸고자 한다면 모든 클라이언트들이 새 레코드를 캐시에 저장할 때까지 24시간을 기다려야 한다는 뜻입니다.
반대로 TTL을 60초 정도로 짧게 설정한다면
- DNS에는 트래픽의 양이 많아져서 비용이 많이 들게 됩니다. Route 53에 들어오는 요청의 양에 따라 요금이 책정되거든요
- 하지만 오래된 레코드의 보관 시간은 짧아지겠죠. 따라서 레코드 변경이 빨라집니다
- 레코드 변경 전반이 더욱 편리하죠.
어떤 TTL 설정이 더 적합할지는 상황에 따라 달라집니다. 레코드를 변경하려는 경우 예를 들어 TTL을 24시간으로 늦춘 다음 모든 클라이언트가 느린 새 TTL을 가지고 있다는 점을 확인한 후, 레코드 값을 바꿔서 모두에게 업데이트가 되면 TTL을 올리는 식이죠. 그런 전략을 사용합니다
TTL은 모든 레코드에 있어 필수적인데요.다음 강의에서 다룰 별칭 레코드는 제외됩니다.
TTL을 콘솔에서는 어떻게 다루는지 살펴봅시다
그럼 이제 Time To Live의 작동 방식을 알아 보죠
새 레코드를 생성해 봅시다
demo라는 이름을 붙여 주죠
값은 앞서 생성한 EC2 인스턴스 중에서 하나를 사용할 겁니다
eu-central-1의
EC2 인스턴스에서 값을 가져와 붙여 넣습니다
그리고 TTL은 2분으로 설정합시다
1분 버튼을 두 번 눌러서 2분으로 설정하면 되겠죠
이제 TTL은 120초입니다
Create records를 누르면
이제 레코드가 생성되었네요
특정 IP 주소로 향하는 A 레코드로
demo.stephanetheteacher.com이죠
이제 레코드의 작동 방식을 보여드릴 텐데요
Firefox에 문제가 좀 있는 상태입니다
Firefox에서 열려고 하면 오류가 생기죠
간단히 고칠 수 있는 문제가 아니라서
Google Chrome을 오른쪽에 띄워 보여드리겠습니다
Google에 IP 주소를 붙여 넣으면
자동으로 eu-central-1 인스턴스로 연결을 해줄 겁니다
연결됐네요, 즉 이 A 레코드가 제대로 작동하고 있다는 뜻이죠
CloudShell을 통해서도 검증이 가능한데요
내용을 모두 지우고, 이 레코드 주소에 대해 nslookup을 실행해 보면
보시다시피 IP 주소가 일치하죠
여기에 dig 명령을 입력하면 결과가 나옵니다
그러면 결과 섹션에서
이렇게 115라는 숫자를 찾을 수 있는데요
제가 DNS 쿼리를 보냈기 때문에
120초 동안 레코드가 캐시된 겁니다
여기에서 dig 명령을 다시 실행하게 되면
숫자가 98로 떨어집니다
즉 98초 내 동안에는
같은 응답을 받게 될 거란 거죠
응답이 이미 컴퓨터 캐시 내에 저장이 되어 있으니까요
잠깐 레코드로 다시 이동해
이 IP 대신 ap-southeast-1의
IP를 가져와서 여기에 넣은 뒤 저장해 보겠습니다
그러면 레코드가 업데이트되었음에도 불구하고
CloudShell에 가서 dig 명령을 실행하면
보시다시피 결과는 전과 동일합니다
레코드가 캐시되려면 66초가 더 걸릴 겁니다
시간이 다 되기 전에 Chrome으로 가서
페이지를 새로 고침하면
여전히 eu-central-1의 결과가 뜹니다
레코드가 캐시되기까지 2분이 걸리기 때문이죠
캐시가 만료되고 나면 그때서야
명령어 라인의 인터페이스나 Chrome 웹 브라우저가
Route 53에게 레코드 값을 다시 묻게 될 것이고
그 후에 새 IP에 대한 결과를 받아 새 주소로 리다이렉팅이 될 겁니다
확인하려면 기다리는 수밖에 없어요
1분 더 기다렸다가 다시 돌아오겠습니다
이제 1분이 지났으니 웹 브라우저를 새로 고침하면
이번에는 Hello World가
ap-southeast-1b라는 다른 IP에서 뜨죠
이제 CloudShell에서 dig 명령을 다시 실행해 보면
120초라는 새 TTL이 표시되고
오른쪽을 보시면 새로운 서버의 IP주소가 나와 있죠
TTL을 시연해 봤습니다
도움이 되었길 바라며 다음 시간에 뵙죠
105. Route 53 CNAME vs Alias + 실습
이번 시간에는 CNAME과 별칭의 차이에 대해 알아 봅시다
- 로드 밸런서나 CloudFront 등 AWS의 리소스를 사용하는 경우 호스트 이름이 노출됩니다
-- 그리고 보유한 도메인에 호스트 이름을 매핑하고자 하실 수 있겠죠. myapp.mydomain.com에 이 로드 밸런서를 매핑하는 경우입니다.
- 두 가지 옵션이 있는데요 첫 번째는 CNAME 레코드로 앞서 A 레코드를 다뤘고 이번엔 CNAME 레코드입니다
-- CNAME은 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있습니다. 예를 들어 app.mydomain.com이 blabla.anything.com으로 향하는 식이죠.
-- 이건 루트 도메인 이름이 아닌 경우에만 가능해서 mydomain.com 앞에 뭔가 붙어야 하죠. 그냥 mydomain.com은 안 되죠 이는 실습에서 살펴볼 겁니다.
- 반면 별칭 레코드도 있습니다.
-- 이건 Route 53에 한정되지만 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있습니다. 가령 app.mydomain.com이 blabla.amazonaws.com를 향할 수 있는 거죠. 이 리소스들에 대해서는 잠시 후에 알아 볼 겁니다
-- 별칭 레코드는 루트 및 비루트 도메인 모두에 작동합니다. mydomain.com을 별칭으로 사용해 AWS 리소스로 향하도록 할 수 있기 때문에, 아주 유용하죠 시험에 출제될 수 있는 내용이니 실습을 해볼 겁니다.
-- 그 외에도 별칭의 장점으로는 무료이고
-- 자체적으로 상태 확인이 가능하다는 점이 있습니다.
별칭 레코드에 대해 자세히 살펴보면
- 이들은 AWS의 리소스에만 매핑이 되어 있습니다. 따라서 예를 들어 Route 53에서 example.com을 A 레코드의 별칭 레코드로 하고 그 값은 로드 밸런서의 DNS 이름을 지정하려 한다고 해봅시다.
- 이건 DNS의 확장 기능으로 시중의 모든 DNS에서 가능합니다.
- 만약 기반 ALB에서 IP가 바뀌면 별칭 레코드는 이걸 바로 인식할 겁니다.
- CNAME과 달리, 별칭 레코드는 Zone Apex라는 DNS 네임스페이스의 상위 노드로 사용될 수 있습니다. example.com에도 별칭 레코드를 쓸 수 있는 거죠.
- AWS 리소스를 위한 별칭 레코드의 타입은 항상 A 또는 AAAA인데 리소스는 IPv4나 IPv6 중 하나죠.
- 별칭 레코드를 사용하면 TTL을 설정할 수 없습니다. Route 53에 의해 자동으로 설정이 되죠.
별칭 레코드의 대상은 무엇이 될까요?
- 일라스틱 로드 밸런서(Elastic Load Balancer)가 될 수도 있고
- CloudFront 배포도 가능해요. 몇몇은 이 강의 과정에서 다룰 것이고 일부는 다루지 않을 거지만 무엇이 대상이 될 수 있는지만 알고 계시면 됩니다.
- ELB와 CloudFront 배포
- API Gateway
- 일래스틱 빈스톡 환경, S3 웹사이트도 가능하고요
- S3 버킷은 안 되고 버킷들이 웹사이트로 활성화될 시 S3 웹사이트는 가능하죠
- VPC 인터페이스 엔드포인트
- Global Accelerator 가속기
- 동일 호스트 존의 Route 53이 대상으로 가능합니다
- EC2의 DNS 이름에 대해서는 별칭 레코드를 설정할 수 없습니다. 기억해 두세요. EC2 DNS 이름은 별칭 레코드의 대상이 될 수 없습니다. 알아 두셔야 합니다.
그럼 이제 콘솔을 통해 CNAME과 별칭 레코드의 작동 방식을 봅시다
레코드를 생성해 줄 텐데
우선 CNAME부터 시작해 보죠
도메인에 myapp이라고 이름을 붙인 뒤
레코드 유횽으로는 CNAME을 선택하죠
값은 도메인 이름이어야 합니다
간단합니다, 이미 사용 가능한 도메인 이름이 있죠
ALB를 사용하면 되죠
ALB의 이름을 복사해서
여기 붙여 넣습니다
그럼 이 URL을 통해 ALB에 접속하는게 아니라
myapp.stephantheteacher.com을 통해서
접속하게 되는 거죠
그리고 Create records를 클릭하면
myapp.stephanetheteacher.com이 생성됩니다
이제 오른쪽에 Chrome 웹 브라우저를
띄워서 이 URL을 입력해 열어 보면
Hello World라는 문구가
AZ eu-central-1c에서 뜨네요
이 도메인 이름은 실제로 ALB에 속해 있으며
ALB는 트래픽을 EC2 인스턴스로 보내고 있으므로
이 Hello World라는 문구가 뜨는 겁니다
훌륭한 방식이지만 AWS 네이티브는 아니죠
많은 도메인 이름에서 가능한 방식이지만
더 나은 방법이 있습니다
ALB로 리다이렉팅을 하고 있기 때문에
별칭 레코드를 생성할 수 있겠죠
그럼 이번에는 레코드를
myalias라는 이름으로 생성해 봅시다
레코드 타입은 A로 합니다
현재 ALB가 IPv4 트래픽만을 허용하고 있으니까요
값을 입력할 때는 Alias 버튼에 체크를 해주고
Route traffic to를 누르면
이렇게 목록이 뜹니다
많은 선택지가 있는데요
이번에는 Alias to
Application and Classic Load Balancer를 선택합니다
지역도 선택해야 합니다 eu-central-1로 할게요
로드 밸런서로는
이걸로 선택을 하겠습니다
그리고 상태 확인은 Yes로 자동 체크가 되어 있습니다
별칭 레코드이기 때문이죠
Create records를 클릭하면
새 레코드가 생성되었네요
myalias.stephanethetheacher.com입니다
좋은 점은, 이 레코드를 쿼리하는 건 무료입니다
별칭 레코드이기 때문에 아무런 비용이 들지 않죠
myalias.stephanethetheacher.com을 클릭하면
DNS 쿼리를 몇 개 처리한 뒤
이렇게 다시 동일한 응답이 나오죠
바뀐 것은 없죠 잘 작동하는 겁니다
아주 좋네요
하지만 도메인 apex를 고려해 본다면 어떨까요?
즉, stephanetheteacher.com만을 사용해 이 페이지로 리다이렉트하려는 경우죠
이를 위해서는 레코드를 생성해야 하는데요
레코드 이름은 그냥 비워둘 겁니다
ALB의 도메인 이름으로 향하는 CNAME 레코드를 생성합니다
여기서 가져와서 붙여 넣을게요
stephanetheteacher.com이 이 값에 대한 CNAME으로 생성되는 거죠
이렇게는 안 될 겁니다 한 번 생성해 보죠
잘못된 요청이라며
CNAME은 이 구역의 apex에 허용되지 않는다고 하네요
이 구역은 stephanetheteacher.com이며
이 구역의 apex도 stephanetheteacher.com이니
CNAME을 apex에 설정할 수 없는 겁니다
이 문제를 해결하기 위한 유일한 방법은
별칭 레코드를 생성하는 겁니다
레코드의 타입은 A로 해주고요
이번에도 별칭은 eu-central-1 지역의 ALB나 CLB를 향할 거고요
로드 밸런서는 기존의 것과 동일합니다
이번에는 별칭 레코드를 썼으니 작동할 겁니다
이런 내용이 시험에 출제되겠죠
이제 stephanetheteacher.com에 접속이 가능해졌습니다
그럼 이제 웹 브라우저로 돌아가
주소 창에 stephanetheteacher.com을 입력하고 Enter를 누르면
로드 밸런서로부터 Hello World가 뜹니다
모두 잘 작동 중이라는 뜻이죠
AWS 내 CNAME과 별칭 레코드의 작동 방식을 살펴봤습니다
106. 라우팅 정책 - 단순 + 실습
이제 Route 53의 라우팅 정책에 대해 알아봅시다
라우팅 정책은 Route 53가 DNS 쿼리에 응답하는 것을 돕습니다.
여기서 라우팅이라는 단어를 혼동하셔서는 안 됩니다.
- 로드 밸런서가 트래픽을 백엔드 EC2 인스턴스로 라우팅하는 것과는 다른 상황이죠.
- 여기서의 라우팅은 DNS 관점입니다. DNS는 트래픽을 라우팅하지 않죠. 트래픽은 DNS를 통과하지 않아요. DNS는 DNS 쿼리에만 응답하게 되고 클라이언트들은 이를 통해 HTTP 쿼리 등을 어떻게 처리해야 하는지를 알 수 있게 되는 거죠. DNS는 호스트 이름들을 클라이언트가 실제 사용 가능한 엔드 포인트로 변환하는 것을 돕죠
Route 53가 지원하는 라우팅 정책은 다음과 같습니다
- 단순, 가중치 기반, 장애 조치 지연 시간 기반, 지리적, 다중 값 응답, 지리 근접 라우팅 정책이 있죠
이번 섹션에서 이들 모두를 하나씩 살펴볼 겁니다
먼저 단순 라우팅 정책입니다. 기존에 우리가 사용해 왔던 방식이죠. 일반적으로 트래픽을 단일 리소스로 보내는 방식입니다.
예를 들어 클라이언트가 foo.example.com으로 가고자 한다고 하면 Route 53이 IP 주소를 알려주는 거죠. 이는 A 레코드 주소입니다.
동일한 레코드에 여러 개의 값을 지정하는 것도 가능한데요.
이렇게 DNS에 의해 다중 값의 받은 경우에는 클라이언트 쪽에서 그 중 하나를 무작위로 고르게 됩니다. 이 예시의 경우에는 클라이언트가 foo.example.com로 가기를 요청하고, Route 53은 세 개의 IP 주소로 답합니다. A 레코드에 임베딩된 주소들이죠. 그럼 클라이언트가 셋 중 하나를 골라서 라우팅에 적용합니다/
단순 라우팅 정책에 별칭 레코드를 함께 사용하면 하나의 AWS 리소스만을 대상으로 지정할 수 있습니다.
단순 정책이라고 하는 건 간단해서죠. 그렇기 때문에 상태 확인은 할 수 없습니다. 상태 확인에 관해서는 섹션 후반에서 다뤄 볼 겁니다.
이제 콘솔로 이동해, 단순 라우팅 정책이 어떻게 생성될 수 있는지 봅시다
레코드를 생성할 텐데요 레코드의 이름으로는
앞에 simple을 붙이는 걸로 하겠습니다
A타입 레코드이고 값으로는
ap-southeast-1 인스턴스를 가져와서 사용하겠습니다
TTL은 20 정도로 아주 낮게 설정할게요
여기에서 라우팅 정책을 고를 수 있죠
정책 선택지가 여러 개 나와 있는데
여기 여섯 개가 있고 하나는 UI 어딘가에 존재하고 있습니다
TTL은 20초로 하고 단순 라우팅 정책으로
레코드를 생성해 봅시다
이전에도 했던 작업이니
이미 알고 계시겠죠
simple.stephanetheteather.com 도메인을 복사해
주소창에 넣어 이동해 보면
ap-southeast-1b 인스턴스에서 Hello World가 뜹니다
그럼 dig 명령을 실행해 보면 어떨까요?
dig를 재설치해야 하네요
sudo yum install bind-utils를 다시 입력하겠습니다
머신을 재시작해서 재설치가 필요하네요
좋습니다 dig 명령을 다시 실행해 보죠
dig 명령을 실행하니
이 IP로 향하고 있는, TTL 값이 20초인 A 레코드가 나옵니다
이제 이 레코드를 바꿔볼 텐데요
레코드를 편집해 봅시다
편집을 위해서는 그냥 레코드를 클릭하면 됩니다
이번에는 값에 IP 여러 개를 넣어 봅시다
ap-southeast-1, 혹은 us-east-1의 값을 가져오죠
이렇게 붙여넣고 저장하고 나면
기존의 TTL이 만료되고 난 뒤에
레코드 두 개가 나오게 될 겁니다
CloudShell에서 검증해 보겠습니다
dig 명령을 실행합니다
보시다시피 결과 섹션에 응답이 두 개 나오네요
각 IP에 하나씩 응답이 나왔습니다
이제 클라이언트가 선택을 하겠죠
웹사이트에 가서 새로 고침을 하면
us-east-1가 두 번 중 한 번은 나올 겁니다
아직 ap-southeast-1b가 나오네요
20초 정도 더 기다렸다가 다시 해볼게요
이제 새로 고침을 해보면
us-east-1a가 Hello World를 표시합니다
이렇게 단순 레코드 방식이 작동하는 모습을 함께 확인해 보셨습니다
도움이 되었길 바라며 다음 시간에 뵙죠
107. 라우팅 정책 - 가중치 + 실습
이제 가중치 기반 라우팅 정책에 대해 알아봅시다
이 정책을 사용하면, 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보내는 식의 제어가 가능합니다. 도면을 보시면 Amazon Route 53이 있고 EC2 인스턴스가 세 개 있는데 70, 20, 그리고 10의 각각 다른 가중치를 할당받아 이 예시에서는 가중치의 합이 100이 되는데 실제로는 이럴 필요는 없습니다. Amazon Route 53에서 오는 DNS 응답의 70%가 첫 번째 EC2 인스턴스로 리다이렉팅된다는 의미죠. 20퍼센트는 두 번째로 10퍼센트는 세 번째 인스턴스로 갑니다.
따라서, 각 레코드에 상대적으로 가중치를 할당하게 되는 거죠.
- 이렇게 하면 각 레코드로 보내지는 트래픽의 양(%)은 해당 레코드의 가중치를 전체 가중치로 나눈 값입니다. 그러면 전체 가중치 중 일부 퍼센트가 되는 거죠
- 합은 100이 아니어도 됩니다. 한 DNS 이름 하에 있는 다른 레코드들과 비교했을 때 해당 레코드로 트래픽을 얼마나 보낼지를 나타내는 값이죠.
이렇게 하려면 DNS 레코드들은 동일한 이름과 유형을 가져야 하며
상태 확인과도 관련될 수 있죠. 물론 아직 상태 확인에 대해서는 배우지 않았으나, 금방 배우게 될 겁니다
가중치 기반 정책이 사용되는 경우는 제법 명확한데요. 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에도 사용합니다.
가중치 0의 값을 보내게 되면 특정 리소스에 트래픽 보내기를 중단해 가중치를 바꿀 수 있죠.
만약 모든 리소스 레코드 가중치의 값이 0인 경우에는 모든 레코드가 다시 동일한 가중치를 갖게 됩니다.
콘솔에서 이 정책이 어떻게 작동하는지 살펴봅시다
새로운 레코드를 생성합시다
도메인 앞에 weighted라고 이름을 붙여 보죠
A 레코드이고, 라우팅 정책은 가중치 기반인 Weighted죠
ap-southeast-1에서 첫 번째 값을 가져오겠습니다
여기에 할당할 가중치는 10으로 지정합니다
아주 적은 가중치죠
TTL도 아주 작은 값인 3초로 설정해 주겠습니다
가중치의 효과를 보여드리기 위함이고
실제로는 TTL에 이렇게 작은 값을 쓰진 않겠죠
상태 확인과도 연결을 할 수 있는데
지금은 하지 않을 겁니다
레코드 ID도 설정할 수 있는데요
가중치 레코드 설정에서 이 특정 레코드를 식별하기 위해 사용되죠
southeast 인스턴스에서 가져온 값이니
그냥 SOUTHEAST라고 하겠습니다
또 다른 레코드도 추가할 수 있는데요
도메인 앞에는 똑같이 weighted를 붙여 주고요
라우팅 정책은 가중치 기반이죠
이번에는 us-east-1에서 값을 가져오겠습니다
이 IP 주소를 여기다 붙여 넣고
이번에는 가중치는 70으로 설정하겠습니다
us-east-1로 70%의 트래픽의 보내지는 거죠
레코드 ID는 US EAST로 설정하고
TTL은 이번에도 3초로 설정하겠습니다
마지막 레코드 생성입니다
이름을 weighted로 하고 eu-central-1의 값을 가져와야겠죠
라우팅 정책은 가중치 기반으로 하고요
가중치는 20으로 정하고 레코드 ID는 EU입니다
TTL은 3초로 설정하면 되죠
그러면 이 레코드들을 생성해 봅시다
표를 보시면 세 개의 레코드가 있죠
그 위에 있는 단순 레코드는 두 개의 IP 주소를 가진 반면
새로운 세 개의 레코드는 각각 하나의 값만 가지고 있죠
각 레코드의 가중치는 10, 20, 70입니다
URL을 이용해
weighted.stephanetheteacher.com로 가보면
us-east-1a에서 응답했네요
말이 되는 결과죠
트래픽의 70%는 이 지역으로 보내질 테니까요
하지만 3초에 한 번씩 새로 고침을 하면
언젠가 다른 지역으로부터 응답을 받게 될 겁니다
가중치에 기반해서요
가중치가 적용된 리소스의 하에 있는 거죠
보시다시피 자주 바뀌지 않고 있죠
출력을 보여드리기 위해 dig 명령을 실행해 보겠습니다
해당 도메인에 dig 명령을 실행합니다
TTL이 3초로 나오고 여기에 보이는 값은
us-east-1에서 온 값이겠죠
한 번 더 시도해서 이제 다른 값이 나오는지 봅시다
가중치 70은 확실히 큰 값이긴 했던 것 같군요
드디어 다른 값이 나왔습니다
3.70.14.253이라는 다른 IP에서 나온 값이죠
가중치 20을 할당한 주소에 해당하네요
이런 식으로 가중치를 할당한 결과를 확인할 수 있죠
가중치가 가장 큰 곳으로 대부분의 쿼리를 리다이렉팅하지만
종종 다른 값이 나오기도 합니다
웹 브라우저에서도 연습해 보실 수 있죠
지금은 eu-central-1c로 리다이렉팅이 됐네요
이번 강의는 여기까지입니다
가중치 레코드의 효과가 잘 이해되셨길 바랍니다
도움이 되었길 바라며 다음 시간에 뵙겠습니다
108. 라우팅 정책 - 대기 시간 + 실습
이번엔 정말 이해하기 쉬운 라우팅 정책인 지연 시간 기반 라우팅 정책에 대해서 알아보도록 하겠습니다.
지연 시간 기반 라우팅 정책이란 뭘까요? 지연 시간이 가장 짧은, 즉 가장 가까운 리소스로 리다이렉팅을 하는 정책입니다.
지연 시간에 민감한 웹사이트나 애플리케이션이 있는 경우에 아주 유용한 정책이죠.
지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정됩니다.
만약 유저가 독일에 있고 미국에 있는 리소스의 지연 시간이 가장 짧다면, 해당 유저는 미국 리전으로 리다이렉팅이 될 겁니다.
이것도 상태 확인과 연결이 가능한데요 다음 강의에서 배울 내용입니다
이해를 돕기 위해 세계 지도를 한 번 보죠. 두 개의 다른 리전에 애플리케이션을 배포한다고 해봅시다. ap-southeast-1과 us-east-1에 각 하나씩 배포하죠. 유저들은 세계 각지에 있으며 Route 53가 지연 시간을 측정한 뒤 지연 시간이 가장 짧은 가까운 거리의 유저들이 us-east-1의 ALB로 연결되고 다른 유저들은 ap-southeast-1로 연결될 겁니다.
이 내용을 콘솔에서 실습해 보도록 하죠
새로운 레코드를 생성할 텐데요
레코드 이름으로는 도메인 앞에 latency를 넣어 주고
ap-southeast-1에서 첫 번째 값을 가져옵니다
여기에 값을 붙여 넣죠
그리고 라우팅 정책은 지연 시간 기반이 될 겁니다
이렇게 할 경우에는
값에 IP 주소를 넣었기 때문에
레코드의 리전을 지정해 줘야 합니다
이 IP 주소를 가진 리전은
싱가포르의 ap-southeast-1이죠
왜냐하면 아직 이 단계에서는 별칭이
해당 IP가 싱가포르에 있는 EC2 인스턴스에서 왔다는 걸
알 수 없기 때문입니다 세계 어디의 IP도 가능한 상황이죠
그래서 이 IP의 리전이
아시아 태평양 지역의 싱가포르임을 표시해 주는 겁니다
그리고 상태 확인 연결도 가능하죠 레코드 ID에는
ap-southeast-1을 입력해 주겠습니다
그냥 제가 임의로 정한 이름입니다
레코드를 하나 더 추가합시다
레코드 이름은 latency로 붙여 주고
us-east-1에서 값을 가져오겠습니다
여기에 값을 붙여넣고 지연 시간 기반 정책을 고른 뒤
리전은 us-east-1이죠
레코드 ID는 역시 us-east-1로 설정하겠습니다
마지막으로 추가할 레코드는 eu-central-1입니다
이 IP 주소를 복사할게요
레코드 이름은 latency고요
값도 넣어 줍니다
지연 시간 기반 정책이고
리전은 eu-central-1이고 이름도 그대로 두겠습니다
그러면 세 개의 레코드를 생성하겠습니다
보시다시피 성공적으로 생성이 됐네요
이제 확인해 봅시다
저는 지금 유럽에 있으니
이 주소를 열면 유럽에 있는 인스턴스로 가겠죠
URL로 이동해 봅시다
eu-central-1c의 IP에서 Hello World를 띄워 주네요
CloudShell에서 dig 명령을 내려 보면
A 레코드가 나오는데 하나의 값으로부터 오죠
브라우저에 뜬 이 IP 주소와 같은 값이죠
eu-central-1c에 있는 인스턴스입니다
계속 새로 고침을 해도
eu-central-1에서 지연 시간이 그대로라
계속 같은 값이 나올 겁니다
그럼 지연 시간 레코드의 작동 여부는 어떻게 확인할 수 있을까요?
이 경우에는 VPN을 사용합니다
예를 들어 캐나다로 가봅시다
캐나다에서는 지연 시간이 가장 짧은 리전이 미국으로 나오네요
이제 페이지를 새로 고침하면 Hello World가 미국에서 뜨죠
VPN을 사용해 위치를 변경하면
노트북의 로컬 DNS 캐시에 있던 TTL도 초기화되죠
그래서 새로 고침했을 때 자동으로
us-east-1a의 새로운 값을 얻을 수 있는 겁니다
하지만 dig 명령을 실행하는 경우에는 바뀐 게 없죠
제 CloudShell은 유럽에 있으니까요
dig 명령을 사용하고 여기 있는 명령을 사용하면
여전히 전과 같은 값을 얻게 됩니다
컴퓨터, 즉 CloudShell은 바로 여기
eu-central-1에 있으니까요
가장 가까운 위치도 여전히 eu-central-1이겠죠
AP southeast도 한 번 확인해 봅시다
홍콩으로 이동해 보죠
이제 싱가포르에 가장 가깝네요
새로 고침을 합니다
ap-southeast-1b에서 Hello World가 뜨네요
지연 시간 레코드가 작동 중입니다
온라인에서 아주 흔하게 사용되는 훌륭한 방식이죠
도움이 되었길 바라며 다음 시간에 뵙겠습니다
109. Route53 - 상태 확인
route 53의 상태 확인에 대해 알아봅니다
상태 확인은 주로 공용 리소스에 대한 상태를 확인하는 방법인데요. 이번 시간에 배우게 될 개인 리소스의 상태를 확인하는 방법 또한 존재합니다.
서로 다른 두 지역에 각 하나씩의 로드 밸런서가 있고 둘은 모두 공용 로드 밸런서라고 해봅시다. 그리고 그 둘의 뒤에서 애플리케이션이 작동 중입니다. 다중 지역 셋업이죠. 지역 레벨에서 고가용성을 원하는 상황이거든요. 그리고 Route 53을 이용해 DNS 레코드를 만들 겁니다. 유저가 mydomain.com과 같은 URL을 이용해 접속하면 해당 유저는 가장 가까운 로드 밸런서로 연결되겠죠. 지연 시간 기반 레코드의 경우가 되겠네요. 하지만 만약 한 지역이 사용 불가능 상태가 되면 당연히 그곳으로는 유저를 보내고 싶지 않겠죠. 그러기 위해선 Route 53에서 상태 확인을 생성해야 합니다. us-east-1의 인스턴스에 상태 확인을 만들어 봅시다. eu-west-1의 인스턴스에도 상태 확인을 생성할 거예요. 이 두 개의 상태 확인을 Route 53의 레코드와 연결할 수 있게 되는데요.
이는 DNS의 장애 조치를 자동화하기 위한 작업입니다. 세 가지의 상태 확인이 가능한데요.
- 하나는 방금 보여드린 것처럼 공용 엔드 포인트를 모니터링하는 것이고 애플리케이션, 서버, 혹은 다른 AWS 리소스가 될 수 있겠죠.
- 다른 상태 확인을 모니터링하는 상태 확인도 있습니다. 계산된 상태 확인이라고 불리죠
- CloudWatch 경보의 상태를 모니터링하는 상태 확인도 있습니다. 앞으로의 강의에서 살펴보겠지만 제어가 쉽고 개인 리소스들에 아주 유용합니다
- 이 상태 확인들은 각자의 메트릭을 사용하는데 CloudWatch의 지표에서도 확인이 가능합니다.
상태 확인이 특정 엔드 포인트에 어떻게 작동하는지 봅시다.
ALB에 대한 eu-west-1의 상태 확인을 한다고 하면 AWS의 상태 확인이 전 세계로부터 올 겁니다. 하나만 있는 게 아니죠. 전 세계로부터 15개 정도의 상태 확인이 옵니다. 이들은 우리가 루트를 설정한 공용 엔드 포인트로 모두 요청을 보내죠. 200 OK 코드 또는 우리가 정의한 코드를 받으면 리소스는 정상으로 간주됩니다.
전 세계에서 온 15개의 상태 확인이 엔드 포인트의 상태를 확인하고
- 임계값을 정상 혹은 비정상으로 설정합니다.
- 간격도 설정 가능한데 두 개의 선택지가 있죠. 30초마다 정기적으로 확인할 수도 있고 비용이 더 들지만 10초마다 할 수도 있죠. 빠른 상태 확인이라고 불립니다.
- HTTP, HTTPS와 TCP 등 많은 프로토콜을 지원합니다
- 18% 이상의 상태 확인이 엔드 포인트를 정상이라고 판단하면 Route 53도 이를 정상이라고 간주합니다. 그렇지 않다면 비정상인 것으로 인식하죠.
- 상태 확인에 사용될 위치도 선택할 수 있습니다
상태 확인은 로드 밸런서로부터 2xx나 3xx의 코드를 받아야만 통과가 됩니다.
상태 확인에는 상당히 유용한 기능이 있는데 텍스트 기반 응답일 경우 상태 확인은 응답의 처음 5,120바이트를 확인합니다. 응답 자체에 해당 텍스트가 있는지 보기 위해서죠
마지막으로 네트워크 관점에서 아주 중요한 부분으로 상태 확인의 작동이 가능하려면 상태 확인이 여러분의 애플리케이션 밸런서나 엔드 포인트에 접근이 가능해야 합니다. 따라서 Route 53의 상태 확인 IP 주소 범위에서 들어오는 모든 요청을 허용해야 합니다. 이 주소 범위는 화면의 우측 하단에 있는 URL에서 확인 가능합니다.
상태 확인의 또 다른 유형은 계산된 상태 확인으로 여러 개의 상태 확인 결과를 하나로 합쳐주는 기능입니다. \
Route 53을 보면 EC2 인스턴스가 세 개 있고 상태 확인을 세 개 생성할 수 있죠. 이들은 EC2 인스턴스를 하나씩 확인해 주는 하위 상태 확인이 될 겁니다. 이제 이 하위 상태 확인을 바탕으로 상위 상태 확인을 정의할 수 있습니다.
이 상태 확인들을 모두 합치기 위한 조건은 OR와 AND 또는 NOT입니다.
하위 상태 확인을 256개까지 모니터링할 수 있고
상위 상태 확인이 통과하기 위해 몇 개의 상태 확인을 통과해야 하는지도 지정할 수 있죠.
이를 사용하는 경우로는 예를 들어 상태 확인이 실패하는 일 없이 상위 상태 확인이 웹사이트를 관리 유지하도록 하는 경우죠.
개인 리소스의 상태 확인은 어떻게 할 수 있을까요?
개인의 리소스를 모니터링하는 것은 어려울 수 있는데 모든 Route 53의 상태 확인이 공용 웹에 있기 때문에 이들은 VPC의 외부에 있죠.
개인 엔드 포인트에 접근이 불가능합니다. 개인 VPC나 온프레미스 리소스인 경우에는 그렇겠죠.
그래서 CloudWatch 지표를 만들어 CloudWatch 알람을 할당하는 식으로 이 문제를 해결할 수 있죠. 그러면 CloudWatch 경보를 상태 확인에 할당할 수 있습니다. CloudWatch 메트릭을 이용해 개인 서브넷 안에 있는 EC2 인스턴스를 모니터 하는 거죠. 그리고 메트릭이 침해되는 경우 CloudWatch 알람을 생성하게 됩니다. 그리고 알람이 ALARM 상태가 되면 상태 확인은 자동으로 비정상이 됩니다. 이렇게 하면 개인 리소스에 대한 상태 확인을 만든 것이나 다름이 없는 거죠. 가장 흔히 사용되는 사례입니다.
110. Route53 - 상태 점검 실습(실습)
111. 라우팅 정책 - 장애 조치 + 실습
이제 라우팅 정책을 살펴보겠습니다. 장애 조치에 관한 것입니다
여기 중간에 Route 53이 있고 EC2 인스턴스가 있습니다. 하나는 기본 EC2 인스턴스이고 두 번째는 보조 EC2 인스턴스 혹은 재해 복구 EC2 인스턴스입니다. 이 경우에는 상태 확인과 기본 레코드를 연결하는데 이는 필수적인 것입니다 상태 확인이 비정상이면 자동으로 Route 53은 2번째의 EC2 인스턴스로 장애 조치하며 결과를 보내기 시작합니다. 그리고 보조 EC2 인스턴스도 상태 확인을 연결할 수 있지만 기본과 보조가 각각 하나씩만 있을 수 있습니다.
클라이언트의 DNS 요청은 정상으로 생각되는 리소스를 자동으로 얻습니다. 기본 인스턴스가 정상이면 Route 53도 기본 레코드로 응답합니다. 하지만 상태 확인이 비정상이면 장애 조치에 도움이 되는 두 번째 레코드의 응답을 자동으로 얻게 됩니다.
여기까지 하고 실습을 통해 연습해 보겠습니다
이제 이 상태 확인을 활용해
장애 조치 레코드를 생성하겠습니다
호스팅 영역에서 레코드를 생성합니다
그리고 이름 입력 칸에 failover를 입력합니다
A 레코드로 하고
첫 번째 값은 저와 가까운
eu-central-1 인스턴스인 3.70.14.253으로 설정하겠습니다
그리고 라우팅 정책은 장애 조치로 합니다
TTL은 아주 낮은 60초로 하고
장애 조치 레코드에는
기본과 보조의 2가지 유형만 있습니다
기본 레코드를 선택한 뒤 상태 확인과
연결해야 합니다
eu-central-1의 상태 확인과 연결하겠습니다
그리고 레코드 ID는 EU로 하겠습니다
이는 이 레코드가 기본 레코드가 되어야 하고
상태 확인과 연결하여 두 번째 레코드로
장애 조치한다는 것을 의미합니다
이제 새 레코드를 추가하고 레코드 이름 칸에
failover를 입력합니다
그리고 us-east-1의 값을 입력합니다
라우팅 정책은 장애 조치로 하고
TTL도 60초로 합니다
장애 조치 유형은 보조로 선택합니다
us-east-1의 상태 확인과 연결할 수도 있는데
하지 않아도 됩니다
레코드 ID는 US로 하고
레코드를 생성합니다
레코드가 성공적으로 생성이 됐습니다
이제 다시 상태 확인을 보면
레코드와 연결한 두 상태 확인은 정상입니다
URL로 이동하죠
이쪽의 failover로 시작하는 URL로 이동하면
eu-central-1c에 응답을 얻었고 아주 좋습니다
이제 장애 조치를 유발하죠
eu-central-1의 리전으로 가서
이쪽에서 인스턴스를 찾아
보안 그룹으로 이동합니다
그리고 몇 가지 보안 그룹 규칙을 삭제하겠습니다
페이지를 새로고침 하겠습니다
여기 있네요, 좋습니다
이제 인바운드 규칙을 수정합니다
80번 포트의 규칙을 삭제하겠습니다
이제 상태 검사기에서 인스턴스를 연결할 수 없게 됩니다
이제 상태 확인이 비정상이 될 때까지 기다렸다가
장애 조치를 테스트하면 됩니다
이제 새로고침 해 보면
eu-central-1 상태 확인이 비정상이 됐습니다
모니터링 탭을 보면
비정상인 것을 확인할 수 있습니다
상태 확인이 양수였다가
0으로 바뀌었죠
또, 몇 퍼센트의 상태 확인기가
정상으로 보고했는지
알 수 있으며 1에서 0으로 떨어졌습니다
이는 상태 확인이 비정상이라는 의미인데
이는 이 상태 확인에 연결한 장애 조치 설정 방식 때문입니다
다시 새로고침 하면 eu-central-1c가 아니라
us-east-1이어야 합니다
페이지를 새로고침 해보죠
us-east-1의 응답을 얻었습니다
장애 조치가 원활하게 실행된 것입니다
이제 끝내려면 보안 그룹으로 돌아가서
인바운드 규칙 수정에서
HTTP 규칙을 다시 추가합니다
그러면 자동으로 상태 확인이 다시 통과하게 되고
기본 위치에서 장애 조치를 실행하게 됩니다
강의가 즐거우셨길 바라요
다음 강의에서 뵙겠습니다
112. 라우팅 정책 - 지리적 위치 + 실습
이제 지리 위치(Geolocation) 라우팅 정책을 살펴보겠습니다.
지연 시간 기반의 정책과는 매우 다르게 사용자의 실제 위치를 기반으로 합니다.
예를 들어 사용자가 특정 대륙이나 국가 혹은 더 정확하게 미국의 경우에는 어떤 주에 있는지 지정하는 것이며 가장 정확한 위치가 선택되어 그 IP로 라우팅 되는 것입니다
일치하는 위치가 없는 경우는 기본 레코드를 생성해야 합니다
사용 사례로는 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화가 있습니다
이런 레코드는 상태 확인과 연결할 수 있습니다
여라 나라가 있는 유럽의 지도를 가정해보죠. 독일의 유저가 독일어 버전의 앱을 포함한 IP로 접속되도록 독일의 지리 레코드를 정의할 수 있겠죠. 프랑스의 경우라면 프랑스어의 버전의 앱을 가진 IP로 가야합니다. 그 외의 다른 곳은 앱에서 영어 버전이 포함된 기본 IP로 이동해야 합니다. 이렇게 지리 위치를 사용합니다. 이제 콘솔에서 연습해 보겠습니다.
첫 번째 지리 위치 레코드를 생성하겠습니다
레코드 생성으로 가서 이름은 geo로 입력하겠습니다
레코드 유형은 A로 하고 이쪽의 값은
ap-southeast-1의 값을 연결하겠습니다
이제 여기서 라우팅 정책을
지리 위치로 선택하고
아시아 전체로 설정합니다 그러면 아시아의 모든 사용자는
ap-southeast-1의 EC2 인스턴스로 이동해야 합니다
그리고 상태 확인과 연결할 수도 있습니다
레코드 ID도 입력하면 끝입니다
두 번째 레코드를 추가하겠습니다
이제 us-east-1의
모든 사용자를 선택하고
라우팅 정책을 지리 위치로 선택한 뒤
나라는 예로 들어
미국으로 하겠습니다
마지막으로 레코드 ID를 US로 입력합니다
이쪽은 국가를 지정했고
여기는 대륙 전체를 지정했는데 크게 상관 없습니다
마지막 레코드를 추가하겠습니다
레코드 이름을 입력하고
eu-central-1의 값을 선택하는데
이 값이 기본 레코드가 됩니다
라우팅 정책은 지리 위치로 하고 location은 기본으로 합니다
이는 아시아나 미국과 일치하지 않으면
기본 위치로 이동한다는 의미이며
레코드 ID는 Default EU로 합니다
이제 레코드를 생성합니다
모든 레코드가 성공적으로 생성됐습니다
이제 테스트해 볼 수 있겠죠?
현재 위치가 미국이나 아시아가 아닌 경우
URL을 열면 eu-central-1의 리전을 얻습니다
기본 값이라는 의미여서
제대로 작동하고 있는 것입니다
이제 지리 위치를 변경하겠습니다
이를 위해 VPN을 사용하겠습니다
아시아에 있는 국가인 인도로 선택하겠습니다
이제 인도에 연결됐습니다
이제 페이지를 새로고침 하면
ap-southeast-1 인스턴스에서 Hello World를 얻을 것입니다
보시다시피 로딩이 깁니다
시간초과가 발생하고 있네요
AWS에서 시간초과가 발생하면 보안 그룹을 확인해야 합니다
보안 그룹으로 이동하면
리전은 싱가폴로, 올바른 리전입니다
그러면 인바운드 규칙을 수정하겠습니다
상태 확인 장애 상황을 만들기 위해서
HTTP 규칙을 삭제했었죠?
그래서 다시 HTTP 규칙을 추가해야 합니다
규칙을 추가하고 CIDR blocks는 전체로 선택합니다
HTTP 규칙이 다시 추가됐습니다
다시 페이지로 돌아가면
ap-southeast-1b에서
Hello World를 얻었으므로 설정은 잘 실행되고 있습니다
이제 국가를
미국 전체로 바꾸고
새로고침 해 보면
us-east-1a에서 Hello World를 얻었습니다
이제 미국 바로 옆에 있지만
미국은 아닌 멕시코를 선택하고
새로고침하면 eu-central-1를 얻는데
이것이 기본 레코드이기 때문이며
지리 위치 Route 53 레코드에서 규칙으로 지정하지 않았기 때문입니다
아주 잘 실행되네요 강의는 여기까지입니다
113. 라우팅 정책 - 지리적 접근성
이제 또 다른 기능인 지리 근접 라우팅을 살펴보죠. 헷갈릴 수도 있지만 다음 슬라이드에 있는 도표로 명확하게 설명해 보겠습니다.
이는 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅하도록 합니다
이 정책으로 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동하는 것입니다. 바로 다음 슬라이드에서 보여드리겠습니다
따라서 지리적 위치를 변경하려면 편향값을 지정해야 합니다
- 특정 리소스에 더 많은 트래픽을 보내려면 편향값을 증가시켜서 확장하면 됩니다
- 리소스에 트래픽을 줄이려면 편향값을 음수로 축소시키면 됩니다
리소스는 AWS의 리소스로 속한 특정 리전을 지정하면
- 목록에서 자동으로 올바른 라우팅을 계산하거나
- AWS 리소스가 아닌 온프레미스 데이터 센터인 경우 위도와 경도를 지정해서 AWS가 위치를 파악하도록 해야 합니다
그리고 기능을 선택하는데 편향 활용을 위해 고급 Route 53 트래픽 플로우를 사용합니다.
이 도표로 쉽게 이해할 수 있습니다. 꼭 기억하시기 바랍니다.
us-west-1의 리소스와 us-east-1 리소스를 예로 들어 보죠. 각 리전의 편향값은 0으로 설정됐습니다. 이는 미국 전역에 사용자가 이 리소스에 액세스를 시도하며 미국을 둘로 나눈다는 뜻입니다. 왼쪽의 사용자는 us-west-1로 이동하고 오른쪽 사용자는 us-east-1로 이동합니다. 편향이 없기 때문에 이 상황은 아주 간단합니다. 사용자 위치에서 가장 가까운 리소스 리전으로 이동하는 것입니다.
하지만 편향으로 인해 동일한 설정이지만 다른 방식으로 사용자를 다른 리전으로 라우팅할 수 있습니다. 예를 들어 보죠. us-west-1과 us-east-1이 있고 us-west-1의 편향값은 0이고 us-east-1의 50이라는 양수의 편향값을 가집니다. 그리고 편향으로 해당 리소스에 더 많은 사용자와 트래픽이 발생됩니다. 그 이유는 편향으로 2가지 리소스 사이의 분할 선이 조금씩 왼쪽으로 이동하는 것이며 이는 us-east-1의 편향이 더 높기 때문입니다. 이는 왼쪽의 사용자는 us-west-1으로 이동하고 오른쪽의 사용자는 us-east-1으로 이동한다는 것입니다
왜 그럴까요? 예를 들어, 전 세계로 리소스를 설정하고 특정 리전에 더 많은 트래픽을 더 보내야 한다고 하면 지리 근접 라우팅 정책을 사용해 특정 리전의 편향을 증가시키면 더 많은 사용자가 생기게 되고 특정 리전에 더 많은 트래픽이 발생하게 됩니다. 시험에 대비해 기억해야 할 것은 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다는 것입니다. 지리 근접 라우팅 정책을 이해하는데 이 도표가 도움이 됐길 바랍니다.
114. 라우팅 정책 - 트래픽 Flow 및 지리적 근접성 실습 + 실습
트래픽 플로우라는 기능으로 복잡한 지리 근접 레코드를 설계하는 방법에 관해 살펴보겠습니다.
이는 지리 근접성뿐만 아니라 모든 것에 적용됩니다
UI라는 비주얼 에디터로 복잡한 라우팅 의사 결정 트리를 관리하는 것입니다.
이것이 바로 UI이고 다른 규칙을 지정해 여러 가지를 시도해 보겠습니다. 이는 Route 53에 있는 DNS 관리 시스템에 하나씩 기록하는 대신 모두 시각적으로 관리하는 것입니다
좋은 점은 트래픽 플로우 정책으로 저장된다는 것입니다
- 버전을 지정하고 호스팅 영역을 적용할 수 있으며
- 호스팅 영역에서 쉽게 변경하고 적용할 수 있습니다
실습을 통해서 방법을 살펴보죠
시작하겠습니다
왼쪽의 패널의
Traffic policies에 있는
UI에서 트래픽 정책을 생성할 수 있습니다
이름은 DemoGeoPolicy로 하고 Next를 클릭합니다
여기 시작점이 있는데
생성하고자 하는 레코드 유형을 지정할 수 있습니다
A, AAAA, CNAME 등이 있습니다
각 레코드의 상세 사항을 제공하죠
A 레코드로 선택하고 특정 규칙과 연결해야 합니다
규칙의 종류는 가중치 규칙과
장애 조치, 지리적 지연 시간 규칙과
다중 값, 지리 근접성 또는 엔드 포인트 규칙이 있습니다
예를 들어, 아주 간단한
엔드 포인트를 지정하려면
A 레코드로는 이쪽의 값을 가리키도록 하고
값은 12.34.56.78로 하면
아주 간단한 레코드가 됩니다
하지만 더 복잡한 정책도 생성할 수 있습니다
가중치 규칙에 연결해서
여러 가중치를 지정할 수 있습니다
가중치를 10으로 하고
장애 조치 등과 같은 고급 레코드를 지정할 수 있습니다
정말 복잡하게 생성할 수 있죠
준비되면 엔드 포인트를 클릭해
원하는 IPv4의 값을 지정하면 됩니다
오늘은 복잡하게 설계하지 않으므로
가중치 규칙을 예로 들면
다른 가중치를 추가하는 정도입니다
모두 시각적이며
Route 53에서 일어나는 일을 이해할 수 있도록 하죠
가중치 규칙은 생성하지 않고
지리 근접 규칙을 생성하겠습니다
설계에 관한 시각적 피드백을 얻기 위해
지도도 보여드리겠습니다
첫 번째 리전을 입력해야
두 번째 리전을 추가할 수 있습니다
이제 엔드 포인트 위치에서
사용자 정의로 좌표를 설정하거나
AWS에서 제공한 것 중 하나의 리전을 선택할 수 있습니다
생성된 리전 중 하나를 사용하겠습니다
US East로 선택하고 편향 값을 지정하겠습니다
지금은 맵의 창을
닫도록 하겠습니다
이제 이 레코드는 새 엔드 포인트와 연결되며
값은 제 us-east-1의 EC2 인스턴스로 하겠습니다
이쪽에 값을 붙여 놓으면 끝입니다
편향 값은 0으로 두겠습니다
두 번째 리전에서는 좌표를 입력하겠습니다
ap-southeast-1인 싱가포르를 입력해 보죠
다시 입력하겠습니다
그리고 새 엔드 포인트와 연결되는데
ap-southeast-1의 IP 주소를 갖는 엔드 포인트입니다
이제 Enter를 누르면 끝입니다
이제 정책을 생성했으니 맵을 살펴보겠습니다
맵 아이콘을 클릭해서 볼 수 있습니다
이 지리 근접 맵에서는
입력 값을 기반으로 어떤 사용자가
어떤 인스턴스로 이동하는지 보여줍니다
만약에 파란색 쪽에 있으면
보시다시피 여기 양쪽을 나누는 선이 있는데
첫 번째 인스턴스로 이동하는 것입니다
그리고 붉은색 쪽에 있으면 두 번째 인스턴스로 이동합니다
그리고 편향 값을 변경하면
예를 들어, 인스턴스의 편향 값을 34로 입력하면
북미의 인스턴스로 리디렉션 되는
면접이 증가하게 됩니다
편향 값을 음수로 줄이면
반대 현상이 나타납니다
더 많은 트래픽이 2번 인스턴스로 집중됩니다
여러 시도를 할 수 있고 시각적인 측면을 가질 수 있죠
좋은 것은 2개 이상의 인스턴스를 고려할 수 있는 것입니다
물론, 지리 근접 위치를 더 추가할 수 있으며
자세히 살펴보기 위해 Frankfurt로 설정해 보겠습니다
그러면 새로운 맵이 생기고
여러 편향 값으로
편향이 지리 근접 맵에 미치는 영향을 확인할 수 있습니다
그리고 프랑크푸르트는 새 엔드 포인트를 갖고
eu-central-1을 붙여 넣겠습니다
그리고 트래픽 정책을 생성하죠
정책을 생성했으니
정책 레코드로 트래픽 정책을 배포해야 합니다
그러려면 이 트래픽 정책을
이 호스트 영역으로 배포해야 하고
정책 레코드 이름을 설정해야 하는데
이름 입력 칸에 proximity를 입력하겠습니다
그리고 TTL을 지정합니다
그리고 중요한 부분은 가격으로 한 달에 50달러입니다
이 정책 레코드를 생성하면 월별로 50달러를 내야 합니다
유지하는 기간에 비례하지만
프리 티어로만 진행하려면 생성하면 안 됩니다
저도 보여 드리기 위해 생성하고
바로 삭제하겠습니다
그러니 끝까지 하지 않아도 됩니다
이 정책 레코드를 생성하면
여기서 보시다시피 정책 버전이 있습니다
그리고 정책을 수정해서
새로운 버전으로 배포할 수 있죠
이제 DemoGeoPolicy라는 레코드가 생성된 것을
확인할 수 있습니다
그리고 다시 맵을 살펴보면 원리를 이해할 수 있습니다
이쪽의 지리 근접 규칙을 클릭하고
새 버전으로 수정한 뒤 다시 맵을 클릭합니다
여기서 보시는 것처럼 프랑스에 있는 경우
이 인스턴스에 연결할 수 있습니다
브라질에 있다면 이 인스턴스에 연결되죠
예를 들어, 인도에 있다면 이 리전에 연결됩니다
레코드를 테스트해서 잠시 후 확인해 보겠습니다
이제 취소하고 생성될 때까지 기다리겠습니다
이제 정책 레코드가 적용됐습니다
보시다시피 사용된 버전은 1입니다
그래서 제가 있는 유럽에서 연결하면
eu-central-1을 얻습니다
브라질로 변경하고 페이지를 새로고침 하면
미국의 인스턴스에 연결되어야 합니다
잠시 후에 볼 수 있습니다
마지막으로 아시아에 연결하죠
태국을 예로 들어
변경해 보겠습니다
새로고침 하면 ap-southeast-1b 인스턴스를 얻습니다
좋습니다
다시 Route 53으로 가서 새로고침 하고
필터에 proximity를 입력하면
이 근접 레코드 자체가
트래픽 정책 레코드에 바로 라우팅 됩니다
이 레코드를 수정하는 방법은 이쪽의 수정을 클릭하면
트래픽 정책 UI에서 수정할 수 있습니다
강의는 여기까지입니다
이제 비용을 지불하지 않으려면
이 정책 레코드를 삭제해야 매달 50달러의 비용을 내지 않게 됩니다
즐거우셨길 바랍니다
115. 라우팅 정책 - 다중 값 + 실습
마지막 라우팅 정책인 다중 값을 살펴보겠습니다
트래픽을 다중 리소스로 라우팅할 때 사용합니다
그래서 Route 53은 다중 값과 리소스를 반환합니다
그리고 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있습니다
각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환됩니다.
ELB와 유사해 보이지만 ELB를 대체할 수는 없습니다. 클라이언트 측면의 로드 밸런싱인 것입니다
예시를 살펴보겠습니다. example.com에서 다중 A 레코드를 설정하고 상태 확인과 연결하겠습니다. 클라이언트에서 다중 값 쿼리를 실행하면 최대 8개의 레코드를 수신하게 되고 클라이언트는 하나를 선택합니다. 하지만 최소한 상태 확인과 결합하면 반환되는 8개 레코드 중 1개 혹은 최대 8개의 레코드가 정상일 것을 알고 있습니다. 그래서 클라이언트는 안전한 쿼리를 가질 수 있죠
이 예시는 조금 다릅니다 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있습니다. 바로 다중 값이 조금 더 강력한 레코드 유형인 이유입니다.
이제 UI에서 테스트하는 방법을 살펴보겠습니다
다중 값 레코드를 연습해 보겠습니다
다중 레코드를 생성하는데 이름 칸에 multi를 입력합니다
그리고 us-east-1의 값을 연결하겠습니다
해당 값을 입력하고
라우팅 정책은 다중 값으로 하고
상태 확인은 us-east-1입니다
그리고 레코드 ID는 US로 합니다
TTL은 60초로 설정하겠습니다
다른 레코드도 추가하죠
이름 칸에 multi를 입력하고 다른 리전인 ap-southeast-1을
라우팅하겠습니다
라우팅 정책은 다중 값으로 하고
상태 확인은 ap-southeast-1로 합니다
그리고 레코드 ID는 Asia로 하겠습니다
또, TTL은 1분으로 하겠습니다
이제 마지막 레코드를 추가하겠습니다
다시 이름을 입력하고
eu-central-1의 값을 연결하겠습니다
TTL은 1분이고
라우팅 정책은 다중 값으로 합니다
상태 확인은 eu-central-1의 값을 사용하겠습니다
그리고 레코드 ID는 EU입니다
이제 레코드를 모두 생성하죠
레코드가 성공적으로 생성됐으니
테스트해 보겠습니다
CloudShell을 사용해 테스트합니다
다시 CloudShell로 연결합니다
이제 이 레코드를 테스트해 보겠습니다
이 레코드를 복사하고 스크린을 정리하겠습니다
그리고 레코드를 테스트하면 3개의 응답을 얻습니다
3개의 IP 주소가 반환됐죠
3개의 상태 확인이 완전히 실행되고 있기 때문입니다
보시다시피 모두 정상입니다
이제 eu-central-1을 예로 들어 삭제한 뒤
비정상으로 만들겠습니다
수정에서 상태 확인 반전으로 변경하는 것입니다
정상에서 비정상 혹은 반대로 변경할 수 있죠
이런 식으로 빠르게 상태 확인을 비정상으로 만들 수 있습니다
잠시 기다리겠습니다
이제 eu-central-1의 상태 확인이 비정상입니다
여기서 dig 명령문을 다시 실행하면
2개의 값을 얻게 될 것입니다
다중 값이 제대로 실행됐네요
다시 반전하려면 상태 확인 수정에서
상태 확인 상태 반전을 선택 해제하면 됩니다
강의는 여기까지입니다
즐거우셨길 바랍니다 다음 강의에서 뵙겠습니다
116. 타사 도메인 및 Route 53
도메인 이름 레지스트라 DNS 서비스를 구별해 보도록 하겠습니다
도메인 이름 레지스트라를 통해 원하는 도메인 이름을 구매할 수 있습니다. 매년 비용을 지불해야 하죠. 지금까지의 강의에서는 Route 53 콘솔을 통한 Amazon 레지스트라를 이용했습니다. 하지만 다른 도메인 이름 레지스트라를 이용해도 괜찮습니다. GoDaddy나 Google 도메인 등이죠
대게 레지스트라를 통해 도메인을 등록하면 DNS 레코드 관리를 위한 DNS 서비스를 제공합니다. 그래서 Amazon 호스트 이름으로 DNS 이름을 등록했다면 DNS 레코드 관리를 위한 Route 53 호스팅 존을 가집니다.
하지만 DNS 레코드로 AWS Route 53 등을 사용하지 않고 Amazon 레지스트라를 사용하거나
반대로 GoDaddy로 도메인을 등록해도 됩니다. example.com에서 구매하고 DNS 레코드는 Amazon의 Route 53으로 관리하면 아주 완벽히 허용되는 조합입니다
어떻게 할까요? GoDaddy에서 도메인을 등록하면 이름 서버 옵션이 생기는데 사용자 정의 이름 서버를 지정할 수 있습니다.
어떻게 지정할까요? 먼저 Amazon Route 53에서 원하는 도메인의 공용 호스팅 영역을 생성하고 호스팅 영역 상세의 오른쪽 부분에서 이름 서버를 찾습니다.여기 있는 4개의 이름 서버는
GoDaddy 웹사이트에서 변경해야 합니다. 이제 GoDaddy에서 사용할 이름 서버에 관한 쿼리에 응답하면 이름 서버가 Amazon의 Route 53 이름 서버를 가리키고 그렇게 Amazon Route 53을 사용해서 해당 콘솔에서 직접 전체 DNS 레코드를 관리합니다.
다시 정리하자면, 도메인을 타사 등록 대행사에서 구매해도 DNS 서비스 제공자로 Route 53을 사용 가능한데
1. 사용하려면 Route 53에서 공용 호스팅 영역을 생성한 뒤
2. 도메인을 구매한 타사 웹사이트에서 NS 혹은 이름 서버를 업데이트하면 Route 53 이름 서버를 가리키게 됩니다
그래서 도메인 이름 레지스트라는 모두 비슷해 보이지만 DNS 서비스가 다릅니다
모든 도메인 이름 레지스트라가 일부 DNS 기능을 제공하더라도 말이죠
