Модуль 1.5: Route 53 та управління DNS

Складність: [MEDIUM]

Час на виконання: 1.5 години

Передумови

Перед початком цього модуля ви повинні завершити:

Модуль 1.2: VPC та основи мереж
Базове розуміння доменних імен та того, як браузери резолвлять URL
Акаунт AWS з принаймні одним зареєстрованим доменом (або готовність зареєструвати його ~$12/рік)
AWS CLI, налаштований з відповідними дозволами

Чому цей модуль важливий

У жовтні 2021 року Facebook зник з інтернету. Не фігурально — буквально. Протягом шести годин DNS-записи компанії були недоступні через рутинну зміну конфігурації BGP, яка випадково відкликала маршрути до DNS-серверів Facebook. Результат: 3.5 мільярда користувачів залишилися без доступу, орієнтовно $100 мільйонів втраченого доходу, а працівники не могли потрапити у власні будівлі, бо системи перепусток залежали від внутрішнього DNS. Того дня акції впали на 4.9%.

DNS — це невидимий фундамент кожного інтернет-додатка. Коли він працює, ніхто про нього не думає. Коли він відмовляє, ніщо інше не має значення — ваші красиво спроєктовані мікросервіси, розгортання в кількох регіонах, стратегія релізів без простоїв — усе це стає недоступним, якщо користувачі не можуть резолвити ваше доменне ім’я.

AWS Route 53 — це керований сервіс DNS від Amazon, названий на честь порту, на якому працює DNS-трафік (порт 53). Він обробляє понад трильйон DNS-запитів на місяць через глобальну мережу edge-локацій AWS. У цьому модулі ви дізнаєтеся, як працює Route 53, як налаштовувати хостинг-зони та записи, як впроваджувати складні політики маршрутизації для мультирегіональних архітектур та як підтримувати здоров’я вашої DNS-інфраструктури за допомогою автоматичних перевірок. Наприкінці ви побудуєте конфігурацію active-passive failover між двома регіонами — таку, що врятувала б інженерів Facebook від дуже поганого дня.

Як насправді працює DNS

Перш ніж торкатися Route 53, переконаймося, що фундамент міцний. DNS часто називають “телефонною книгою інтернету”, але ця аналогія занадто спрощена. Краща аналогія: DNS — це поштова система інтернету, яка перекладає зрозумілі людині адреси (наприклад, api.yourapp.com) у машиночитані IP-адреси (наприклад, 54.231.128.12).

Ось що відбувається, коли користувач вводить ваш домен у браузері:

                    Браузер користувача
                         |
                    [1] Запит: api.yourapp.com?
                         |
                         v
                  Локальний DNS-резолвер      <-- Провайдер або корпор. резолвер
                  (Recursive Resolver)             (напр., 8.8.8.8)
                         |
           [2] Немає в кеші? Питаємо root сервери
                         |
                         v
                   Root Name Servers          <-- 13 кластерів у світі
                   (., root zone)
                         |
           [3] "Спробуй сервери .com TLD"
                         |
                         v
                  TLD Name Servers            <-- Керуються Verisign для .com
                  (.com zone)
                         |
           [4] "Спробуй ns-123.awsdns-45.com"
                         |
                         v
              Authoritative Name Server       <-- ЦЕ ROUTE 53
              (зона yourapp.com)
                         |
           [5] "api.yourapp.com = 54.231.128.12"
                         |
                         v
                  Локальний DNS-резолвер
                         |
           [6] Повертає IP браузеру (кешується на час TTL)
                         |
                         v
                    Браузер користувача
                    Підключається до 54.231.128.12

Route 53 живе на кроках 4-5 у цьому ланцюжку. Це авторитетний сервер імен (authoritative name server) для ваших доменів. Коли будь-який резолвер у світі запитує “де знаходиться api.yourapp.com?”, Route 53 відповідає.

Типи DNS-записів, які вам потрібно знати

