Брэндированный DNS или white labeling на Amazon Route 53

Брэндированный DNS или white labeling на Amazon Route 53 Хостинг

Хостинг сайта или почему aws

На статическом сайте практически нечего ломать. Если нельзя ломать сайт, можно ломать, например, хостинг. Вы купили виртуальную машинку в DigitalOcean, поставили туда nginx и залили сайт. Но nginx и другие пакеты тоже надо периодически обновлять. Поэтому логичным выбором в пользу уменьшения забот (ака maintenance) является использование облаков, например, AWS. ОСь и веб-сервер никуда не денутся, но их обновление и защита перестанут быть вашей задачей.

Для примера я взял сайт, который мы (Plesk) используем в качестве промо наших open source проектов на GitHub.

Сайт статический. Состоит, по сути, из одной странички index.html, нескольких картинок, кастомного шрифта, css-стилей и некоторого количества JavaScript’а.

Этот сайт мы и попробуем разместить в инфраструктуре AWS. Схематично инфраструктура будет выглядеть следующим образом:

Almost there…

Finally, you need to get your Domain Name from the CloudFront distribution. It should be something like this dsfdser83543.cloudfront.net.

Automated dns record management

As I mentioned earlier, the real benefit of sticking with Route 53 over another solution is the fact that it’s fully integrated with AWS and can be automated via the same methods as other AWS resources.

Aws s3

Для хостинга сайта мы воспользуемся сервисом


For example, say you’re creating a bunch of servers and a load balancer via CloudFormation:

This also makes it simple to manage the lifecycle of those records — because the records are associated with the same CloudFormation stack as the actual servers, when you delete the stack and the servers, the Route 53 records are deleted at the same time.


Осталось буквально последнее действие — настроить

, чтобы наш сайт стал доступным для пользователей.

How do you get an ssl certificate with aws?

Log into your AWS console and navigate to the AWS Certificate Manager (ACM).

Make sure you change the region from the default (Ohio) to N. Virginia. This is not explicit in the guides and only the N. Virginia region can issue certificates. I learned the hard way and wasted a lot of time!

Then click on “Get Started” under “Provision Certificates”.

Follow the documentation with AWS (“Requesting a public certificate using the console”) and use Victoria Drake’s guide (under “SSL certificate”).

In addition to the guides there are few things that weren’t fully explained:

It’s an Excel spreadsheet which will contain something like this:

  • You’ll need to add these records to your DNS settings with your registrar. Log in and go to DNS settings. The interface varies with different registrars but you’re looking for your Host records under your DNS settings.
  • Click on “Add Record” > record type is CNAME:

You need to add two records: 1) Hostname should be “@” and Target Name should be the Record value from the DNS configuration file.

2) Hostname should be * (asterisk) and Target Name should be the Record value from the DNS configuration file.

If you want more information about the CNAME and record types, I found this helpful article.

It’s quite long, but I’ve pulled out the useful part:

How much does it cost for an ssl certificate?

I’ve seen a range of ways of getting an SSL certificate. You can pay a premium for a service that will do this on your behalf or you can do it for free with Let’s Encrypt. Let’s Encrypt is an official Certificate Authority (CA). But you have to renew your certificate every three months and the process is quite complicated.

I didn’t want to pay a premium or want the hassle of renewing every three months. Conveniently, AWS can issue SSL certificates for a very small fee. You pay $0.75 for each certificate issued and it lasts for one year.

Читайте также:  Как узнать где мой сайт

If you choose not to go with AWS, make sure you do your research and choose a trusted CA!


Route 53 records can also be automatically added and removed via a Lambda function which is called each time a new resource is created or deleted. This option removes the requirement for specifying any DNS records in a CloudFormation template, as the DNS record lifecycle is now managed via this Lambda function and its interaction with the Route 53 API.

For more information on this approach, head over to this AWS blog post: Building a Dynamic DNS for Route 53 using CloudWatch Events and Lambda.

Reverse lookups

