Управління 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.