Тип запису	Призначення	Приклад	Коли використовувати
A	Мапінг імені на IPv4 адресу	`api.example.com -> 54.231.128.12`	Прямий мапінг IP
AAAA	Мапінг імені на IPv6 адресу	`api.example.com -> 2600:1f18:...`	IPv6 ендпоінти
CNAME	Мапінг імені на інше ім’я	`www.example.com -> example.com`	Аліаси (не можна в корені зони)
ALIAS	Розширення Route 53 для A/AAAA	`example.com -> d1234.cloudfront.net`	Ресурси AWS у корені зони
MX	Сервери пошти	`example.com -> mail.example.com (пріор. 10)`	Маршрутизація пошти
TXT	Довільний текст	`example.com -> "v=spf1 include:_spf.google.com"`	SPF, DKIM, верифікація домену
NS	Делегація серверів імен	`example.com -> ns-123.awsdns-45.com`	Делегація зони
SOA	Start of Authority	Метадані зони	Керується Route 53 автоматично
SRV	Локатор сервісів	`_sip._tcp.example.com -> sip.example.com:5060`	Service discovery
CAA	Certificate Authority Authorization	`example.com -> 0 issue "letsencrypt.org"`	Хто може видавати TLS сертифікати

ALIAS-запис заслуговує на особливу увагу. Стандартний DNS не дозволяє використовувати CNAME у корені зони (naked domain, наприклад example.com). Але ви часто хочете, щоб ваш основний домен вказував на балансувальник або CloudFront. ALIAS-запис у Route 53 вирішує це — він працює як CNAME, але повертає A/AAAA запис, тому працює в корені зони. До того ж, запити до ALIAS-записів, що вказують на ресурси AWS, є безкоштовними.

Хостинг-зони (Hosted Zones): Публічні та Приватні

Хостинг-зона — це контейнер для DNS-записів одного домену. Думайте про неї як про конфігураційний файл DNS для одного домену та його піддоменів.

Публічні хостинг-зони

Публічні зони відповідають на запити з усього інтернету. Коли ви реєструєте домен або переносите управління DNS у Route 53, ви створюєте публічну хостинг-зону.

# Створення публічної хостинг-зони
aws route53 create-hosted-zone \
  --name example.com \
  --caller-reference "$(date +%s)" \
  --hosted-zone-config Comment="Production domain"

# Список усіх хостинг-зон
aws route53 list-hosted-zones

# Отримання деталей конкретної зони (замініть на ваш ID)
aws route53 get-hosted-zone --id Z0123456789ABCDEFGHIJ

Коли Route 53 створює публічну зону, він автоматично призначає чотири сервери імен з різних TLD доменів (напр., ns-123.awsdns-45.com, ns-456.awsdns-78.net, ns-789.awsdns-12.org, ns-1012.awsdns-34.co.uk). Такий розподіл гарантує, що навіть якщо інфраструктура одного TLD матиме проблеми, ваш DNS продовжуватиме працювати.

Приватні хостинг-зони

Приватні зони відповідають на запити тільки всередині однієї або кількох асоційованих VPC. Вони незамінні для внутрішнього service discovery — надання зрозумілих імен внутрішнім ресурсам без їх виставлення в інтернет.

# Створення приватної зони, асоційованої з VPC
aws route53 create-hosted-zone \
  --name internal.yourcompany.com \
  --caller-reference "$(date +%s)" \
  --vpc VPCRegion=us-east-1,VPCId=vpc-0abc123def456 \
  --hosted-zone-config Comment="Internal services",PrivateZone=true

# Асоціація додаткових VPC з приватною зоною
aws route53 associate-vpc-with-hosted-zone \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --vpc VPCRegion=us-west-2,VPCId=vpc-0xyz789ghi012

Популярним патерном є split-horizon DNS: одне й те саме доменне ім’я резолвиться в різні IP залежно від того, чи прийшов запит зсередини, чи ззовні вашої VPC. Наприклад, api.yourapp.com може резолвитися в публічний IP ALB для зовнішніх користувачів, але в приватний IP для сервісів всередині VPC. Це зменшує затримки та уникає зайвого трафіку через internet gateway.

Архітектура Split-Horizon DNS:

Зовнішній користувач                     Внутрішній сервіс (у VPC)
     |                                       |
     | Запит: api.yourapp.com                | Запит: api.yourapp.com
     v                                       v
 Публічна хостинг-зона                 Приватна хостинг-зона
 api.yourapp.com -> 54.231.128.12      api.yourapp.com -> 10.0.1.50
 (Public ALB IP)                       (Private ALB IP)
     |                                       |
     v                                       v
 Трафік іде через інтернет              Трафік залишається в VPC
 -> ALB -> Target Group                 -> Internal ALB -> Target Group

