Чи можуть різні облікові записи 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не вирішує). Я також спробував встановити ns-запис test.example.com в головному обліковому записі на той, який вказаний у дочірньому обліковому записі (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 сервери імен, які маршрут 53 присвоїв зоні розміщення testing.example.com. Перевірте, чи всі вони різні, ніж ті, які призначені зоні розміщення example.com. (Для будь-якого з них бути однаковим повинно бути неможливо, але перевірте це.)

Тепер, повернувшись у зону example.com, створіть нову запис ресурсу з іменем хоста testing, використовуючи тип запису NS, і введіть testing.example.comу вікно нижче 4 серверів імен, яким призначено маршрут 53 .

Тепер, коли запит на testing.example.com і все, що нижче, надходить на один із серверів маршруту 53, що обробляє example.com, відповідь не буде відповіддю від testing.example.com - відповідь надасть запитувача 4 запису NS, пов’язані з testing.example.com, і відповідь, еквівалентна "Я не знаю, але спробуйте попросити одного з цих хлопців".

Ось як це робиться.

Я думаю, вам потрібно створити testing.example.comзапис у головному обліковому записі (Parent) під example.comдоменом. І якщо ви використовуєте ELB, скопіюйте кінцеву точку ELB для testingдочірнього облікового запису або, можливо, публічний IP призначений для testingдомену у вашому дочірньому обліковому записі та оновіть його в маршруті батьківського облікового запису 53. Я думаю, що кінцева точка ELB полегшить вирішення адреси, а не використання виділеного Еластичний IP. Вам також потрібно створити всі піддомени testingв батьківському обліковому записі. Я б запропонував використовувати кінцеві точки ELB у дочірньому обліковому записі для всіх субдоменів testingсайту. Будь ласка, переконайтеся, що всі кінцеві точки ELB повинні мати схему, як internet-facingна aws console.