Czy różne konta AWS mogą zarządzać różnymi poddomenami?

Mam dwa konta AWS. Konto główne z example.comStrefą hostowaną zawiera szereg zestawów rekordów (np. Api.example.com i kibana.example.com).

Drugie konto będzie zarządzane testing.example.comjako Strefa hostowana z tym samym zestawem rekordów (tj. Api.testing.example.com i kibana.testing.example.com).

Jak mam powiedzieć, aby konto główne skierowało żądania dotyczące .testing.example.comkonta podrzędnego. Nie chcę zmieniać konta głównego, ponieważ chcę używać tych samych szablonów Cloud Formation zarówno w trybie „Na żywo”, jak i „Test”.

Ustawiłem oba jak wyżej i to nie działa ( api.testing.example.comnie rozwiązuje). Próbowałem również ustawić rekord test.example.com ns na koncie głównym na rekord określony w koncie podrzędnym (1). Niestety nie zrobiłem tego wcześniej, a wyszukiwania w Google nic nie zwracają.

1) Zepsułem to i to jest odpowiedź. Patrz poniżej.

Jak mam powiedzieć, aby konto główne wysyłało żądania .testing.example.comdo konta podrzędnego.

Żądania są przekazywane, a nie wypychane, ale można osiągnąć pożądany wynik, delegując poddomenę do innego zestawu serwerów Route 53 niż tych, które obsługują strefę nadrzędną.

Spójrz na nową strefę hostowaną utworzoną do testowania.example.com. Może to być na tym samym koncie AWS, innym koncie AWS ... dowolnym koncie AWS. Nie ma tu nic związanego z „kontem”. Używa standardowej konfiguracji DNS. Cały DNS jest hierarchią. Globalny katalog główny może powiedzieć ci, gdzie znaleźć com, a comserwery mogą ci powiedzieć, gdzie znaleźć example.com, i nie jest niczym innym, example.comjak powiedzieć ci, gdzie znaleźć, testing.example.comzamiast dać ci bezpośrednią odpowiedź.

Zwróć uwagę na 4 serwery nazw, które Route 53 przypisała do strefy hostowanej test.example.com. Sprawdź, czy wszystkie różnią się od przypisanych do strefy hostowanej w example.com. (Aby którykolwiek z nich był taki sam, powinno być niemożliwe, ale sprawdź to.)

Teraz z powrotem w strefie example.com utwórz nowy rekord zasobu z nazwą hosta testing, używając typu rekordu NS, i wprowadź 4 serwery nazw, do których przypisano trasę 53 testing.example.com, w polu poniżej.

Teraz, gdy żądanie dotyczące test.example.com i cokolwiek poniżej dotrze do jednego z serwerów Route 53 obsługujących example.com, odpowiedź nie będzie odpowiedzią z test.example.com - odpowiedź dostarczy wnioskodawcy 4 rekordy NS związane z testowaniem.example.com i odpowiedź równoważną z „Nie wiem, ale spróbuj zapytać jednego z tych facetów”.

Tak to się robi.

Myślę, że musisz utworzyć testing.example.comrekord na głównym koncie (Parent) w example.comdomenie. A jeśli używasz ELB, skopiuj punkt końcowy ELB dla testingkonta podrzędnego lub może to być Publiczny adres IP przypisany do testingdomeny na Twoim koncie podrzędnym i zaktualizuj go na trasie konta nadrzędnego 53. Myślę, że punkt końcowy ELB ułatwiłby rozpoznanie adresu zamiast używania dedykowanego Elastyczne IP. Musisz także utworzyć wszystkie subdomeny testingna koncie nadrzędnym. Sugeruję użycie punktów końcowych ELB na koncie podrzędnym dla wszystkich poddomen testingwitryny. Upewnij się, że wszystkie punkty końcowe ELB muszą mieć schemat jak internet-facingw konsoli aws.