Вартість хостинг-зон

Ціноутворення Route 53 просте, але на великих масштабах може здивувати:

Компонент	Вартість
Хостинг-зона	$0.50/місяць за зону (перші 25 зон)
Стандартні запити	$0.40 за мільйон запитів
Запити з маршрут. за затримкою	$0.60 за мільйон запитів
ALIAS запити до ресурсів AWS	Безкоштовно
Health checks	$0.50/міс (базовий), $0.75/міс (HTTPS + перевірка рядка)
Реєстрація домену	$12-40/рік залежно від TLD

Той факт, що ALIAS запити безкоштовні, дуже важливий. Якщо ви можете використати ALIAS замість CNAME, ви заощаджуєте на запитах і отримуєте підтримку кореня зони. Завжди віддавайте перевагу ALIAS для ресурсів AWS.

Створення та управління DNS-записами

Давайте створимо кілька записів. Route 53 використовує систему change-batch, де ви подаєте JSON з описом змін.

Базове створення записів

# Створення A-запису, що вказує на EC2 екземпляр
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "app.example.com",
          "Type": "A",
          "TTL": 300,
          "ResourceRecords": [
            {"Value": "54.231.128.12"}
          ]
        }
      }
    ]
  }'

# Створення ALIAS-запису, що вказує на ALB
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "example.com",
          "Type": "A",
          "AliasTarget": {
            "HostedZoneId": "Z35SXDOTRQ7X7K",
            "DNSName": "my-alb-123456789.us-east-1.elb.amazonaws.com",
            "EvaluateTargetHealth": true
          }
        }
      }
    ]
  }'

Зверніть увагу на дію UPSERT у другому прикладі. Вона ідемпотентна — створює запис, якщо його немає, або оновлює, якщо він існує. В автоматизації продакшну завжди краще використовувати UPSERT.

TTL: Важіль кешування, який треба розуміти

TTL (Time to Live) визначає, як довго резолвери кешують ваші DNS-записи (у секундах). Це одне з найбільш незрозумілих налаштувань у DNS:

Значення TTL	Сценарій використання	Компроміс
60 секунд	Активний failover, під час міграцій	Велика кількість запитів, вища вартість
300 сек (5 хв)	Стандартні записи продакшну	Гарний баланс для більшості додатків
3600 сек (1 год)	Стабільні записи (MX, TXT)	Менша вартість, повільніші зміни
86400 сек (24 год)	Записи, що ніколи не змінюються	Найменша вартість, дуже повільне поширення

Критичний урок: знижуйте TTL перед внесенням змін. Якщо ваш TTL — 24 години, і вам треба перейти на нову IP, деякі резолвери не побачать змін цілу добу. Стандартний план дій:

За 48 годин до зміни: знизити TTL до 60 секунд.
Почекати час старого TTL (24 години).
Змінити IP.
Перевірити, що зміна поширилася.
Повернути TTL до нормального значення.

Політики маршрутизації (Routing Policies)

Саме тут Route 53 перетворюється з “керованого DNS” на “інтелектуальне управління трафіком”. Політики визначають, як Route 53 відповідає на запити.

Проста маршрутизація (Simple Routing)

Один запис, одне або кілька значень. Якщо значень кілька, Route 53 повертає всі у випадковому порядку, а клієнт обирає один.

Зважена маршрутизація (Weighted Routing)

Розподіл трафіку між ресурсами у пропорціях, які ви контролюєте. Ідеально для blue-green розгортань, A/B тестування та поступових міграцій.

# 90% трафіку на продакшн, 10% на canary
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "app.example.com",
          "Type": "A",
          "SetIdentifier": "production",
          "Weight": 90,
          "TTL": 60,
          "ResourceRecords": [{"Value": "54.231.128.12"}]
        }
      },
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "app.example.com",
          "Type": "A",
          "SetIdentifier": "canary",
          "Weight": 10,
          "TTL": 60,
          "ResourceRecords": [{"Value": "52.86.200.34"}]
        }
      }
    ]
  }'

Вага 0 означає, що запис ніколи не повертатиметься, поки всі інші записи також не матимуть вагу 0. Це корисно для “темних запусків” (dark launching).

Маршрутизація за затримкою (Latency-Based Routing)

