안녕하세요.
이번 시간에는 AWS에서 Route 53 레코드 마이그레이션 방법에 대한 가이드를 작성하도록 하겠습니다.
1. 개요

DNS는 인터넷의 전화번호부와 같은 역할을 하는 핵심 인프라입니다. 기업이 성장하고 인프라가 변화함에 따라 DNS 레코드를 다른 호스팅 존이나 계정으로 마이그레이션해야 하는 상황이 자주 발생합니다. 특히 AWS Route 53을 사용하는 환경에서는 서비스 통합, 계정 통합, 또는 인프라 재구성으로 인해 DNS 레코드 마이그레이션이 필요한 경우가 많습니다.
DNS 마이그레이션은 단순해 보이지만 잘못 수행할 경우 서비스 중단, 이메일 전달 실패, 웹사이트 접속 불가 등 심각한 문제를 야기할 수 있습니다. 따라서 체계적이고 안전한 마이그레이션 전략이 필수적입니다.
이 가이드에서는 AWS Route 53에서 DNS 레코드를 안전하고 효율적으로 마이그레이션하는 방법을 단계별로 상세히 다루겠습니다.
2. 마이그레이션 사전 준비
1. 현재 DNS 레코드 파악
마이그레이션을 시작하기 전에 반드시 기존 DNS 레코드를 완전히 파악해야 합니다.
AWS CLI를 사용한 레코드 조회
# 호스팅 존 목록 조회
aws route53 list-hosted-zones
# 특정 호스팅 존의 모든 레코드 조회
aws route53 list-resource-record-sets --hosted-zone-id {Hosted-Zone-id} --output table
# JSON 형태로 레코드 백업
aws route53 list-resource-record-sets --hosted-zone-id {Hosted-Zone-id} > dns-backup.json
다음과 같이 테이블 형태로 모든 레코드를 조회하거나 콘솔에서 레코드를 파악한 후 json 형태로 파일을 내보내기 합니다.
중요한 레코드 유형 확인:
- A 레코드: 웹사이트, API 엔드포인트
- CNAME 레코드: 서브도메인 매핑
- MX 레코드: 이메일 서버 설정
- TXT 레코드: SPF, DKIM, 도메인 검증
- NS 레코드: 네임서버 정보
- SOA 레코드: 도메인 권한 정보
마이그레이션 24-48시간 전에 TTL(Time To Live) 값을 최소화하여 DNS 변경사항이 빠르게 전파되도록 합니다.
1. 영역 가용성 모니터링
2. TTL 설정 낮추기
3. 상위 영역에서 DS 레코드 제거(DNSSEC가 구성된 경우)
4. 마이그레이션 호스팅 영역에 의존하는 다른 진행 중인 작업이나 서비스가 없는지 확인
= 네임 서버를 넘길 경우 의존 중인 서비스에서 문제가 발생할 수 있으니 넘기기 전에 해당 호스팅 영역에 의존 중인 작업이나 서비스가 있는지 반드시 확인해야 합니다.
3. 마이그레이션 방법
https://docs.aws.amazon.com/ko_kr/Route53/latest/DeveloperGuide/hosted-zones-migrating.html
호스팅 영역을 다른 AWS 계정으로 마이그레이션 - Amazon Route 53
하나 이상의 별칭 레코드가 다른 별칭 레코드를 참조하는 경우 별칭 대상인 레코드는 파일에서 참조하는 별칭 레코드 앞에 나와야 합니다. 예를 들어, alias.example.com이 alias.alias.example.com의 별칭
docs.aws.amazon.com
AWS 레코드 마이그레이션에 대한 공식 문서입니다. 내용을 보면 내보내기 한 파일을 그대로 가져올 수 없기 때문에 자동화하지 않으면 사용자 공수가 상당히 많이 발생하게 됩니다.
1. 새 호스팅 영역 생성
호스팅 영역을 마이그레이션 하려는 계정에 새 호스팅 영역을 생성합니다. 콘솔이나 아래 CLI 명령어를 통해 새 호스팅 영역을 생성합니다.
aws route53 create-hosted-zone \
--name $hosted_zone_name \
--caller-reference $unique_string
위에서 새 호스팅 영역을 생성하셨고, json 파일을 내보내기 하셨다면 이제 json 파일을 가공해야 합니다.
2. json 파일 가공
{
"Comment": "string",
"Changes": [
{
"Action": "CREATE",
"ResourceRecordSet":{
"ResourceRecords": [
{
"Value": "192.0.2.4"
},
{
"Value": "192.0.2.5"
},
{
"Value": "192.0.2.6"
}
],
"Type": "A",
"Name": "route53documentation.com.",
"TTL": 300
}
},
{
"Action": "CREATE",
"ResourceRecordSet":{
"AliasTarget": {
"HostedZoneId": "Z3BJ6K6RIION7M",
"EvaluateTargetHealth": false,
"DNSName": "s3-website-us-west-2.amazonaws.com."
},
"Type": "A",
"Name": "www.route53documentation.com."
}
}
]
}
- 파일 상단의 ResourceRecordSets 요소를 Changes 요소로 바꿉니다.
- 선택 사항 - Comment 요소를 추가합니다.
- 호스팅 영역 이름의 NS 및 SOA 레코드와 관련된 줄을 삭제합니다. 새 호스팅 영역에 이미 해당 레코드가 있습니다.
- 각 레코드에 대해 Action 및 ResourceRecordSets 요소를 추가하고 필요에 따라 열기 및 닫기 대괄호({ })를 추가하여 JSON 코드를 유효하게 만듭니다.
다음과 같이 서식을 지정하지 않으면 Route 53에서 레코드를 정상적으로 가져오지 않습니다.