One other piece about Route 53 — reverse lookup zones are not automatically created or maintained. With some DNS services, when you create a DNS record in a zone, it will maintain a record in a reverse lookup zone, as well. This is not the case with Route 53.

Manually maintaining reverse lookup records would be easy enough when there is a rigid process for performing DNS record updates. However, in an environment that is dynamic and changing often, it is more cumbersome.

The method I have implemented for reverse zones is to:

Route 53

Прежде чем настраивать публичный доступ к сайту, давайте разберемся с доменным именем. В качестве такового я выбрал tech.plesk.space.

Отправляемся в консоль Amazon, открываем сервис Route 53 и создаем новую публичную зону.

После создания зоны мы получаем информацию об NS-записях. Это DNS-серверы, которые будут хранить информацию о нашей зоне. Если вы раньше работали с какими-нибудь небольшими провайдерами, то выглядело это примерно так: есть ns1, ns2, и на них хостятся все домены. В случае с AWS сказать какие DNS-серверы будут обслуживать зону заранее нельзя.

Итак, у нас есть список NS-записей, что с ним делать? Если вы купили домен, то далее идете в панель управления доменом и прописываете полученные записи. Вот так это выглядит, например, у GoDaddy:

В нашем случае домен tech.plesk.space является поддоменом plesk.space, а эта зона хостится в Digital Ocean DNS аккаунте. Для того, чтобы правильно выполнить делегирование, нам нужно прописать соответствующие glue records.

Проверяем с помощью dig’а:

Одних NS-записей для обслуживания сайта не достаточно. Нужна еще A-запись. Мы вернемся к этой теме немного позже, когда доберемся до CloudFront, но перед этим нам нужно сделать еще одно действие.

Route 53 background and limitations

For those not familiar, Route 53 is Amazon’s scalable DNS service (more information here). It is quite powerful and very cost effective. It offers great integration with AWS services, has support for private and public zones, and supports all of the most commonly used record types. For enterprises who are new to AWS, it might seem like the obvious choice.

An example of how one might expect Route 53 hybrid DNS integration to work. Unfortunately, this is not the case.

Many who are new to AWS expect to be able to use Route 53 as expressed in the above diagram, by forwarding on-premise systems to Route 53 for DNS resolution, and adding forwarders to Route 53 for resolving on-premise names. This will not work.

Set up your s3 buckets

In the meantime you can set up your S3 Buckets. The S3 Bucket is the storage for your files such as your index.html.

This brings us to some of the key downsides to route 53:

Route 53 private endpoints are not available over VPN/DirectConnect:

What is a hosting provider?

“An Internet hosting service is a service that runs Internet servers, allowing organizations and individuals to serve content to the Internet. There are various levels of service and various kinds of services offered.”

When I was looking for a hosting provider for my website, I explored different options. The prices ranged from £2.00 — £5.00 per month with various storage options from 0.5GB to 10GB. The prices seemed reasonable but all I wanted to do was host a static website. It had a few images, HTML, CSS and JavaScript files. No dynamic content.

Where can you buy your domain name?

You can buy a domain name from a domain name registrar. Prices start from a few dollars. Your domain name is unique. Each domain name registrar offers different levels of services/support. But you can register your domain with any registrar.

Читайте также:  Отслеживание камер видеонаблюдения

Who is this guide for?

This guide is aimed at complete beginners who want to host a static website (a site with fixed content). I will provide a how-to-guide for the following:

  1. How to buy a domain.
  2. How to configure your domain for an external hosting provider.
  3. How to host your website with Amazon Web Services (AWS).
  4. How to make your website secure (SSL certification) using Amazon Certification Manager.

There might be some terminology that’s new to you. Please go ahead and look up terms that are not familiar. I’ve put in useful links and explanations where I thought appropriate.

Why aws?

After some further research, I found AWS. AWS offers a free tier option. Essentially, you get lots of free products. Some of them expire after 12 months and others are free in perpetuity. The only cost that you will incur for hosting a static website is the cost of setting up a hosted zone. This cost $0.50 per month. So I went with AWS and set up my account.