Route 53 направляє трафік у регіон із найменшою затримкою для користувача. AWS постійно вимірює затримки між мережами інтернету та своїми регіонами.

Користувачі в Нью-Йорку потраплять у us-east-1. Користувачі в Лондоні — в eu-west-1.

Маршрутизація відмовостійкості (Failover Routing)

Конфігурація active-passive. Route 53 повертає основний запис, поки його health check успішний, інакше перемикається на резервний.

# Основний запис із перевіркою здоров'я
aws route53 change-resource-record-sets \
  --hosted-zone-id Z0123456789ABCDEFGHIJ \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "TTL": 60,
        "HealthCheckId": "abcdef12-3456-7890-abcd-ef1234567890",
        "ResourceRecords": [{"Value": "54.231.128.12"}]
      }
    }]
  }'

Перевірки здоров’я (Health Checks)

Health checks роблять політики маршрутизації інтелектуальними. Без них Route 53 буде щасливо надсилати трафік на “мертві” ендпоінти.

Як працюють Health Checks

Перевірки запускаються з дата-центрів у кількох регіонах AWS. За замовчуванням вони опитують ваш ендпоінт кожні 30 секунд із приблизно 15 локацій по всьому світу. Ендпоінт вважається здоровим, якщо принаймні 18% перевірок (десь 3 з 15) повідомляють про успіх.

Коли перевірки фіксують збій:

Failover маршрутизація активує резервний запис.
Weighted/latency маршрутизація видаляє цей ендпоінт із відповідей.
Тригериться CloudWatch алярм (якщо налаштовано).

Тип CLOUDWATCH_METRIC критично важливий для приватних ресурсів. Оскільки перевірки Route 53 йдуть із публічного інтернету, вони не бачать ресурси всередині VPC. Для них ви створюєте CloudWatch алярм, а потім — health check, що стежить за цим алярмом.

DNSSEC: Підписання вашої зони

DNSSEC захищає від підміни DNS (spoofing) шляхом криптографічного підписання записів. Без DNSSEC зловмисник може повернути фальшиві записи, направивши ваших користувачів на шкідливі сервери.

Увімкнення DNSSEC у Route 53 передбачає створення ключа (KSK) в AWS KMS (обов’язково в регіоні us-east-1).

Попередження: увімкнути DNSSEC просто, але помилка в налаштуванні може зробити ваш домен повністю недоступним. Завжди спочатку тестуйте на некритичних доменах.

Чи знали ви?

Route 53 має SLA 100% аптайму — це один із небагатьох сервісів AWS із такою гарантією. Це досягається завдяки глобальній anycast-мережі з понад 200 edge-локацій. З моменту запуску в 2010 році у Route 53 не було жодного повного збою.
Назва “Route 53” має подвійний сенс. Очевидно, DNS працює на порті 53. Але це також відсилка до знаменитого американського шосе Route 66 — поєднання концепції “маршрутизації” (routing) трафіку в інтернеті з маршрутами для авто через усю країну.
ALIAS-записи були винайдені AWS, бо стандартний DNS не міг вирішити проблему CNAME у корені зони. Пізніше IETF формалізував схожу концепцію як тип запису ANAME, але ALIAS залишається специфічним розширенням AWS. Інші провайдери мають свої варіанти: Cloudflare називає це “CNAME flattening”.

Типові помилки

Помилка	Чому це стається	Як виправити
Забули знизити TTL перед міграцією	TTL часто налаштовують один раз і забувають	Створіть план міграції, який починається зі зниження TTL за 48 годин до змін
Використання CNAME у корені зони	CNAME здається правильним типом для аліасів	Використовуйте ALIAS-записи Route 53 для кореня домену
Немає health checks на failover записах	Перевірки коштують грошей і здаються опційними	Failover без health check не має сенсу — він ніколи не спрацює. Завжди додавайте перевірки до основних записів
Ендпоінт перевірки закритий групою безпеки	Перевірки йдуть із публічних IP AWS, які заблоковані	Додайте IP-діапазони health-чекерів AWS у вашу Security Group
Приватна зона не асоційована з VPC	Зона створена, але запити повертають NXDOMAIN	Асоціюйте приватну зону з кожною VPC, яка повинна її бачити

Тест

1. У чому головна різниця між записом CNAME та ALIAS у Route 53?