빨간색으로 표시된 부분이 가장 중요합니다.
4. 마이그레이션 파일 자동화 방법
1. AWS CLI 스크립트와 CDK를 이용한 자동화
import boto3
import json
import time
def migrate_dns_records(source_zone_id, target_zone_id):
route53 = boto3.client('route53')
# 소스 존에서 레코드 가져오기
response = route53.list_resource_record_sets(HostedZoneId=source_zone_id)
records = response['ResourceRecordSets']
# NS, SOA 레코드 제외 (자동 생성되므로)
filtered_records = [
record for record in records
if record['Type'] not in ['NS', 'SOA']
or record['Name'] != target_domain_name
]
# 배치 단위로 레코드 생성
batch_size = 100
for i in range(0, len(filtered_records), batch_size):
batch = filtered_records[i:i+batch_size]
changes = [{'Action': 'CREATE', 'ResourceRecordSet': record} for record in batch]
try:
route53.change_resource_record_sets(
HostedZoneId=target_zone_id,
ChangeBatch={'Changes': changes}
)
print(f"배치 {i//batch_size + 1} 완료")
time.sleep(1) # API 제한 고려
except Exception as e:
print(f"오류 발생: {e}")
# 개별 레코드로 재시도 로직 추가
다음과 같이 위 지정 양식에 맞춰 CLI와 CDK를 이용하여 수정 가능합니다.
장점: 대량의 레코드 처리에 효율적, 반복 가능
단점: 스크립트 작성 및 테스트 필요
2. Terraform을 이용한 IaC
# 기존 레코드를 Terraform으로 import
resource "aws_route53_record" "example_a" {
zone_id = aws_route53_zone.new_zone.zone_id
name = "example.com"
type = "A"
ttl = 300
records = ["192.0.2.1"]
}
resource "aws_route53_record" "www_cname" {
zone_id = aws_route53_zone.new_zone.zone_id
name = "www.example.com"
type = "CNAME"
ttl = 300
records = ["example.com"]
}
# MX 레코드 예시
resource "aws_route53_record" "mx" {
zone_id = aws_route53_zone.new_zone.zone_id
name = "example.com"
type = "MX"
ttl = 300
records = [
"10 mail.example.com",
"20 mail2.example.com"
]
}
다음과 같이 테라폼을 이용해서 코드형 인프라로 구성할 수도 있습니다. 다만 의존성 및 초기 설정이 복잡할 수 있습니다.
장점: 버전 관리, 롤백 가능, 문서화
단점: Terraform 학습 필요, 초기 설정 복잡
5. 중요도가 낮은 레코드부터 순차적인 마이그레이션
aws route53 change-resource-record-sets --hosted-zone-id Z987654321 --change-batch '{
"Changes": [{
"Action": "CREATE",
"ResourceRecordSet": {
"Name": "test.example.com",
"Type": "A",
"TTL": 60,
"ResourceRecords": [{"Value": "192.0.2.100"}]
}
}]
}'
중요도가 낮은 서브 도메인부터 순차적으로 마이그레이션 하거나 사전에 미리 테스트하여 본 마이그레이션 시 발생할 수 있는 문제를 예방할 수 있습니다. 물론 네임 서버가 변경되지 않았기 때문에 변경하기 전에는 따로 영향도가 없을 테지만 확인해 보고 넘어가면 좋습니다.
6. 이전 호스팅 영역과 새 호스팅 영역 간 레코드 비교
기존 호스팅 영역과 신규 호스팅 영역에 레코드가 일치하는지 일치하지 않는지 확인해보고 일치할 수 있도록 변경합니다.
7. 새 호스팅 영역에 네임 서버를 사용하도록 DNS 업데이트
도메인을 호스팅 하고 있는 사이트에서 네임 서버를 호스팅 영역에 있는 네임 서버로 업데이트합니다.
8. 결론
AWS Route 53 레코드 마이그레이션은 신중하고 체계적인 접근이 필요한 작업입니다. 성공적인 마이그레이션을 위해서는 다음 핵심 사항들을 반드시 기억해야 합니다.
마이그레이션 후 고려사항
DNS 마이그레이션이 완료된 후에도 지속적인 관리가 필요합니다. CloudWatch를 통한 모니터링 설정, 정기적인 DNS 레코드 감사, 그리고 재해 복구 계획 수립을 통해 안정적인 DNS 서비스를 유지할 수 있습니다.
무엇보다 DNS는 모든 인터넷 서비스의 기반이 되는 중요한 인프라입니다. 따라서 마이그레이션 과정에서 서비스 중단을 최소화하고, 사용자 경험에 미치는 영향을 최대한 줄이는 것이 가장 중요한 목표가 되어야 합니다.
이 가이드를 통해 안전하고 효율적인 Route 53 DNS 마이그레이션을 수행하시기 바라며, 추가적인 질문이나 특정 상황에 대한 상담이 필요하시면 언제든지 문의해 주시기 바랍니다.
이번 시간에는 AWS에서 중요한 작업인 Route 53 레코드 마이그레이션 방법에 대한 가이드에 대해 작성해 봤습니다.
감사합니다.
'Cloud > Amazon Cloud' 카테고리의 다른 글
| [AWS] 클라우드 운영자가 알고 있으면 좋은 AWS Health 예정된 변경 사항/유지보수 알람 설정하기 (Slack/Teams) (0) | 2025.02.25 |
|---|---|
| [AWS] 애플리케이션 접속이 안되거나 간헐적으로 접속이 끊길 시 로드밸런서 서브넷 설정 확인하기 (0) | 2025.02.18 |
| [AWS] ECS 블루/그린 배포를 위한 CodePipeline 구성 방법을 자세하게 알아보기 (0) | 2024.12.31 |
| [AWS] CloudWatch Logs Agent를 이용하여 서버 로그 정리하기 (0) | 2024.12.20 |
| [AWS] Korea PLES GameDay 2024 Network Topology Titans 참여 후기 (0) | 2024.09.25 |
클라우드, 개발, 자격증, 취업 정보 등 IT 정보 공간
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!