Registrar, 네임서버, ACM DNS 검증 흐름
Route 53에서 도메인을 구매하면 Registrar, 등록자 정보, 네임서버, Hosted Zone, DNS Record 관리가 하나의 흐름으로 연결됩니다. 여기에 ACM 인증서를 붙이려면 DNS 검증용 CNAME 레코드를 정확히 만들고, 도메인 소유권 검증과 인증서 자동 갱신 조건을 이해해야 합니다.
Route 53 도메인 구매와 ACM 인증서 연결 흐름을 설명합니다. Registrar, Hosted Zone, 네임서버 위임, WHOIS, 도메인 소유권 인증, ACM DNS CNAME 검증을 정리합니다.
도메인을 구매한다는 것의 의미
도메인을 구매한다는 것은 인터넷에서 사용할 이름을 일정 기간 등록한다는 의미입니다. 정확히는 도메인을 영구 소유하는 것이 아니라 등록 기간 동안 사용할 권리를 확보하는 것입니다.
예를 들어 `example.com`을 등록하면 해당 도메인의 등록자 정보와 네임서버 정보가 상위 도메인 체계에 반영됩니다. 이후 사용자는 DNS 질의를 통해 이 도메인을 어느 네임서버가 관리하는지 찾습니다.
Route 53은 도메인 등록과 DNS 관리를 함께 제공할 수 있습니다. 도메인을 Route 53에서 등록하면 Hosted Zone을 만들고, 그 안에 웹사이트, API, 메일, 인증서 검증용 레코드를 관리할 수 있습니다.
Registrar, Registry, Registrant 차이
도메인 등록 구조를 이해하려면 Registrar, Registry, Registrant를 구분해야 합니다. Registry는 `.com`, `.net`, `.org` 같은 최상위 도메인을 운영하는 주체입니다.
Registrar는 사용자가 도메인을 등록할 수 있게 해주는 등록 대행자입니다. Route 53은 지원하는 TLD에 대해 도메인 등록 기능을 제공합니다.
Registrant는 도메인을 등록한 소유자입니다. 도메인 분쟁, 이전, 만료, 인증 절차에서 등록자 정보는 중요한 기준이 됩니다.
| 구분 | 역할 | 예시 |
|---|---|---|
| Registry | 최상위 도메인 운영 | .com, .net, .org 운영 주체 |
| Registrar | 도메인 등록 대행 | Route 53, 외부 도메인 업체 |
| Registrant | 도메인 등록자 | 회사 또는 개인 |
| Name Server | DNS 질의 응답 서버 | Route 53 NS |
| Hosted Zone | DNS 레코드 컨테이너 | example.com Zone |
Route 53에서 도메인 등록하는 흐름
Route 53에서 도메인을 등록할 때는 먼저 원하는 도메인을 검색해 사용 가능 여부를 확인합니다. 사용 가능하면 등록 기간, 자동 갱신, 등록자 연락처를 설정합니다.
AWS 공식 문서 기준 도메인 이름은 등록 후 변경할 수 없습니다. 철자, TLD, 브랜드 표기, 하이픈 여부를 등록 전에 반드시 확인해야 합니다.
도메인 등록 후에는 등록자 이메일 검증이 필요할 수 있습니다. 이 검증을 완료하지 않으면 정책에 따라 도메인이 정지될 수 있으므로 등록자 이메일은 반드시 수신 가능한 주소여야 합니다.
Hosted Zone과 네임서버 연결
Hosted Zone은 도메인의 DNS 레코드를 담는 컨테이너입니다. Route 53에서 `example.com` Hosted Zone을 만들면 `www.example.com`, `api.example.com` 같은 레코드를 추가할 수 있습니다.
중요한 점은 도메인 등록 정보의 네임서버가 실제 사용할 Hosted Zone의 NS 값과 일치해야 한다는 것입니다. Hosted Zone을 새로 만들었는데 Registrar의 네임서버가 예전 DNS를 가리키면 Route 53 레코드는 응답되지 않습니다.
외부 Registrar에서 구매한 도메인도 Route 53에서 DNS를 운영할 수 있습니다. 이 경우 Route 53 Public Hosted Zone을 만들고, 외부 Registrar에서 네임서버를 Route 53 NS로 변경해야 합니다.
| 상황 | 해야 할 일 | 주의사항 |
|---|---|---|
| Route 53에서 도메인 구매 | Hosted Zone과 NS 확인 | 자동 생성 Zone과 사용 Zone 혼동 주의 |
| 외부 Registrar 사용 | Route 53 NS로 위임 | Registrar 콘솔에서 NS 변경 |
| 새 Hosted Zone 생성 | 도메인 NS를 새 Zone NS로 변경 | 기존 Zone 방치 주의 |
| 기존 DNS 이전 | 레코드 복사 후 NS 변경 | 메일·인증 레코드 누락 방지 |
| 서브도메인 위임 | 부모 Zone에 NS 레코드 추가 | 하위 Zone 관리 분리 |
WHOIS와 등록자 정보 관리
도메인을 등록할 때 입력하는 등록자 정보는 단순한 연락처가 아닙니다. 도메인 소유권, 이전, 갱신, 분쟁, 검증 절차의 기준이 됩니다.
일부 TLD는 WHOIS 개인정보 보호를 지원합니다. 하지만 TLD 정책에 따라 공개 범위가 다를 수 있고, 등록자 이메일 검증은 여전히 중요합니다.
운영 도메인은 개인 이메일보다 조직에서 관리하는 메일 주소를 사용하는 것이 좋습니다. 담당자 퇴사나 메일 비활성화로 갱신·검증 알림을 놓치면 서비스 장애로 이어질 수 있습니다.
도메인 등록자 이메일은 갱신, 검증, 이전 승인에 사용됩니다. 조직 도메인은 개인 메일이 아니라 관리 가능한 공용 메일로 운영하는 것이 안전합니다.
도메인 소유권 인증이 필요한 이유
도메인 소유권 인증은 특정 사람이 해당 도메인의 DNS를 제어할 권한이 있는지 확인하는 절차입니다. 인증서 발급, SaaS 연결, 검색엔진 등록, 메일 서비스 설정에서 자주 사용됩니다.
가장 흔한 방식은 DNS 레코드 검증입니다. 서비스 제공자가 고유한 TXT 또는 CNAME 값을 제공하고, 사용자가 해당 값을 DNS Zone에 추가하면 소유권을 증명할 수 있습니다.
이 방식은 DNS 레코드를 수정할 수 있는 사람이 도메인 관리 권한을 가진다고 보기 때문에 가능합니다. 따라서 Route 53 레코드 변경 권한은 보안상 중요한 권한입니다.
| 인증 방식 | 사용 예시 | 특징 |
|---|---|---|
| TXT 검증 | 검색엔진, SaaS 도메인 인증 | 문자열 토큰 추가 |
| CNAME 검증 | ACM DNS 검증 | 검증용 이름을 인증 도메인으로 연결 |
| Email 검증 | 인증서 이메일 검증 | 관리자 메일 수신 필요 |
| HTTP File 검증 | 일부 서비스 인증 | 웹 서버 파일 업로드 |
| Registrar 확인 | 도메인 이전 | 이전 잠금과 승인 코드 확인 |
ACM 인증서와 DNS 검증 방식
AWS Certificate Manager는 TLS 인증서를 발급하고 관리하는 서비스입니다. ALB, CloudFront, API Gateway 같은 서비스에 HTTPS를 적용할 때 ACM 인증서를 자주 사용합니다.
ACM 퍼블릭 인증서를 요청하면 도메인 검증 방식으로 DNS 검증 또는 이메일 검증을 선택할 수 있습니다. 운영 환경에서는 자동 갱신이 쉬운 DNS 검증을 주로 사용합니다.
DNS 검증을 선택하면 ACM은 도메인별 CNAME 레코드 이름과 값을 제공합니다. 이 레코드를 Route 53 Hosted Zone에 추가하면 ACM이 도메인 소유권을 확인하고 인증서를 발급합니다.
| 항목 | 의미 | 주의사항 |
|---|---|---|
| Certificate Domain | 인증서 대상 도메인 | example.com, *.example.com |
| Record Name | 검증용 CNAME 이름 | Hosted Zone에 정확히 추가 |
| Record Value | ACM 검증 대상 도메인 | acm-validations.aws 형태 |
| Validation Status | 검증 상태 | Pending validation 확인 |
| Renewal | 자동 갱신 | 검증 CNAME 유지 필요 |
ACM 인증서는 리전에 주의해야 한다
ACM 인증서는 사용하는 AWS 서비스와 리전 관계를 확인해야 합니다. ALB에 연결할 인증서는 ALB가 있는 리전에서 발급해야 합니다.
CloudFront에 사용할 ACM 인증서는 반드시 미국 동부 버지니아 북부 리전, 즉 `us-east-1`에서 발급해야 합니다. 이 부분을 놓치면 인증서를 만들었는데 CloudFront에서 선택되지 않는 문제가 생깁니다.
도메인 검증용 CNAME은 인증서 리전과 무관하게 해당 도메인의 DNS Zone에 등록합니다. 같은 도메인에 대해 여러 리전 인증서를 만들 때도 ACM이 제공하는 검증 레코드가 같거나 재사용 가능한 경우가 있으므로 레코드를 함부로 삭제하지 않는 것이 좋습니다.
CloudFront용 ACM 인증서는 us-east-1에서 발급해야 합니다. ALB용 인증서는 ALB가 있는 리전에서 발급해야 합니다.
TXT와 CNAME 인증 레코드 이해
도메인 인증에는 TXT와 CNAME이 많이 사용됩니다. TXT는 특정 문자열 값을 DNS에 올려 소유권을 증명하는 방식이고, CNAME은 검증용 이름을 서비스 제공자가 지정한 도메인으로 연결하는 방식입니다.
ACM DNS 검증은 CNAME을 사용합니다. Record Name과 Record Value를 정확히 입력해야 하며, DNS 공급자마다 전체 도메인을 넣는 방식이 다를 수 있습니다.
잘못 입력하면 `_abc.example.com.example.com`처럼 도메인이 중복되어 검증이 실패할 수 있습니다. Route 53 콘솔에서 ACM이 제공하는 레코드를 자동 생성할 수 있다면 그 방식을 사용하는 것이 안전합니다.
도메인 이전과 네임서버 변경 시 주의사항
운영 중인 도메인의 DNS를 Route 53으로 이전할 때는 기존 DNS 레코드를 모두 확인해야 합니다. 웹, API, 메일, TXT 인증, SPF, DKIM, DMARC, ACM 검증 레코드를 빠뜨리면 장애가 발생할 수 있습니다.
권장 절차는 기존 레코드 인벤토리, TTL 낮추기, Route 53 Hosted Zone 생성, 레코드 복사, 테스트, 네임서버 변경, 전파 확인 순서입니다.
네임서버 변경은 즉시 전 세계에 반영되지 않습니다. 전파 기간에는 기존 DNS와 새 DNS가 함께 조회될 수 있으므로 양쪽 레코드가 일관되게 유지되는지 확인해야 합니다.
| 단계 | 작업 | 확인할 것 |
|---|---|---|
| 1 | 기존 DNS 레코드 백업 | A, CNAME, MX, TXT, CAA |
| 2 | TTL 낮추기 | 전환 전 캐시 시간 단축 |
| 3 | Route 53 Hosted Zone 생성 | NS 값 확인 |
| 4 | 레코드 복사 | 메일·인증 레코드 포함 |
| 5 | 네임서버 변경 | Registrar에서 Route 53 NS로 위임 |
| 6 | 전파 확인 | 여러 Resolver에서 응답 확인 |
이 글은 Amazon Route 53 Developer Guide의 도메인 등록, 기존 도메인 DNS 이전, AWS Certificate Manager DNS validation 공식 문서를 기준으로 작성했습니다.
SUMMARY
FAQ
Route 53에서 도메인을 사면 바로 웹사이트가 연결되나요?
아닙니다. 도메인 등록 후 Hosted Zone에 A, Alias, CNAME 같은 레코드를 만들어 실제 웹사이트나 CloudFront, ALB로 연결해야 합니다.
ACM DNS 검증용 CNAME은 인증서 발급 후 삭제해도 되나요?
권장하지 않습니다. DNS 검증 CNAME을 유지해야 ACM 인증서 자동 갱신과 재검증이 안정적으로 동작합니다.
CloudFront에서 ACM 인증서가 보이지 않는 이유는 무엇인가요?
CloudFront용 ACM 인증서는 us-east-1 리전에서 발급해야 합니다. 다른 리전에서 발급한 인증서는 CloudFront 배포 설정에서 선택되지 않습니다.
Route 53에서 도메인을 구매하고 ACM 인증서를 연결하는 과정은 도메인 등록, 네임서버 위임, Hosted Zone 레코드 관리, 도메인 소유권 검증이 이어지는 흐름입니다. 도메인을 등록했다고 HTTPS 서비스가 완성되는 것은 아닙니다. 실제 사용할 Hosted Zone의 NS가 도메인 등록 정보와 맞아야 하고, ACM이 제공한 DNS CNAME 검증 레코드가 정확히 등록되어야 합니다. 특히 CloudFront용 인증서는 us-east-1에서 발급해야 하며, 운영 중인 도메인을 이전할 때는 기존 DNS 레코드와 TTL, 메일 인증 레코드까지 함께 점검해야 합니다.
'AWS Guides' 카테고리의 다른 글
| S3 웹 접근 설정 이해: CORS와 정적 웹사이트 호스팅은 언제 필요한가 (0) | 2026.07.04 |
|---|---|
| S3 버킷 생성 옵션 해설: 객체 소유권, 퍼블릭 액세스 차단, 버전 관리, 암호화, 객체 잠금 설정 기준 (0) | 2026.07.04 |
| CloudFront + AWS WAF 보안 구성 베스트 프랙티스: CDN 앞단에서 웹 공격과 비정상 트래픽을 막는 방법 (0) | 2026.07.04 |
| CloudFront와 Route 53 관계 이해: 도메인, Alias Record, ACM 인증서로 CDN에 연결하는 방법 (0) | 2026.07.04 |
| Amazon Route 53이란 무엇인가: DNS, Hosted Zone, Record, Resolver 기본 구조 이해하기 (0) | 2026.07.04 |