Запис CNAME створює аліас одного імені на інше, але його НЕ МОЖНА використовувати у корені зони (наприклад, для example.com без піддомену). Це обмеження протоколу DNS. Запис ALIAS — це розширення Route 53, яке працює як CNAME, але повертає A або AAAA запис у відповіді. Це дозволяє використовувати його в корені зони, а при вказуванні на ресурси AWS (ALB, CloudFront) такі запити безкоштовні.

2. У вас налаштована маршрутизація за затримкою для us-east-1 та eu-west-1. Користувач із Бразилії резолвить ваш домен. Куди він потрапить?

Він потрапить туди, де для його мережі буде зафіксована менша затримка. Route 53 використовує базу вимірювань затримок від реальних інтернет-провайдерів до регіонів AWS. Для користувача в Бразилії (район Сан-Паулу) us-east-1 (Вірджинія) зазвичай ближче за мережевою затримкою, ніж eu-west-1 (Ірландія), тому він потрапить до США. Але це не гарантовано географією — все залежить від пірингу інтернет-провайдера користувача.

3. Ваша перевірка здоров'я (health check) показує статус healthy, але користувачі повідомляють про помилки в додатку. Що не так?

Найчастіше це стається тому, що ендпоінт /health повертає 200 OK, навіть коли додаток працює некоректно. Базовий HTTP health check перевіряє тільки код відповіді (2xx/3xx). Використовуйте HTTPS_STR_MATCH перевірку, яка шукає конкретний рядок у тілі відповіді (наприклад, "status":"healthy"). Ваш ендпоінт здоров’я повинен виконувати реальні перевірки: з’єднання з базою, доступність кешу тощо.

Практична вправа: Мультирегіональний Active-Passive Failover

У цій вправі ви побудуєте конфігурацію відмовостійкості продакшн-рівня. Ми симулюємо два регіональні ендпоінти та налаштуємо Route 53 на автоматичне перемикання, коли основний вийде з ладу.

Завдання 1: Створення перевірок здоров’я (Health Checks)

Створіть HTTP health checks для основного (PRIMARY) та резервного (SECONDARY) ендпоінтів.

# Створення перевірки для основного (замініть IP на ваші або тестові)
PRIMARY_HC=$(aws route53 create-health-check \
  --caller-reference "primary-hc-$(date +%s)" \
  --health-check-config '{
    "Type": "HTTP",
    "IPAddress": "54.231.128.12",
    "Port": 80,
    "ResourcePath": "/health",
    "RequestInterval": 10,
    "FailureThreshold": 2
  }' \
  --query 'HealthCheck.Id' --output text)

echo "ID основної перевірки: ${PRIMARY_HC}"

Завдання 2: Налаштування записів Failover

Створіть основний та резервний записи, пов’язавши кожен із відповідною перевіркою здоров’я.

aws route53 change-resource-record-sets \
  --hosted-zone-id YOUR_HOSTED_ZONE_ID \
  --change-batch '{
    "Changes": [
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "failover-demo.example.com",
          "Type": "A",
          "SetIdentifier": "primary-us-east-1",
          "Failover": "PRIMARY",
          "TTL": 60,
          "HealthCheckId": "'"${PRIMARY_HC}"'",
          "ResourceRecords": [{"Value": "54.231.128.12"}]
        }
      },
      {
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "failover-demo.example.com",
          "Type": "A",
          "SetIdentifier": "secondary-us-west-2",
          "Failover": "SECONDARY",
          "TTL": 60,
          "ResourceRecords": [{"Value": "52.86.200.34"}]
        }
      }
    ]
  }'

Завдання 3: Симуляція відмови та перевірка

Перевірте резолв через dig failover-demo.example.com +short — має повернути основний IP.
Змініть IP у health check основного запису на неіснуючий (192.0.2.1), щоб симулювати збій.
Почекайте ~45 секунд.
Перевірте резолв знову — він повинен повернути резервний IP.

Очищення

Не забудьте видалити записи та health checks після вправи, щоб уникнути зайвих витрат (~$1/місяць за перевірки).

Наступний модуль

Далі: Модуль 1.6: Elastic Container Registry (ECR) — навчіться зберігати, керувати та захищати образи контейнерів. Ви налаштуєте політики життєвого циклу, сканування вразливостей та крос-акаунт доступ — необхідний фундамент перед деплоєм контейнерів у ECS або EKS.