The great thing about AWS is the price and it’s a reliable hosting provider. But one thing to bear in mind is that you’re reliant on their documentation. As I started reading about what services AWS offered, it quickly became confusing! I used the official AWS guide provided for setting up static websites.

I found this this excellent guide by Victoria Drake.

I followed Victoria Drake’s guide alongside the AWS one and managed to muddle through. But there were still a few things that were not explained which I hope to flesh out.

Before we proceed, here is your to do list:

Here we go!

Брэндированный dns или white labeling на amazon route 53

Брэндированный DNS или white labeling на Amazon Route 53 - 1Управление виртуальным — это сложная, но интересная в реализации задача, которая постоянно сопряжена с различными трудностями.

Например, когда у вас сотни клиентов, приходится иметь дело с большим количеством доменных имен, которые обычно относятся к разным регистраторам и принадлежат разным людям. С этой ситуацией не всегда легко справиться.

Поэтому я хотел бы поделиться историей успеха одного из наших клиентов, демонстрирующей, как можно использовать Amazon Route 53 в виртуальном .

Любой нормальный предоставляет свои NS сервера для обслуживания клиентских доменов. Более того, очень желательно их реально использовать — в будущем это облегчит миграцию клиентских сайтов с сервера на сервер или восстановление из бэкапа. В этом случае хостеру не нужно участие клиента, чтобы установить новые IP для домена, поэтому в случае работ по обслуживанию или аварии сайты заработают на новом месте с минимальным простоем или вообще без него.
Обычно NS сервера выглядят следующим образом:

Если вы решили использовать сервис Amazon Route 53 в качестве DNS, то вы быстро заметите, что по умолчанию он предоставляет отдельный набор NS серверов для каждого домена:

Вот как это выглядит из панели Route 53:
Брэндированный DNS или white labeling на Amazon Route 53 - 2

Как видно в секции под названием “Hosted Zone Details”, расположенной справа на скриншоте, сервера имен имеют адреса типа «ns-1072.awsdns-06.org». Это означает, что DNS не начнет свою работу до тех пор, пока эти адреса не будут указаны у регистратора этого доменного имени.

Как же получить один набор NS серверов для всех, да еще и white-label? Переключать домены по одному явно не вариант.

Выход есть — Route 53 API позволяет создать «reusable delegation set» или, если по-русски, переиспользуемый набор NS серверов. Интересно, что данный функционал не доступен из самой панели Route 53.

Однако, даже в этом случае новый набор серверов имеет все тот же “страшный” вид:

На самом деле, ничего страшного в этом нет. Идея заключается в том, чтобы создать все доменные зоны с одним набором серверов имен, и в качестве IP-адресов для ns1.awesome-hoster.com и ns2.awesome-hoster.com указать амазоновские IP-адреса серверов имен. Да-да, IP тех самых ns-XXXX.awsdns-XX.org и ns-XXXX.awsdns-XX.co.uk, как пример.

Если вы пользуетесь контрольной панелью Plesk, то мы рекомендуем использовать наше расширение для интеграции c Route 53. Данное расширение автоматизирует создание доменных зон в Route 53 и поддерживает «reusable delegation set».

Расширение устанавливается в один клик из каталога в самом Plesk’e («Расширения» в главном меню и затем “Каталог расширений”).
Брэндированный DNS или white labeling на Amazon Route 53 - 3

Читайте также:  Ищешь лучший хостинг? Учись на моих ошибках! Мой опыт...

Следуйте инструкциям расширения, чтобы получить пару секретных ключей на портале Amazon и включить синхронизацию. Каждый домен, созданный в Plesk, тут же получит доменную зону в Route 53.

Давайте вернемся к «reusable delegation set» и посмотрим на функционал, который дает нам расширение для управления этими наборами. С помощью расширения вы можете создать новый переиспользуемый набор серверов имен или сделать таким один из существующих наборов. Чтобы сделать это, необходимо открыть расширение, перейти во вкладку «Reusable Delegation Sets» и выбрать «Create Delegation Set». В результате появится новый набор из 4 серверов имен, который мы будем использовать по умолчанию.
Брэндированный DNS или white labeling на Amazon Route 53 - 4

