Как указано в документации Amazon, CNAME является бесплатным.
Теперь ваша реальная путаница, почему службы, такие как Dropbox или другие, не используют пользовательский CNAME?
Ответ - ресурс поиска. Каждый раз, когда кто-то (возможно, браузер) ищет файл, он ищет, чтобы найти его хост. Затем он обнаруживает, что он размещен в Cloudfront. Затем извлекает файл. Теперь внимательно проверьте процесс,
первый поиск на сайте yoursite.com> Cloudfront Lookup> файл.
Это простой процесс для небольшого сайта. Но угадайте, что произойдет, когда вы запустите сайт, на котором больше миллиона ударов в день/час. Тот же процесс запускается снова и снова. Которая потребляет много ресурсов. И иногда, этот большой поиск поставляется за дополнительную плату. Таким образом, они вырезали один результат из уравнения. Теперь это как,
Cloudfront Lookup> файл.
Экономит много времени и ресурсов. Для небольшого сайта, например, ниже 100 тысяч в день, пользовательский CNAME не будет смертельным.
Как Поиск работа
Lookup является простым и тем же процессом сложного времени. Давайте объясним это в сценарии,
Вы введете google.com в свой браузер и нажмите enter. В этом случае кеш DNS не существует для объяснения.
Ваш браузер просит вашу ОС найти google.com. У вашей ОС есть DNS-Resolver.Обычно это исходит от вашего интернет-провайдера, иногда вы используете сторонний DNS-ресивер, такой как Google DNS. После того как DNS-резольвер получил запрос от ОС, он передаст запрос Root DNS-серверу. Есть 13 корневых серверов DNS по всему миру с 360 узлами.
Когда корневой сервер получает запрос, сначала он проверяет наличие TLD. В этом случае это домен .com. Корневой сервер знает местоположение обработчика домена .com, поэтому он отправляет ответ с адресом . Com. Обработчик. Затем ваш resolver отправляет запрос обработчикам .com, чтобы увидеть, как он знает местоположение google.com. Поскольку .com является gTLD (Generic), он поддерживается коммерческим лицом. Этот коммерческий объект имеет список всех доменов .com, когда-либо существовавших, и их расположение серверов имен. Они отправляют местоположение серверов имен google.com вашему распознавателю.
Здесь ns1.google.com, ns2.google.com, ns3.google.com, ns4.google.com. Теперь ваш распознаватель спрашивает сервер имен Google для IP-адреса google.com. Теперь у вас есть окончательный сервер имен, на самом деле есть IP-адрес google.com. Он отправляет IP-адрес.
Ваш распознаватель отправляет этот IP-адрес обратно в вашу ОС и вашу ОС в ваш браузер. Затем запускается сообщение об ошибке TCP. Ваш браузер запускает IP-адрес, соединение между вашим компьютером и физическим сервером IP. Он отправляет обратно HTML, и ваш браузер интерпретирует их для вас.
Теперь, в большинстве случаев, этот процесс длительный и рискованный. Таким образом, на каждом шаге имеется список кеша. У вашего распознавателя уже есть список IP-адресов часто посещаемых доменов. Таким образом, он немедленно разрешает IP.
Проблема с вашим случаем, ваш распознаватель, вероятно, кэшировал cdn.yoursite.com и напрямую вызывал IP. Но угадайте, что происходит, когда вы стоите с миллионами посетителей. Существует вероятность того, что 15% пользователей посещают, когда их DNS-резольвер обновляет свой кеш. Это означает, что 15% запросов пользователя должны следовать процедуре, которую я объяснил, чтобы попасть на ваш сайт. Теперь им приходится искать cdn.yoursite.com в первый раз, а затем, когда он возвращается с хостом CloudFront, тот же процесс снова запускается для IP-адресов облачных фронтов. Огромная потеря времени и ресурсов, потому что каждый поиск открывает 4 слоя базы данных, которые требуют памяти и вычислительной мощности физического процессора.
Затем, некоторые DNS-ресиверы кэшируют только один уровень IP-адреса. CNAME на самом деле является объявлением хоста, он сообщает распознавателю, что этот конкретный CNAME указывает на другое место. Это другое другое требование. Таким образом, он также запускает два запроса в кеше Resolver. И если нет кеша, 4 слоя боли поступают внутрь.
Надеюсь, я объяснил это правильно. Моя голова уже вращается после написания этого!
[Выбор между псевдонимами и наборами записей ресурсов неалиаса] (http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) – BMW
Но я не подписался на Маршрут 53. Я вошел в консоль AWS -> Маршрут 53, чтобы убедиться, и он все еще показывает мне кнопки «начать». Док, с которым вы связаны, по-видимому, применяется, когда я использую Route 53. – aisajib