Différents comptes AWS peuvent-ils gérer différents sous-domaines?
J'ai deux comptes AWS. Le compte principal avec example.com en tant que zone hébergée, celle-ci comporte alors un certain nombre de jeux d'enregistrements (c'est-à-dire api.example.com et kibana.example.com).
Un deuxième compte gérera testing.example.com en tant que zone hébergée, avec le même jeu d'enregistrements (c'est-à-dire api.testing.example.com et kibana.testing.example.com).
Comment dire au compte principal de renvoyer les demandes de .testing.example.com jusqu'au compte enfant. Je ne veux pas changer le compte principal car je veux utiliser les mêmes modèles de formation cloud dans les deux 'Live' et 'Test'.
J'ai configuré les deux comme ci-dessus et cela ne fonctionne pas (api.testing.example.com ne résout pas). J'ai également essayé de définir l'enregistrement ns testing.example.com dans le 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 d'envoyer des demandes Push pour
.testing.example.comjusqu'au 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 différent de serveurs Route 53 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 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 serveurs com peuvent vous dire où trouver example.com, et ce n'est pas très différent pour example.com pour vous dire où trouver testing.example.com au 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 que Route 53 a attribués à testing.example.com, dans l'encadré ci-dessous.
Maintenant, lorsqu'une demande de testing.example.com et de tout ce qui se trouve en dessous arrive sur l'un des serveurs Route 53 gérant example.com, la réponse sera pas la réponse de testing.example.com - la réponse fournira au demandeur les 4 NS enregistrements associés à testing.example.com et une réponse équivalente à "Je ne sais pas, mais essayez de demander à l'un de ces types."
C'est comme ça que c'est fait.
Je pense que vous devez créer testing.example.com enregistrement dans le compte principal (parent) sous example.com domaine. Et si vous utilisez ELB, copiez le point de terminaison ELB pour testing du compte enfant ou une IP publique peut être attribuée pour le domaine testing dans votre compte enfant et mettez-la à jour dans la route 53 du compte parent. Je pense que ELB le point de terminaison permettrait de résoudre facilement l'adresse plutôt que d'utiliser une adresse IP Elastic dédiée. Vous devez également créer tous les sous-domaines de testing dans le compte parent. Je suggère d'utiliser les points de terminaison ELB dans le compte enfant pour tous les sous-domaines du site testing. Veuillez vous assurer que tous les points de terminaison ELB doivent avoir un schéma comme internet-facing dans la console aws.