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

[ForumBot]

J’ai deux comptes AWS. Le compte principal avec example.com comme zone hébergée, qui possède ensuite un certain nombre d’enregistrements (par exemple api.example.com et kibana.example.com).

Un second compte va gérer testing.example.com comme zone hébergée, avec le même ensemble d’enregistrements (par exemple api.testing.example.com et kibana.testing.example.com).

Comment puis-je indiquer au compte principal de rediriger les requêtes pour .testing.example.com vers le compte enfant ?

Je ne veux pas modifier le compte principal car je souhaite utiliser les mêmes templates Cloud Formation dans les environnements « Live » et « Test ».

J’ai configuré les deux comme décrit ci-dessus et cela ne fonctionne pas (api.testing.example.com ne se résout pas). J’ai aussi essayé de définir l’enregistrement NS de testing.example.com dans le compte principal vers celui spécifié dans le compte enfant(1). Hélas, c’est quelque chose que je n’avais jamais fait auparavant et les recherches Google ne retournent rien.

1. J’ai fait une erreur à ce niveau, et c’est en fait la réponse. Voir ci-dessous.

[ayi]

Comment puis-je indiquer au compte principal de rediriger les requêtes pour .testing.example.com vers le compte enfant ?

Les requêtes sont référé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 par rapport à ceux qui hébergent la zone parente.

Examinez la nouvelle zone hébergée que vous avez créée pour testing.example.com. Elle peut être dans le même compte AWS, un compte AWS différent… n’importe quel compte AWS. Il n’y a rien ici qui soit lié au « compte ». Cela utilise une configuration DNS standard. L’ensemble du DNS est une hiérarchie. La racine globale peut vous indiquer où trouver com, et les serveurs com peuvent vous indiquer où trouver example.com, et il n’y a rien de fondamentalement différent pour que example.com vous indique 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. (Qu’ils soient identiques devrait être impossible, mais vérifiez-le quand même.)

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 saisissez les 4 serveurs de noms que Route 53 a attribués à testing.example.com, dans le champ ci-dessous.

Désormais, lorsqu’une requête pour testing.example.com et tout ce qui se trouve en dessous 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 ceux-ci ».

C’est comme cela que ça fonctionne.