У меня две учетные записи AWS. Мастер-счет с example.com в качестве размещенной зоны она имеет несколько наборов записей (например, api.example.com и kibana.example.com).
Вторая учетная запись будет управлять testing.example.com в качестве размещенной зоны с тем же набором наборов записей (например, api.testing.example.com и kibana.testing.example.com).
Как указать главной учетной записи направлять запросы на .testing.example.com вплоть до дочернего аккаунта. Я не хочу менять основную учетную запись, так как хочу использовать одни и те же шаблоны Cloud Formation как в «Live», так и в «Test».
Я установил два, как указано выше, и это не работает (api.testing.example.com не рассасывается). Я также попытался установить для записи test.example.com ns в основной учетной записи значение, указанное в дочерней учетной записи (1). Увы, я не делал этого раньше, и поиск в Google ничего не возвращает.
1) Я напортачил, и вот ответ. Увидеть ниже.
Как указать главной учетной записи, чтобы отправлять запросы на
.testing.example.comвплоть до дочернего аккаунта.
Запросы передаются, а не проталкиваются, но вы можете достичь желаемого результата, делегировав поддомен другому набору серверов Route 53, отличному от тех, на которых размещена родительская зона.
Посмотрите на новую зону хостинга, которую вы создали для test.example.com. Это может быть одна и та же учетная запись AWS, другая учетная запись AWS ... любая учетная запись AWS. Здесь нет ничего, что связано с "аккаунтом". При этом используется стандартная конфигурация DNS. Вся DNS представляет собой иерархию. Глобальный корень может сказать вам, где найти com, а com серверы могут сказать вам, где найти example.com, и для example.com сказать вам, где найти testing.example.com вместо того, чтобы дать вам прямой ответ.
Обратите внимание на 4 сервера имен, которые Route 53 назначил зоне, размещенной на сайте testing.example.com. Убедитесь, что все они отличаются от тех, которые назначены зоне хостинга example.com. (Чтобы любое из них было одинаковым, должно быть невозможно, но проверьте это.)
Теперь, вернувшись в зону example.com, создайте новую запись ресурса с именем хоста testing, используя тип записи NS, и введите 4 сервера имен, которым Route 53 назначил testing.example.comв поле ниже.
Теперь, когда запрос на testing.example.com и все, что ниже него, поступает на один из серверов Route 53, обрабатывающих example.com, ответ будет не быть ответом от testing.example.com - ответ предоставит запрашивающей стороне 4 записи NS, связанные с testing.example.com, и ответ, эквивалентный «Я не знаю, но попробуйте спросить одного из этих парней».
Вот как это делается.
Я думаю тебе нужно создать testing.example.com запись в основном счете (Родитель) под example.com домен. А если вы используете ELB, скопируйте конечную точку ELB для testing дочерней учетной записи или может быть публичным IP-адресом, назначенным для testing домен в своей дочерней учетной записи и обновите его в маршруте 53 родительской учетной записи. Я думаю, что конечная точка ELB упростит определение адреса, а не использование выделенного эластичного IP. Вам также потребуется создать все поддомены testing в родительском аккаунте. Я бы предложил использовать конечные точки ELB в дочерней учетной записи для всех поддоменов testing сайт. Убедитесь, что вся конечная точка ELB должна иметь схему как internet-facing в консоли AWS.