diferentes contas da AWS podem gerenciar diferentes subdomínios?

Question

Eu tenho duas contas da AWS. A conta principal com example.com como uma Zona hospedada, isso então tem vários conjuntos de registros (por exemplo, api.example.com e kibana.example.com).

Uma segunda conta gerenciará testing.example.com como uma Zona hospedada, com o mesmo conjunto de conjuntos de registros (ou seja, api.testing.example.com e kibana.testing.example.com).

Como posso dizer à conta mestra para encaminhar solicitações de .testing.example.com para a conta secundária. Não quero alterar a conta principal, pois quero usar os mesmos modelos de Formação de nuvem em "Ao vivo" e "Teste".

Eu configurei os dois como acima e isso não funciona ( api.testing.example.com não resolve). Também tentei configurar o registro testing.example.com ns na conta principal para o especificado na conta secundária (1). Infelizmente isso não é algo que eu fiz antes e as pesquisas do Google não estão retornando nada.

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

    

Answer 1

How to I tell the master account to push requests for .testing.example.com down to the child account.

As solicitações são encaminhadas, não enviadas, mas você pode alcançar 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 da AWS diferente ... em qualquer conta da AWS. Não há nada aqui que seja relacionado à "conta". Isso usa a configuração padrão do DNS. Todo o DNS é uma hierarquia. A raiz global pode dizer onde encontrar com , e os com servidores podem dizer onde encontrar example.com , e não é nada diferente para example.com dizer onde encontrar testing.example.com em vez de dar você uma resposta direta.

Observe os 4 servidores de nomes que o Route 53 atribuiu à zona hospedada testing.example.com. Verifique se todos são diferentes daqueles atribuídos à zona hospedada de 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 hostname testing , usando o tipo de registro NS e insira os 4 servidores de nomes que o Route 53 atribuiu a testing.example.com , na caixa abaixo.

Agora, quando um pedido de testing.example.com e qualquer coisa abaixo dele chegarem a um dos servidores do Route 53 que lidam com 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 é feito.

    

Answer 2

Acho que você precisa criar testing.example.com record na conta principal (pai) em example.com domain. E se você estiver usando o ELB, copie o endpoint do ELB para testing da conta filha ou o IP público atribuído ao testing domain na sua conta filha e atualize-o na rota da conta pai 53. Acho que o endpoint do ELB facilitaria resolva o endereço em vez de usar o Elastic IP dedicado. Você também precisa criar todos os subdomínios de testing na conta pai. Eu sugeriria usar pontos de extremidade ELB na conta filha para todos os subdomínios de testing site. Certifique-se de que todo o endpoint do ELB deve ter esquema como internet-facing no console do aws.