As diferentes contas da AWS gerenciam subdomínios diferentes?

Eu tenho duas contas da AWS. A conta principal example.comcomo Zona Hospedada, possui vários conjuntos de registros (por exemplo, api.example.com e kibana.example.com).

Uma segunda conta será gerenciada testing.example.comcomo zona hospedada, com o mesmo conjunto de conjuntos de registros (por exemplo, api.testing.example.com e kibana.testing.example.com).

Como eu digo à conta principal para encaminhar solicitações para .testing.example.coma conta secundária. Não quero alterar a conta principal, pois quero usar os mesmos modelos de formação em nuvem no 'Live' e no 'Test'.

Eu configurei os dois como acima e ele não funciona ( api.testing.example.comnão resolve). Também tentei definir o registro testing.example.com ns na conta principal como o especificado na conta filha (1). Infelizmente, isso não é algo que eu fiz antes e as pesquisas no Google não estão retornando nada.

1) Eu estraguei tudo, e esta é a resposta. Ver abaixo.

Como eu digo à conta principal para enviar solicitações para .testing.example.coma conta filho.

As solicitações são encaminhadas, não enviadas por push, mas você pode obter o resultado desejado delegando o subdomínio a um conjunto diferente de servidores Route 53 daqueles que hospedam a zona pai.

Veja a nova zona hospedada que você criou para testing.example.com. Isso pode estar na mesma conta da AWS, em uma conta diferente da AWS ... em qualquer conta da AWS. Não há nada aqui relacionado à "conta". Isso usa a configuração DNS padrão. Todo o DNS é uma hierarquia. A raiz global pode lhe dizer onde encontrar come os comservidores podem lhe dizer onde encontrar example.com, e não é nada materialmente diferente para example.comlhe dizer onde encontrar, em testing.example.comvez de lhe dar uma resposta direta.

Observe os 4 servidores de nome que o Route 53 atribuiu à zona hospedada testing.example.com. Verifique se são todos diferentes dos atribuídos à zona hospedada example.com. (Para qualquer um deles ser o mesmo, deve ser impossível, mas verifique isso.)

Agora, de volta à zona example.com, crie um novo registro de recurso, com o nome do host testing, usando o tipo de registro NSe insira os 4 servidores de nome aos quais o Route 53 atribuiu testing.example.com, na caixa abaixo.

Agora, quando uma solicitação para testing.example.com e qualquer coisa abaixo dela chegar em um dos servidores Route 53 manipulando example.com, a resposta não será a resposta de testing.example.com - a resposta fornecerá ao solicitante os 4 registros NS associados a testing.example.com e uma resposta equivalente a "Não sei, mas tente perguntar a um desses caras".

É assim que se faz.

Eu acho que você precisa criar testing.example.comregistro na conta principal (pai) no example.comdomínio. E se você estiver usando ELB, copie o endpoint ELB para testinga conta filho ou pode ser um IP público atribuído ao testingdomínio em sua conta filho e atualize-o na rota 53 da conta pai. Acho que o endpoint ELB facilitaria a resolução de endereços em vez de usar o dedicado IP elástico. Você também precisará criar todos os subdomínios da testingconta pai. Sugiro usar pontos de extremidade ELB na conta filho para todos os subdomínios do testingsite. Verifique se todos os pontos de extremidade ELB devem ter o esquema como internet-facingno console do aws.