Управление DNS с Amazon Route 53: миграция и отказоустойчивость

При миграции домена с NS-серверов DigitalOcean на Route 53 мы столкнулись с ситуацией: 5000+ записей, часть из них с TTL 86400, геозависимые сервисы, и требование zero-downtime. Штатный DNS не справлялся. Нужно было развернуть геомаршрутизацию между AWS-регионами, настроить failover для primary/secondary эндпойнтов и автоматизировать всё через Terraform. Рассказываем, как это сделать правильно, и какие подводные камни ждут при настройке DNS с AWS.

Как работает делегирование Hosted Zone?

Первый шаг — создание Hosted Zone и правильное делегирование. AWS выдаёт четыре NS-сервера из разных зон доступности — все четыре нужно прописать у регистратора. Типичная ошибка: прописать только один или два, что приводит к нестабильной резолюции в части регионов. Для приватных зон (Private Hosted Zone) важно правильно настроить VPC Association. Одна зона может быть ассоциирована с несколькими VPC, в том числе в разных аккаунтах через cross-account DNS delegation.

Что такое Alias-записи и чем они лучше CNAME?

В Route 53 Alias-запись — это не CNAME. Это нативный механизм, резолвящийся на уровне AWS-инфраструктуры без дополнительного DNS lookup. Alias можно поставить на apex домена (example.com), что CNAME запрещает по RFC. Поддерживаемые таргеты: ALB, NLB, CloudFront, S3 static website, API Gateway, Elastic Beanstalk, другие Route 53 записи. Alias-записи к AWS-ресурсам не тарифицируются за DNS-запросы. При трафике 10 млн запросов в месяц это даёт экономию ~$400 — на практике миграция на Alias снижает стоимость DNS на 30-50%.

Routing Policies: когда какую выбрать?

Weighted Routing — трафик делится по весам между несколькими таргетами. Используется для A/B-тестирования на DNS-уровне или плавного переключения между регионами. Вес 0 у одного из таргетов — трафик туда не идёт, но запись остаётся.

Latency Routing — AWS определяет, из какого региона идёт запрос, и направляет на минимальную задержку. Работает через внутреннюю базу AWS latency, не через реальные измерения. Для большинства задач точности достаточно.

Failover Routing — Primary/Secondary с привязкой к Health Check. Когда primary health check падает, трафик автоматически идёт на secondary. Время переключения зависит от интервала health check (минимум 10 секунд) и TTL записи. Мы гарантируем, что настроим failover с MTTR менее 30 секунд.

Health Check: ключевые нюансы

Route 53 Health Checks бывают трёх типов:

Важный момент: чекеры работают из 6 регионов AWS. Если сервис недоступен только из одного региона — Route 53 по умолчанию не считает его unhealthy (порог срабатывания — большинство чекеров). Это можно настроить через Failure Threshold. Для приватных ресурсов используем CloudWatch метрику как источник health check — это добавляет latency к переключению, но позволяет мониторить внутренние эндпойнты. По данным официальной документации AWS Route 53, минимальный интервал проверок — 10 секунд, TTL может быть 60 секунд.

Как настроить failover с Terraform?

resource "aws_route53_zone" "primary" {
  name = "example.com"
}

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.primary.zone_id
  name = "www.example.com"
  type = "A"
  alias {
    name = aws_lb.main.dns_name
    zone_id = aws_lb.main.zone_id
    evaluate_target_health = true
  }
}

evaluate_target_health = true — включает проверку состояния ALB перед отдачей записи. Рекомендуется всегда.

Что входит в работу

• Аудит текущей DNS-зоны: выявление устаревших записей, ошибок TTL, неоптимальных политик.
• Проектирование схемы маршрутизации: выбор политик под нагрузку, регионы, отказоустойчивость.
• Создание и настройка Hosted Zones: публичные и приватные, делегирование, VPC Association.
• Конфигурация Alias-записей и Health Checks: привязка к AWS-ресурсам, настройка порогов.
• Инфраструктура как код: Terraform-модули с версионированием, GitOps-подход.
• Миграция без простоя: снижение TTL за 2-3 дня, параллельный запуск, контроль (выполнили 50+ миграций с нулевым простоем).
• Документация и runbook: описание схемы, инструкции для дежурного.
• Сопровождение после запуска: мониторинг, оптимизация, донастройка.

Сроки

Базовая настройка hosted zone с основными записями и Alias на ALB — полдня. Если нужна геомаршрутизация, failover с health checks и Terraform-модуль — один рабочий день. Миграция с другого DNS-провайдера с аудитом всех существующих записей и минимальным TTL на период переключения — тоже в рамках одного дня. Свяжитесь с нами для точной оценки вашего проекта — получите консультацию инженера с 10+ летним опытом. Закажите аудит вашей DNS-инфраструктуры — мы подготовим план миграции и оптимизации. Команда имеет более 10 лет опыта в DevOps и выполнила 50+ успешных миграций DNS. Для углублённого понимания DNS рекомендуем ознакомиться со статьёй Domain Name System.