Différents comptes AWS peuvent-ils gérer différents sous-domaines?

J'ai deux comptes AWS. Le compte principal avec en example.comtant que zone hébergée, celui-ci a alors un certain nombre de jeux d'enregistrements (par exemple api.example.com et kibana.example.com).

Un deuxième compte sera géré en testing.example.comtant que zone hébergée, avec le même ensemble de jeux d'enregistrements (c'est-à-dire api.testing.example.com et kibana.testing.example.com).

Comment dire au compte principal de renvoyer les demandes .testing.example.comvers le compte enfant. Je ne souhaite pas modifier le compte principal, car je souhaite utiliser les mêmes modèles de formation cloud dans les deux versions 'Live' et 'Test'.

J'ai configuré les deux comme ci-dessus et cela ne fonctionne pas ( api.testing.example.comne résout pas). J'ai également essayé de définir l'enregistrement ns testing.example.com du compte principal sur celui spécifié dans le compte enfant (1). Hélas, ce n'est pas quelque chose que j'ai fait auparavant et les recherches Google ne retournent rien.

1) J'ai foiré ça, et c'est la réponse. Voir ci-dessous.

Comment dire au compte principal de pousser les demandes .testing.example.comvers le compte enfant.

Les demandes sont référencées, pas poussées, mais vous pouvez obtenir le résultat souhaité en déléguant le sous-domaine à un ensemble de serveurs Route 53 différent de ceux qui hébergent la zone parent.

Regardez la nouvelle zone hébergée que vous avez créée pour testing.example.com. Cela peut être dans le même compte AWS, un autre compte AWS ... n'importe quel compte AWS. Il n'y a rien ici qui soit lié au "compte". Cela utilise la configuration DNS standard. L'ensemble du DNS est une hiérarchie. La racine globale peut vous dire où trouver com, et les comserveurs peuvent vous dire où trouver example.com, et ce n'est pas très différent pour example.comvous dire où trouver testing.example.comau lieu de vous donner une réponse directe.

Notez les 4 serveurs de noms que Route 53 a attribués à la zone hébergée testing.example.com. Vérifiez qu'ils sont tous différents de ceux attribués à la zone hébergée example.com. (Pour que l'un d'eux soit le même, cela devrait être impossible, mais vérifiez cela.)

Maintenant, de retour dans la zone example.com, créez un nouvel enregistrement de ressource, avec le nom d'hôte testing, en utilisant le type d'enregistrement NS, et entrez les 4 serveurs de noms auxquels Route 53 a été affecté testing.example.com, dans la zone ci-dessous.

Désormais, lorsqu'une demande de testing.example.com et de tout élément inférieur arrive sur l'un des serveurs Route 53 gérant example.com, la réponse ne sera pas la réponse de testing.example.com - la réponse fournira au demandeur les 4 enregistrements NS associés à testing.example.com et une réponse équivalente à "Je ne sais pas, mais essayez de demander à l'un de ces gars."

C'est comme ça que c'est fait.

Je pense que vous devez créer un testing.example.comenregistrement dans le compte principal (parent) sous example.comdomaine. Et si vous utilisez ELB, copiez le point de terminaison ELB pour testingle compte enfant ou une adresse IP publique peut être attribuée pour le testingdomaine dans votre compte enfant et mettez-la à jour dans la route 53 du compte parent. IP élastique. Vous devez également créer tous les sous-domaines du testingcompte parent. Je suggère d'utiliser des points de terminaison ELB dans le compte enfant pour tous les sous-domaines du testingsite. Veuillez vous assurer que tous les points de terminaison ELB doivent avoir un schéma comme internet-facingdans la console aws.