Теперь все новые доменные зоны, созданные в Plesk, будут использовать один и тот же набор серверов имен. Стоит отметить, что Route 53 накладывает ограничение, не позволяющее изменить сервера имен в уже существующих зонах. Для изменения набора придется пересоздать каждую зону, с указанием правильного набора, а это та еще задача. Интерфейс панели Route 53 всеми способами препятствует удалению зоны: необходимо сначала удалить из нее все ресурсные записи, кроме NS, и только после этого можно удалить зону.

В своем расширении мы предлагаем инструменты для групповых операций (на вкладке “Mass Management”), которые позволяют в один клик удалять и создать заново в Route 53 все доменные зоны, зарегистрированные в Plesk, без сложностей, присущих панели Route 53.
Брэндированный DNS или white labeling на Amazon Route 53 - 5

Когда синхронизированные зоны будут содержать единый набор серверов, можно переключить A записи ns1.awesome-hoster.com и ns2.awesome-hoster.com на IP-адреса соответствующих серверов из набора (достаточно выбрать 2 из них). Нужно отметить, что запись CNAME в данном случае не будет работать по соображениям безопасности.

Чтобы удостовериться в правильности настройки, мы можем воспользоваться command line утилитой dig или онлайн сервисом от Google.

Следует учитывать следующие ограничения, которые накладывает на нас Route 53:

Кроме высокой доступности, облачный провайдер предлагает возможности масштабирования: настроить проверки DNS для переключения на резервную копию сайта, иметь Geo-распределенный трафик и многое другое. Но это уже отдельная тема для будущих статей.

Нам было бы интересно узнать опыт других пользователей Amazon Route 53. Ждем ваших комментариев!

Автор: Plesk


Прочие моменты

Я не затрагивал тему логирования запросов. По-умолчанию оно выключено, но его можно настроить. Логи будут складываться в S3 bucket. Нужно учитывать специфику подхода к CDN (тут Amazon совершенно не уникален) о том, что такое логирование — это не инструмент real time отладки.

Еще один момент, который хотел кратко упомянуть, это цена. В случае free tier и небольшой нагрузки стоимость будет около 50 центов, и то только на Route53. Без free tier получалось где-то 1-2 доллара в месяц. В целом, наверное, может показаться, что это даже дорого для хостинга статического сайта, но, на самом деле, в случае с AWS, у нас огромный потенциал для развития проекта (масштабируемость, оплата по мере роста, глобальная доступность, огромное количество других удобных сервисов и многое-многое другое).

Статические сайты

Для начала, в двух словах — а почему статический сайт? Как ни странно, мода на статические сайты, вернувшаяся лет 8-10 назад, до сих пор не проходит. И речь не только об огромном количестве сайтов на

. Генераторы статических сайтов такие как

или хипстерский

продолжают выпускать регулярно новые релизы и остаются более чем востребованными.


Как я уже упоминал в начале,

от Amazon теперь советует использовать сервис

. Он действительно удобней: тут и подключение Git-репозитория, и полуавтоматическая настройка ряда вышеописанных вещей. Но, порой, нужно разобраться с уже настроенной инфраструктурой или организовать некоторые вариации хостинга, из-за чего уже придется разбираться со всеми нюансами.

Еще один интересный взгляд на данную проблему — это сервисы типа Netlify. Они еще сильнее упрощают некоторые вещи (правда, бывает и усложняют), но, конечно, и их использование будет стоить дополнительных денег.

Надеюсь, статья поможет сберечь время при настройке хостинга статического сайта в AWS.


I hope this compilation of information about private DNS zones on AWS will be helpful for someone else. I’ve gone through a couple of these hybrid DNS integrations, so I wanted to share some learnings and pain points I’ve come across. I also found there wasn’t much comprehensive information available on hybrid DNS on AWS. I’m hoping this can fill a small part of that gap.

Thanks for reading!

Оцените статью