Могут ли разные учетные записи AWS управлять разными поддоменами?

У меня есть два аккаунта AWS. Основная учетная запись с example.comразмещенной зоной имеет несколько наборов записей (например, api.example.com и kibana.example.com).

Вторая учетная запись будет управляться testing.example.comкак размещенная зона с тем же набором записей (например, api.testing.example.com и kibana.testing.example.com).

Как мне сказать, чтобы основная учетная запись передавала запросы на .testing.example.comдочернюю учетную запись. Я не хочу менять основную учетную запись, так как я хочу использовать одни и те же шаблоны облачного формирования в «Live» и «Test».

Я настроил два, как указано выше, и он не работает ( api.testing.example.comне разрешается). Я также попытался установить запись test.example.com ns в основной учетной записи на ту, которая указана в дочерней учетной записи (1). Увы, это не то, что я делал раньше, и поиски в Google ничего не возвращают.

1) Я все испортил, и это ответ. См. ниже.

Как сказать основной учетной записи отправлять запросы на .testing.example.comдочернюю учетную запись.

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

Посмотрите на новую размещенную зону, которую вы создали для testing.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дочерней учетной записи или может быть Public IP, назначенный для testingдомена в вашей дочерней учетной записи, и обновите его по маршруту 53 родительской учетной записи. Я думаю, что конечная точка ELB упростит разрешение адреса, а не использование выделенного Эластичный IP. Вам также необходимо создать все дочерние домены testingв родительской учетной записи. Я бы предложил использовать конечные точки ELB в дочерней учетной записи для всех поддоменов testingсайта. Пожалуйста, убедитесь, что все конечные точки ELB должны иметь схему, как internet-facingв консоли aws.